Website Migration: What Actually Breaks, and the Order to Do It In

Most website migrations that go badly go badly in exactly one way: the content moved fine and the URLs did not, and three weeks later somebody notices organic traffic fell off a cliff and nobody can say precisely when.

Agencies sell migration as a service, and for a large site with a CMS change it is genuinely worth paying for. For a straightforward host-to-host move it is a sequence you can run yourself, provided you run it in the right order. The order is the whole trick — most of the damage in a bad migration comes from doing the right steps at the wrong time.

Table of contents

• The four kinds of migration, because they have different risks
• Before you touch anything: inventory
• The redirect map is the migration
• Staging, cutover, and the DNS sequence
• After: the part everyone skips
• How this fits the rest of the stack
• FAQ

The four kinds of migration, because they have different risks

People say migration to mean four different things, and conflating them is why generic advice is unhelpful.

• Host migration. Same site, same URLs, new server. Lowest risk. The main hazards are DNS cutover and something in the environment differing from the old one.
• Platform or CMS migration. New software, content re-imported, URLs likely change. Highest risk, because URL structure almost always shifts and the redirect map is the entire game.
• Domain migration. Same site, new name. Moderate risk, entirely about redirects and telling search engines the move was deliberate.
• Restructure. Same domain, same platform, new URL scheme. Sneaky risk, because it does not feel like a migration and gets done without a redirect map.

A host migration can be done in an evening. A platform migration with a restructure is a project. Know which one you are doing before you start, because the difference is a factor of ten in effort and risk.

The rest of this assumes the risky case and scales down cleanly if yours is simpler.

Before you touch anything: inventory

You cannot verify a migration you did not measure first. Do this while the old site is still live and healthy.

1. Crawl the existing site and export every URL that returns 200. This is the definitive list of what must still work afterwards.
2. Export your top pages by traffic and by inbound links from analytics and search console. These are the URLs where a mistake is expensive, and they get verified individually.
3. Record current performance and status codes for a sample of pages, so you can tell afterwards whether something got slower.
4. List every external dependency — payment providers, embedded services, webhooks, anything with your domain or IP in an allowlist elsewhere.
5. Take a full backup and restore it somewhere. A backup you have not restored is a guess.

The crawl is the single most valuable artefact. It converts did the migration work from an opinion into a list you can check.

Also note your current DNS TTLs now, because the next step depends on them.

The redirect map is the migration

If URLs change, every old URL needs a permanent redirect to its closest equivalent. Not to the homepage — to the actual matching page. Redirecting everything to the homepage is functionally identical to deleting the site as far as search engines are concerned, and it is the single most common serious migration error.

Build it as a spreadsheet: old URL, new URL, one row per page from your crawl. For a site with a systematic structure change, most rows are generated by a pattern and only the exceptions are manual. For a genuinely restructured site, expect real manual work — and expect it to be worth it.

Rules that matter:

• Use 301 (permanent), not 302. A 302 tells search engines the old URL is coming back and the new one should not inherit anything.
• Redirect in one hop. A chain of old to intermediate to new loses value at each step and adds latency for every visitor.
• Do not redirect to a page that itself redirects. Test the map for chains before cutover, not after.
• Keep the redirects in place indefinitely. Old links exist forever; a redirect you remove after six months is a link you broke.

Where the redirects live depends on the platform — server config, a redirects file in a static build, or platform rules. What matters is that they are in version control alongside everything else, not hand-edited on a server where the next deploy overwrites them.

Staging, cutover, and the DNS sequence

Build the new site on a temporary hostname first, and make sure that hostname is not indexable — a noindex header or a robots rule, verified by actually requesting the page and reading the response. A staging site that gets indexed competes with the real one, and cleaning that up is worse than the migration.

Verify on staging: pages render, forms submit, logins work, checkout completes, the redirect map resolves correctly, and the certificate is valid. Walk the top-traffic list by hand. Automated crawls miss things that only break when a human clicks.

Then the cutover, which is a sequence with a wait in it:

1. Lower the DNS TTL on the records you will change — to five minutes or so — and wait for the old TTL to expire. This is why you noted the TTLs earlier. Do this a day ahead, not an hour.
2. Sync content one final time, so anything published since the staging copy is included.
3. Change the DNS records to the new host.
4. Watch both hosts. Traffic drains from the old one over minutes to hours as caches expire.
5. Keep the old host running for at least a week. Some resolvers ignore TTLs and some visitors have stale entries; a live old host serving correctly is much better than a connection refused.
6. Raise the TTL back once you are confident.

The reason to keep the old host alive is that it converts a possible outage into a slow drain. It is cheap insurance for a week.

After: the part everyone skips

The migration is not finished at cutover. It is finished when you have verified it, and verification takes a couple of weeks of attention.

• Re-crawl and compare against the original inventory. Every URL that returned 200 before should now return 200 or redirect in one hop to something that does. Any 404 in that comparison is a bug.
• Submit the new sitemap and watch the coverage report for crawl errors. Expect some churn; watch for a trend that does not recover.
• Verify certificates and mail. If MX records moved, send and receive test mail in both directions. If they did not move, confirm you did not overwrite them while editing the zone — this is a distressingly common way to lose a company’s email for a day.
• Watch performance and error rates for a fortnight. New environment, new resource limits, new failure modes.
• Watch organic traffic against the same weeks last year rather than last month, so seasonality does not fool you either way.

A well-executed migration typically shows a small dip that recovers within a few weeks. A dip that keeps going down is a redirect problem, and the sooner you go back to the map the cheaper it is to fix.

How this fits the rest of the stack

Part of choosing where to migrate is knowing what the destination costs once it is carrying real traffic rather than a staging copy. The RunxBuild hosting calculator breaks it into the service, the database, the storage and the bandwidth so the comparison against your current bill is like for like. On RunxBuild the pieces this post depends on are first-class: redirects and headers are configuration in the repository rather than server files, deploys keep a history you can roll back in one action, and custom domains and certificates are handled at deploy time.

Useful related references:

• Cloud Migration Tools: The Major Providers’ Native Services
• What Is a Static Website? Benefits, Examples, Hosting
• Deploy an Astro Website for Free
• Services on RunxBuild

FAQ

Will migrating my website hurt SEO?

Only if URLs change without a complete redirect map. A host migration that keeps URLs identical should have no SEO impact at all. A platform migration that changes URL structure depends entirely on whether every old URL 301-redirects in one hop to its closest equivalent.

How long does a website migration take?

A host-to-host move with unchanged URLs is an evening plus a week of watching. A platform migration with a URL restructure is a project measured in weeks, and most of that time goes into building and testing the redirect map rather than moving content.

Should I redirect old URLs to the homepage?

No. This is the most common serious migration mistake. Search engines treat a mass redirect to the homepage as equivalent to deleting those pages, and visitors following an old link land somewhere that does not answer their question. Redirect each URL to its closest actual equivalent.

How do I migrate without downtime?

Lower the DNS TTL a day in advance and wait out the old TTL, build and verify on a staging hostname, do a final content sync, then change the records. Keep the old host running and serving correctly for at least a week afterwards so visitors with cached DNS still reach a working site.

Do I need a professional website migration service?

For a large site, a CMS change, or an e-commerce site with transactions in flight, paying for it is usually cheaper than the mistakes. For a straightforward host move with unchanged URLs, the sequence above is manageable in-house — the risk is in the redirect map, not the file transfer.