A hosting migration is really three separate migrations happening together — files, databases, and DNS/email configuration — and most migration problems trace back to one of those three being handled incompletely rather than to anything exotic. This checklist is organized around the sequence that avoids the common failure points, not just a list of tasks in no particular order.

Before you start: what a migration actually involves

Moving a site to new hosting means copying its files and database(s) to the new server, confirming it runs correctly there, and then redirecting the domain's DNS so visitors and mail actually reach the new location instead of the old one. The part that causes the most real-world trouble isn't the copying itself — it's the handoff: DNS doesn't switch instantly for every visitor at once, so there's a window where the old and new servers both need to be considered live, and anything that only exists on one of them (a newly submitted form, an email that arrives mid-transition) can be missed if that window isn't planned for.

Pre-migration checklist

  • Full backup of the current site — files and database, confirmed restorable, before touching anything. See How Website Backups Work if it's not already clear what a complete backup needs to include.
  • A complete inventory, not just the obvious files — every database in use, all email accounts and their current settings, any scheduled cron jobs, SSL certificate details, and any third-party integrations with hardcoded references to the old server's IP address.
  • Lower the domain's DNS TTL in advance — ideally at least 24-48 hours before the planned cutover. See DNS TTL Explained for why this specific step matters: a long TTL set at the moment of cutover means some resolvers keep using the old server's address long after the new one is actually ready, which is precisely the scenario a pre-lowered TTL avoids.
  • Confirm the new hosting environment's specifications actually match what the current site needs — see Shared Hosting vs. VPS vs. Dedicated Servers if the migration is also a tier change, not just a provider change.

Migration day: copying and testing before cutover

Copy files and export/import databases to the new server, then test the site there before any DNS change happens at all — this is the step that gets skipped under time pressure and is exactly the step that catches a broken configuration before visitors ever see it. Testing before DNS points anywhere new is done with a temporary local override (editing the operating system's hosts file to point the domain at the new server's IP just for the testing machine) rather than waiting for DNS to actually propagate — this lets the new environment be fully exercised, including checking that the database connected correctly and the site isn't throwing errors, while the live site visitors see is still untouched on the old server.

Cutover: switching DNS

With the new server tested and confirmed working, update the domain's DNS records to point to it. Because of the lowered TTL set in advance, this should propagate to most resolvers within the TTL window rather than taking an unpredictable, much longer time. Keep the old server running and unchanged, not decommissioned, until DNS has had time to fully propagate — during that window some visitors will still reach the old server, so anything accepting new data (form submissions, new orders on a store, new user registrations) needs a plan for either staying fully functional on the old server during this window or being paused briefly, rather than silently losing anything submitted to the server that's about to be retired.

Post-migration checklist

  • Confirm email is still working correctly — both sending and receiving, from the new server. Mail routing is configured separately from web traffic and is a specific, common point where a migration quietly breaks something that isn't obvious from checking the website alone; see Why Business Emails Go to Spam if deliverability issues show up after cutover.
  • Confirm SSL is active and valid on the new server — a certificate doesn't automatically carry over and needs to be reissued or reinstalled in most migrations.
  • Monitor the new server closely for a period after cutover — error logs, resource usage, and actual site behavior — rather than assuming a successful initial test means everything will continue running cleanly under real traffic.
  • Restore the DNS TTL to its normal value once the migration is confirmed stable — the lowered TTL served its purpose during the transition and doesn't need to stay low indefinitely.
  • Decommission the old server only after DNS has fully propagated and the new server has run cleanly for a reasonable period — not immediately at the first sign of a successful cutover.

Where migrations typically go wrong

A small number of specific mistakes account for most migration problems: not lowering TTL in advance, so cutover takes far longer to propagate than planned; not testing on the new server before pointing DNS at it, so a configuration problem is discovered by visitors instead of by the person doing the migration; forgetting email configuration entirely, since it's easy to focus on "the website" and overlook mail routing as a separate thing that also needs to move; and decommissioning the old server too early, before every resolver has actually picked up the new DNS records. Each of these is avoided by a specific step already in the checklist above — they're listed as a failure mode here because knowing what breaks, specifically, makes it clearer why each checklist step exists rather than feeling like process for its own sake.

A realistic timeline

Spread over several days rather than compressed into one, a typical migration looks roughly like: 2-3 days before cutover, lower the DNS TTL and complete the inventory and backup; 1 day before, copy files and databases to the new server and begin testing via a hosts-file override; cutover day itself, confirm testing passed, then update DNS and keep the old server fully live and unchanged; the following 24-48 hours (matched to the lowered TTL), monitor both servers and confirm traffic has fully shifted before touching the old one; after that, complete the post-migration checklist and only then consider decommissioning the old server. Compressing this into a single afternoon is where the common failures below tend to originate — rushing the TTL step in particular removes the entire safety margin the rest of the timeline depends on.

Resisting the urge to compress the timeline

A migration that follows this sequence — inventory and backup first, TTL lowered well in advance, full testing on the new server before any DNS change, a deliberate monitoring period after cutover before retiring the old server — is unlikely to cause real downtime or data loss, because every point where something commonly goes wrong has a specific step addressing it. The temptation under time pressure is to compress all of it into "copy files, change DNS, done," and that compressed version is precisely what produces the email outage or the lost form submissions this checklist exists to avoid. If the migration also involves changing registrar or domain ownership details rather than just hosting, review Domain Transfer Explained as a related but separate process with its own timing considerations.