Introduction

A server cutover can move the site successfully while cron jobs continue running on both the old and new server. The application may already serve traffic from the destination environment, but scheduled jobs still execute twice because the retired host was never fully removed from the task schedule.

Treat this as a duplicate-scheduler problem instead of a generic application bug. Start by checking whether the same scheduled tasks still run from both environments, because post-migration cron problems often appear as duplicate emails, repeated imports, or conflicting maintenance work rather than as obvious server errors.

Symptoms

  • Cron jobs still run on both the old and new server after cutover
  • Scheduled emails, imports, renewals, or cleanups happen twice
  • Logs show the same task executing from two different hosts
  • Data updates conflict because background work still originates from legacy infrastructure
  • The main site works from the new server, but scheduled automation still behaves unpredictably
  • The issue started after server migration, app cutover, or incomplete decommissioning of the old host

Common Causes

  • The old server still has active cron entries for migrated tasks
  • The new server was enabled before the old scheduler was disabled
  • Shared deployment or server templates recreated the same cron jobs in more than one place
  • Background workers were moved, but server-side schedulers on the old environment remained active
  • Teams validated the web cutover but skipped noninteractive scheduled execution paths
  • One task moved to the new server while related helper jobs still run on the retired host

Step-by-Step Fix

  1. Identify the exact task or symptom that appears duplicated and confirm whether it runs from both servers, because duplicate scheduling must be proven before you disable automation.
  2. Check cron configuration, scheduled task panels, and service timers on both the old and new environments, because one hidden scheduler can keep the legacy job alive after cutover.
  3. Compare execution logs, hostnames, or job output between the two servers, because duplicate work often becomes obvious only when you trace the actual runtime source.
  4. Confirm the intended post-cutover execution model for each scheduled task, because some jobs should move entirely while others may have been intentionally redesigned.
  5. Disable the old scheduler at the real control point only after confirming the new environment owns the task completely, because removing the wrong schedule can stop critical background work.
  6. Retest the affected automation and verify it now runs only once from the intended host, because eliminating one duplicate path is the real fix.
  7. Review related worker, queue, timer, or panel-based schedules on the retired server, because cron duplication often survives in more than one scheduler mechanism.
  8. Confirm the old server no longer produces task-side effects such as mail, imports, or queue processing, because backend evidence should match the new single-host design.
  9. Document which environment owns each scheduled job after recovery, because duplicate automation is easy to reintroduce during future server migrations.