How do I know if my CMS is actually the bottleneck?

Check whether every content change needs a developer ticket, whether release windows force pages to wait weeks, and whether templates are too rigid for a simple new page type. Two or three of these being consistently true points at the platform.

Should we replatform before ruling out the other causes?

No. Replatforming is expensive and slow to reverse. Test one recent slow page first against a different CMS, a different vendor, and a single owner with no extra sign-off round to see which one would actually have shipped it faster.

Is it the CMS, the agency, or the process?

Q: What are the signs it's the agency, not the CMS?

Slow turnaround on changes the platform itself does not gate, chasing required for status updates, and everything billed hourly with no fixed scope. The same request moving quickly with different hands on the same system is the clearest tell.

Q: Can a bad internal process look exactly like a CMS problem?

Yes. Multiple sign-off rounds, briefs that change mid-build, and no single owner able to approve a page all produce the same symptom as a slow platform: everything takes far longer than it should.

"We need a new CMS" is usually the second thing said in that meeting, not the first. The first is normally "why does everything take so long", and the CMS gets the blame because it's the thing everyone can point at. Sometimes it deserves it. Often it's covering for one of the other two.

Replatforming is expensive and slow to reverse, so it's worth ten minutes of honest diagnosis before committing to it as the fix. Three places the actual bottleneck tends to live, and the tells for each.

Signal set one

It's genuinely the CMS

Every content change, even a headline, needs a developer ticket. Landing pages can't be built without a release window, and release windows are weeks apart. Templates are rigid enough that a simple new page type means custom development rather than a new layout choice. If two or three of these are true regardless of who's doing the work or how well the request was briefed, the platform itself is the ceiling.

Signal set two

It's the agency or vendor, not the system

Turnaround is slow on work the CMS itself doesn't gate; a change that should take an hour takes a week because it's queued behind someone else's priorities. Communication requires chasing rather than status updates arriving on their own. Everything gets billed hourly with no fixed scope, so the incentive to move fast is weak. If the same request would move quickly with a different pair of hands on the same platform, the platform isn't the problem.

Signal set three

It's the process, not the tools

A single page routinely needs three or more rounds of internal sign-off before anyone touches it. The brief changes mid-build because nobody owned the decision before work started. No one person can approve a page alone, so every delay is really a queue of approvals rather than a queue of development work. This one is the easiest to misdiagnose as a tooling problem, because a slow process feels exactly like a slow system from the outside.

The test that actually separates them

Take one recent slow page. Ask: would it have shipped faster on a different CMS, with the same brief and the same sign-off chain? If yes, it's the CMS. Would it have shipped faster with a different agency, on the same platform, with the same approvals? If yes, it's the vendor. Would it have shipped faster with one owner and no extra sign-off round, on the exact same platform and the exact same team? If yes, it was never a tools problem.

A new CMS fixes a CMS problem. It has never once fixed a sign-off problem.

Why this is worth doing before you commit

Replatforming the wrong problem is expensive twice

Once, in the actual migration cost. Twice, because the real bottleneck, an agency relationship or an approval chain, survives the move intact and shows up again on the new platform within a quarter, at which point the team has spent months and a real budget proving the CMS was never it. Running the test above first costs an afternoon.

The CMS is the easiest thing to blame because it can't defend itself in the meeting. That doesn't make it the thing that's actually broken.

Keep reading: Website and CMS migration

Questions worth answering

Check whether every content change needs a developer ticket, whether release windows force pages to wait weeks regardless of urgency, and whether templates are too rigid for a simple new page type. Two or three of these being consistently true, regardless of who does the work, points at the platform.

Slow turnaround on changes the platform itself doesn't gate, chasing required for status updates, and everything billed hourly with no fixed scope. The tell is that the same request would move quickly with different hands on the exact same system.

Yes, and it's the most commonly misdiagnosed of the three. Multiple sign-off rounds, briefs that change mid-build, and no single owner able to approve a page all produce the same symptom as a slow platform: everything takes far longer than it should.

No. Replatforming is expensive and slow to reverse. Run the test on one recent slow page first: would a different CMS, a different vendor, or one owner with no extra sign-off round have actually shipped it faster. Whichever answer comes back yes is where the real problem lives.