Can We Migrate Without Rebuilding the Whole Site? The Scope Realities
The site went live eighteen months ago. The board signed off on the design, the brand team finally stopped arguing about the navigation, and nobody wants to reopen that conversation. Then the renewal quote arrives 40% higher than last year, or the vendor announces end-of-life on your version, and you have to move platforms anyway. The first question every VP asks is the same one: can we do this without rebuilding the whole site?
The honest answer is yes, but only if you separate what “the site” actually contains. In most migrations away from a tightly coupled CMS, the visual design can carry forward while the delivery layer is reimplemented against the new platform. The content model usually determines more of the scope than the page count does. eight25 is a Contentful Solution Partner and certified Contentstack partner, and we have seen that pattern repeatedly across enterprise replatforms including NetApp and Sophos.
Yes, You Can Migrate Without Rebuilding the Whole Site. Here’s What That Means.
The question is unanswerable as asked, because “the site” is not one thing. It is five layers stacked on each other, and a migration treats each one differently. Most scope disputes trace back to a client and an agency using the word “rebuild” about different layers.
| Layer | Rebuilt in a migration? | What actually happens |
|---|---|---|
| Content (copy, assets, URLs, metadata) | Usually no | Extracted, transformed or remapped to the target structure, validated, and republished. Complexity is driven more by structural variance, relationships, localization, and exceptions than by raw page volume alone. |
| Content model (types, fields, relationships, components) | Usually, at least in part | Redesigned, normalized, or translated for the target platform. On complex migrations, this is often one of the largest scope drivers and one of the most important areas to resolve during discove |
| Front-end code (templates, rendering, routing) | Usually, when leaving a coupled platform | Reimplemented against the new delivery APIs and architecture. Existing front-end code may be reusable when the source site was already sufficiently decoupled, but traditional CMS-specific templates and rendering logic generally do not transfer directly. |
| Design system (tokens, type scale, grid, component specs) | Often carried forward | Existing visual rules, tokens, and component specifications can usually be retained when the design is still fit for purpose. The implementation changes; a full visual redesign does not have to. |
| Integrations (search, DAM, analytics, forms, CRM, consent) | Reconnected, adapted, or occasionally replaced | Each integration has to be mapped to the new architecture, re-established or replaced where necessary, and revalidated end to end. |
Read that table back against the proposal on your desk. If a “full rebuild” does not distinguish visual redesign from front-end reimplementation, ask exactly which one you are paying for. And if a “simple migration” contains no explicit content-modeling workstream, treat the estimate cautiously: structural problems discovered after build begins are one of the easiest ways for scope and cost to expand.
Leaving a Coupled CMS Usually Means Rebuilding the Delivery Layer. It Does Not Mean Redesigning the Site.
Vendors blur this distinction more than any other, and it is the one that decides whether the answer to your question is yes or no.
When you leave a traditionally coupled Sitecore, AEM, or Tridion implementation, the CMS-specific templates, rendering conventions, and much of the presentation logic generally stay behind. They are tied to each platform’s runtime and authoring model rather than being portable application code. A move to a headless CMS instead puts content behind delivery APIs and lets the presentation layer run independently. That normally means implementing or adapting a front-end application, often with a framework such as Next.js, while preserving the visual system where it still makes sense.
Much of what the design team produced can travel: color and spacing tokens, type scales, grid rules, breakpoint behavior, component specifications, and established interaction patterns are largely platform-agnostic. Reimplementing a design system you already own can eliminate much of the discovery, creative exploration, and stakeholder approval involved in a true redesign. That distinction can materially reduce both scope and organizational disruption.
NetApp is a useful example from our own work. The estate moved from SAP/RWS Tridion to Contentstack with a Next.js front end deployed on Vercel behind Akamai. Phase 1 intentionally retained the existing visual direction while the underlying delivery layer changed; the broader redesign was deferred to Phase 2.
A redesign genuinely belongs in scope when the current design predates a rebrand, fails a WCAG audit you are already committed to fixing, or was built for a page-centric authoring model that cannot be expressed as modular components without distorting it. That last case is especially important in older page-centric implementations. In those situations, the apparent “design system” may actually be a collection of page-specific layouts, making a clean migration to reusable structured components considerably harder.
It often does not belong in scope when the current design is still performing well, aligns with the brand, meets accessibility and usability requirements, and the real migration driver is licensing cost, platform risk, or end-of-life. Bundling a redesign into that program adds stakeholders and approval dependencies that may have little to do with the reason for migrating.
What you want out of this analysis is a template-level verdict, produced before scope is fixed:
| Verdict | Criteria |
|---|---|
| Carry forward | Design is current, actively used, and structure maps cleanly to modular content |
| Normalize | Same visual output, but three or four near-identical variants collapse into one |
| Retire | Unused, superseded by a newer pattern, or exists only as a workaround for a platform limitation |
The Content Model Is Where Your Budget Is Actually Decided
Page count is the number everyone in the room reaches for, but by itself it is a poor predictor of migration effort. A 3,000-page estate built on fragmented templates, shared-content relationships, multilingual variation, and personalization dependencies can be harder to migrate than a 10,000-page estate built on a small set of consistent templates. Structural variance is often the more useful predictor because it determines how many distinct mappings, exceptions, and workflows the migration has to accommodate.
Component sprawl is one of the places where discovery regularly changes the scope. In eight25’s Sophos/Secureworks work, two Sitecore estates were consolidated into a single Contentstack implementation, and the audit surfaced roughly 249 source components that were ultimately consolidated toward approximately 100 target components. In a project like that, normalization is not cleanup around the edges; it is a core part of the migration.
The mapping exercise looks like this, and it should exist before anyone commits to a price:
| Source components | Target content type | Decision |
|---|---|---|
| Hero (Standard, Campaign, Product, Legacy) | hero with variant + eyebrow fields | Normalize four into one |
| Card Grid 2-up, 3-up, 4-up | card_grid with a column count field | Normalize three into one |
| Promo Banner (2019, unused since redesign) | none | Retire |
| Product Spec Table | spec_table referencing product entries | Carry, but re-point at structured product data |
Volume estimates can move dramatically in either direction once the estate is audited properly. Locale variants, indexed PDFs, undocumented microsites, redirects, and content omitted from the original inventory can all change the apparent page count. NetApp’s estate moved the other way: an early estimate of roughly 40,000 pages was refined to approximately 12,000 during audit and ultimately landed near 14,000 at launch. The point is not that page counts always rise or fall; it is that a scope built before a page-level inventory is inherently less reliable.
The content layer is “no rebuild” with three exceptions
The first table says content gets migrated rather than rebuilt, and that holds at the level of copy and assets. Three things inside it do get rebuilt, and they are where automated migration tooling either earns its keep or quietly fails.
| What breaks | Why | How it gets handled |
|---|---|---|
| Rich-text embeds (inline video, interactive widgets, embedded CTAs) | Legacy implementations often store embedded widgets, CTAs, or media as platform-specific markup inside rich-text or body fields. A structured target model may represent those elements differently, so they cannot always be migrated as opaque markup without losing editability or functionality. | Extracted into separate entries and referenced, or converted into structured blocks. Anything with no target equivalent gets flagged for manual recreation before the migration runs, not after. |
| Cross-references between pages | Internal links and shared-content relationships point at source-platform IDs that stop resolving on the target. | An automated audit reports every reference by page ID, reference type, source URL, and resolution path. Unresolvable references become a scope item rather than a QA ticket. |
| URL history and version history | Legacy redirect chains and historical revisions do not necessarily map one-to-one into the target platform and should be treated as explicit migration decisions rather than assumed to transfer automatically. | Redirects get consolidated into a single mapping, tested against live referrer logs, and served at the CDN independently of CMS-resolved routes. Version history is an explicit decision: full preservation, archive-and-simplify, or clean start with the legacy platform kept read-only through the sunset window. |
Skip this analysis and a lift-and-shift discovers in UAT that several hundred pages contain content the new model has nowhere to put.
A near 1:1 model translation is defensible under three conditions together: a small estate, a genuinely clean existing model, and a hard external deadline such as an end-of-life date, a license non-renewal, or a compliance mandate. Translating the model and fixing it in a later phase is a rational trade there. It stops being one anywhere the existing model already causes editorial pain. Paying to reproduce existing technical debt on a new platform can make an initially inexpensive migration much more costly over its lifecycle. A near-1:1 translation is a valid tactical choice when speed matters, but it should be made deliberately rather than mistaken for architecture modernization.
Lift-and-Shift Is a Legitimate Scope, If Phase 2 Has a Date
The strongest version of “migrate without rebuilding” is not a promise that nothing changes. It is a deliberate separation of platform modernization from visual redesign. That allows teams to establish the content model, headless delivery layer, integrations, and migration foundation first, while scheduling a broader experience refresh separately when the business actually needs it.
NetApp is the clearest example from our own work. The program moved roughly 14,000 pages across 10 languages from SAP/RWS Tridion to Contentstack on a Next.js delivery layer in about five months. Phase 1 focused on migration and launch readiness while the visual redesign was deliberately deferred to a committed Phase 2 tied to a later business milestone.
Leadership raised the obvious objection partway through: high-visibility pages would launch looking the same as before. Slipping the date to bundle a redesign was one option. What happened instead was that the two questions were separated, executive approval was secured on high-fidelity components for the later phase, and that phase was committed to a date tied to something the business already cared about.
| Phase | Scope | What is explicitly not in it |
|---|---|---|
| Phase 0, Foundation | Content audit, model design, taxonomy, integration map, redirect strategy | Any build |
| Phase 1, Lift-and-shift launch | Content migration, new front-end implementation of the existing design, integrations rewired, redirect parity at the CDN | Visual redesign, new templates, new IA |
| Phase 2, Refresh | Redesigned components, IA changes, net-new templates | Platform work. The platform is already live. |
| Phase 3, Sunset | Legacy platform retired, license non-renewed, integration cleanup | none |
The condition that makes this work is the one people skip. Phase 2 needs a date, an owner, and a budget line before Phase 1 launches. Without all three, “we’ll redesign later” becomes a permanent lift-and-shift, and you have spent a migration budget to arrive at the same site on a new platform.
Where “Without Rebuilding the Whole Site” Actually Goes Wrong
Four failure modes account for most of the regret, and every one of them is visible in discovery if somebody looks.
The first is preserved debt. Translating templates one-for-one is the fastest way to carry old problems into a system that costs more to run. The model should be designed around what the business needs next, not reverse-engineered from what already exists.
The second is hidden business logic. Organizations leaving a coupled DXP routinely underestimate how much logic lives inside personalization rules, conditional rendering, audience configurations, and experience settings. Skip that inventory and you launch a modern platform with a real regression in business capability, which is the one outcome nobody budgeted for.
The third is author experience regression. Most migrations are architecture-led rather than editor-led. The model looks elegant in a workshop and painful in production when editors used to page-centric workflows are handed modular content without guardrails, preview support, or workflow design. A lift-and-shift makes this worse, because visual familiarity sets an expectation the authoring experience does not meet.
The fourth is front-end sprawl. Headless removes many of the platform’s constraints on your delivery layer, which is one of its advantages and one of its governance risks. Without component governance, teams can rebuild one-off variants, fragment the design system, and push content problems into code. Done well, the same separation gives teams independent control over content architecture and presentation without forcing every experience decision through the CMS.
How to Scope This Before You Sign
The scope question is answerable, just not from a proposal. Answering it takes a page-level inventory, a component audit with a carry/normalize/retire verdict on every template, an integration map, and an inventory of what the current platform is actually doing for the business today. Not what is licensed. Not what is documented. At eight25, that discovery work typically runs two to four weeks. On a large replatforming program, the goal is to spend a small amount of time resolving uncertainty before that uncertainty becomes build scope.
Ask every partner the same uncomfortable question: when you find business logic, authoring behaviors, or content relationships that don’t map cleanly into the new platform, how do you decide what gets rebuilt, redesigned, or retired? A partner who answers with a classification method and an example is thinking like a migration strategist. A partner who answers “we work in agile sprints” is thinking like an implementer, and those decisions will land on you at the worst possible moment.
One more option deserves saying out loud. Sometimes the right answer is not to migrate at all. If the current platform meets your editorial, integration, and governance needs and the only real driver is licensing cost, renegotiation is faster and lower-risk than any version of this project.
Frequently Asked Questions
Can we migrate to a new CMS without redesigning our website?
Yes. The design layer and the platform layer are separate decisions. Your visual design, meaning tokens, type scale, grid, and component specifications, is portable and can be reimplemented on the new platform without a redesign cycle. What cannot be avoided is rebuilding the front-end code itself, because template and rendering logic on a coupled platform like Sitecore or AEM does not transfer to a headless architecture. Budget for a front-end rebuild. Do not assume you need a design rebuild.
Do we have to rebuild our front end when we move to a headless CMS?
If you are moving from a traditionally coupled CMS implementation, usually yes. CMS-specific templates and rendering logic generally cannot simply be moved into Contentful, Contentstack, or another headless CMS. Instead, content is delivered through APIs to an independently deployed front end, often using Next.js or another modern framework. If your existing architecture was already decoupled, portions of that front end may be reusable. The important distinction is that the visual design can often carry forward even when the CMS-specific implementation cannot.
What’s the difference between a CMS migration and a website redesign?
A migration changes where content lives and how it is structured. A redesign changes what users see. They get bundled because both require front-end work, but they carry different stakeholders, approval cycles, and risk profiles. Bundling is reasonable when the design is already due for replacement, and costly when the only driver is licensing cost or platform end-of-life.
How much does it cost to migrate a site without redesigning it?
Skipping the redesign removes the design and creative-approval workstreams. It does not remove the two largest cost drivers: content model design and front-end implementation. Across the kinds of enterprise migrations eight25 delivers, effort commonly concentrates in three broad areas: architecture, modeling and discovery; front-end implementation and integrations; and content migration, QA, redirects and launch readiness. The exact mix varies substantially with the estate, which is why we do not recommend estimating from page count alone. A lift-and-shift compresses the design portion, not the structural portion. There is no reliable duration based on company size alone. Well-scoped enterprise migrations can complete in roughly five months, as NetApp and Qlik demonstrate, while estates with heavier customization, localization, integration dependencies, or redesign scope can take substantially longer. The meaningful predictors are structural complexity, decision speed, and how much work is allowed to run in parallel.
How do I find a migration partner who will scope this honestly instead of selling a full rebuild?
Ask for the classification method, not the estimate. A partner who can show you how they decide which templates get carried forward, normalized, or retired, and who produces that verdict as a discovery deliverable before build is committed, is scoping from evidence. eight25 runs this as a focused discovery process that produces a content inventory, component audit, integration map, and phasing recommendation before implementation scope is locked. A recommendation for a full rebuild should come out of that evidence. If the recommendation appears before the estate, components, integrations, and business logic have been audited, ask what architectural evidence it is based on.
Scoping the Real Work Before You Commit to a Rebuild
If your team is weighing a platform move against a redesign your board has not approved, the most useful next step is a clear look at what your current estate actually contains, well before an RFP goes out. eight25 helps enterprise teams separate what genuinely needs to change from what can carry forward: content models, templates, integrations, business logic, design patterns, and migration exceptions. That evidence lets you evaluate whether a headless replatform can modernize the underlying architecture without unnecessarily turning the program into a redesign. It turns “can we do this without rebuilding the whole site?” from a hope into a scoped answer.
Start a scoping conversation with our team
eight25 CMS Migration Services
Monolithic DXP vs Composable: An Architect’s Honest Assessment