How to Choose the Right CMS for Your Organization (And Why the Wrong One Will Cost You)

The CMS you inherited (and the one you're about to choose)

A communications director I worked with a few years ago described her organization's website situation this way: "We have 900 pages, six people who know how to publish, and a CMS that three of them refuse to open."

The platform had been chosen by IT, evaluated against a technical checklist, and signed off by a committee that included nobody who would actually be writing content in it. It could do almost everything they needed. It just made almost everything harder than it needed to be.

That's the pattern I see most often in CMS decisions gone wrong. The tool isn't broken. It just wasn't chosen for the people who have to live inside it.

The decision you make here compounds over years. A good CMS fades into the background and lets your team do their work. A bad one generates workarounds, editor frustration, governance gaps, and eventually a migration project nobody budgeted for. Evaluating it properly upfront is one of the highest-leverage decisions in your digital strategy.

Why CMS decisions go wrong

Most CMS evaluations focus on the wrong things. They compare features, not fit. They prioritize what the platform can do rather than what your organization actually needs it to do. And they almost never start with the most important question: who will be managing this, day-to-day, in two years?

Three failure modes show up repeatedly:

Over-engineered for the team. A platform chosen for its power and flexibility, deployed into an organization where the primary content editors are communications generalists with no technical background. The result is chronic underuse, reliance on a single technical gatekeeper, and content that goes stale because updating it is too hard.

Under-powered for the growth. A lightweight platform chosen for its simplicity, deployed into an organization that then adds microsites, multilingual content, an intranet, and a digital service portal over three years. Now you're managing workarounds on top of workarounds.

Governance mismatch. A platform with no meaningful role-based permissions, deployed into a department-heavy organization where legal needs to approve certain content before it goes live. The result is a publishing process built on email chains and honour systems.

The framework below addresses all three. But only if you fill it out honestly.

The five criteria that actually matter

1. Who will actually manage it

This is the criterion that most evaluations list last and should list first. Before you compare platforms, map your content team:

How many people will publish content regularly?

What is their technical comfort level (honestly)?

Is there a dedicated web person, or is publishing a secondary responsibility for comms staff?

Will external contributors (departments, partners, agencies) need access?

What does your IT or development capacity look like for ongoing support?

The answers determine your entire evaluation. A team of two generalists with no developer support needs a fundamentally different platform than a team of ten with a dedicated front-end developer. Platforms are not universally good or bad: they are appropriate or inappropriate for a specific team and context.

A useful exercise: ask your most reluctant content editor to describe their ideal publishing workflow in plain language. Build your evaluation criteria around that description.

2. Editorial workflow and governance

Governance is how content gets approved, updated, and retired. Most organizations don't think about it until it breaks.

Questions to ask about any platform you're evaluating:

Roles and permissions: Can you restrict what different users can see and edit? Can a department editor publish to their section without touching anyone else's content?

Approval workflows: Can content be routed for review before it goes live, or does everything publish immediately?

Content expiry and scheduling: Can pages be scheduled to go live at a specific time? Can you set a review date so content doesn't silently go stale?

Audit trail: Can you see who changed what and when? Can you roll back to a previous version?

Multilingual support: If your organization serves multiple language communities, does the CMS handle translation workflows natively or through a costly add-on?

For municipal and public-sector organizations specifically: role-based permissions and audit trails are not optional. They're how you maintain accountability for what's on your site and who put it there.

3. Scalability

Scalability doesn't just mean traffic volume. It means your CMS can grow with your organization's content strategy without requiring a rebuild.

Think through where you expect to be in three years:

Will you add microsites or subdomain properties?

Are you likely to add a digital service layer (online applications, bookings, payments)?

Will you need to serve content through channels beyond the website (mobile app, digital signage, API integrations)?

Is there a likely merger, expansion, or restructure that would change your content architecture?

A platform that handles your current site beautifully but can't support structured content reuse across multiple channels will become a constraint, not an asset, as your digital ambitions grow.

4. Integrations

No CMS operates in isolation. Evaluate how each platform connects with:

Analytics: Google Analytics 4, Adobe Analytics, or your analytics platform of choice

Search: Does the platform support on-site search natively, or does it require integration with a search service?

Forms and service delivery: Do you need the CMS to connect with booking systems, payment processors, service request tools, or a CRM?

Single sign-on: If editors authenticate through your organization's identity provider (Microsoft 365, Google Workspace), does the platform support it?

Accessibility scanning: Some platforms have built-in accessibility checking; others require third-party integrations

CDN and performance infrastructure: Especially relevant for high-traffic public-sector sites

Build a short list of the five integrations your organization cannot function without. Any platform that doesn't support them natively or through a well-maintained, reasonably priced extension is off the list, regardless of its other merits.

5. Total cost of ownership

The licence or hosting fee is the smallest part of the cost. Evaluate the full picture:

Implementation: What does it cost to build and launch on this platform? Who does that work?

Training: How long does it take a new editor to become productive? What's the learning curve for your specific team?

Ongoing development: Will you need developer time for plugin updates, customizations, or security patches?

Support: Is there a vendor support contract? A community forum? A local agency ecosystem that knows the platform?

Migration: When the time comes to move off this platform (and it will), how hard is that? Is your content locked in a proprietary format?

Open-source platforms like WordPress and Drupal have no licence fees but real ongoing development and hosting costs. Hosted SaaS platforms shift infrastructure costs to a subscription but add vendor dependency. Headless CMS options separate content management from delivery, offering flexibility at the cost of complexity. None of these trade-offs is inherently right or wrong: they're right or wrong for your context.

Platform comparison: WordPress, Drupal, and headless options

Here's an honest look at the three platform categories that come up most in mid-sized organization evaluations. This is not exhaustive: it's a starting point for informed conversations.

WordPress

Best fit: Organizations with small to mid-sized web teams, generalist editors, and a need for a large plugin ecosystem.

| Strength | Limitation |

|---|---|

| Lowest learning curve for non-technical editors | Governance and permissions require plugins (not native) |

| Enormous plugin ecosystem for almost any feature | Plugin quality varies; security surface is large |

| Widest agency and freelance support network | Can become unwieldy at enterprise scale without discipline |

| Low cost to launch and maintain at smaller scale | Performance optimization requires ongoing attention |

| Strong multilingual options (WPML, Polylang) | No native content approval workflow |

WordPress is the right choice more often than its critics admit, especially for organizations with generalist teams and limited development capacity. It becomes the wrong choice when governance and permissions are critical and nobody has the appetite to maintain the plugin layer that provides them.

Drupal

Best fit: Larger organizations, government, and public-sector entities with complex governance requirements, multiple content types, and in-house or contracted technical capacity.

| Strength | Limitation |

|---|---|

| Native role-based permissions and granular access control | Steep learning curve for editors and administrators |

| Robust content modelling for complex structured content | Higher implementation and maintenance cost |

| Strong accessibility and standards compliance out of the box | Smaller freelance talent pool than WordPress |

| Built for multi-site and enterprise-scale deployments | Overkill for smaller, simpler organizations |

| Active government and public-sector user community | Major version upgrades (e.g., Drupal 7 to 10) have been costly migrations |

Drupal earns its reputation in public-sector digital. The governance tooling, accessibility track record, and structured content capabilities are genuinely strong. But it requires ongoing technical investment. Organizations that choose Drupal without a realistic plan for who maintains it are setting up a future migration project.

Headless CMS (Contentful, Sanity, Prismic, and similar)

Best fit: Organizations with a development team, a need to deliver content across multiple channels, or a desire to decouple content architecture from front-end technology.

| Strength | Limitation |

|---|---|

| Content modelled once, delivered anywhere (web, app, API) | Requires front-end development for any presentation layer |

| Modern, structured content approach reduces duplication | Higher implementation complexity; not beginner-friendly |

| Vendor-managed infrastructure reduces hosting burden | Vendor lock-in risk; SaaS pricing at scale can be significant |

| Excellent for design systems and component-driven publishing | Editorial interface varies widely in quality |

| Easy integration with modern front-end frameworks | Live preview and in-context editing can be limited |

Headless is not more advanced: it's different. It's the right architecture for organizations where content needs to flow into multiple products and channels, and where front-end development is a core capability. For organizations without development capacity, it adds complexity without meaningful benefit.

The CMS evaluation scorecard

Use this to evaluate up to four platforms side by side. Score each criterion from 1 (poor fit) to 5 (strong fit) based on your specific context, not on the platform's theoretical capability.

CMS EVALUATION SCORECARD
Organization: ___________   Date: ___________
Evaluators: ___________

CRITERION                          | Weight | Platform A | Platform B | Platform C
-----------------------------------|--------|------------|------------|------------
Editor usability for your team     |  25%   |            |            |
Role-based permissions             |  15%   |            |            |
Approval and governance workflows  |  10%   |            |            |
Scalability for 3-year roadmap     |  15%   |            |            |
Required integrations (list below) |  15%   |            |            |
Total cost of ownership            |  10%   |            |            |
Implementation timeline            |  5%    |            |            |
Support and maintenance capacity   |  5%    |            |            |

WEIGHTED TOTAL                     | 100%   |            |            |

Required integrations to evaluate:
1. ___________
2. ___________
3. ___________

Disqualifying gaps (any platform that fails these is off the list):
1. ___________
2. ___________

Notes:
___________

How to use the weights: The default weights above reflect a general mid-sized organization profile. Adjust them for your context. If you're a municipal government where governance and permissions are non-negotiable, increase their combined weight. If you're a small business where editor simplicity is the primary concern, increase the editor usability weight and reduce governance.

Disqualifying gaps are deal-breakers. If a platform can't support a critical integration or meet a fundamental governance requirement, it fails regardless of its weighted score. Define these before you start scoring.

How to run the evaluation internally

A good CMS evaluation takes two to three weeks. Not two to three months. Here's the sequence:

Week 1: Define your requirements. Answer the five criteria questions above. List your required integrations and your disqualifying gaps. Identify everyone who should have input: editors, IT, legal (if relevant), communications leadership.

Week 2: Hands-on trials. Shortlist two or three platforms. Set up a trial or sandbox environment for each. Have your actual content editors complete a standard set of tasks: create a new page, upload an image, edit an existing page, and preview a draft. Time them. Ask them to rate ease of use. Their experience matters more than any feature matrix.

Week 3: Score and decide. Complete the scorecard. Pressure-test your shortlist against your disqualifying gaps. If the scores are close, weight the editor usability criterion more heavily: you can compensate for a missing feature with a plugin or custom development, but you cannot compensate for a tool your team won't use.

Document your decision and your reasoning. In two years, when someone asks why you chose the platform you chose, you'll want that record.

The question to ask before you sign anything

After you've run the evaluation, before you commit, ask one more question: who in my organization will own this decision in three years?

CMS platforms only work as well as the people maintaining them. If the person championing your platform evaluation leaves, or the agency that built your site moves on, who inherits the relationship? Who will handle the next major version upgrade? Who is accountable when something breaks at 4pm on a Friday before a long weekend?

If you don't have a clear answer, that's not a reason to delay the decision. It's a reason to find the answer before the contract is signed.

Not sure which CMS is the right fit for your organization? Get in touch for a vendor-neutral evaluation and a recommendation built around your team, your governance needs, and your three-year digital roadmap.