A migration is any change that alters the addresses of your pages: a new platform, a new domain, a restructure, moving from several sites to one. The traffic that is lost in these projects is almost never lost for a subtle reason. It is lost because some pages changed address and nothing told a search engine where they went, and by the time anybody notices, the rankings have been reassigned to somebody else.
Everything starts with a complete inventory of the old site
Before anything moves, you need every address that exists, gathered from the crawl, the analytics, the server logs, the sitemap and the search console, because each of those misses things the others catch. Old pages nobody remembers are often the ones carrying links from elsewhere. A migration plan that starts from the new site's page list rather than the old site's address list has already decided to lose whatever it did not think of.
Every old address maps to one page, or it is a decision you made
Each address either redirects permanently to the page that now serves that purpose, or is deliberately retired, and the second needs to be a choice rather than an omission. Redirecting everything to the home page is the classic failure: it is technically a redirect and it tells a search engine that none of those pages has a replacement. The map should be a spreadsheet somebody signs off.
Test on a staging site before the launch, not after
The redirect rules, the new templates, the structured data, the canonical tags and the robots directives can all be checked before anything goes live, and the single most expensive migration error, launching with the staging site's block on crawling still in place, is caught by looking. Insist that somebody crawls the staging site and compares it page for page against the old one.
The first two weeks after launch are the real work
Watch the error reports, the crawl, the indexed page count and the rankings daily, because the redirects that were missed announce themselves immediately as errors and fixing them in week one costs almost nothing. Leaving them for a month means the replacement page has to re-earn its position from scratch. Budget attention for this period explicitly; it is where a good migration separates from a bad one.
Expect a dip, and agree in advance how long is too long
Even a well-executed migration usually sees some volatility for a few weeks while everything is recrawled. That makes it hard to tell normal settling from a real problem, which is why you agree beforehand what the recovery should look like and at what point you investigate. Without that, every migration is followed by a month of arguing about whether the dip is expected.
Questions people ask about seo migration service
When should we bring in migration help?
Before the new site is built, not before launch. Most of the expensive decisions, the structure, which pages survive, how addresses map, are made during the build, and arriving in the final week means documenting mistakes rather than preventing them.
Can we redirect everything to the home page?
You can, and it is the most reliable way to lose the traffic. A redirect to the home page tells a search engine that the old page has no replacement, so whatever it had earned is discarded rather than transferred.
How long does a migration take to recover?
Usually a few weeks of volatility while everything is recrawled, longer for a large site. Agree beforehand what recovery should look like and when you would investigate, so the settling period is not an argument.
What is the most common migration mistake?
Launching with the staging site's crawl block still in place, closely followed by an incomplete address inventory. Both are caught by somebody crawling the staging site and comparing it to the old one before launch.