A migration can erase years of rankings in a single weekend.

What actually breaks during a migration

Three failures account for almost every migration drop, and all three are preventable. Redirects that are missing, broken or chained leave years of link equity stranded on URLs that no longer resolve. A changed URL structure with no mapping means Google cannot connect the old page to the new one. And new URLs stay invisible for weeks when the sitemap is never resubmitted and robots.txt was not revalidated at launch.

None of these are exotic. They are checkable inside a day, which is why a migration drop is worth diagnosing immediately rather than waiting to see whether it recovers on its own.

Before a single URL changes

We run a full technical audit of both the staging build and the live site, then produce a complete URL map between them. Internal links are checked so every one returns a 200. Staging functionality is tested. Existing backlinks are analysed so the redirects protect the pages that actually carry authority, not just the pages in the menu.

You receive a migration checklist and a sign-off framework before anything moves. Nothing goes live on our say-so alone.

What happens at go-live

Tracking codes are verified before launch, not after. At go-live we monitor Search Console, GA4 and Ahrefs in real time, validating every redirect, resubmitting sitemaps and fixing crawl errors as they surface. A final technical audit confirms the new build behaves the way the staging version did.

The 90 days after launch

This is the part most migration quotes leave out. We deliver weekly ranking and traffic reports for 90 days after go-live, with rapid escalation and targeted fixes for any volatility. Migration damage rarely appears on day one. It appears in week three, when a page quietly drops out of the index and nobody is watching.

The kinds of migration this covers

People use the word migration for several different jobs, and the risk profile is not the same in each. What follows is how we scope them.

• Domain change. Same site, new address. Everything rests on the redirect map and on how quickly Google reassociates the brand with the new host.
• Replatform. WordPress to Shopify, a custom build to WordPress, one framework to another. URL patterns almost never survive intact, so the mapping work is the whole job.
• Redesign on the same domain. URLs may not move at all, yet rankings still fall, because content was shortened, headings were restyled into images, or a page was quietly dropped from the navigation.
• Subfolder or subdomain onto its own domain. The hardest of the group. You are giving up the authority of the parent domain and starting a new host from zero, so the redirect map has to carry every signal it can.
• Consolidation. Two or more sites merged into one. The risk is not the redirects, it is deciding which of two competing pages survives.
• Protocol and hostname changes. HTTP to HTTPS, www to non-www, trailing slash to none. Small in scope, and still capable of producing duplicate indexing if the canonicals disagree with the redirects.
• Server and hosting changes. No URL moves at all, and still a real risk: response times, SSL, and whether the new host returns a clean 200 to a crawler rather than a soft error under load.
• Recovery. The migration already happened, traffic fell, and nobody kept a record of the old URLs. This is a different engagement: we reconstruct the old structure from Search Console, archived crawls and backlink data, then rebuild the map after the fact.

What you actually receive

Activity is easy to describe and hard to check. These are the artefacts, and you keep all of them whether or not you stay with us afterwards.

• The pre-launch technical audit of both the staging build and the live site, with a severity and an owner against every issue.
• The URL map. Every old URL, its new destination and the redirect type, in a sheet your developer can implement from directly.
• The backlink protection list. The linked URLs that must not be lost, ranked by referring domains, so the redirect decisions are made in the right order.
• The keyword baseline. Where you rank the day before launch. Without it, no one can prove afterwards whether the migration cost you anything.
• The launch-day redirect test report, covering every mapped URL rather than a sample.
• The meta set for the new build — title, description, H1 and canonical, page by page.
• Weekly ranking and traffic reports for 90 days after go-live.
• A live monitoring dashboard, shared rather than emailed, so you are looking at the same numbers we are.

We run this on Sitebulb, Semrush, Ahrefs, Advanced Web Ranking and Moz Pro, alongside Search Console, Bing Webmaster Tools and GA4. Naming them matters here: a migration is judged on crawl data, and crawl data is only as good as the crawler that produced it.

The migration plan we run, stage by stage

This is the working document, not a marketing summary of it. Every migration we run uses the same tracked plan, each task carries an owner, and the client sees the same sheet we do. Publishing it means you can hold us to it, and it means you can check any other proposal against it.

Stage one — before anything moves

1. Noindex the staging site (developer)
2. Upload the new content and review it in full (developer)
3. Add and test the tracking codes, analytics and ad pixels (both)
4. Move Search Console verification to the new build, using whichever method the property was verified with (both)
5. Apply the URL structure we supply (developer)
6. Health check of the current live site (VOCTOS)
7. Full technical SEO audit (VOCTOS)
8. Fix what the audit finds, on staging, before launch (developer)
9. Confirm a custom 404 page exists (developer)
10. Take a complete backup of the current site (both)
11. Confirm the corporate pages are all present: about, contact, privacy policy, terms, HTML sitemap and the cookie notice (both)
12. Export the new URL list (developer)
13. Build the URL map, old to new, every page (VOCTOS)
14. Set up the monitoring and reporting dashboard (VOCTOS)
15. Record the current ranking keywords if no list exists (both)
16. Carry the existing meta tags across to the new build (both)
17. Put the 301 redirects in place, all URLs at once rather than in batches (both)
18. Handle Google News, where the site is registered for it (both)

Stage two — launch day

1. Submit both XML sitemaps, old and new (VOCTOS)
2. Update robots.txt (both)
3. Confirm analytics, Search Console and Tag Manager are firing on the new build (both)

Stage three — after launch

1. Technical audit the same day, looking for 404s, broken links, internal redirects and any redirect that is not a 301 (VOCTOS)
2. Test speed and Core Web Vitals (VOCTOS)
3. Test every old-to-new redirect (VOCTOS)
4. Fix what we report (developer)
5. Weekly ranking audits (VOCTOS)
6. Supply the meta set for each page: title, description, H1 and canonical (VOCTOS)
7. Implement them (developer)
8. Review the implementation (VOCTOS)
9. Update robots.txt again once the launch state is settled (both)
10. Review internal links and run the mobile-friendly test (VOCTOS)
11. Validate the code fundamentals against the standard tools (both)
12. Add any missing fundamental pages and the cookie notice (developer)
13. Confirm a valid SSL certificate and that every HTTP URL redirects to HTTPS (developer)
14. Test the site across devices and browsers (both)
15. Confirm every page that matters is indexable, with no stray noindex and canonicals pointing where they should (both)
16. Remove pages from the index that should never have been there (VOCTOS)
17. Monitor Domain Authority through the recovery window (VOCTOS)

Thirty-eight tasks across three stages. Roughly half sit with your developer, which is the point: a migration is not something an SEO agency can do to a site from the outside, and any proposal that implies otherwise is describing a redirect spreadsheet rather than a migration.