How to Plan a Site Migration Without Losing Rankings
Planning is where migrations are won. The single most useful thing to understand is that the search work starts before the design work rather than after it. Most projects reverse that, which is exactly why the search consequences arrive as surprises rather than as decisions.
The Order Everybody Gets Wrong
Search input is usually sought at the end of a build project and needs to arrive at the beginning. That single inversion accounts for more migration damage than any technical fault.
What gets decided in week one. The irreversible things.
How addresses will be constructed. What the site's hierarchy will be. Which pages will exist, which will be merged and which will quietly disappear. All of that is settled before anything is designed.
What a week ten review can achieve. Very little.
Somebody handed a nearly finished site can check that redirects exist and catch obvious errors. They cannot change a structural decision without the build being redone. No project agrees to that at that stage.
Why the reversal happens. It looks logical.
Search feels like something you check, in the way you check spelling. Checking implies something finished to check. That framing puts it last, when it needed to be an input rather than a review.
What to change. One meeting, moved.
Involvement when the structure is being decided rather than when it is being implemented. That is a scheduling change rather than a budget one. It is also the highest return available on any migration.
Who Owns The Search Side
On most projects, nobody does. Not because anybody refused. It was never assigned, so everybody reasonably assumed somebody else had it.
How the gap forms. Two sensible assumptions.
The developer assumes the agency or the marketing side is handling search, since that is their subject. The agency assumes the developer is handling it, since it lives in the build. Both assumptions are reasonable and together they produce nobody.
Why it stays hidden. Nothing raises it.
An unassigned task produces no meeting, no ticket and no escalation. It simply is not on any list, which means it is never late and never flagged. It surfaces after launch, as a consequence rather than a warning.
What the owner actually does. Less than people expect.
They are not required to build anything. They make sure the audit happened, the map exists, the tests were run and somebody is watching afterwards. It is a responsibility rather than a workload.
Why this is the cheapest control available. It costs a sentence.
Naming one person, in writing, at the start, is free. It prevents most of what goes wrong in this cluster. A project unwilling to name anybody has told you something about how it will run.
What Has To Exist Before Anything Moves
Four things must be captured while the current site still exists. Each of them becomes impossible the moment the old site is replaced, which is what makes this stage different from every other.
A full crawl of the old site. The complete record.
Every address, what is on it and how the pages connect. This is what any later comparison is made against. There is no way to reconstruct it afterwards, because the moment the old site is replaced the evidence of what it contained goes with it.
A performance benchmark. The proof.
How the current site performs, recorded before anything changes. Without it, nobody can demonstrate that anything was lost or recovered. Every subsequent conversation becomes an exchange of impressions.
A complete list of addresses. Wider than the page list.
Not the pages somebody would list from memory. Everything that resolves, including parameters, filters, pagination and things nobody remembers creating. Block five explains why that distinction dominates the timeline.
A mapping. The destination for each one.
Where every old address will point afterwards. The detail is in URL mapping for a site migration. The recording stage is in site audit before migration.
How Long It Takes
There is no answer to this that survives contact with a specific project, so the useful version is what determines it. Three things do, compounding rather than adding.
The number of addresses. The dominant factor.
A site with a few dozen addresses and a site with tens of thousands are different projects wearing the same name. The address count drives the mapping, the testing and the checking afterwards. It is the first thing worth establishing before anybody estimates anything.
How many changes are happening at once. The multiplier.
A platform move alone is one exercise. A platform move with new addresses, a new design and rewritten content is four, with each interacting with the others. That is not four times the work and it is considerably more than one times it.
Whether the mapping can be automated. The variable people forget.
Where old and new addresses follow a predictable relationship, most of the map can be generated. Where they do not, it is produced by hand. That difference alone can separate two otherwise identical projects.
What to do instead of asking for a figure. Ask what it depends on.
A supplier who answers with a period before seeing the address count is guessing. One who answers with the three factors above, then asks for a crawl, is estimating. The second answer is worth considerably more.
The Mapping Is The Longest Part
On any site of size, deciding where every address goes takes longer than building the new site does. Projects underestimate it consistently, for a reason worth naming.
Why it is underestimated. It does not look like work.
A design is visible. A build is visible. A spreadsheet listing addresses and destinations is invisible, produces nothing anybody can look at and is easy to assume somebody will finish quickly.
Why it takes so long. The exceptions.
The bulk of a large site follows patterns and can be handled quickly. The remainder does not. That remainder is where the value usually sits, because the odd addresses are frequently the old ones that accumulated links.
What happens when it is rushed. Two failures.
Addresses get missed entirely, which means they stop working. Or they get mapped to something approximate rather than equivalent, which wastes the value the exercise existed to protect.
What to do about it. Start it early.
Mapping can begin as soon as the crawl exists, well before the new site is finished. Projects that leave it until the build is done have compressed the longest task into the shortest available window.
Best Time To Migrate
The right window is the quietest trading period for that business, with people available to watch what happens. Which window that is differs by business. The planning question is what has to fit inside it.
Why it is a planning constraint. The window is not the launch day.
The migration continues after launch. The window has to cover the launch, the checks in the hours afterwards and the weeks of watching that follow, which is a considerably longer period than most schedules allow for.
What that does to the plan. It fixes the end, not the start.
Working backwards from the window is more reliable than working forwards from the kickoff. The launch date is the fixed point and everything else is arranged to arrive before it.
The pressure this creates. A real one.
A project running late faces a choice between launching outside the window and delaying to the next one. Delaying is almost always correct and almost never popular, which is why the decision should be agreed in advance rather than in the moment.
Which window to choose. Covered separately.
How to identify it from a business's own trading history, plus the argument about which day of the week, are in when should you migrate a website.
Staging And Testing
The new site is built somewhere private first. Two things about that private environment matter. Both cause problems that appear only after launch.
It has to be protected. Or it becomes a duplicate.
An unprotected staging site can be found and indexed, producing a complete copy of the site at a different address. That is a problem the live site then has to compete with. It persists after launch, because the copy does not disappear when the real site arrives.
The protection has to come off. This is the classic disaster.
Whatever was used to keep the staging site private is part of the build. It travels with the build unless somebody removes it. A site launched with those protections still in place is invisible and looks entirely normal.
What testing has to cover. More than appearance.
That content survived the rebuild, that internal links point at final addresses, that the redirects match the map and that the site is not telling anything to stay away. Appearance is the easiest of these to check and the least consequential.
Where the mechanism sits. Its own guide.
How staging protection works and what it does is covered on the crawl and indexing page, which is where the two classic failures are explained in full.
The Rollback Question
What happens if this goes badly. Almost no migration plan answers that. The answer also changes rapidly in the hours after launch.
Why it stops being available. The move propagates.
Once addresses have changed and been discovered, reversing puts everything through a second migration. The site would be moving twice rather than returning to where it was. The second move carries every risk the first one did.
What that means practically. A short window.
Reversing within the first hours is usually feasible. Reversing after a period of real traffic and discovery is a decision to migrate again. It should be recognised as one rather than described as undoing something.
Why asking still helps. It changes the launch.
A team that has accepted the move is effectively one-way behaves differently on launch day. The checks get done immediately rather than tomorrow, because tomorrow is too late to reverse anything.
What to keep available regardless. The old environment.
Even where reversing is impractical, keeping the previous site accessible somewhere allows comparison and diagnosis. Shutting it down on launch day removes the only reference point anybody has.
Freeze Everything Else
Content changes, link building and other site work should pause around a migration so that any movement in performance has one explanation rather than several.
Why it matters so much. Attribution again.
If the site moved and three other things changed in the same fortnight, a decline has four candidate causes. Each has to be eliminated in turn while performance stays poor, which costs far more than the paused work was worth.
What to freeze. Anything that changes the site.
New pages, rewritten pages, structural changes, new campaigns pointing at specific addresses and any technical work unrelated to the migration itself.
What not to freeze. Two things.
Fixing migration problems, which is the whole point of watching. And anything genuinely urgent for the business, which is a commercial judgement rather than a technical one. The rule exists to protect diagnosis, not to stop the business operating.
How long. Until the reading is clean.
Long enough that performance has stabilised and any effect is visible. That is a judgement rather than a fixed period, described on the monitoring page as a shape rather than a number.
The Monitoring Window
The project does not end at launch. The following weeks are when problems actually surface. Resource has to be reserved for them at the planning stage rather than found afterwards.
Why plans stop at launch. That is where the deliverable is.
A build project is scoped to produce a working site. Once it exists, the contract is fulfilled, the team is allocated elsewhere and the budget is spent. Everything after that is somebody's goodwill.
What that produces. Nobody watching by week two.
The most attentive period is the first day, when almost nothing has been processed yet. By the time the effects are visible, attention has already moved on.
What to reserve. Time and a person.
Named time in the weeks after launch, belonging to somebody specific, with agreement in advance about what warrants action rather than observation. That distinction is the difference between watching a problem and addressing one.
Why it belongs in the plan. Otherwise it is optional.
Work that is not scoped does not happen when everybody is busy. The detail of what to watch is in monitoring after migration.
What A Plan Should Actually Contain
A migration plan is a short list of things that exist rather than a document describing an approach. If these seven exist and somebody owns each, the plan is adequate.
The crawl and the benchmark. Per block three.
Both captured before anything changes, because neither can be produced later.
The map. Per block five.
Every address and its destination, in one document that survives the project.
The test plan. What will be checked, against what.
Usually the map itself, used as the checklist. That is the point of keeping it as one document rather than several.
The launch sequence and the notification steps. Who does what, in order.
Including who is available on the day, what they check first and how quickly a problem found can actually be corrected.
The monitoring schedule. Per block ten.
Reserved rather than assumed. The stage-by-stage version is in the site migration SEO checklist. The full series is on the website migration guide.
Week one
cannot be undone
in week ten.
The search side named to one person in writing at the start, the crawl and benchmark captured while the old site still exists, the mapping begun as soon as the crawl does because it is the longest task, the monitoring weeks reserved in the plan rather than found afterwards, with everything else frozen so any movement has one explanation.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
