The question "should we get a new CMS?" usually arrives before the diagnosis. Somebody has become frustrated – the editorial team, the developers, management – and the frustration gets translated into a platform question quickly, because that is the easiest thing to act on. A new CMS is a project with a start and an end. Working out what is actually wrong is harder, and it often gets skipped.
First: what actually hurts?
What people call "a CMS problem" is usually one of three different things, and each needs a different fix.
- A maintenance problem. Old plugins, no updates, code nobody dares touch, no version control. That is not the platform's fault – it is eight years where nobody cleaned up. The fix is cleanup, not a new system.
- An implementation problem. The platform is fine, but this particular build is not – a product structure that was never thought through, an integration glued together at the last minute, a content hierarchy that made sense for the first project and not for what the site has become since. The fix is rebuilding the part that is broken, not replacing the foundation.
- A platform problem. This is the rarest of the three, and the strongest argument for a new CMS: the way the platform models data and handles workflows no longer fits what the business needs. Not because anyone implemented it badly – but because what the business needs to do does not fit the way the platform thinks about content.
A platform problem can also be more fundamental: the system is no longer maintained or security-patched, and staying on it is no longer safe.
The three get mixed up constantly, and that is expensive. A maintenance problem fixed with a migration is money spent on the wrong thing – and a real platform problem met with yet another cleanup is time that just postpones the same conversation a year later.
When the CMS is not the problem
Most "we should switch CMS" conversations start here, without anyone noticing. Plugins that overlap because different developers solved the same problem twice over eight years. A theme nobody dares update. No version control, so nobody knows what has actually changed since last time. None of that is a sign the platform is wrong – it is a sign the system has never had the maintenance it needed. I wrote the full list in The art of inheriting a WordPress installation; I will not repeat it here.
When the CMS has actually become the problem
A real platform problem looks different. It shows up when the way the system organises content and data no longer fits what the business needs to do. If a new feature keeps requiring another exception, another layer, or the same information stored in more than one place, it is worth asking whether the problem can still be solved within the existing platform.
The technical side is only half the story. A system can work flawlessly on a technical level and still be wrong, if the editorial team has outgrown it. If an editor has to know internal IDs to fix a page, copy the same content into three different places, or call a developer to create a new content type, the problem is not necessarily performance or old code. It is a sign that the system's workflows no longer match the organisation using it every day. Whether that calls for a new CMS or a better implementation of the existing one is exactly what needs working out.
What actually gets better?
Before deciding on a migration, there should be a concrete answer to: once we are done, we will be able to ___, which we cannot today.
"We get a newer codebase" is not an answer that carries a project of that size. "The editorial team can manage several markets without developer help" is. "Product data gets one model instead of living in three different places in three different ways" is too. The difference is whether the answer points to something someone can concretely do afterwards – not whether the code looks nicer.
What you leave behind
"We'll just build it fresh" sounds simpler than it is. Underneath sits content, URLs, redirects, metadata, structured data, images and files, users, integrations, forms, tracking, consent, historical data, editorial workflows, permissions, and everything the search engines already know about the site.
But there is also something less visible than the list.
The old solution contains eight years of decisions.
Some of them are bad. Some of them solve problems nobody remembers existed – an exception for one client, a workaround for a system that no longer exists, a rule nobody can explain any more but that still solves a real problem. Do not move anything before you know why it is there.
A migration is a project of its own
A migration is not installing a different system and pouring the old content into it. The old system typically has to keep working while the new one is built, and changes to content and data do not stop in the meantime.
That is why a migration also needs a plan for the transition: what moves automatically, what has to be rebuilt, what has to be tested, and when the new system takes over. "We'll just move the content over" often turns out to be the smallest part of the work.
Fix it, or switch?
Not because the system is old. Not because the code is ugly. And not because a different CMS looks better in a demo.
Switch when the existing system is in the way of what the business or the editorial team needs to be able to do – and when it costs more to keep working around the limitations than it does to move.
If the problem is instead plugins, missing updates and code nobody dares touch any more, you may not need a new CMS.
You need to get a grip on what you already have. That is also the part of the work on CMS solutions I most often get called in for.
