CMS Migration Readiness: What to Settle Before Day One
The change orders arrive in month three. Usually they trace back to something nobody settled before kickoff, and build is where the bill comes due. Does “Solution” mean the same thing to the product team and the web team? Who signs off on the German site? Nobody is sure whether the four thousand indexed PDFs count as pages, and a sprint stalls while stakeholders who were never in the room get pulled into a conversation that belonged in the SOW.
CMS migration readiness comes down to five decisions: what is actually in the content estate, what the shared vocabulary means, how content should be modeled, how localization will operate, and who owns each integration. eight25 is a Contentful and Contentstack partner that addresses these decisions through a focused discovery phase before implementation begins. This is also where a team can determine whether a structured, headless architecture will create enough reuse, delivery flexibility, and integration value to justify the additional architectural responsibility. Decisions are substantially less expensive to revise here than after models, components, and integrations have been built.
Readiness is a decision state, not a task list
Most pre-migration checklists measure activity. Content audited, integrations listed, backup taken, environment provisioned. Useful work, all of it. But a finished task can still leave the underlying question wide open. A team can complete a content audit and still not know whether the regional marketing leads or the central web team decides what gets retired.
What matters is whether a question is settled: someone specific has decided, the decision exists in writing, and the people it affects have seen it. Unsettled questions do not stay quiet. They surface during build, when answering them costs a change order instead of a meeting.
This is why discovery is one of the highest-leverage investments in an enterprise migration. Projects encounter trouble when scope is built around assumptions that have not been tested against the content estate, editorial workflows, localization model, and integration landscape. Our operating principle is that material unknowns should be identified, assigned, and resolved before implementation begins. Discovery may add time at the front of the plan, but it reduces the risk of revisiting foundational decisions after the build is underway.
| Decision | Typical owner | Settled when |
|---|---|---|
| What is in the estate | Digital ops + analytics | Every URL classified, not just counted |
| What the words mean | Product marketing + web | One taxonomy, conflicts logged and resolved |
| What the content model is | Content strategy + engineering | Model approved by editors, not just developers |
| How localization works | Regional leads + central web | Locale structure, ownership, and workflow documented |
| Who owns each integration | IT + agency | Named owner on both sides for every system |
The five decisions that have to be settled before kickoff
1. What is actually in the estate
Page counts in project briefs are usually working estimates, not reliable scope measures. The number may rise or fall once the team separates primary pages, locale variants, indexed PDFs, undocumented microsites, redirect candidates, and legacy content outside the original audit. On eight25’s SAP/RWS Tridion-to-Contentstack migration for NetApp, the estate was initially feared to contain around 40,000 pages. A URL-level audit produced a working estimate of roughly 12,000, and the launch estate ultimately tracked at approximately 14,000 pages across 10 languages.
A count does not make scope knowable. A classification does. Every URL needs to carry enough dimensions that you can slice the estate by migration approach, phase, and owner.
| Dimension | Why it changes scope |
|---|---|
| Source template | Determines mapping effort and reuse potential |
| Locale variant | Distinguishes true pages from translations of one page |
| Integration dependency | Flags pages that cannot move until a system moves |
| Traffic and conversion value | Sets phase order and redirect priority |
| Editorial owner | Identifies who approves retirement |
| Disposition | Migrate as-is, transform, rewrite, retire, or redirect |
Disposition is also where readiness meets tooling. How rich text components get extracted, how broken references get repaired, whether URL history survives: these are execution questions, and a classified inventory is what makes them answerable. [INTERNAL LINK: CMS Migration Tooling: Mapping, Validation, Redirects, and Rollback]
The classification also has to stay current. On the NetApp program, a gap snapshot two weeks before launch appeared to show a large volume of unmigrated pages. When the team checked it line by line against the updated audit, only around 286 of roughly 14,000 pages still needed migration or publishing. Another 238 required review, while 741 were redirects that had already been resolved. In this case, the apparent gap came largely from stale audit data. Reconciling the lists gave the team a defensible view of the remaining scope and helped keep the launch on track.
2. What the words mean
Different teams inside the same organization define “Product,” “Solution,” and “Platform” differently. In a legacy CMS, the page hierarchy papered over the inconsistency: the product team had their section, the solutions team had theirs, and nobody had to reconcile them. In a structured content model, the conflict surfaces immediately, because both teams need the same content type and disagree about what belongs in it.
Taxonomy alignment should begin before detailed information architecture and content modeling, but the three disciplines usually need to be refined together. Agree on the core terms and unresolved conflicts first, then test them against navigation, content relationships, search, and real editorial scenarios. If disputed definitions remain hidden until implementation, they can produce duplicate types, inconsistent navigation, and additional localization work.
The artifact is a conflict log, resolved before modeling starts:
| Term | Team A definition | Team B definition | Resolution |
| Solution | Bundled offering by industry | Any multi-product use case | Industry-bundled; use-case becomes a separate type |
| Platform | The technology layer | The full product portfolio | Technology layer; portfolio is a navigation grouping |
| Resource | Gated asset | Any non-product page | Gated asset only; ungated content typed by format |
3. What the content model is
The content model is not the same as the information architecture, but the two have to work together. Information architecture organizes how people find and navigate information; the content model defines the entities, fields, and relationships that make that information reusable and deliverable. Treating modeling as a short technical exercise can leave editors, brand owners, compliance teams, and downstream channels with a structure that does not support their work. The effort required should be based on estate complexity rather than a fixed workshop duration.
A common failure mode is rebuilding the old CMS inside the new one. When a headless implementation mirrors legacy page templates too closely, content can remain coupled to presentation and the organization captures little of the reuse or channel flexibility that justified decoupling in the first place. Core content types should represent reusable business entities such as Product, Customer Story, Person, or Announcement. Page and assembly types can still exist where editors need layout control, but they should reference reusable content rather than contain every piece of it. A Homepage can be an assembly entry; it should not become the only place its content can live.
| Legacy page template | Business object | Why the change |
|---|---|---|
| Product detail page | Product | Reused in nav, comparison, search, and email |
| Case study page | Customer Story + Person reference | Quotes and people become reusable entities |
| Solutions landing page | Composed page referencing Solution | Layout stops being a content type |
| Press release template | Announcement | One type serves web, newsroom, and syndication |
Consolidation is one visible outcome. On a program unifying two Sitecore estates in Contentstack, the team reduced roughly 249 components across the two sites toward approximately 100. The number alone does not prove a better model, but removing duplicate and near-duplicate components can make editorial choices clearer, reduce maintenance, and create a more consistent foundation for reuse.
Page-oriented modeling can be reasonable for a small brochure site with one channel, one locale, and a limited content team. Headless becomes more compelling when the same structured content must support multiple sites, products, channels, locales, or independently released front ends. Minimal modeling can also be appropriate for an MVP used to test whether decoupled delivery fits the organization. The opposite risk is over-modeling: unnecessary types and relationships can make the editorial experience harder even when the architecture is technically elegant.
4. How localization works
Suite-based platforms such as AEM provide an opinionated localization structure through features such as blueprints, Live Copies, translation integrations, and multisite governance. Headless platforms including Contentful and Contentstack also provide locale configuration, fallback behavior, localized entries, publishing controls, APIs, and translation integrations, but they do not automatically define the organization’s regional operating model. Decoupling gives teams more freedom to design localization around their channels and governance needs; it also makes decisions about inheritance, ownership, workflow, and fallback behavior explicit architectural responsibilities.
Four decisions have to be explicit before architecture begins:
| Decision | What has to be answered |
|---|---|
| Locale structure | Language-only, or language plus region, and which fields are translatable |
| Content ownership | Which locales can author independently and which inherit from a master |
| Translation workflow | Which service, which trigger, and who approves regional copy |
| Fallback behavior | What a visitor sees when a locale variant does not exist |
Translation tooling is a decision that has to be made deliberately. The NetApp program runs 10 languages through Trados, while the two-estate Contentstack consolidation uses Phrase’s Contentstack connector. Both approaches can work, but the choice affects workflow stages, translatable fields, authentication, automation, and regional review. Changing the translation architecture after the content model has been implemented is possible, but it usually creates additional mapping, integration, and QA work.
A genuinely single-locale organization with no international requirement may not need a full localization architecture. If expansion is plausible during the expected life of the platform, however, define the locale strategy and field-level localization rules during modeling even if additional locales will be enabled later. Headless platforms make later expansion flexible, but adding localization to a live model can still require changes to fields, workflows, integrations, publishing logic, and frontend fallback behavior.
5. Who owns each integration
An integration list is not an integration plan. The list says Marketo exists. The plan says who configures the form handler, who owns the field mapping, who tests lead flow end to end, and what happens when the mapping is wrong at 2am on launch night.
The NetApp estate connects Coveo, Marketo, Adobe Analytics, Adobe Target, Lytics, Trados, Bynder, and YouTube, with video delivery migrated from Brightcove. These eight systems each require a client-side owner who understands the business logic and an implementation owner who understands the technical dependency. When either side is missing, access, mapping, testing, or launch responsibility can remain unresolved.
| Integration | Client owner | Agency owner | Decision still open |
|---|---|---|---|
| Search | Digital ops | Engineering | Index rebuild before or after cutover |
| Marketing automation | MarOps | Engineering | Field mapping parity vs. cleanup |
| DAM | Brand | Engineering | Native connector vs. asset re-upload |
| Analytics | Analytics lead | Engineering | Tag parity vs. re-tagging to new model |
| CDN and WAF | IT security | DevOps | Retain incumbent or adopt bundled option |
That last row represents a real architectural decision. On the two-estate consolidation, the client retained Akamai because its security and operations teams required specific control over cache policy, certificate management, WAF behavior, and purge operations. A headless CMS can deliver content through its own API CDN while the website uses a separate edge provider, so the CMS, hosting, CDN, and WAF choices should be evaluated as related but distinct parts of the delivery architecture.
What “settled” looks like on paper
Readiness is auditable. Before kickoff, a program should be able to produce six artifacts, each with a name attached and a date on it. If a document exists but nobody will sign it, the question is not settled.
- Classified content inventory with disposition per URL, not a page count
- Resolved taxonomy conflict log that every team using the disputed terms has signed
- Approved content model that editors have walked through against real publishing tasks
- Localization architecture covering structure, ownership, workflow, and fallback
- Integration matrix with a named owner on both sides for every system
- Single accountable client-side decision maker with authority to break ties
The final requirement is frequently underestimated. Without a person who can reconcile stakeholder input and make binding decisions, questions about taxonomy, modeling, scope, and governance can remain open long enough to affect cost and schedule. Software still matters, particularly when the target architecture introduces new delivery, integration, or operational responsibilities, but organizational decision-making is often the less visible source of migration risk.
When the honest answer is “not yet” or “not at all”
Some programs are not ready, and starting anyway converts a scheduling problem into a financial one. Two signals are worth checking before a kickoff date gets locked.
The first signal is whether content work has been budgeted as a real workstream. Audit, cleanup, mapping, restructuring, migration development, redirect planning, and content QA can rival or exceed the effort required to configure and build the platform, depending on the condition of the estate. Instead of applying a universal build-to-content ratio, estimate the work from sampled content types, locale counts, transformation requirements, approvals, and QA coverage. A budget focused only on platform implementation leaves the most variable part of the migration unpriced.
The second signal is complexity. A practical readiness score can consider brand count, locales, content volume, custom integrations, regulated approvals, fixed launch dates, and the number of channels or front ends the new platform must serve. Any weighting should be treated as an internal planning heuristic, not an industry benchmark, and calibrated against completed delivery data. A high score indicates that discovery needs greater depth and stronger evidence; it does not, by itself, predict cost or rule out migration.
Then there is the harder answer. If the current platform meets the operating model, the editorial complaints are workflow problems rather than platform problems, and no license or end-of-life event is forcing the timing, the honest recommendation is to fix the workflow and revisit in a year. A replatform is an expensive way to solve a governance problem.
Frequently Asked Questions
What needs to be ready before a CMS migration starts?
Five things have to be settled before kickoff: a classified content inventory with a disposition for every URL, a resolved taxonomy that all teams agree on, an approved content model built on business objects rather than page templates, a documented localization architecture, and an integration matrix with named owners on both the client and agency side. A sixth requirement is organizational: one accountable client-side decision maker with authority to break ties.
How long should discovery take before a CMS migration?
A focused readiness phase may take two to four weeks when the estate is bounded and the right stakeholders and data are available. Multi-brand, multi-locale, regulated, or integration-heavy programs may require longer or may divide discovery into stages. The phase should produce enough evidence to approve the content scope, target model, localization approach, integration responsibilities, and delivery plan. Duration should follow complexity; a universal minimum is less useful than clear exit criteria.
Why do CMS migrations go over budget?
CMS migrations go over budget for several reasons, including underestimated implementation work, content scope discovered after planning, integration complexity, localization requirements, delayed decisions, and insufficient content QA. Page counts can expand once local variants, PDFs, redirects, and undocumented properties are included. Headless migrations also require teams to budget for the frontend, delivery layer, integrations, preview experience, and operational ownership rather than treating the CMS license as the whole platform.
Should we redesign our content model or migrate the one we have?
Redesign it selectively rather than migrating it unchanged. Preserve content, metadata, relationships, and URL intent that still serve the business, but reconsider structures that exist only because of the legacy CMS. A headless architecture creates the most value when reusable entities such as Product, Customer Story, Person, or Announcement are separated from their presentation. Page and assembly types can still support editorial composition, especially for campaign and landing pages. For a small single-channel site, a simpler page-oriented model may remain the better choice.
How do we find a partner who will tell us if we are not ready?
Ask how their discovery phase ends. A partner that treats unknowns as things to figure out during build will produce a fast, attractive proposal and bill the difference later. Ask for a sample discovery output, ask what they would recommend if the honest answer were “do not replatform,” and ask which of your decisions they expect you to own. eight25 works with enterprise teams to scope migrations before commitment, including the parts most vendors defer until the contract is signed.
Before you set a kickoff date
If your team is heading toward a replatform, close the five decisions above and use their answers to test the target architecture. Headless is a strong fit when structured content needs to be reused across sites, products, locales, or channels; when frontend teams need independent delivery cycles; or when the organization needs a composable integration layer. If those requirements are absent, a conventional CMS may be simpler to operate. eight25 runs this as a focused discovery engagement that produces an inventory, proposed content model, localization architecture, integration matrix, and documented architecture recommendation before implementation begins.
Start a scoping conversation with our team
eight25 CMS Migration Services