Moving a website without losing anything

Migrations have a reputation for being risky, and the reputation is deserved. What is misleading is where the risk actually sits.

Moving files and a database between two servers is mechanical and rarely goes wrong. What goes wrong is everything else that was quietly attached to the old environment and never documented anywhere.

Start with an inventory, not a copy

Before anything moves, write down what exists. Not just the website. This step takes an hour and prevents most of the bad outcomes.

• Every domain and subdomain on the account, including ones nobody remembers buying
• Where email actually lives, which is frequently not where the website lives
• SSL certificates, who issued them, and when they renew
• Cron jobs and scheduled tasks: nightly imports, feeds, backups, syncs
• Databases, including ones used by something other than the main site
• Third party services allowlisted by IP address: payment gateways, APIs, partner systems
• FTP and SFTP accounts, and who has them
• Redirect rules already in place in server configuration
• Anything running on a non-standard port or path that's not part of the CMS

Treat email as a separate project

This is the single most common way a migration causes real damage, and it's entirely avoidable.

Email and websites share a domain name and nothing else. The MX records that route mail are independent of the A records that point at the website. If your email is with a provider and you move nameservers to a new host without recreating the mail records, delivery starts failing as the old records drop out of resolver caches. It happens unevenly, over hours, which is exactly why it gets noticed late.

Some senders queue and retry for a day or two; some bounce. The quieter and worse case is a host that creates its own mail records for the domain by default: the new server then accepts your mail perfectly happily and files it into a mailbox nobody is watching.

Before touching DNS, record every mail-related record: MX, SPF, DKIM selectors, DMARC, and any verification records. If mail is moving too, that's a separate migration with its own plan, its own rehearsal and its own cutover.

Build on the new host first

The site should be fully working on the new server, reachable privately, and tested before anything public changes. Check the pages that matter, forms, logins, search, and for a store, an actual test transaction.

Make sure the staging copy isn't indexable while you do this. A staging site that gets crawled creates duplicate content and occasionally outranks the site it was copied from, which is an unusually annoying problem to fix.

DNS and the cutover

Lower the TTL on the records you're changing well in advance, and check what it's currently set to first. TTL tells resolvers how long to cache a record, and a new lower value only reaches everybody once the old one has expired. So a record on a 24 hour TTL needs 24 hours; a record on a week-long TTL, which older registrar defaults still produce, needs a week. Lower it to a few minutes and both the switch and the rollback become fast.

The sequence that works:

1. Lower TTLs, at least one full current-TTL period ahead.
2. Have a valid certificate ready on the new server before DNS moves, otherwise there's a window where every visitor gets a security warning. Worth confirming how, because the usual automated method validates by fetching a file over HTTP at your domain, which still resolves to the old server. Pre-issuing therefore means DNS-based validation, importing the existing certificate, or the new host staging one for you.
3. Sync content and database one last time at a quiet hour, immediately before you switch, so nothing created in between is stranded on the old server.
4. For a store or an application, freeze new orders or submissions for the few minutes of the final sync.
5. Change the DNS records.
6. Watch. Both servers stay running, so an early rollback is a DNS change rather than a restore. That stops being true once real orders and form submissions have landed on the new server: those don't travel back with the DNS, so after the first live hours a rollback means reconciling data as well.

Redirects, if the URLs are changing

Host to host moves usually keep URLs identical and need no redirects. Platform migrations almost always change them, and that's where traffic gets lost.

Build the redirect map before the migration, not after. Export the existing URLs, including the ones that receive traffic and links rather than only the ones in the menu, and map each to its new destination. Redirect to the specific equivalent page. A site full of redirects to the homepage is only marginally better than a site full of missing pages.

Redirect planning

Afterward, verify rather than assume

• Forms submit, and the notification email actually arrives
• Logins work, including any single sign-on or third party authentication
• For a store, place a real test order end to end including the confirmation
• Scheduled tasks are running on the new server, verified by seeing one complete
• SSL is valid, and there's no mixed content warning
• Redirects resolve in one hop, with no chains and no loops
• The staging or old site is no longer indexable
• Analytics is still collecting, and Search Console is verified for the new setup
• Third party services that allowlist by IP have been updated

Don't delete the old environment

Keep it intact and paid for a while after the move. It costs very little and it's the difference between a small inconvenience and a serious problem when somebody discovers in three weeks that a directory of files nobody inventoried was still being used.

A month is reasonable. A quarter isn't excessive if the site is complicated.

When not to move at all

If the reason for moving is that the site is slow, establish first whether the site or the server is responsible. Moving a slow site to a new host produces a slow site on a new host, and you'll have spent money to arrive in the same place.

Migration is a good answer to unreliable hosting, a host that won't give you access to your own logs, a platform that no longer fits, or a supplier relationship that has broken down. It's a poor answer to an application problem.