Technical SEO
Migration and replatform planning
This is the narrowest useful unit of Technical SEO: change domain, platform or structure without losing the visibility you spent years building.
What is migration and replatform planning?
Change domain, platform or structure without losing the visibility you spent years building. In practice that means a full pre-migration inventory of URLs, rankings, links and templates, and then the harder half: a redirect map covering every URL with traffic, links or rankings, one hop only.
Why this work exists
The work has no natural owner, which is why it survives three reorganisations untouched.
Technical SEO is the wider programme; this is the piece that gets scoped first more often than any other.
The nearest piece of work to it is sorting which 404s deserve a redirect and which deserve to stay gone. Where that is already handled, this moves faster than the estimate; where it is not, the two get done together or neither of them holds.
What good looks like
It is right when the exceptions are written down rather than remembered.
The gap between that and where most accounts start is why this is scoped as migration and replatform planning rather than as a line inside something larger. Reading the server log rather than guessing what the crawler did is the usual second step once it is in place.
When this is the right work
Three observations mean this work is due:
- A migration is planned and no redirect map exists yet
- A previous migration cost traffic that never came back
- The new platform is being built without the old URL inventory to hand
If none of those is true, something else is probably the constraint, and the Technical SEO overview maps the alternatives. The usual neighbours are finding the slow query behind the page that is slow only sometimes and making sure the search console property covers every version of the domain.
What the work covers
What gets done:
- A full pre-migration inventory of URLs, rankings, links and templates, scoped against what the business can actually act on rather than what is possible.
- A redirect map covering every URL with traffic, links or rankings, one hop only. This is where the theory meets the account and usually loses.
- Parity testing of content, markup and internal links before launch, which changes often enough that a single pass has a shelf life.
- Post-launch monitoring with a defined rollback trigger, the step where disagreements surface, which is why it goes early rather than late.
How it runs
The shape of the work, stage by stage.
Setting the guardrails
Limits get agreed early: what will not be touched, what needs sign-off, what can be changed without asking. Arguments about scope mostly trace back to skipping this.
Testing on the awkward cases
Whatever gets built is checked against the messy real examples rather than the clean ones, because the clean ones were never going to be the problem.
Writing it down for the next person
The reasoning gets recorded alongside the result, so a decision taken in March can still be defended in September by somebody who was not there.
What each part runs into
Each piece has its own friction:
- A full pre-migration inventory of URLs, rankings, links and templates, which in Ahmedabad runs into an enquiry path that runs through a messaging app rather than a form
- A redirect map covering every URL with traffic, links or rankings, one hop only: the Abu Dhabi version of this has to deal with a catchment smaller than the ambition on the website
- Parity testing of content, markup and internal links before launch, where a Leeds engagement contends with an incumbent whose position comes from presence rather than effort
- Post-launch monitoring with a defined rollback trigger – working in Dallas this means accounting for a buying pattern that resolves faster than the reporting cycle
What not to do
Redirecting everything to the homepage. It destroys the specific relevance each URL had earned and it is the single most common cause of migration loss.
Naming it upfront is the difference between a result and a report about effort.
How it is measured
Share of pre-migration organic traffic and rankings recovered within eight weeks. The measure is specific on purpose: a headline figure that cannot move inside the engagement is not useful.
Movement smaller than the normal week-to-week swing gets reported as no movement.
What you end up with
Specifically: a complete redirect map, a parity-tested staging build, a launch runbook and a monitored post-launch period.
Kept short enough that it gets read, which is the only property that matters.
How it differs by sector
How the sector changes it:
- Finance and fintech: Regulated claims, compliance review in the publishing path, and trust signals that have to be real. so this work has to account for that before anything else.
- Travel and hospitality, where aggregators hold the demand, so direct booking depends on being the specific named property. which moves this work earlier in the plan.
- In Marketplaces and platforms the binding constraint is that two sides to acquire, and a programmatic page set that can sink the whole domain.
The industry pages carry the rest of that detail. Finance and fintech and Travel and hospitality are the two where this piece of work most often decides the outcome.
Common questions
How long does it take to recover from a migration?
Four to twelve weeks for a well-executed one, with a dip in the first fortnight that is normal rather than alarming. A badly executed one may never fully recover. The variables that matter most are redirect completeness, content parity and whether internal links point at the new URLs rather than through redirects.
Should redirects be kept forever?
Keep them for at least a year, and keep the ones that still carry traffic or external links indefinitely. They cost almost nothing to maintain and removing them discards the equity they pass. The redirect map is a permanent asset, not a temporary launch artefact.
How long does this take?
The diagnostic part is usually two to three weeks. What follows depends on what the diagnosis finds, and we scope the second phase after the first rather than quoting both upfront. People arriving here usually end up on Analytics and Measurement, and often on App Store Optimization after that.
How much of our time does this take?
A few hours in the first fortnight, mostly answering questions about history that cannot be reconstructed from the data. After that, a monthly review. If budget allows only one of these, 301 redirect or Canonical tag first, then Broad match or Exact match next quarter.
What do we actually get at the end?
A complete redirect map, a parity-tested staging build, a launch runbook and a monitored post-launch period. Documented, so it survives whoever was in the room, and specific enough to act on without a follow-up conversation. The page that answers the follow-up question is How long does SEO take to show results?. The one that answers the objection is How many words should a page be?.
Ask about migration and replatform planning
Give us the site and one question. If the honest answer is that you do not need this, we will say so.
Ask what we would do first, and why
One call, no sequence of follow-up emails afterwards. If the timing is wrong we will leave you to it.