Replatforming off a legacy CMS — how to do it without losing traffic

A content management system rarely fails all at once. It ages. The version falls behind, security updates slow and then stop, the people who knew it move on, and every change becomes a little slower and a little riskier than it should be. At some point a business has to move off it — and the fear that holds most teams back is losing the search traffic the old site has spent years earning. This is a practical guide to replatforming off a legacy CMS without that happening.

The short version: a legacy CMS is a cost that does not show up as a crisis, so it never makes the agenda — until it does. Replatforming is the answer, and the search-traffic risk that scares everyone is real but entirely manageable. The move can be done in stages, with the site live throughout and the rankings carried across deliberately. The mistake is the big-bang switch; the safe path is a planned, staged migration.

What a legacy CMS quietly costs you

The damage a legacy CMS does is rarely dramatic, which is exactly why it is dangerous. It is a slow tax. Pages load slower than a modern platform would allow, and you have little ability to fix it. Every content or design change takes longer and feels riskier, because the system is dated and few people fully understand it. New features are hard to add because the platform was not built for them.

Underneath all of that sits the most serious cost: security. When a CMS version falls out of support, it stops receiving security updates — and an unsupported, public-facing system is a genuine risk, not a theoretical one. None of this announces itself. It just quietly makes the business slower, more exposed, and more expensive to run, year after year, for a reason nobody puts on a slide.

Signs it is time to replatform

A few signs are reliable. The CMS is on a version that is no longer supported, or is heading there. Security updates have become rare or stopped. The people who originally built or understood the system have left, and changes now involve nervous guesswork. Simple updates take far longer than they should. You have been told a feature the business wants is “not possible” on the current platform. Hiring someone who knows the technology has become hard.

Any one of these is a yellow flag. Several together mean the platform has crossed from “dated but working” into a genuine liability — and the cost of staying has started to outweigh the cost of moving.

Choosing what to move to

The replatforming decision is not only about leaving the old system; it is about choosing the right new one, and that choice should be driven by what the site actually is. A content-heavy marketing or publishing site often belongs on a modern, well-supported CMS such as current WordPress. A site that is really an application — portals, tools, complex interactions — may belong on a modern web framework instead. The honest answer depends on the site, and a good replatforming project starts by deciding it deliberately rather than defaulting to whatever is familiar.

What matters in every case is that the destination is current, supported, well understood, and able to carry where the business is going next — including, increasingly, AI features the legacy platform could never host. The goal is not just “newer.” It is a foundation that will not become a legacy problem again in three years.

The migration, step by step

A replatforming project has a clear shape. It begins with an audit: a full inventory of the existing site — every page, every URL, every piece of functionality, and which pages actually earn traffic. That inventory is the map for everything that follows. Content is then migrated onto the new platform, structured cleanly rather than dumped. The site is rebuilt on the new foundation — usually an opportunity to improve on the old design and performance, not merely to copy it. Functionality and integrations are rebuilt properly. And the URL redirect map is prepared from the audit.

Throughout, the existing site stays live. The new site is built and tested in parallel, and the switch happens only when it is genuinely ready. Nothing about a careful replatform requires the business to go dark or to freeze while the work happens.

Protecting your search traffic — the part that scares people

This is the fear that delays replatforming projects for years, so it deserves a direct answer. Search rankings are attached to URLs. When a site moves platform, the danger is that URLs change and the rankings attached to the old addresses are lost. The protection is correspondingly direct: every URL on the old site must either keep its address on the new one, or be sent to its new home with a permanent redirect.

That is why the audit matters so much — it produces the complete list of URLs to preserve. The redirects are built from that list and go live at the moment of switchover. Page content and structure are kept recognisably consistent so the new pages are clearly the same pages in search terms. Handled this way, search traffic carries across the move intact. The fear is reasonable; the loss is avoidable.

Doing it without a big-bang switchover

For a large or complex site, the whole project does not have to land in one moment. A replatform can be staged — moving the site across in sections, with the old and new running alongside each other during the transition and traffic shifting gradually. This is the same incremental, low-risk approach that makes any modernisation safe: smaller steps, each one verified, each one reversible, rather than a single dramatic cutover with everything riding on it.

For a smaller site a single clean switch is fine, because the risk is contained. For a big one, staging the move is what turns a frightening project into a controlled one. Either way, the principle holds: the site stays live, and no step is taken that cannot be checked before the next begins.

Why teams wait too long — and what it costs

Almost every replatforming project happens later than it should have. The reason is rarely ignorance — teams usually know their CMS is ageing. It is that a legacy CMS never forces the issue. It keeps working, after a fashion, so the replatform never becomes this quarter’s emergency. It loses, every quarter, to whatever is genuinely on fire — until something finally breaks and it becomes the emergency itself.

The cost of that delay is real, even though it stays invisible. Every month on an unsupported platform is a month of security exposure. Every slow page is conversions quietly lost. Every change that takes three times longer than it should is engineering effort spent on friction instead of progress. And the longer the wait, the larger the eventual project becomes: more content accumulates, more workarounds pile up, and more of the people who understood the old system leave. Replatforming is never cheaper or easier later than it is now.

None of this argues for panic. It argues for putting the replatform on the calendar — scoping it, sequencing it, and giving it a real slot — rather than leaving it as a someday item that the next urgent thing will always outrank. The teams that handle it well are the ones that treat it as planned, scheduled work, decided before a breakage forces the timing for them.

When to modernise in place instead

Replatforming is not always the answer. Sometimes the content and the URLs are fine and the real problem is the version and the infrastructure — in which case upgrading and modernising the existing platform in place may be lower-risk and lower-cost than moving to a new one. The honest decision depends on how far gone the current platform is: a CMS that is merely behind can often be brought current, while one that is genuinely end-of-life, unsupported, and unhirable-for is a replatform. A good first step is an assessment that tells you plainly which situation you are in.

The honest path

A legacy CMS will not force the issue with a dramatic failure. It will just keep costing the business quietly — in speed, in risk, in the effort of every change — until someone decides to act. When that time comes, replatforming is a well-understood project, not a leap into the dark. Audit the site, choose the new foundation deliberately, migrate carefully, and treat URL continuity as a core requirement rather than an afterthought. Stage the move if the site is large. Done that way, you come out the other side on a platform that is fast, secure, supported, and ready for the next decade — with the search traffic you spent years earning still intact.

Common questions