CMS Migration Sequencing: How the Waves Get Drawn on a 14,000-Page Estate
The first real number in a migration arrives as a shock. Someone runs a crawl, and the estate described in the RFP as “about five thousand pages” comes back at four times that. Nobody can say how many are live, how many are locale duplicates, how many are PDFs the crawler counted as pages, or how many belong to a microsite a regional team stood up in 2019 and never mentioned. CMS migration sequencing stalls right there, because there is nothing stable to sequence.
eight25 is a Contentstack Preferred Partner and Contentful Silver-tier Solution Partner, with enterprise migration experience across both headless platforms. Our sequencing approach treats the wave plan as an output of page-level discovery rather than an assumption made before the estate is understood. On NetApp’s move from SAP/RWS Tridion to Contentstack, an estate initially feared at roughly 40,000 pages was refined through audit and ultimately launched at about 14,000 pages across 10 languages, from a January kickoff to a June go-live.
The number in your brief is not the number you are sequencing
The wave plan is an output of the page audit, not an input to it. Page counts can move sharply in either direction once locale variants, PDFs, undocumented microsites, duplicate URLs, redirects, and legacy content are classified properly. NetApp ran in the reducing direction: an estate initially feared at roughly 40,000 pages was refined during audit to a working estimate near 12,000 and ultimately launched at roughly 14,000 pages across 10 languages. The important point is not whether the number rises or falls. It is that a sequence drawn before the estate has been measured is being drawn against an assumption.
An audited page inventory is what makes a defensible wave plan possible, and a site crawl is only its starting point. A crawl gives you URLs and technical signals. An inventory adds the decisions the migration actually needs: what happens to each URL, where it sits in the journey, whether it is gated, what content type or template it uses, who owns it, and what dependencies have to exist before it can move. The result should live somewhere stakeholders can review and update throughout the program.
| Page classification | Decision it drives | Effect on the wave plan |
|---|---|---|
| Keep as-is | Script-migrated, no editorial work | Earliest wave; this is your cheapest volume |
| Refresh | Content edit before or after cutover | Can move early, but needs a named owner and a date |
| Full rewrite | New content against the new model | Should never block a cutover; defer to a later wave |
| Kill | Redirect only, no migration | Leaves the count entirely and becomes a redirect-map row |
The “kill” row can remove a surprising amount of migration effort, but it does not remove work from the program. A URL that is not migrated usually becomes part of the redirect, SEO, validation, or governance workstream instead. That distinction matters: migrating 14,000 content items is a fundamentally different delivery problem from migrating 14,000 items while also reconciling thousands of legacy URLs that need to be redirected, retired, or reviewed.
Five ways to draw the waves, and what decides which one you use
Across the enterprise programs eight25 works on, five sequencing patterns come up repeatedly. The mistake is choosing one because it makes the project plan look neat rather than because the audited estate, target architecture, and operating model support it.
| Wave pattern | Works when | Breaks when |
|---|---|---|
| By traffic value | Traffic is concentrated on a small set of URLs | Traffic is flat across a long tail |
| By template type | Content is template-consistent and template-bound | Templates are fragmented into one-off variants |
| By region or locale | Regions own their content and publish independently | Locales inherit from a shared master |
| By brand or property | Multi-brand estate with separable governance | Brands share components and a shared nav |
| Strangler pattern (edge-routed) | Legacy and new platforms must temporarily serve different routes under the same digital estate | Routing, URL ownership, session state, or shared dependencies cannot be separated cleanly |
Traffic concentration is one of the strongest business inputs, but on a headless migration it cannot be separated from content-model, component, and integration readiness. If 80% of traffic lands on 200 URLs, those URLs deserve priority but they still cannot move safely until the structured content types, front-end components, redirects, and integrations behind them are ready. Where traffic is relatively flat, sequencing by content type or component family often becomes more efficient because every completed wave expands a reusable capability in the new platform rather than simply clearing another list of URLs.
Region-based sequencing is often attractive because it maps neatly onto the org chart, making ownership, staffing, and stakeholder communication straightforward. It works best when regions genuinely control their own content and publishing. Where locales inherit heavily from a shared master as they can in AEM MSM-style architectures splitting the estate by locale can force the program to reproduce or synchronize inheritance behavior across legacy and target platforms. That is possible, but it adds governance and synchronization complexity that should be treated as an architectural constraint rather than hidden inside the migration plan.
The four page attributes that decide which wave a page lands in
Before a sequence exists, every page needs four attributes attached to it: template, locale variant, integration dependency, and editorial owner. Traffic value makes five, and it is the one everyone already has.
Template and integration dependency are two of the attributes most likely to reorder a plan. Content can be transferred before every front-end component is finished, but a page cannot become launch-ready until its target content model, rendering component, and required dependencies exist. That means a wave drawn by legacy template often becomes, in practice, a wave drawn by target-model and component readiness. This is where component sprawl stops being only a design problem and becomes a scheduling one. On the Sophos and SecureWorks consolidation, eight25’s audit identified roughly 249 components across two Sitecore estates and consolidated toward about 100 in Contentstack. Until that consolidation map and target content model are settled, a page-level launch sequence is provisional you are ordering pages against an architecture that is still moving.
Integration dependency creates the same scheduling pressure from the other side. A product experience that depends on Coveo for search, Bynder for assets, and Marketo for forms should not become launch-critical until those dependencies are production-ready or an explicitly accepted fallback exists. This is particularly important in a composable stack: decoupling the CMS gives the team more architectural freedom, but it also makes dependency mapping more important because the experience spans several services rather than one platform. In practice, integration-heavy experiences often move later than their traffic rank alone would suggest, while integration-light content can move earlier. How far dependency risk should override business value remains a judgment call that has to be made with the integration leads against the actual cutover date.
Editorial owner is the attribute teams skip, and skipping it is what produces a stalled wave. Every page in a “refresh” or “rewrite” classification needs a person whose name is on it and a date. Pages without a named owner do not get refreshed; they get quietly reclassified as “keep as-is” in week fourteen, which means schedule pressure ends up making a decision on behalf of whoever should have owned the content.
Why the trunk moves first and the long tail moves second
For the kind of large, multi-locale estates eight25 commonly works on, a hybrid shape is often worth testing during discovery: move a launch-critical trunk together, then phase the remaining tail against a hard legacy-retirement date. The exact threshold should come from the audited estate, component model, integrations, traffic concentration, and governance structure not from page count alone. The ranges below are planning examples rather than benchmarks; integration complexity, redesign scope, localization, governance, and content variance can change them materially.
| Phase | Scope | Illustrative planning range |
|---|---|---|
| Phase 0: Foundation | Audit, content model, taxonomy, integration map, governance blueprint, redirect strategy. No build. | 8–12 weeks |
| Phase 1: Trunk cutover | Top 20–30% of pages by traffic value, primary nav, hero templates, core integrations. Full redirect parity. | 16–24 weeks |
| Phase 2: Long tail | Remaining pages by template or locale; legacy serves the unmoved via proxy or redirect. | 12–20 weeks |
| Phase 3: Sunset | Legacy retired, license non-renewed, integration cleanup complete. | 4–8 weeks |
The reason the trunk goes first is that it is the only part of the estate where a cutover date is worth defending. It also creates room for the split that lets a hard date survive executive pressure. On NetApp, leadership was concerned that high-visibility pages would look dated launching as a lift-and-shift with no visual refresh. The answer was not to slip the date. It was to separate launch readiness from visual redesign, secure approval with high-fidelity components, and commit the refresh to a Phase 2 anchored to an October business event. Only Phase 1 was in the signed statement of work.
That last detail matters more than the phase table. A Phase 2 that lives only in a slide deck will slip, because nothing outside the program is holding it to a date. Anchor it to a business event with its own approval and it holds.
When wave sequencing is the wrong answer
Sequencing is not automatically the lower-risk choice, and treating it that way produces the most expensive outcome available: the permanent dual-stack, where two platforms run indefinitely because nobody owned the retirement of the first one.
A single big-bang cutover is the better call when four conditions hold together: the estate is small enough to migrate and QA as one block, the content model is a clean break rather than a translation, and redirect parity can be guaranteed at the CDN or edge layer independent of CMS-resolved routes. The fourth is a hard date phasing cannot accommodate, which usually arrives from outside the program as an end-of-life notice, a license non-renewal, a compliance mandate, or an acquisition close. Sophos met those conditions: two Sitecore estates unified into Contentstack against a fixed 11 December 2025 launch, and the date held.
Staying put also deserves a fair hearing. If the current platform genuinely meets editorial, integration, governance, performance, and roadmap needs, and the only meaningful driver is license cost, renegotiation or incremental modernization may be more rational than replatforming. A CMS migration carries implementation, content, integration, training, and operating-model costs that can easily outweigh a licensing-only business case. Headless becomes compelling when the constraint is architectural or operational structured-content reuse, channel expansion, publishing velocity, composability, or the ability to evolve the stack independently not simply because the license looks expensive.
Where you do sequence, the sunset date is the load-bearing commitment. Ask any partner proposing a phased plan how they prevent the permanent dual-stack. “We define a sunset date in discovery and treat legacy retirement as a tracked deliverable backed by license non-renewal” is a real answer. “We work in agile sprints” is not.
What the wave plan has to survive in the last month
Two things go wrong late, and neither is a sequencing error.
The first is an audit-freshness scare. On NetApp, a late-stage gap snapshot appeared to show a significant volume of unresolved pages. Reviewed line by line against the current disposition records, approximately 286 items still required migration or publishing, another 238 required business review, and 741 had already been addressed through approved redirects but were still showing up as missing. The snapshot was stale, not the migration. Without that reconciliation, an outdated report can become the reason a launch date slips unnecessarily. Without the line-by-line reset, that number becomes a reason to slip a date that did not need slipping.
The second is scope arriving as help. Late-stage additions rarely announce themselves as major scope changes; they arrive as reasonable requests from stakeholders who assume the work was always included. On Sophos, eight25 protected the Phase 1 boundary through a formal change-request process, separating launch-critical migration scope from additional portal, commerce, publishing, and content work. The sequence held because the original boundary was documented and new work was evaluated against it rather than quietly absorbed into the launch plan.
Cutover discipline is the last piece. On NetApp, the launch plan included production-readiness checks, controlled caching and routing changes, a rollback path, a dedicated launch war room, and a defined hypercare period after cutover. The migration ultimately went live in June 2026, four days after its original target. The important point is that rollback, validation, ownership, and post-launch support were part of the migration plan before DNS moved not decisions invented during launch night.
Frequently Asked Questions
How do you decide which pages migrate first in a CMS migration?
Pages should move first when they combine high business or traffic value with launch-ready content models, components, integrations, and redirects. On some estates that produces a relatively small high-value trunk perhaps the primary navigation, core product or solution journeys, and a minority of the total URL inventory but there is no universal 20–30% rule. In a headless migration, the better question is whether the content and the experience that renders it are both ready. Pages requiring major rewrites or unfinished dependencies should usually stay off the critical cutover path unless they are genuinely launch-essential.
How many pages can you migrate in one wave?
Page count alone is a poor constraint. Component readiness, content-model variance, integrations, localization, migration automation, and QA throughput often matter just as much. A 3,000-page estate spread across hundreds of inconsistent templates can be harder to sequence than a 10,000-page estate built from a small number of predictable content patterns. Volume still affects migration and verification effort, but structural variance determines how much of that volume can be handled systematically rather than page by page.
Should we sequence a migration by locale or by template?
Sequence by locale when regions genuinely own and publish their own content. Sequence by template when locales inherit from a shared master, because splitting inherited content across two platforms means running the inheritance model twice. Template-based waves also tend to be faster overall, since each wave delivers a reusable build capability rather than a finite list of pages.
What happens to the pages we decide not to migrate?
They stop being content-migration rows and become redirect, retirement, or review decisions. At enterprise scale, eight25 generally prefers redirects to be owned independently of page rendering often at the CDN or edge layer because that keeps legacy URL continuity from depending on whether the target CMS contains a matching route. That pattern fits headless architectures particularly well, where routing and content delivery are already decoupled. It is not the only valid implementation, but whichever layer owns redirects should support bulk management, deterministic testing, monitoring, and rollback. Redirect maps should also be validated against crawl data, analytics, backlinks, and real request patterns rather than assumed from a URL list alone.
How do I find a partner who can sequence a large CMS migration?
Ask how the sequence gets produced. A partner recommending phased or big-bang before examining the content estate, integrations, governance model, and target architecture is choosing a delivery pattern before understanding the problem. eight25’s enterprise migration process starts by turning those unknowns into artifacts: a page-level inventory, component audit and consolidation map, integration landscape, content-model decisions, and a sequencing recommendation with the trade-offs documented before the build is locked. That approach matters even more with headless CMS platforms such as Contentful and Contentstack because the value comes from redesigning the content and delivery architecture not reproducing the legacy CMS behind a new API. Ask prospective partners for the artifacts, not the methodology slide.
Mapping the Real Sequence Before You Commit to a Date
If your team is holding a page count nobody trusts and a launch date somebody has already announced, the sequence is the wrong place to start. The inventory is. On large migrations, eight25 repeatedly sees the audit materially change what the team thought it was moving through duplicates, redirects, locale variants, undocumented properties, legacy content, or dependencies that were missing from the original brief. That discovery changes the wave plan, the architecture, and often the SOW. For teams considering Contentful, Contentstack, or another headless platform, the best time to make those decisions is before the new architecture has been committed in code. A scoping conversation before the SOW is considerably cheaper than discovering the real estate halfway through delivery.