After enough pre-migration audits, I've landed on a simple rule: replace a CMS when the problems are structural, and keep fixing when they're configurable. The tell I look for is whether each fix actually solves the problem or just buys a few months before the same kind of problem comes back. When a team is renting time — patching the same class of issue over and over — that's when I stop recommending fixes and start talking about replacement. Here's how I tell the difference, and the mistake I watch teams make most.
The sunk-cost trap I see every time
Almost every team I look at replaces its CMS years later than it should have, and it's rarely for a technical reason. It's sunk cost. They've paid for licenses, trained editors, built custom modules, and hauled their content into this setup more than once. Walking away feels like throwing all of that out — so instead they patch. Another plugin, another workaround, another late night before a launch. Each fix looks reasonable on its own. Stacked up, they're an expensive way to avoid a decision.
What I try to point out is that the time and money already spent are gone either way. The only question that changes anything is forward-looking: what will the next two years cost on this platform versus a new one? Framed that way, a lot of "let's just fix it" calls start to look different.
Fixing vs. replacing — the line I draw
When I dig into a site a team wants to replace, the first thing I try to work out is whether the problem lives at the surface or in the architecture.
I call a problem fixable when it's at the surface: a template, a setting, a plugin, one slow page, a caching rule. I can point at the cause, change one thing, and it stays fixed.
I call it structural when it comes from how the platform itself works — how it models content, how it renders pages, what it assumes about your team and your channels. You can't configure your way out of that. You can only work around it, and I've never seen a workaround that didn't eventually breed more workarounds.
What tells me it's structural (replace)
These are the signals that, when I see several of them feeding each other, move me from "fix it" to "replace it":
- The team builds around the CMS, not with it. When basic things — a new page type, a simple layout — need a developer and a workaround, the platform is fighting you.
- Editors can't publish without developers. If every content change is a ticket, you're paying engineering rates for copywriting.
- Performance can't be fixed inside the platform. When I can't get Core Web Vitals to pass without rebuilding how the CMS renders pages, that's architecture, not tuning.
- Security and maintenance are a treadmill. A steady stream of plugin updates and CVEs to chase is both a cost and a risk that never really goes down.
- You've outgrown the content model. Localization, structured content, reuse across channels — if you're forcing these into a model that wasn't built for them, the seams show.
- Cost climbs without new value. Rising license, hosting, and developer time for the same output usually means you've outgrown the platform's pricing and its ceiling.
- Your version is end-of-life. An unsupported major version is a forced re-platform anyway — the only question is whether you do it on your schedule or the vendor's.
- You're quietly falling out of search and AI answers. When a platform can't emit clean structured data or stable URLs, you drop out of the results — and the AI answers — your competitors still show up in, and you usually don't notice until the traffic's already gone.
One of these on its own is worth watching. Three or four at once, each making the others worse, is a structural problem — and I've never seen those get cheaper by waiting.
What tells me to leave it alone (keep it)
Just as often, I look at a site a team is itching to replace and tell them not to. The signs it's still worth fixing:
- The complaint is about one page, template, or feature — not the whole experience.
- The fix is a setting, a plugin, a theme change, or a caching rule, and it stays fixed.
- Editors are productive and the platform still does what the business needs.
- The pain is recent and traces to a specific change, not a slow drift over years.
A lot of what I hear called a "CMS problem" is really an implementation problem. I've watched well-built sites on old platforms run circles around poorly-built ones on modern stacks. If your platform can still do the job and your team can still move, keep it — and spend the migration budget somewhere with a clearer payback.
The part I have to say out loud: replacing is risky
Before anyone talks themselves into a rebuild, I make them price in the risk, because it's real. Major replatforms routinely lose 20–60% of organic traffic for months, recovery to old levels can take well over a year, and a large share of migrations blow their budget or timeline. Replacing a CMS because a newer one looks shinier, or because one release cycle went badly, is how I've watched teams trade a manageable problem for an expensive one.
So the bar I hold "replace" to isn't "this CMS annoys us." It's this: the compounding cost of staying — lost editor time, lost performance, lost reach, rising spend — is now bigger than the one-time cost and risk of moving. Until that line crosses, staying is usually the cheaper bet. After it crosses, staying is the expensive one.
My one-question gut check
If you want the short version, ask it of your last handful of CMS fixes: did each one solve the problem, or buy a few months before the same kind of problem came back?
Solving means it's gone and the team moved on. Buying time means you're paying, over and over, to defer a decision you've already half-made. A platform that keeps generating the same class of problem is telling you something — the workarounds aren't the solution, they're the symptom.
Decide with a map, not a mood
Whichever way you're leaning, I'd make the call on evidence. Before you sink more into the current platform or commit to a new one, get an honest picture of what you actually have: how many pages carry real value, what's duplicated or dead, and what would break in a move. That turns "it feels like time" into something you can defend — and if you do replace, it's the same map that keeps the migration from bleeding traffic.
That's the whole reason I built this. The free "Should you switch CMS?" tool walks you through the fix-versus-replace call in a few minutes, and a free scan grades your current site and flags what a move would break — so you're deciding with the map in front of you, before you commit either way.