Published May 20, 2026 · 7 min read · Workflow and process
Migrations have a bad reputation for a reason - done carelessly, they mean a few hours of a client's site being down, emails bouncing, or a "temporarily unavailable" screen right when a customer was trying to check out. None of that is actually necessary. A migration done in the right order, with the right safety nets, can be completely invisible to the people using the site.
Almost all migration downtime comes from doing things in the wrong order - pointing DNS at the new server before the site is actually ready there, or shutting down the old server before confirming the new one works. The fix isn't a fancier tool, it's a sequence: get everything running and verified on the new server first, and only then switch traffic over.
Set up the new site on the destination server - matching PHP version, extensions and any custom configuration - then copy the files and export/import the database. At this point the new copy is live on its own temporary address, but nothing public points to it yet, so there's no rush and no risk to the client's actual traffic.
Use a local hosts file entry (or a staging subdomain) to preview the migrated site exactly as it will look once DNS switches over. Check forms, logins, checkout flows, and anything involving email - these are the parts that most often reveal a missed configuration setting before it becomes a client-facing problem.
DNS records are cached for a length of time set by the TTL (time to live) value - often an hour or more by default. Lowering it to a few minutes at least 24 hours before the switch means that when you do update the record, visitors around the world pick up the change almost immediately, instead of some of them still hitting the old server for hours afterward.
Update the DNS record to point at the new server, then check the live site from a few different networks or a DNS propagation checker - not just your own browser, which may have the old address cached locally regardless of the TTL. Keep the old server running and untouched during this window in case anything needs a quick rollback.
Once traffic, forms and email are confirmed working on the new server for at least 24-48 hours, it's safe to decommission the old one. This is also the right moment to set up fresh automatic backups on the new server - a surprising number of agencies migrate a site successfully and forget to re-enable the safety net that protects it afterward.
Doing this by hand for a handful of sites is manageable. Doing it for thirty client website hosting accounts by hand is how migrations turn into a weekend nobody wanted. A hosting control panel for agencies that can duplicate a site to a new server with its configuration intact turns most of these steps into a background task instead of a manual checklist.
Copy a client site to a new server with its database, PHP version and backups intact.
Get Started Free