Website Replatform: The Questions Digital Teams Ask Most
The renewal quote lands 40% above last year, or the vendor posts an end-of-life date for your version, and a website replatform stops being a roadmap item and becomes a decision with a deadline. Within a week you are in a room with engineering, marketing operations, and someone from procurement, and everyone has brought a question. They sound like nine different questions. In practice they are three, asked by people who each have a different reason to be nervous.
eight25 is a Contentful Solution Partner and Contentstack Preferred Partner with enterprise replatforming experience across organizations including NetApp, Sophos, and Ellucian. Across those programs, the same questions surface repeatedly, and most become much easier to answer once the team has audited the content estate, integrations, governance model, and publishing workflows rather than relying on assumptions in the original brief.
Every replatform question is really one of three questions
Once you strip the phrasing, the list collapses. Teams ask about scope, about risk, and about ownership. Nothing else. The questions feel unrelated because they arrive from different people with different incentives, but they resolve against the same three sets of facts.
There is also an architectural question underneath all three: how tightly should the next CMS be coupled to the website itself? Traditional platforms tend to combine content management and presentation more closely. Headless platforms separate those concerns and deliver structured content through APIs, which can make content reuse, front-end evolution, integration, and multi-channel delivery easier. That flexibility is valuable only when the organization has a reason to use it, which is why architecture should follow the audit rather than the other way around.
| What the room asks | What it is actually asking | What settles it |
|---|---|---|
| Cost, timeline, “do we rebuild everything,” phased or big bang | How much of our estate is genuinely in scope? | A content and integration audit, not the page count in the brief |
| SEO, editors, cutover, wrong-platform regret | What breaks, and can we put it back? | Mitigations someone has rehearsed, not mitigations someone has promised |
| In-house or agency, who does what, who runs it in year two | Who is accountable, and when does that change hands? | A workstream split written down in discovery |
The sorting is not academic. Treat these as nine separate questions and you get nine answers from four vendors with no way to line them up. Sort them into three and you can ask every vendor the same three things, then watch which ones have actually done the work and which ones are describing a methodology.
Scope questions: what this actually costs and how long it takes
How long does a website replatform take?
In our experience, a mid-market estate with a redesigned component system, structured content model, standard integrations, established governance, and reasonably fast internal decision-making can often be delivered in roughly six to nine months. Larger multilingual estates with legacy customization, personalization dependencies, complex integrations, or multiple stakeholder groups can extend into nine to fifteen months or beyond. The important variable is usually not page count alone, but how much architecture, content, integration, and governance work sits behind those pages. .
Fast is possible. NetApp moved roughly 14,000 pages across 10 languages from SAP/RWS Tridion to Contentstack in five and a half months. Phase 1 was deliberately constrained around migration rather than trying to combine every redesign ambition into the same release. That scope discipline, combined with a detailed audit and clearly separated workstreams, is what made the timeline achievable.
How much does it cost?
Enterprise agency-led replatform budgets are set by scope rather than a standard range, with CMS licensing and other platform costs typically budgeted separately. The variables that move the implementation number most are usually the content estate, number and complexity of integrations, governance and workflow requirements, migration automation, localization, and whether the program also includes a substantial front-end redesign or rebuild.
Effort distributes fairly consistently across the programs we have delivered: 30% to 40% on architecture, content modeling, audit and planning; 30% to 40% on implementation and integration; 20% to 30% on content migration, QA, redirects and operational readiness. If a proposal puts almost nothing in the first bucket, that work has not been removed from the project. It has been moved into the middle of the build, which is the most expensive place for it to happen.
Do we have to rebuild the whole site?
No. Content, content models, design systems, front-end code, integrations, and infrastructure are separate decisions, and they do not all need to move at the same time. This is one reason headless architecture can be useful during a replatform: separating the CMS from the presentation layer gives teams more freedom to decide what should be preserved, rebuilt, or replaced independently. What should rarely be copied blindly is the old CMS’s template structure. Recreating legacy templates one-for-one as new content types can carry the same constraints into a more flexible platform. Can We Migrate Without Rebuilding the Whole Site? The Scope Realities
Phased or big bang?
This is a question that is often answered before enough of the estate is understood. Phasing should be informed by the content model, governance requirements, integration map, SEO concentration, migration dependencies, and the organization’s tolerance for running two platforms in parallel. An experienced partner may have an early hypothesis, but it should remain a hypothesis until discovery produces enough evidence to defend it.
Big bang fits when the estate is small enough to migrate and QA as one block, the deadline is external and immovable, the content model is a clean break rather than a translation, and redirect parity can be guaranteed at the CDN or edge layer rather than assumed from CMS-resolved routes. Sophos took that route: legacy Drupal, WordPress and Sitecore estates unified into a single Contentstack experience against a fixed 11 December 2025 launch date, and the date held.
Phased fits above a certain complexity, particularly multi-brand or multi-region governance differences, heavy localization with regional content ownership, or integration-heavy architectures where dependencies have to be replaced one at a time. It carries its own failure mode, and it is the expensive one. A phased plan with no sunset date for the legacy platform tends to become a permanent dual stack, which costs more than either clean approach.
What if the honest answer is “don’t replatform”?
Sometimes it is. If your current platform meets the editorial, integration and governance needs of the team, and the only real driver is the licensing line, renegotiation usually beats a replatform. Ask a prospective partner when they last told a client not to replatform. If they cannot name an occasion, their recommendation on your estate is worth less than they think.
When does headless actually make sense?
Headless is not automatically the right answer because a platform is newer. It becomes compelling when the organization needs structured content reused across multiple experiences, wants the front end to evolve independently of the CMS, has a meaningful integration ecosystem, or expects content to serve channels beyond a single website. API-first platforms such as Contentful and Contentstack are designed around that separation. For a small site with simple publishing needs and little integration complexity, that additional architectural freedom may not justify the operational change. For a multi-brand, multi-locale or fast-moving enterprise content operation, it often does.
Risk questions: what breaks
Will we lose SEO?
A replatform does not have to cause lasting SEO loss, but redirects are only one part of the migration. The team needs URL-level mapping, server-side permanent redirects where URLs change, preserved metadata and canonicals, updated internal links and sitemaps, crawl testing, and post-launch monitoring. For large headless estates, implementing redirects at the CDN or edge can make them easier to manage independently of the CMS, but the important requirement is complete, tested redirect parity rather than the specific infrastructure layer used. SEO Continuity Through a Headless CMS Migration.
What happens to our editors?
Editors are often the group most affected by the change because a move from page-centric publishing to structured, reusable content changes how they work. A content model that looks elegant in an architecture workshop can still be painful in production if preview, workflow, permissions, localization, and publishing guardrails are treated as secondary concerns. Headless does not remove the need for a strong editorial experience; it makes designing that experience deliberately part of the implementation.
The upside is real when the authoring design gets attention. On NetApp, publishing a PDF had required roughly 30 to 40 minutes of manual CMS work per document in Tridion; after migration it became an upload, with metadata pulled automatically from Bynder and H-tag assignment handled by the system instead of by hand. That kind of result comes from designing the authoring experience alongside the content model, not after it.
Training is the other half. Sophos ran structured author training through November and December before the December launch, segmented by content type and team rather than delivered as one generic session. NetApp had four structured CMS sessions plus dedicated translation-workflow training before go-live.
What if we pick the wrong platform?
This fear usually gets answered with reassurance, which is the wrong shape of answer. The useful version is a decision record. If the architecture recommendation is documented with the trade-offs that were rejected and the reasons, then a platform that turns out to be a poor fit in year three is a decision you can revisit with evidence. If the recommendation arrived as a conclusion with no visible reasoning, you have no way to tell whether the platform was wrong or the implementation was.
Worth naming the counterweight: staying on a mature platform you have outgrown is also a decision, and its constraints can compound over time. One reason teams increasingly consider headless and composable architectures is that the CMS, front end, search, personalization, DAM, and other services can be evaluated as separate parts of the stack rather than replaced as one monolithic system. That does not eliminate switching costs, but it can reduce how much of the architecture has to change when one capability no longer fits. Signs You Have Outgrown Your Legacy CMS covers the signals that separate a platform problem from an implementation problem.
What actually breaks at cutover?
Cutover issues tend to concentrate around predictable areas: redirects, caching, integrations, forms, authentication, analytics, search, localization, and content published during the migration window. Our approach is to rehearse the cutover rather than rely on a written launch plan alone: validate the production architecture, test redirects and critical journeys, define the content-freeze window, prepare a genuine rollback path, staff a launch war room, and move into structured hypercare after the switch. The exact runbook varies by architecture. On NetApp and Sophos, those controls were planned before launch rather than improvised during it.
Even a heavily tested enterprise cutover can surface issues that were invisible in staging. The objective is therefore not to assume a perfect first hour; it is to know which failures are tolerable, how they will be detected, who owns the response, and when rollback is triggered. A rollback plan that has never been rehearsed is considerably less useful than one the delivery team has already tested.
Are we sure the audit is right?
Ask this one twice. Page counts move in both directions and they move late. NetApp’s estate was initially estimated at around 40,000 pages, refined during audit to roughly 12,000, and ultimately launched at approximately 14,000 pages across 10 languages. Late-stage migration snapshots still surfaced apparent gaps, which had to be reconciled against the latest audit to separate genuinely missing content from pages requiring review or redirects that had already been resolved. The lesson was not that the original audit had failed, but that an enterprise content inventory has to remain a living source of truth through launch.
Ownership questions: who does the work, and who owns it afterwards
Should we do this in-house or hire an agency?
Score the complexity before comparing cost. A simple agency-fee-versus-internal-salary comparison treats existing engineering capacity as if it has no opportunity cost. If senior developers spend six months on migration work, something else on the roadmap is likely to move. That deferred work should be included in the business case alongside implementation fees, platform costs, migration risk, and the value of bringing in a team with recent experience on the target architecture.
As a simple eight25 planning heuristic, we sometimes score a few characteristics that tend to increase coordination and implementation complexity: multi-brand +5, multi-locale +5, 1,000 to 5,000 pages +5, more than 5,000 pages +10, custom integrations +5, regulated governance +5, and a hard external deadline +5.
| Score | Lowest-risk path |
|---|---|
| 0 to 10 | In-house is viable, if platform experience and roadmap capacity are both genuinely there |
| 11 to 20 | Hybrid: agency-led, in-house embedded |
| 21 or higher | Agency-led implementation |
This is not an industry benchmark or predictive model. It is simply a conversation tool we use to expose where delivery complexity is coming from before a team decides how much specialist support it needs.
In-house genuinely wins in a narrow window, and it is worth naming honestly: single brand, single locale, roughly under a hundred pages, a team with recent hands-on experience of the target platform, two or three integrations they already maintain, a roadmap that can absorb a six-month focus shift, mature documented editorial governance, and a launch date that is internally chosen and can move. A hard external launch date changes that calculation quickly because it reduces the team’s ability to absorb delays caused by unfamiliar platform work, access dependencies, integration surprises, and governance decisions. The less schedule flexibility the organization has, the more valuable recent experience with the target architecture becomes.
Who does what?
A replatform is six parallel workstreams, not “move the content and rebuild the templates.” Strategy, implementation, SEO, localization, QA and post-launch support each have their own staffing curve and their own peak, and each needs a named owner before the SOW is signed rather than after. Who Handles Strategy, Implementation, SEO, Localization, QA, and Post-Launch Support in a CMS Migration breaks the split down workstream by workstream.
The hybrid version is not a fifty-fifty split. On NetApp it was a formal co-development arrangement: NetApp’s own developers ran their own repositories, branches and Vercel environments for the areas they owned, including Account Home, Events, personalization and account login, and submitted pull requests into eight25’s staging branch. Internal capability got built through delivery instead of transferred at the end.
Who owns the platform on day 31?
This is the question that separates a replatform from a rescue. Name the post-launch ownership model before launch, and make sure the people who will run the platform are embedded in the build. Some organizations want full internal ownership; others deliberately retain an experienced web team to manage releases, platform evolution, experimentation, and ongoing optimization. Both models work when they are chosen early.
The questions that do not get asked, and should
Three questions rarely make it into the room, and each of them predicts trouble better than anything on the standard list.
- What are we sunsetting, and on what date? A legacy platform with no retirement date and no named owner does not retire. Sophos retired Sitecore by December and deliberately kept Acquia for smaller properties, which is a decision. “We’ll decommission it eventually” is not.
- What is our decision latency? Timelines are driven less by build speed than by how quickly your organization can settle structural questions. If a content model decision takes three weeks to clear, that number, multiplied across a program, is your real schedule.
- What gets routed to a change order, and who prices it? Scope discipline is what protects a fixed date. On Sophos, everything beyond the Phase 1 migration went through a priced change-request log, which is what kept the December date intact.
Frequently Asked Questions
What questions should we ask before a website replatform?
Ask three, and ask every vendor the same three. First, what does your audit say about our real page, locale and integration count, as opposed to what our brief says? Second, which mitigations for SEO, editor readiness and cutover have you rehearsed rather than promised? Third, which workstreams do you recommend we keep in-house, and who owns the platform on day 31? A partner who answers all three with specifics has done the work. A partner who answers them with methodology names has not.
How long does a website replatform take for an enterprise site?
Six to nine months for a mid-market estate with standard integrations and fast internal decision-making. Nine to fifteen months or longer for multilingual enterprise estates with legacy customization and personalization dependencies. Faster is achievable with scope discipline: NetApp moved roughly 14,000 pages across 10 languages in five and a half months by holding Phase 1 to a lift-and-shift and deferring the redesign.
Is it cheaper to run a CMS replatform in-house?
Usually not, once you count what the comparison leaves out. Agency fees versus internal salaries ignores the roadmap work that will not ship while your senior engineers are on the migration, and for many organizations that opportunity cost exceeds the implementation fee. In-house is genuinely the right call for single-brand, single-locale estates under about a hundred pages where the team has recent experience of the target platform and the launch date can move.
Will we lose search traffic when we replatform?
A CMS replatform does not inherently mean losing organic search traffic, but SEO continuity has to be designed into the migration. Preserve or deliberately map URLs, implement permanent server-side redirects where URLs change, carry forward metadata and canonicals, update internal links and sitemaps, test crawlability, and monitor indexing after launch. On large headless implementations, teams may manage redirects at the CDN or edge so they remain independent of CMS routing, but that is an architectural choice rather than a requirement.
How do we find a good website replatform partner?
Ask a prospective partner to walk you through the decisions behind recent programs, not just the finished case studies. What did discovery uncover that the original brief had missed? What did the team recommend against? Which risks changed the architecture or migration plan? What did the client keep in-house? Strong partners should be able to explain their reasoning in detail even when client confidentiality prevents them from sharing the underlying documents. eight25 is a Contentful Solution Partner and Contentstack Preferred Partner specializing in enterprise CMS replatforming and migration. Our discovery work typically maps the content estate, integrations, component architecture, governance model, editorial workflows, SEO requirements, and migration options before the build is locked. The output is not simply a platform recommendation; it is a defensible architecture and migration plan, including the trade-offs, phasing strategy, and the workstreams we believe the client should retain internally.
Before you commit budget to a replatform
If your team is working through these questions now, the useful next step is usually to make the estate visible before locking the implementation scope. That means understanding what content actually exists, which integrations need to be rebuilt or reconnected, how editors need to work, and whether a traditional, headless, or broader composable architecture best fits what the organization is trying to do next. eight25 runs that work through a focused discovery engagement that ends with a documented architecture recommendation, migration scope, phasing plan, and the trade-offs behind each decision – something your marketing, technology, and finance teams can evaluate before committing to the full build.