Why Your CMS Choice Matters More Than Ever (And It's Not About Features)

Choosing the right CMS is like the wild west at the moment. There is 101 different options and they all have electric sales teams hounding you. Internally, marketing wants a supreme editing experience, IT wants a simple and straight forward hosting platform and product asks about integrations. Everyone has their checklist of must haves.

These are all valid wants and needs but it's viewed in a very myopic lense. The tech landscape - especially with the advent of AI - is changing at such a rate of knots, that choosing a platform that can evolve with it is integral.

Going into 2026, AI integration, personalisation, headless architecture, omnichannel delivery aren't just nice-to-haves anymore. They're increasingly table stakes and the platform that looks sufficient for today's feature checklist might not give you the flexibility you'll need in eighteen months.

But we are all aware that 'The best laid plans are laid to waste' and at the moment, it seems more about being directionaly correct than being stagnant but accurate in the now. The difference compounds over time in ways that don't show up in initial evaluations.

Open Source vs Vendor Lock-In

The vendor lock-in conversation is a toss up as old as software itself. Do you want an out of the box solution (less setup cost + more overhead) or one that is more configurable (more setup + less overhead). I'm here to argue that you can get both with open source and (surprise surprise) Drupal.

Let's start with a vendor. This seems great from the outset. You get a great demo, a stunning website and then are thrown on some monthly plan. To be fair, for a lot of use cases, this is plenty. A nice website, mimimal maintenance and you're away. Once you start getting more involved, you will run into issues. When your CMS vendor decides AI features require their enterprise tier at triple the price, you pay or you don't get the feature. When they decide your integration use case isn't common enough to prioritize, you wait or you work around it. When their roadmap diverges from your needs, you have limited recourse.

This plays out in subtle and rather frustrating ways. I've worked with organisations on Webflow who wanted sophisticated member authentication but the platform doesn't support it natively, so you end up integrating third-party services like MemberStack or Xano. Each integration adds cost, adds complexity, and creates dependencies on vendors who might themselves raise prices or change terms. You are in a death spiral of vendor lock-in and the further you go, the harder (and more expensive) it is to unwind.

Open source platforms like WordPress and Drupal operate differently. When you need a capability the platform doesn't provide, you can build it. When a vendor raises prices, you can switch providers. When your requirements evolve in unexpected directions, you have the flexibility to evolve with them. Drupal has some extremely powerful developer tools and can roll out features in a near instant if need be (can you tell we are biased). This is a focus on autonomy and control over your business.

If your requirements are stable and you don't see much evolution over the next few years within a vendor's model, lock-in is probably a good choice. But if you're operating in a space where requirements change frequently, where competitive advantage comes from doing things others can't, open source gives you that edge. For more on how Drupal handles these challenges in practice, see our thoughts on the State of Drupal in NZ.

Total Cost of Ownership

Most of the time, we only look at upfront cost. Quotes like the following: WordPress site for $15,000, Webflow for $20,000, Drupal for $60,000. Easy choice right? But those numbers represent only the build cost, and the build is often the cheapest part of the total investment.

McKinsey research found that hidden costs exceed direct licence and hosting fees by an average of 2.7 times. A TrustRadius study showed that licence costs represent only 36% of five-year total costs. So where does the rest go? Implementation, customisation, maintenance, upgrades, integrations, and all the work required to keep the platform meeting your needs as those needs evolve.

This is where the year-one maths breaks down. That $15,000 WordPress site might need $8,000 in custom plugin development in year two when you add personalisation. Then another $12,000 in year three when plugin conflicts and technical debt require refactoring. The hosting that started at $96/month grows to $400/month as you scale. Security incidents add unplanned costs. Performance optimisation becomes necessary. By year three, you've spent $60,000 (give or take) and you're still dealing with platform limitations.

Meanwhile, the Drupal build that cost $60,000 upfront included the architectural decisions and flexibility that accommodate growth. Adding personalisation might cost $8,000 in new features, but it doesn't require rebuilding existing architecture. Multi-site capabilities are built-in rather than bolted on and maintenance costs are predictable because you're not constantly fighting technical debt.

I'm not arguing Drupal is always cheaper and a lot of the time it isn't, especially for simple sites. But the gap narrows considerably when you account for evolution over time. A platform migration study found one company (Bombas) saved $108,000 in their first year after migrating platforms. Another organisation calculated $2.3 million in foregone revenue during an 8-month migration when they finally hit the limitations of their initial platform choice.

The pattern that occurs continuously is organisations optimise for upfront cost, then spend years paying the delta in workarounds, technical debt, and eventual migration. The platforms that look expensive initially often prove cheaper when you measure over 3-5 years and account for the full cost of ownership (including opportunity costs from things you couldn't build).

Growth Potential

Evaluating a CMS is hard but it should be in line with evaluating the business. Is growth on the cards or are you playing reserved? This can all be rather murky. You think you know what integrations you'll require, what scale you'll reach and what features you'll need but you're probably wrong - not because you're bad at planning, but because requirements change in response to market conditions, competitive pressures, and opportunities you haven't encountered yet.

This is where platform flexibility becomes valuable. Not flexibility in the abstract sense of "can do anything," but practical flexibility around the specific kinds of evolution that matter. Can you add sophisticated personalisation without a full rebuild? Can you integrate with internal systems that don't have pre-built connectors? Can you support member portals, gated content, and complex authentication? Can you go headless if you need to support mobile apps or digital signage?

WordPress handles some of this well - the plugin ecosystem covers many common use cases and is massive. But as requirements get more specific or more complex, you start hitting limitations. Plugins conflict with each other and custom development gets complicated because you're working around theme constraints. Performance suffers under the weight of too many plugins and the platform that felt flexible at the start feels constraining two years in.

Webflow's strength is speed to launch for standard use cases, but that strength becomes a weakness when you need to do something the platform wasn't designed for. Every workaround is expensive. Every integration requires additional services. The visual builder that made simple things easy makes complex things harder.

Drupal has historically had the opposite problem - being immensely flexible but with a steep learning curve. This created the "Drupal is hard" perception that kept many organisations away. But the platform has evolved significantly. Canvas (Drupal's new visual page builder released December 2025) provides the drag-and-drop editing experience people expect from modern CMSs whilst maintaining the underlying flexibility that makes complex requirements achievable. Premium theme marketplaces like Dripyard now offer beautiful, accessible designs out of the box. The UX gap that used to exist has closed.

What matters isn't the features you can check off today but whether the platform can grow with you into requirements you haven't defined yet. This is especially true when you consider how AI is about to reshape what we expect from content platforms.

AI Changes Everything

It's become a bit of a running joke that AI is a game changer but reality is only just starting to catch up with the hype we have heard the last 2 years. We are at a pivotal crutch in AI capability and it is time to capitalise.

AI capabilities have been (and will continue) evolving faster than any CMS vendor can adapt. The model that's best for content generation today won't be best in six months. The tool you choose for personalisation might get superseded by something better next quarter. New capabilities will emerge that you can't anticipate and we have no idea which AI tools you'll actually want to use because the landscape is moving too fast to predict.

This is where platform architecture becomes decisive. Proprietary platforms will build AI features, but they'll choose which models to integrate, which use cases to support, and which tier to gate them behind. You'll get AI, but you'll get their version of it, on their timeline, at their price point. Open source platforms let you integrate with any AI service, swap tools when better alternatives emerge, and build capabilities that aren't mainstream yet. When your CMS constrains which AI tools you can use, you're building on a foundation that limits your ability to take advantage of emerging capabilities. The gap between what's possible with AI and what your platform supports will grow, not shrink. We're already seeing organisations on rigid platforms struggle to add AI features that organisations on flexible platforms are deploying rapidly.

Things such as simple quality of life features are becoming second nature and expected. Semantic search, content generation and workflow automation - all things that used to be multiple different systems - can lie within your CMS with full governance over build and strategy. For practical examples of what's possible, check out our guide on AI quick wins for Drupal.

Building Systems

The CMS evaluation process usually focuses on matching features to requirements. Can it do X? Check the boxes, tally the scores, choose the platform with the most checkmarks at the best price. That approach made sense when CMSs were static, but that world is gone.

The total cost of ownership isn't primarily about dollars anymore but also about accumulated constraints. Every time your platform can't support a requirement, you choose between working around it or not doing it at all and those constraints compound. After three years, you might be spending more on workarounds than you would have spent on a platform that had the flexibility you needed from the start.

For organisations where digital is core and competitive advantage comes from building experiences others can't replicate, choosing a platform that preserves optionality is worth the investment. For others with simple, stable requirements, a simpler platform might be the right choice, even with some lock-in.

What matters is being honest about which situation you're in and taking a long term approach. In a world where AI is reshaping everything and the pace of change is accelerating, the platforms that preserve your options are worth more than the platforms that tick the most boxes today.

---

If you're evaluating CMS platforms and want to talk through your specific situation, particularly around AI integration and Drupal's modern capabilities, reach out. We work with organizations across New Zealand to match platform decisions to actual needs, not just feature checklists.