Your CMS Isn’t the Problem. Your Approach Is.

Josh Brittenham

Development, and Strategy

March 18, 2026

The CMS is never really the problem. But it’s almost always the first thing to get blamed, and that confusion is exactly how rebuilds spiral before they start.

Here’s what usually happens. An organization hits a wall: the site is slow, editors are frustrated, leadership is asking why publishing takes three days, and someone surfaces the obvious conclusion. “We need to rebuild.”

That’s not wrong. But it’s incomplete. Because the next step is almost always to treat the rebuild as a technical problem to be solved with a better platform… and that’s where things quietly start to go sideways.

The Rebuild Starts Before the Strategy Does

When teams frame a CMS project as a technology decision, the conversation immediately moves to platforms, stacks, and feature comparisons. The business is evaluating demos. The developers are scoping integrations. And somewhere in the middle of all that, nobody has asked the questions that actually determine whether this rebuild will succeed: How does content get created here? Who publishes it, under what conditions, and how fast do they need to move? What has to be true for this system to still be working well in three years?

We see this pattern constantly. An organization spends months selecting the right CMS, then loses another three months because the migration strategy wasn’t defined until the end. Or they build an elegant, flexible architecture and then watch their editorial team struggle to use it because nobody prototyped the admin experience alongside the public-facing design.

Good intentions. Predictable mess.

The Patterns That Sink Projects

None of this is rare. After enough of these projects, you start to recognize the same four failure modes appearing in almost every rebuild that goes wrong.

The first is migration debt: the decision, made early and quietly, to “figure out migration later.” Later always comes at the worst time. Content audits surface inconsistent taxonomies, broken relationships, and templates nobody remembers building. Migration scripts that should have been running in parallel with development get written in the final sprint. Teams hit the wall right before launch.

The second is over-customization. Developers are problem-solvers, and CMS projects give them a lot of problems to solve. The trouble is that not every editorial challenge needs a custom post type or a bespoke field group. Every deviation from what the platform does well out of the box is maintenance debt and it quietly accumulates until the organization is dependent on a developer for changes that should only take ten minutes.

Next is treating the editorial interface as an afterthought. A CMS is not just a backend. It’s the daily workspace for a communications team. When the rebuild focuses on the public-facing experience and leaves the admin as a functional but joyless afterthought, editors make mistakes, content stagnates, and the organization never gets the efficiency gains it expected.

Lastly? API ambition without an integration plan. Headless setups, in particular, have a way of revealing this gap. When a data model changes mid-project and three connected systems — a CRM, a donation platform, an email tool — break in different ways, you know the integrations weren’t mapped before the architecture was set.

Want more like this?

Get fresh insights from the WDG team, delivered straight to your inbox. Subscribe below!

What Content-First Actually Means

When World Central Kitchen came to us, the stakes were unusually clear. Their site was handling over 520,000 monthly page views. During a humanitarian deployment, that traffic could spike dramatically, overnight, with no warning. Their communications team needed to publish fast, in two languages, with confidence. The Prismic platform they were on just couldn’t keep up.

The temptation in that situation is to move quickly to a platform decision. But the work we did first — before a single line of code — was to audit what existed: 3,000+ content items, 8,600+ digital assets, editorial workflows that reflected years of accumulated habits and workarounds, integrations with Salesforce, Classy, and Mailgun that had to survive the transition without disruption.

That audit shaped everything that followed. The information architecture, the migration scripts, the component library, the user roles. By the time we were building, we weren’t making structural decisions on the fly. We were executing against a model we understood.

This is what “content-first” actually means in practice. It doesn’t mean ignoring technology. It means letting the shape of your actual content and the reality of how your team works determine the architecture, rather than bending your team to fit the architecture you’ve already built.

Editors Are Users. Treat Them That Way.

We’ve worked on projects where the public-facing site launched beautifully and the editorial team spent weeks relearning workflows they thought would get easier. That gap is not a small problem. It compounds over time into outdated content, frustrated staff, and eventually another rebuild conversation.

With WCK, we ran recorded training sessions tailored to their specific editorial and communications workflows, planned honestly around how the team works in real life. The goal wasn’t just knowledge transfer. It was self-sufficiency: editors who could publish confidently, troubleshoot independently, and manage content during a crisis without needing to call anyone.

At scale, this discipline matters even more. When we helped the Independent Insurance Agents & Brokers of America consolidate 37 disconnected sites into a single governed multisite network, the editorial efficiency gains were only real because staff could actually use the new system. That’s not an afterthought. That’s the work.

Launch Is a Milestone, Not a Finish Line

The organizations that get the most from a CMS rebuild are the ones who treat launch as a handoff, not a conclusion. That means documented ownership. It means defined maintenance processes. It means someone on the team knows what to do when something breaks at 11pm during a crisis deployment and doesn’t need to track down a developer to find out.

A CMS rebuild gives you a rare window to align your technology with how your organization actually works. Most teams use it to rebuild the same dysfunction in a newer stack. The ones who don’t start earlier, think more carefully about their content and their people, and resist the urge to make every decision a technical one.