Choosing a CMS: Lessons from Seven Platforms in Production

"What CMS?"

Most CMS conversations I've been in over the years start in the wrong place. Someone names a platform: "we're moving to Contentful" or "we're rebuilding in Sitecore." By the time I'm in the room the decision is often already made, without the questions that would have helped the team see whether it was the right one.

I've worked across seven commercial CMSs in production: Drupal, WordPress, Umbraco, Storyblok, Strapi, Sitecore, and Shopify. Plus the no-code cluster (Webflow, Framer, Elementor, GoHighLevel, Squarespace, Ghost) for founder-led and MVP work. Plus conceptual fluency in Contentful and Sanity, and Contentstack on the radar. The point isn't the count. It's the pattern across them.

Platform choice is one of the hardest decisions a business makes. Most organisations end up with a CMS that doesn't fit how they work, how they edit, or where they're heading. This is what I've learned about how to make the call before the marketing layer makes it for you.

Strategic considerations

Five questions I ask before recommending a CMS, in order.

Who's editing? Vendor demos never start here. They start with features. But the people who'll use the platform every day are the ones who decide whether it delivers or quietly fails. I've watched marketing teams work around brilliant headless platforms for months because the authoring experience was punishing. The features were all there. Nobody used them. The OU's Drupal estate worked because it served a distributed editorial team across academic and commercial units, with workflows designed around how those teams actually wrote. Umbraco's visual editor at ExpressTest worked because non-technical editors could update protocol content at the pace public health guidance changed, without engineering tickets. Get this question wrong and the platform becomes shelfware regardless of how powerful it is.

What's the governance scale? The editor experience question taken into the strategic frame. Multi-brand, multi-region, multi-language, distributed editorial across business units, federated governance. A platform that works for one team in one brand often breaks the moment a second brand or a second language arrives. The OU's Drupal estate worked because distributed editorial governance was designed in from the start. Sitecore's enterprise positioning is partly about multi-brand and multi-region governance at scale (which is also why it costs what it does). Storyblok and Strapi at VMO2 had to serve a post-merger context where editorial governance across two heritage brands was the substantive structural question. Choose for the governance scale you're actually running, not the one you started with.

What does the content need to do? Content that mostly informs (editorial, marketing) has different needs from content that drives transactions (commerce). Content that's mostly static has different needs from content that's structured and reusable. This is where I've observed businesses struggle with their platform choice down the line: a content-heavy brand stuck with a commerce platform, a commerce business stuck with a publishing one. Shopify and Shopify 2.0 served Lucy & Yak's commerce needs because the platform's core job is commerce; content lives inside that. Storyblok and Strapi serve headless ambitions in larger estates because the content layer needs to flow across multiple brands, channels, and customer touchpoints. The real question isn't "which CMS is best?" It's "what is content's job in this business, and which platform was built for that job?"

Where does the content need to flow? Single-channel publishing (one website, served from one CMS) is a different problem from multi-channel publishing (web, app, customer support, partner integrations, AI agents, agent-driven retrieval). The channel set is expanding, not contracting. AI agents consuming structured content for retrieval-augmented generation are increasingly a first-order channel in platform choice, not a future-proofing afterthought. Headless and composable platforms (Storyblok, Strapi, Contentful, Sanity) earn their complexity premium when content genuinely needs to flow across this expanded channel set. They don't, when content is mostly going to one place. The Sitecore engagement for a US-based EdTech client was high-flexibility for a multi-channel future that justified the architecture. WordPress at a scale-up was right because the SaaS marketing site was the destination, not a hub feeding others.

What's the team's reality? The team you actually have, today, in the room. Not the team you'll hire. Not the team you wish for. Engineering capability, content team size, governance maturity, existing stack investments. WordPress for a small team with mostly marketing content. Umbraco for a .NET shop that wants visual editing. Headless for a team mature enough to manage the content modelling discipline upstream. The mismatch between platform sophistication and team capability is where most CMS implementations quietly fail.

The practical considerations

The questions above are strategic. They sit alongside five practical realities that the marketing layer obscures.

Complexity. What setup actually involves. Sitecore: the Ferrari engine of enterprise CMSs. Brilliant in the rare hands that actually need it. Sold to almost everyone else. Drupal: significant complexity, repaid in customisation, but only when there's engineering depth to maintain it. The marketing brochures describe ideal-state implementations; the reality is months of structural decisions and configuration before content can land. Choose for the complexity you can sustain, not the complexity the demo absorbs.

Budget. Total cost of ownership, not licence cost. The Ferrari analogy holds for budget too: Sitecore's licence is one cost; specialist engineers, agency partners, training, and ongoing support are the others. The headless platforms (Storyblok, Strapi) trade lower licence cost for higher integration complexity. WordPress and Shopify are cheaper to start; their constraints show up later. Budget for the five-year cost of running the platform, not the year-one cost of starting on it.

Build. What implementation actually takes. Templates, content modelling, integration, editor training, governance, migration. Each platform has a different distribution of effort across these. Headless platforms shift effort upstream (content modelling); traditional CMSs shift effort downstream (template work). Composable architectures need stronger upstream discipline than any of them. The build phase is where mismatches between platform and need become structural debt that costs years to clear.

Migration. Moving onto and off this platform. The CMS you choose today is the one you'll migrate from in five years. Choose a platform with strong content export, clean structured data, and minimal proprietary content shapes if you want migration to be tractable later. Strapi and Storyblok expose content as data; Umbraco and Drupal expose it as semi-structured pages; Sitecore wraps it deep inside proprietary structures. The cost of vendor lock-in is paid at migration time, not selection time.

Future development. Extensibility and integration. Will the platform support the integrations you don't have today (new analytics, new commerce, new automation)? Is vendor lock-in tight or loose? Can the platform be extended by your team, or do all changes go through the vendor's roadmap? Choose for the use cases you can see today, with extensibility headroom for the ones you can't.

What it taught me

Most CMS implementations I've seen fail were the platform failing to fit, not the platform failing on its own terms. Vendors sell features. Businesses need fit. Cutting through the marketing layer to ask the questions vendors won't is the senior work, and most organisations skip it before the contract is signed.

None of the seven platforms is wrong. All of them are right, in the right context. The senior call is matching context to platform with discipline, evidence, and honest assessment of the team that's actually in the room. The platform is the surface. The content strategy underneath, and the team that will run it, is the work.

And the role is evolving. As platforms get more disciplined, content strategy gets more strategic. The need for structured and composable content discipline upstream is growing, not shrinking.

Where it's going

The framework above is built from twenty years of choosing CMSs in their traditional shape: a platform that stores content, renders it as pages, and gets migrated when the business outgrows it. That shape is shifting.

Schemas-as-code (content models defined in your own repository, versioned in git, reviewed before they ship) move the modelling discipline upstream of the CMS itself. The schema isn't a setting; it's an asset. That changes who owns the content model and how it travels.

Content lakes (content stored as structured, queryable data, channel-agnostic by design) move content out from inside any single platform. The CMS becomes one consumer of the content alongside apps, AI agents, partner integrations, and surfaces that don't exist yet. The "five-year migration" line above still holds for traditional CMSs built page-first. It weakens fast for content lakes built data-first. If your content lives as structured data, swapping the delivery surface becomes a smaller exercise than swapping the platform.

The questions don't change. The shape of the answer does. The same five strategic questions and five practical considerations apply, but the answers tilt towards content-as-data over content-in-platform. AI agents accelerate this shift, not slow it. The composable and headless platforms named earlier are best positioned for it, already treating content as structured data. The ones built around page templates have a translation problem to solve.

This is where the senior content strategy work increases in value, not decreases. The schema gets committed. The choice is reviewable. The model gets read by more consumers than ever, including ones that don't read at all. Someone has to hold the whole system in their head while it gets built.