Migrations and replatforming
Move the site without handing your rankings to a competitor.
A migration is the single riskiest thing most sites do, and the damage is nearly always avoidable. Redirects that were never mapped, canonicals left pointing at the old URLs, content that quietly changed in the move. We plan the migration, implement it, and verify it on the live site, so the rankings survive the launch.
Straight answer
Migrations do not lose rankings by bad luck.
They lose rankings because the move was treated as a launch date rather than a project with a redirect map, a continuity check, and someone watching the logs afterwards. Every common failure below is preventable.
How the traffic usually disappears
- Redirects never mapped, mapped to the wrong page, or chained three deep
- Canonicals left pointing at the old URLs after launch
- Internal links still aimed at pages that now 301
- A noindex or robots rule carried over from staging
- Content that changed in the move so the page no longer matches its intent
How it should be handled
- A full redirect map built from the old URL set, not a sample
- Canonicals, hreflang and internal links updated to the new structure
- A parity check on content, metadata and structured data both sides
- Staging rules confirmed gone before the switch, not after
- Log and Search Console monitoring through the settling window
Said plainly
The people who plan the migration are the people who execute and verify it. Nothing gets lost in a handover to a developer who was not in the room when the risks were listed. If your own team is implementing, you get a redirect map and a checklist they can act on, and we verify what actually went live rather than trusting it matched the plan.
Scope
What a migration actually involves.
Any change to URLs, hosting, CMS, domain, HTTPS, structure or rendering is a migration, because any of them can drop the signals Google has attached to your pages. Here is what protecting them looks like.
Redirect mapping
Every old URL mapped to its closest new equivalent, from the full URL set rather than a sample, with a rule for the ones that have no exact match. One to one where possible, never a blanket redirect to the homepage, and no chains that dilute the signal on the way through.
Canonical and hreflang continuity
Canonicals repointed to the new URLs, and hreflang clusters kept intact if you run more than one language or region. These are the tags most often left aimed at the old site, which quietly tells Google the migration never happened.
Internal link repair
Internal links updated to point straight at the new URLs rather than hopping through a redirect. Left unfixed, every internal link becomes a small tax on crawl and on the signal reaching the page, and the navigation is usually the worst offender.
Content and metadata parity
A check that the page which ranked still says what it said. Titles, headings, body content and structured data compared old against new, so a redesign does not silently strip the very content the ranking depended on.
Staging and index controls
The noindex tags, robots rules and password walls that protect a staging site are the ones that tank a launch when they survive it. We confirm they are gone before the switch, and that the new site is actually crawlable, not after the traffic has already dropped.
Post launch monitoring
Search Console, the server logs and rankings watched through the settling window. The redirect that got missed usually surfaces a week or two later, not on launch day, so success is verified over time rather than declared at go live.
Which kind
The migrations we take on.
Different moves carry different risks. The redirect map matters most on a URL change, rendering matters most on a replatform, and parity matters most on a redesign.
Replatform or CMS change
WordPress to headless, one CMS to another, or a rebuild on the same platform. The URL structure usually changes and the rendering often does too, so the redirect map and a check on what a crawler sees both matter.
Redesign with URL changes
A visual refresh that also changes URL patterns or removes pages. The trap here is content parity: the new template looks better and says less, and the ranking followed the words that got cut.
Domain change or HTTPS
A rebrand, a domain move, or an overdue move to HTTPS. Mechanically simple, brutal when the redirect map is incomplete, and worth doing with the Search Console change of address handled properly.
Site merge or consolidation
Two sites becoming one, or subdomains folding into subfolders. The hardest kind, because two URL sets have to map into one without cannibalising, and duplicate content has to be resolved rather than redirected blindly.
Docs and subdomain moves
Moving documentation, a help centre or a blog between a subdomain and a subfolder. Often the right call for SEO, always a migration, so it gets a redirect map and a parity check like any other.
Recovery after a bad migration
If the move already happened and traffic dropped, the first job is finding what changed and which of the loss is technical rather than real. Most post migration drops trace to an incomplete redirect map, and those are fixable.
How it runs
Before, during, and after the switch.
Before
We capture the current state: the full URL set, current rankings and the pages that earn them, the redirect map, and a parity baseline for content and structured data. This is the work that decides whether the migration is safe, and it happens before anything moves.
Planned and agreed firstDuring
Redirects, canonicals and internal links go live to the new structure, staging rules are confirmed removed, and the new site is checked as crawlable before the old one is retired. Implemented by us or handed to your developers as a checklist we then verify.
Verified at launchAfter
Search Console, logs and rankings monitored through the settling window, with the misses caught and fixed as they surface rather than assumed away. Before and after evidence, and a rollback path tested in advance for anything reversible.
Watched, not assumedCost
What it costs.
Migration work is technical SEO, billed at £90 to £110 an hour, or a £95 blended rate where it crosses into development. Most migrations are scoped as a fixed project once we have seen the size of the URL set. Minimum engagement is 4 hours.
Migration plan
From £900
The redirect map, the parity baseline and the launch checklist for your team to implement. The right choice if your developers are doing the work and want a plan they can execute and be checked against.
Planned and implemented
Scoped
The full job, planned and executed by us, from the redirect map through to post launch monitoring. Fixed scope and cost agreed in writing once we have seen the URL set and the platform.
Recovery
From £900
A diagnosis of a migration that already went wrong: what changed, what was lost, and which of it is technical rather than real. You get the honest split before any recovery work is quoted.
Time is logged as it is spent and the ledger is open to you, including anything scrapped or reverted. Full breakdown on the rates page.
FAQ
Questions clients actually ask
What counts as a migration?
More than a replatform. Any change to URLs, hosting, CMS, domain, HTTPS, site structure or rendering is a migration in SEO terms, because any of them can drop the signals Google has attached to your pages. A design refresh that changes URL patterns is a migration. Merging two sites is a migration. Moving docs from a subdomain to a subfolder is a migration.
If you are not sure whether what you are planning counts, send it over. The answer is usually yes, and the cheapest time to find out is before it ships.
How do migrations lose rankings?
Almost always through broken continuity rather than anything exotic. Redirects that were never mapped, or mapped to the wrong target, or chained three deep. Canonicals left pointing at the old URLs. Internal links still aimed at pages that now 301. Content that quietly changed in the move so the new page no longer matches the intent it ranked for. A robots file or noindex tag carried over from staging.
None of these are hard to prevent. They are missed because the migration is treated as a launch date rather than a project with a parity check on both sides of it.
Can you do the migration itself, or only advise?
Both, and it is the point. We build the redirect map, we can implement the redirects, we set the canonicals, we fix the internal links, and we verify the result on the live site. The people who plan the migration are the people who execute it, so nothing gets lost in a handover to a developer who was not in the room when the risks were listed.
If your own developers are doing the implementation, we hand them a redirect map and a checklist they can act on, then verify what went live rather than trusting that it matched the plan.
We already migrated and traffic dropped. Can you recover it?
Often, if you move quickly. The first job is a diagnosis: what changed, which URLs lost their rankings, whether the redirects are correct, whether canonicals and internal links survived, and whether the new pages still match the intent. Most post migration drops trace back to a redirect map that was incomplete or wrong, and those are fixable.
What we cannot promise is full recovery, because if the content genuinely changed or pages were removed, some of the loss is real rather than technical. We will tell you which part is which before you spend anything.
How long before rankings settle after a migration?
Days to weeks for a clean same content migration, longer if the structure or the content changed materially. Google has to recrawl, follow the redirects, and reassign the signals. We keep monitoring through that window rather than declaring success on launch day, because the problems that matter often show up a week or two later when a missed redirect surfaces in the logs.
Keep reading
Related services
Book me
Tell us what you are planning to move.
A replatform, a redesign, a domain change or a merge. Send the current site and what it is becoming, and we will tell you where the ranking risk is and how it gets protected, before anything ships.