Sitecore Migration Services: How to Move Without Losing Traffic

Content migration is a solved problem. Someone writes a script, the content moves, and by the second or third rehearsal it runs clean. It is genuinely the easy half, and it is where migration proposals spend most of their words.

The expensive half is everything the content is attached to: the URLs it lived at, the redirects that pointed to it, the structured data that described it, and the search visibility built up over a decade. That half has no obvious owner, it fails silently, and the bill arrives three months after go-live as an unexplained drop in organic traffic.

We do this work, including a legacy host retirement where we hand-verified a seventy-four row redirect map and watched it for a month afterward. Here is what a Sitecore migration actually involves.

What are Sitecore migration services?

Sitecore migration services move a website onto, off, or between Sitecore platforms: content and media migration, content model mapping, integration rework, URL and redirect continuity, and cutover execution. The technical content transfer is usually the smallest component. Model mapping and search continuity dominate the risk.

Which migration do you actually mean?

Four distinct projects share the name, and they have almost nothing in common except the word.

Get specific about which one you are buying before you compare proposals, because a partner quoting one while you are imagining another produces a number that means nothing. The version-to-version case is a different enough animal that we covered it separately in Sitecore upgrade services.

Why does content model mapping decide the project?

Because it is the one decision you cannot revisit cheaply afterward.

Every migration reaches a fork. Either you reproduce the existing content model on the new platform, or you design a model for where you are going. Reproducing is faster, cheaper, and lower risk during the project. It also carries every accumulated compromise forward: the field added for a 2019 campaign, the template that exists because one business unit would not use the standard one, the inheritance chain that nobody can explain and everybody is afraid to touch.

Designing a new model costs more during the project and is worth it in almost every case, for one reason: migration is the only moment when changing the content model is cheap. Everything downstream is being rebuilt anyway. After go-live, the same change means a data migration on a live system, and the cost multiplies.

The test we apply with clients: for each template, can somebody name what it is for and who uses it? Templates that fail that test are candidates for consolidation or deletion, and there are usually more of them than anyone expects. Our Sitecore XP technical debt audit exists to make this measurable before the migration rather than during it, because a mapping exercise on an unmeasured model is where timelines go.

The failure pattern worth naming: teams defer the model decision, start migrating with "we will clean it up later," and by the time later arrives the new platform has the old model plus a migration's worth of new compromises.

What actually costs you money: URL and search continuity

This is the section to hand to whoever owns your migration plan.

Every URL that changes breaks every link pointing at it, from search engines, other sites, emails, PDFs, and bookmarks. If a page moves without a redirect, its accumulated authority is gone and so is the traffic. If a redirect chains through three hops, it degrades. If it returns the wrong status code, search engines treat a permanent move as temporary and never update their index.

Five things belong in the plan, and the first one is the one most often skipped.

A complete inventory of current URLs before anything moves. Not the sitemap. The sitemap is what you think you have. Pull the real list from server logs, from analytics, from Search Console, and from a crawl, then reconcile them. The gaps between those four sources are the pages you would otherwise have lost, and there are always gaps. We have never run this reconciliation and found the sources agreed.

A redirect map with a disposition for every row. Each old URL gets a decision: redirect permanently to a specific new URL, or return gone deliberately. Every row explicitly decided. The dangerous entry is not a wrong redirect. It is an entry nobody assigned, which becomes a soft 404 that quietly reports as fine.

Correct status codes. A permanent move is a 301. Content deliberately removed is a 410, not a 404, because 410 tells the crawler the decision was intentional and it drops the URL faster and more cleanly.

No redirect chains. Old URL to new URL, one hop. Chains accumulate across successive migrations, and the estate that has moved three times has some URLs going through four redirects before landing.

A verification pass against real HTTP responses. Not the plan. The live site. Request every row of the map and record the status code and final destination. We do this row by row after any migration and it has never once been fully clean on the first pass.

Two more that get forgotten because they are not URLs: structured data and metadata continuity, since a rebuilt front end has to re-emit the titles, descriptions, canonicals, and JSON-LD the old platform produced, and in a headless build none of that comes for free. We wrote up what moves to your front end in headless CMS SEO, and a migration is exactly when that debt comes due.

Big bang or phased?

Both are defensible. The choice is mostly about site size and organizational tolerance.

Big bang cuts everything at once. Simpler to reason about, no dual-running complexity, one cutover, one redirect event. The risk concentrates into a single moment, and a problem discovered at midnight affects everything. Appropriate for smaller sites and for estates where partial migration would create an incoherent user experience.

Phased moves in sections, usually by site, brand, or content type. The risk spreads out and each phase teaches you something for the next. The cost is a period, often a long one, where content lives in two systems, authors work in two places, and something has to route traffic correctly between them. That routing layer is real engineering and is routinely underestimated. Appropriate for large multi-site estates where big bang is genuinely too risky.

The version that reliably fails is phased-by-accident: a big bang that slipped, leaving half the content migrated with no routing strategy, because nobody planned for a state that was not supposed to exist.

What should a migration plan contain?

Nine items. Read a proposal against this list and the gaps show up quickly.

1. Inventory of content, templates, media, integrations, and URLs, from reconciled sources.
2. Content model mapping, old to new, with the deliberate changes called out and justified.
3. Migration tooling, scripted and rehearsable rather than manual, because you will run it more than once.
4. Redirect map with a disposition for every URL and no unassigned rows.
5. Integration plan for every system that reads or writes content.
6. Rehearsal schedule. At least two full dress rehearsals against production-scale data. Not a subset, because the problems that only appear at full volume are the ones that ruin a cutover.
7. Cutover runbook with a rollback path that has been tested rather than written.
8. Verification plan covering functionality, performance, and search visibility.
9. A post-launch watch window with a named owner and a defined duration.

That last one is the most commonly missing and among the most valuable. Migration problems surface over weeks, not hours. Search engines take time to recrawl, and the traffic effect of a bad redirect is invisible on day one and obvious on day thirty. A month of somebody actually watching is cheap compared to finding out in the next quarterly review.

What a real rehearsal covers

Two full dress rehearsals is the item most often trimmed when a timeline slips, and it is the one that most reliably determines whether the cutover is calm. A rehearsal that is worth the name covers six things.

Full-scale data. Production volume, not a subset. Migration scripts that run in twenty minutes against a sample can run for nine hours against the real content tree, and you need that number before you write the cutover window, not during it.

The actual cutover sequence, timed. Every step in order, with a stopwatch. This produces the runbook timings you will commit to.

The rollback. Actually executed, not discussed. A rollback plan that has never been run is a hypothesis. This is the step teams skip most often and regret most sharply.

The redirect map, applied and verified. Load the map into the target environment and request every row. This is where you find the entries that were wrong on paper.

Integrations, live. Every system that reads or writes content, exercised against the migrated data. Integrations that pass against test content routinely fail against real content, because real content contains the edge cases.

A named go and no-go decision. Rehearsals should be able to fail. If there is no criterion under which you would postpone, you are not rehearsing, you are practising optimism.

The second rehearsal exists to prove the fixes from the first one worked. Teams that run one rehearsal usually discover a problem, fix it, and then cut over having never tested the fix under full conditions.

How do you know it worked?

Agree these before the work starts, because after go-live everyone is motivated to declare victory.

Content completeness. Counts reconcile per type, and spot checks confirm fields landed where intended.

Functional parity. Every template, workflow, and integration exercised against a written list.

Performance. Measured against a baseline you captured before the migration. Capture it early, because you cannot benchmark against a system you have turned off.

Redirect coverage. Every row of the map verified by real HTTP request, with status code and final destination recorded. Zero unassigned URLs.

Search visibility. Indexed page count, impressions, and rankings for your top terms, tracked weekly for at least a month. A migration that loses a fifth of organic traffic has failed even if every other check passed, and this is the metric most likely to be omitted from acceptance criteria.

The honest summary: a Sitecore migration is not primarily a content transfer problem. It is a modeling decision, a continuity problem, and a verification discipline, wrapped around a content transfer that is mostly solved. Proposals that treat it the other way around are pricing the easy half accurately and the hard half not at all.

If you are planning a migration, holding a proposal that says little about URL continuity, or already moved and cannot explain where the traffic went, that is our work. We run redirect verification against real HTTP responses row by row, and our support hours never expire, so the post-launch watch window is covered rather than being a change request. Book a call, or read about our Sitecore development and support practice.

Read next

• Sitecore Upgrade Services: What You Are Actually Buying: the version-to-version case, which is a different project.
• The Sitecore XP Technical Debt Audit: measuring the content model before you map it.
• Headless CMS SEO: The Complete Guide: the metadata and rendering responsibilities a migration hands to your front end.
• Is Sitecore a Headless CMS?: what an XP to XM Cloud move actually involves.
• Work with us: Sitecore development and support, or our headless CMS agency practice.