Development
Migrations go wrong when somebody skips a step. The checklist we work through, in order, so you keep your rankings and your enquiries.
Most of the horror stories about website migrations come from the same cause: somebody changed the site and the addresses at the same time, without a list. Traffic falls off a cliff, nobody can say exactly what changed, and unpicking it takes longer than the build did.
A migration is not difficult. It is just unforgiving of skipped steps. This is the checklist we work through, in order.
People use one word for five different jobs, and the risk is wildly different between them.
| Type | What changes | Risk to rankings |
|---|---|---|
| New host, same site | Where the files sit | Very low |
| New design, same URLs | How it looks | Low to moderate |
| New platform | What runs the site, often the URLs too | Moderate to high |
| New URL structure | Every address on the site | High. This is where sites get hurt |
| New domain | The address itself | Highest |
Change one at a time where you can. Redesign and keep the URLs, launch, confirm it is stable, then change addresses if you still need to. Doing both at once means that if traffic drops you cannot tell which one caused it. We cover the rankings side of that in will a redesign hurt your Google rankings?
You cannot tell whether a migration went well without a before. Capture it while the old site is still up.
Not the automatic one you assume exists. Take a real backup of files and database, put it somewhere off the server, and confirm you could restore it. Our guide to backing up a WordPress site covers doing that properly.
This is the single most important artefact in a migration. Every old URL needs to point at its closest new equivalent, as a permanent 301 redirect.
Do not move the domain the same day you launch the site. See how to transfer a domain name, and while you are in the registrar, check the renewal date and whose name it is in.
In rough order of how often we see it.
| Mistake | What it costs |
|---|---|
| Noindex left on at launch | Total disappearance from search until someone notices |
| No redirects, or all to the homepage | Every ranking page starts from nothing |
| Titles and descriptions not carried over | Rankings and click-through both drop |
| Forms not tested | Enquiries silently stop, sometimes for weeks |
| Internal links still pointing at old URLs | Every click goes through a redirect it should not need |
| Changing design and URLs together | You cannot diagnose the drop |
| No before data | You cannot prove it went well or badly |
You will be told to allow up to 24 hours for changes to take effect. That figure is mostly cover. In practice new visitors usually see the new site within minutes.
What confuses people is that the owner is often the last to see it, because their own phone and browser still hold the old address in memory. If the site looks unchanged to you an hour later, check it on mobile data or on somebody else’s phone before assuming something has failed.
Before: record current URLs, rankings, traffic and enquiries. Full tested backup. Redirect map written. Titles, descriptions, alt text and structured data carried across. Domain and hosting handled separately.
Launch: quiet time. Remove noindex. Redirects on and spot checked. Certificate valid. Sitemap submitted. Forms tested from a phone. Analytics firing.
After: watch coverage daily. Fix every 404. Check speed. Expect a dip. Wait a month before concluding anything.
This is the order we actually work in, and the warnings are things we have either done ourselves or been called in to unpick afterwards.
The DNS section is the one we would underline. It comes from watching owners panic on launch day because their own phone still showed the old site while everyone else could already see the new one. Nothing had failed. Their browser was holding the old address in memory.
The point about redirects being the whole job comes from taking over sites where nobody wrote a redirect map, and the point about staging blocks travelling to live comes from it being the single most common launch fault we see, including on sites built by other people.
None of it is clever. It is just a list, and migrations go wrong when there isn’t one.
If you are moving a site and would rather not carry the risk yourself, it is the kind of job we do regularly, including moving shops between platforms with the addresses and rankings kept intact. Tell us what you are moving and we will tell you what is involved. Worth running the website audit checklist over the old site first as well, because a migration is a good moment to stop carrying problems across.
An ordered list of what to record, carry across and test when a website changes host, design, platform, URL structure or domain. The essentials are a full tested backup, a redirect map from every old URL to its closest new equivalent, carrying titles, descriptions and alt text across, removing the staging noindex at launch, and watching Search Console daily afterwards.
It depends entirely on which kind of migration it is. Moving host with the same site is very low risk. Changing URL structure or domain is high risk and is where sites get hurt. A dip in the first two to four weeks is normal while Google recrawls. Change one thing at a time where you can, because if you redesign and change addresses together you cannot tell which caused a drop.
Leaving the noindex tag on at launch. Staging sites block search engines, and if that block travels to live the site disappears from search entirely until somebody notices. Check it before anything else on launch day. The next most common are missing redirects, or redirecting every old page to the homepage, which Google treats as a soft 404.
Yes, if any URL changes. Every old address needs a permanent 301 redirect to its closest genuine equivalent, not to the homepage. Avoid chains where A points to B which points to C, and keep the redirect map afterwards, because you will need it when something looks wrong weeks later.
You will be told up to 24 hours, but that figure is mostly cover. New visitors usually see the new site within minutes. The owner is often the last to see it because their own phone and browser still hold the old address in memory, so check on mobile data or somebody else's phone before assuming something has failed.
About a month, unless something is plainly broken. Watch Search Console coverage daily and fix every 404 that appears, but resist changing things in response to normal ranking movement. Without before data on rankings, traffic and enquiries you cannot tell whether it went well anyway, which is why recording that first matters.
Free quote
Tell us what you do and we will come back with clear, honest next steps.
Shopify or WooCommerce? UK plan prices, card fees worked out at two sales volumes, upkeep, flexibility and ownership, in plain English.
Paul Fletcher · 19 Oct 2026
A customer says their card payment failed, but nothing is wrong with your shop. What 3D Secure is, why the check fails,…
Paul Fletcher · 2 Oct 2026
An ecommerce website costs about £3,000 to £15,000 plus transaction fees. What drives the price, the costs people miss, and whether you…
David Ellis · 19 Oct 2026
