Introduction

A hosting migration can look successful for a few minutes or a few hours before the new site starts reverting to old content. In many cases the real problem is not cache or deploy failure. The old server is still running a scheduled sync, mirror, backup restore, or file-copy job that keeps pushing outdated data into the new production environment.

Treat this as a write-direction problem instead of a frontend content problem. Start by checking when the site reverts and whether that timing matches a cron job, rsync task, control panel sync, or automation script, because repeated overwrites usually come from legacy jobs that were left active during the migration overlap.

Symptoms

  • New site changes disappear and old content returns on a schedule after migration
  • File timestamps on the new server keep changing even when nobody is editing the site
  • Pages, media, or configuration revert to an older version after a backup or sync window
  • The old server still shows outbound sync, mirror, or deployment activity
  • Re-deploying the site fixes the problem only temporarily before the old state returns
  • The issue started after a migration that used temporary file sync, rsync, or mirrored publishing

Common Causes

  • A cron job or scheduled task on the old server still pushes files to the new site
  • An rsync, mirror, or deployment script still treats the old server as the source of truth
  • A backup restore or automated publish task runs against the new production path
  • Bidirectional sync was left enabled during cutover and one side is still overwriting the other
  • The migration team kept the old sync job temporarily and never disabled it afterward
  • Troubleshooting focused on cache or deploy symptoms instead of background overwrite jobs

Step-by-Step Fix

  1. Record the times when the site reverts and compare them with scheduled task times, because a reliable time match is often the fastest way to identify the job doing the overwrite.
  2. Check the old server, the new server, the hosting control panel, backup tools, and any CI or deployment system for jobs that touch the production files or database, because the overwrite may come from outside the web server itself.
  3. Identify the source, destination, and write direction of each sync or restore job before disabling anything, because you need to know which automation is authoritative and which one is stale.
  4. Pause or disable the legacy outbound sync from the old server and any related restore or mirror jobs, because leaving even one active task can keep undoing the migration.
  5. Confirm that the new server is now the only intended write source for site files and, if relevant, the database or media storage, because the production authority must be clear after cutover.
  6. Review recent file timestamps, sync logs, and deployment logs on the new environment to verify that the unplanned overwrites have stopped, because the absence of new changes is part of proving the fix.
  7. Reapply the correct production content or run a clean deployment only after the old sync path is disabled, because redeploying first will usually just get overwritten again.
  8. Monitor the environment through at least one full former sync window and retest the affected pages, because scheduled overwrite problems often look fixed until the next task cycle runs.
  9. Document the final sync design and decommission legacy automation from the old server, because leftover scheduled jobs are a common way for hosting migrations to quietly revert.