When Should You Stop Fixing a CMS and Replace It?

Open your ticket tracker and find the one that keeps coming back from the dead. Closed in March, reopened in June, closed again with a slightly cleverer fix, reopened last week. Same page, same bug, same quiet pride when it finally held. And some part of you already knows you'll be right back here. I've watched that reopening ticket in enough pre-migration audits to land on a rule that's almost embarrassingly simple: replace a CMS when the problems are structural, and keep fixing when they're configurable. What I'm actually watching is whether a fix solves the problem or just rents you a few months before the same kind of problem wanders back in. When a team is paying that rent over and over, patching one class of issue on a loop, I stop recommending fixes and start talking replacement. Here's how I tell the two apart, 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

So here's what I actually think, since you asked. Most of the teams I meet are leaning toward replace when they should stay, and staying long past the point they should have moved, and the only thing that separates the two is evidence, not the mood in the room. Before you pour more into the current platform or commit to a new one, get an honest picture of what you're holding: how many pages carry real value, what's duplicated or dead, what would break in a move. If you're genuinely on the fence, lean toward staying until the compounding cost of staying clearly crosses the cost and risk of moving. That's the cheaper bet far more often than people want to hear.

That's why this thing exists. 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. Do that, and the ticket that keeps rising from the dead stops being a feeling and becomes a number you can point at. Which is the only honest way to decide whether to finally bury it or keep patching it.