Website replatforming: the signals, the costs, and the phased path

TL;DR

For anyone deciding what their next website project actually is, before it goes into an RFP:

• The vocabulary matters more than it looks. A redesign changes what visitors see on the platform you already have. A replatform changes the platform underneath the experience you already have. A rebuild changes both. Most projects that go wrong were rebuilds nobody named.
• The signals point in different directions. Replatform signals are operational: licence renewals, developer velocity, security patches on an ageing CMS, markets the platform cannot absorb. Redesign signals are commercial: brand, message, conversion. Diagnose before you scope.
• Bundling both doubles the risk, and halves what you can learn. When traffic or conversion moves after a combined launch, you cannot tell whether the platform, the design, or the content caused it. Attribution is the quiet casualty of the all-in-one project.
• The phased route exists and it works. Change one layer, verify it against live traffic, then change the next. It turns one unbounded risk into a series of small, observable ones.
• Sometimes the answer is neither. If editors are productive, costs are sane, and performance is fixable in place, staying put is a legitimate outcome of the analysis, and any partner who never reaches it is selling you something.

Three words your RFP should use precisely

The terms get used interchangeably in briefs, and the confusion is expensive, because each one names a different project with a different risk profile, budget shape, and team.

A redesign is the same platform with a new skin. The CMS, the hosting, and usually the URLs stay where they are. What changes is what visitors see and how it converts: visual identity, layout, messaging, information architecture at the margins. It is fundamentally a brand and conversion project that happens to involve developers.

A replatform is a new platform under the same brand. The CMS, the front end, or the hosting change; the experience your visitors know is deliberately preserved, or close to it. Replatforming means moving the machinery: content models, templates, integrations, URLs, and editorial workflows all travel from one system to another. It is fundamentally an engineering and operations project that happens to involve designers.

A rebuild is both at once: new platform and new experience in a single programme. Sometimes that is the right call, and we will get to when. But it should be a decision someone makes on purpose, with the doubled risk priced in, not the accidental sum of a brand team’s wishlist and an IT team’s migration backlog.

There is a fourth word, migration, which in practice is the umbrella for the whole move: the inventory, the mapping, the cutover, the monitoring. Every replatform contains a migration. A pure redesign, done properly, barely touches one.

If what you want is the two options compared side by side as projects, our website migration vs website redesign guide does exactly that, and the website migration guide walks the full process end to end. This article owns the decision that comes before either: whether the platform is the problem at all.

The trap is that organizations rarely choose a rebuild. They arrive at one. A redesign brief picks up “and while we are at it, let’s finally get off the old CMS.” A replatform business case picks up “and the brand team wants the new identity live at launch.” Each addition sounds efficient, one agency, one launch, one line in the budget. What it actually does is fuse two projects with different owners, different success metrics, and different failure modes into a single event where nothing can be isolated.

The signals you need a replatform, not a redesign

Replatform signals live in operations and finance, not in how the site looks. If the honest complaints in your organization sound like the following, no amount of visual refresh will fix them.

The licence renewal is doing the maths for you. Platforms like Sitecore and AEM carry licence and infrastructure lines that made sense for the organization that bought them a decade ago. If the renewal figure now buys more than the platform returns, and the surrounding costs (specialist developers, upgrade projects, hosting) keep compounding, the platform itself is the cost problem. When we moved Bennetts’ three sites off a 2017 Sitecore install, total cost of ownership dropped by 70% against that baseline, and most of that was the licence, the infrastructure, and the standing dependency on specialist developers going away.

Small changes take weeks. A banner update that needs a ticket, a landing page that needs a sprint, a campaign that misses its window because the deployment queue was full. Developer velocity is a platform property. When every routine marketing task routes through engineering, the platform has stopped serving the team that publishes on it, and hiring more developers treats the symptom.

You are paying for security patches on borrowed time. End-of-life announcements, extended support contracts, plugin ecosystems drifting out of maintenance. Drupal estates past end-of-life and WordPress installs held together by ageing plugins both reach a point where the cost of keeping the old platform safe exceeds the cost of leaving it. A redesign on top of an unpatched CMS is repainting a house with a cracked foundation.

The platform cannot absorb your markets. New locales handled by copy-paste, brand sites forked into separate CMS instances, regional teams maintaining near-duplicate content because the platform has no real localization or multi-site model. This is the signal that scales worst, because every market you add multiplies the operational debt. Consolidating several sites onto one platform the whole organization publishes to is precisely what a replatform is for, and it is not something a redesign can even attempt.

Performance has a ceiling you keep hitting. If the platform’s architecture, not its configuration, is what keeps pages slow, then optimization work in place has diminishing returns. When Alpro replatformed from Gatsby to Next.js, with the CMS and the brand staying put, page performance rose 127.9% and SEO metrics 17.6%. Nothing about the design drove that. It was the machinery.

The signals a redesign is enough

Now the other column, and it deserves equal honesty, because a replatform sold to a company that only needed a redesign is a year of disruption for nothing.

The brand has moved and the website has not. The message changed, the market changed, the site still says what you were three years ago. Conversion is the complaint: traffic arrives and does not act, and the analytics point at comprehension and trust rather than speed. Editors, meanwhile, are productive. The CMS does what the team asks of it, costs are predictable, patches ship, and performance problems are the fixable kind: images, scripts, caching.

In that situation the platform is an asset, and the correct project keeps it. This is exactly what Descope did: two years after we built their site on Contentful, Next.js, and Vercel, they came back for a complete redesign to match a bold new brand identity. The platform did not change, because it did not need to. The content, the SEO, and the editorial workflow the team relied on all survived the rebrand, and the project stayed the size of a redesign instead of growing into a rebuild.

A useful test for which column you are in: imagine the current design, pixel for pixel, running on a modern platform. If most of your complaints disappear, you need a replatform. Imagine the current platform serving a brand-new design. If most of your complaints disappear, you need a redesign. If both lists survive their thought experiment, you are heading for a rebuild, and the next section is the most important one in this article.

Why bundling a redesign into a replatform doubles the risk

The efficiency argument for doing both at once is real: one project, one launch, one round of stakeholder alignment. The costs are quieter, and the biggest one is epistemic.

Attribution becomes impossible. A replatform changes the machinery under every URL. A redesign changes the templates, the content hierarchy, and often the information architecture on top of them. Launch both together and every metric that moves afterwards has two candidate explanations, or three once content edits are counted. Traffic dips: was it a redirect gap, or the new templates changing on-page signals, or the new navigation burying a section that used to rank? Conversion rises: was it the faster platform or the better page? You cannot tell. Which means you cannot fix the right thing when something breaks, and you cannot credit the right thing when something works, and the post-launch review becomes an argument instead of an analysis.

The risk surfaces multiply, not add. Each project has known failure modes. Replatforms lose traffic through dropped redirects, changed rendering, and forgotten technical signals, the full catalogue is in our guide to protecting organic traffic through a replatform. Redesigns lose conversion through untested layouts and buried journeys. Combined, they interact: the new design’s templates are being built on a platform nobody has operated in production yet, by teams discovering both at once, against a single immovable launch date. Debugging a problem means holding every variable in your head simultaneously.

Organizational attention is finite. A replatform needs your best engineering and content-operations people for its whole duration. A redesign needs your best brand and marketing people for its whole duration. A rebuild needs both groups, fully engaged, coordinating with each other, for longer than either project alone. Something else in the roadmap pays for that, and it is rarely priced in.

None of this means both-at-once is always wrong. It means the bundle should be a priced decision, not a drift.

The phased alternative

The pattern that keeps the risk decomposed is simple to state: change one layer, stabilize it, measure it, then change the next.

Replatform first, like-for-like, then redesign on the new platform. The strongest default when the platform signals dominate. Move the existing experience onto the new machinery with as little visual change as possible. Traffic behaves? Redirects hold? Editors publishing? Then run the redesign as its own project, on a platform where a component library and fast deploys make design iteration cheap. Each phase has one owner, one success metric, and one thing to blame.

Redesign first, replatform later. Right when the commercial pressure is urgent and the platform, while doomed, is stable: a rebrand with a public deadline, a merger, a product launch. The redesign ships on the old platform, earns its results attributably, and becomes the specification for what the new platform must reproduce.

Phase within the replatform itself. Even a single replatform does not have to be a big-bang cutover. Alpro’s move from Gatsby to Next.js ran page-type by page-type behind a router, old and new stacks serving live traffic side by side, so every step was verified against real users before the next one shipped. The first phase teaches you how the new platform behaves in production, and every later phase inherits that knowledge.

And the honest exception: sometimes both at once is right. When the old design cannot be reproduced on the new platform without absurd effort, or when you are consolidating several differently-designed sites onto one system and a shared design system is the point of the exercise, separating the phases would mean building things twice. Bennetts was exactly this case: three sites, one ageing Sitecore install, redesigned and replatformed together onto DatoCMS and Next.js, deliberately, with the migration controls carrying the extra risk, and the rankings held. The difference between that and the accidental rebuild is that the doubled risk was chosen, priced, and instrumented.

What each path costs in time and attention

Numbers depend on the estate, so treat these as shapes rather than quotes. The pattern that holds across projects: the money is the smaller surprise. The organizational attention is the larger one.

Two budget notes that briefs tend to miss. First, a replatform’s cost does not end at launch: the weeks after cutover need engineering time held in reserve for what monitoring surfaces, and the editorial team needs real onboarding, not a handover document. Second, the redesign hiding inside a replatform (or the reverse) is the most common source of a mid-project cost surprise, because it was never scoped as the second project it is. If the destination platform is headless, there is a further ownership shift to budget for, which we cover in what headless changes for SEO.

A note on ecommerce replatforming

In commerce, “replatforming” usually means moving the transactional engine: the catalogue, cart, checkout, and order flow from one commerce platform to another. The decision logic in this article still applies, but the stakes concentrate differently: revenue is interrupted by the hour rather than the quarter, product URLs carry both rankings and live demand, and the integration surface (payments, tax, ERP, fulfilment) dwarfs anything a content site deals with. If anything, the case for separating the replatform from the redesign is stronger, because a checkout conversion dip with two candidate causes is measured in money per day.

Where we work in that picture is the experience layer: composable commerce architectures that decouple the storefront your customers see from the commerce engine underneath, so the next engine swap does not force another full rebuild. If your question is purely which commerce engine to pick, that is a different evaluation with different specialists, and you should hear that from us early rather than late.

When staying put is the right call

The most useful thing a migration partner can tell you is that you do not need one yet, so here is our version.

Stay put if the complaints are cosmetic and the operations are healthy: a redesign on the platform you have is cheaper, faster, and less risky than any move. Stay put if the licence has years to run and the platform is merely unfashionable rather than failing; unfashionable is not a business case. Stay put if the organization cannot spare the attention this year, because an under-resourced replatform is more dangerous than a maintained legacy platform. And be suspicious of a replatform whose real motivation is a redesign: if what everyone actually wants is a new look, changing the machinery underneath it adds risk and cost to a project that did not need either.

The moves that do justify themselves look like the signal list above: compounding licence and specialist costs, blocked editors, security exposure, markets the platform cannot hold. When we run the audit at the start of a migration engagement, “stay and fix in place” is a real possible recommendation, and the fact that we sometimes give it is what makes the other recommendation worth trusting.

Common questions

What is website replatforming?

Website replatforming is moving a website from one platform to another, typically the CMS, the front-end framework, the hosting, or all three, while preserving the content, URLs, search equity, and brand experience the organization has already earned. It is distinct from a redesign, which changes the visual experience on the platform you already have.

What is the difference between a replatform and a redesign?

A redesign changes what visitors see and keeps the platform: same CMS, same hosting, mostly the same URLs, new design and messaging. A replatform changes the platform and keeps the experience: new machinery underneath, deliberately continuous look and content. Doing both at once is a rebuild, and it should be a deliberate, priced decision rather than scope drift, because combining them makes post-launch cause and effect nearly impossible to attribute. For the full side-by-side comparison, including when combining them makes sense, see website migration vs website redesign.

How long does website replatforming take?

It depends on the size of the estate, the number of integrations, and how much content has to be restructured rather than transferred, so treat any quote given before an audit with suspicion. The reliable shape: redesigns run in months, replatforms in quarters, and phased approaches trade a longer calendar for much lower risk per step. The post-launch watch period, weeks of monitoring with engineering time in reserve, is part of the timeline, not an optional extra.

Should we redesign during a replatform?

Default to no: migrate like-for-like, stabilize, then redesign on the new platform where iteration is cheap and results are attributable. The exceptions are real but specific: when the old design cannot reasonably be reproduced on the new platform, or when several differently-designed sites are being consolidated onto one design system and separating the phases would mean building twice. In those cases, accept the bundled risk knowingly and instrument the launch so questions can still be answered.

Does replatforming hurt SEO?

It does not have to, but it is the riskiest event in the life of an organic channel, and the losses come from known, preventable failures: dropped redirects, changed templates, forgotten technical signals. The full prevention checklist, from URL inventory to the post-launch watch period, is in our website migration SEO guide.