How to choose the right CMS for an established business

The CMS is often selected too early.

A stakeholder has used WordPress before. A competitor appears to use a headless platform. The ecommerce team prefers Shopify. IT has an enterprise vendor relationship. An agency leads with the technology it knows best.

Familiarity and capability matter, but none of those facts defines the business requirement.

A content management system sits inside a wider operating model. It affects how people create and approve content, how the website represents structured information, how systems exchange data, how releases are managed, who owns risk and how the platform evolves.

The right CMS is the one that meets the required business, user and operating needs with acceptable risk and lifecycle cost.

There is no universal best CMS for an established business.

The short answer: compare twelve dimensions

The twelve dimensions are content model; editorial experience; workflow and permissions; multisite and localisation; experience and design flexibility; integrations and APIs; ecommerce and transactions; accessibility support; security and privacy; performance and availability; ownership and portability; and lifecycle cost and internal capability.

Score evidence against requirements, not brand familiarity.

Weight the criteria. A retailer, professional-services firm, multi-location health network and multilingual manufacturer should not use the same scorecard priorities.

Start with the job, not the platform

The Australian Government’s business website guidance recommends reviewing business goals and target-market needs before choosing hosting, CMS and design.

Define:

Priority audiences and tasks
Website business outcomes
Content types and relationships
Publishing frequency and team
Approval and compliance workflows
Locations, brands, regions and languages
Functional and ecommerce requirements
Systems and sources of truth
Accessibility, privacy, security and availability needs
Planned change
Ownership and support model

Then identify which requirements are essential, desirable or later-phase. A selection exercise fails when every stakeholder’s preference becomes mandatory.

Understand the main platform models

These categories overlap, and individual products can support more than one architecture. They are useful for clarifying responsibility rather than picking a winner.

SaaS website or commerce platform

The provider operates the underlying hosted service, upgrades and standard platform capability. The customer configures the site, content, users and approved extensions within the service boundary.

Potential strengths include a managed platform, predictable core updates and an integrated ecosystem. Trade-offs can include product constraints, edition-dependent functionality, recurring fees, extension dependence and limited control over some infrastructure or architecture decisions.

Open-source or self-hosted CMS

The organisation or its partners deploy and maintain the application on separately arranged infrastructure. It can offer substantial flexibility and ownership, but that flexibility creates responsibility for implementation, dependencies, updates, environments, security configuration and support.

"Open source" does not mean free to own. Licence cost is only one component.

Managed digital experience platform

Enterprise platforms can combine content, personalisation, analytics, workflow, marketing and multi-experience capability. The value depends on whether the organisation can use and govern those capabilities. A broad feature set can become expensive shelfware when people, data and process are not ready.

Headless or composable architecture

Content management is separated from one or more presentation layers and connected through APIs. This can support multiple channels and specialist frontend experiences. It also introduces architecture, integration, preview, deployment and operational decisions that may be unnecessary for a controlled website.

Headless is an architecture choice, not a synonym for modern, fast or future-proof.

Commerce-led platform

Ecommerce platforms centre products, carts, orders, customers and payments. They may include strong content capability or be combined with another CMS. If transactions drive the website, compare commerce rules and operations alongside editorial needs.

Platform selection changes responsibility; it does not remove it.

Emote does not sell, resell or directly provide website hosting infrastructure. Emote can advise on hosting requirements, recommend and coordinate with an appropriate hosting partner, or work with the client’s suitable existing host. Where the platform includes infrastructure as part of its service, the provider contract governs that layer.

1. Content model: can the CMS represent the business properly?

Do not begin with pages. Identify structured content such as:

Services
Products and categories
Locations
People and credentials
Projects and case studies
Resources and events
Brands and markets
Policies and documents

Then map relationships. A dentist may work at several practices. A product may appear in several industries. A service may differ by region.

A suitable CMS should allow editors to manage the underlying information without copying it into many disconnected pages. The model should also support navigation, search, filtering, metadata and future reuse.

Test the most difficult content, not only a news post.

2. Editorial experience: can real teams use it well?

Feature lists rarely show the daily publishing experience.

Ask editors to complete representative tasks:

Create a service page
Update a location once and reuse it
Preview responsive content
Schedule a campaign
Find and replace an expired document
Add accessible image text
Recover an earlier version
Manage a shared component safely

Evaluate learnability, error prevention, preview, reuse, media, scheduling, search and bulk operations.

A highly flexible interface can increase inconsistency if every editor can invent layouts. An overly rigid one can require developers for routine publishing. The right balance depends on governance and frequency.

3. Workflow and permissions: who can do what?

Established organisations often need more than administrator and editor.

Map authors, reviewers, publishers, regional editors, agencies and technical administrators. Apply least privilege and separate sensitive administration from routine publishing.

WordPress’s official roles documentation demonstrates how one CMS distinguishes role capabilities. Drupal’s content moderation documentation demonstrates published content coexisting with a working copy under configured workflow states. These are examples of capability, not recommendations for a particular project.

Test whether the required workflow is native, configurable or custom.

4. Multisite, brands, locations and languages

Decide whether the organisation needs one site, a shared multisite system, separate sites or a hybrid before comparing CMS features.

Requirements may include:

Shared components and brand variations
Central content with local overrides
Separate domains or regional URLs
Local approvals and permissions
Shared search or accounts
Translation workflow
Locale-specific products, legal text or data
Cross-site analytics and governance

Google’s multi-regional and multilingual guidance recommends distinct URLs for language versions and describes `hreflang` for linking the appropriate variations. The CMS needs to support the chosen publishing and URL model reliably.

5. Experience flexibility

Clarify whether the website uses:

An established theme or template
A tailored component system
Focused custom design
Several brand themes
A separate frontend application
Multiple digital channels

The CMS should support the experience without allowing uncontrolled design variation. Ask how components, fields, layouts and design tokens are governed.

Custom does not require every component to be bespoke. Reusable foundations often create consistency and lower change cost.

6. Integrations and APIs

List systems and exchanges at the appropriate level:

CRM
ERP
PIM
Inventory
Booking
Authentication
Search
Email and automation
Analytics and consent
Payments and fulfilment

For each, define data, source of truth, direction, frequency, failure handling, environments and owner. A CMS with an API does not prove that every required integration is feasible or sensible.

Review vendor documentation and access before fixing implementation scope. Material unknowns may need targeted technical validation or Focused or Full Website Discovery.

7. Ecommerce and transactions

If commerce is important, assess products, catalogues, pricing, promotions, accounts, tax, payments, shipping, returns, inventory and administration.

Content-led CMS extensions can support commerce. Commerce-led platforms can support content. The right centre of gravity depends on the operating model.

Article 6 provides a deeper Shopify-versus-WooCommerce framework; neither product name should replace requirements analysis.

8. Accessibility support

The CMS should enable people to create accessible content and should itself be usable by required authors.

W3C’s Authoring Tool Accessibility Guidelines address both accessible authoring interfaces and tools that support production of accessible web content.

Assess:

Semantic content fields
Heading and link controls
Alternative-text prompts
Captions and transcripts
Error prevention
Accessible components
Preview and validation
Editor interface accessibility

No CMS guarantees compliant output. Templates, components, content, configuration and governance all contribute.

9. Security and privacy

Evaluate the complete responsibility model:

Authentication and multifactor options
Roles and privileged access
Security update process
Extension or app governance
Logging and alerting
Data location and handling
Backups and restoration
Vendor response and support lifecycle
Secure development and deployment
Offboarding and data export

The Australian Cyber Security Centre advises organisations choosing technology to consider secure-by-design practices and product lifecycle. The OAIC’s Guide to securing personal information explains the need for reasonable steps across the information lifecycle.

Do not ask whether a CMS is simply "secure". Ask which party secures each layer, under what process and evidence.

10. Performance and availability

Performance depends on frontend implementation, media, extensions, third-party scripts, caching, infrastructure and content patterns as well as the CMS.

Define priority page and journey expectations, traffic patterns, geographic reach, release frequency and criticality. Separate provider availability commitments from application functionality.

Google’s Web Vitals guidance defines metrics for loading, responsiveness and visual stability. Use field and laboratory evidence appropriately; do not reduce experience quality to one tool score.

11. Ownership and portability

Ask:

Who owns content, data, code, designs and accounts?
Can the organisation export structured content and media?
Are extensions and licences held in client-controlled accounts?
What proprietary templates, APIs or skills create lock-in?
What happens when a vendor, agency or edition changes?
Is current documentation available?

No platform is free of switching cost. The goal is informed dependence and an exit path proportionate to the website’s importance.

12. Lifecycle cost and capability

Compare more than implementation fees:

Platform and extension licences
Hosting or SaaS subscription
Implementation and migration
Internal editorial and governance time
Maintenance and security updates
Support and monitoring
Specialist availability
Version upgrades
Performance and accessibility improvement
Exit and replatforming

A feature-rich platform can have poor value if the organisation cannot operate it. A familiar platform can have poor value if it requires extensive workarounds.

Public Emote example: architecture follows the operating model

Emote’s public Brown Brothers case study describes four brand sites running from a shared core and brought under one CMS for easier management. The solution also connected a central stock master, supported cross-brand purchasing and used modular design customised for each brand.

The lesson is not that every brand group needs multisite or a particular CMS. Brown Brothers had a specific requirement: distinct brand experiences, shared commerce and inventory, and manageable central administration. Those needs shaped the architecture.

Platform design should follow the operating requirement.

A practical CMS selection process

Define outcomes, users and operating context.
Inventory content, systems, data and current constraints.
Separate essential requirements from preferences.
Weight the twelve selection dimensions.
Shortlist platform models before individual products.
Validate difficult editorial and technical scenarios.
Review security, privacy, accessibility and responsibility boundaries.
Compare implementation and lifecycle cost.
Test ownership, support and exit arrangements.
Record evidence, assumptions and residual risks.

Do not run a generic vendor demonstration. Give each vendor the same real scenarios and ask it to show the path, configuration and dependencies.

Run scenario demonstrations, not sales demonstrations

The strongest CMS evaluation asks each shortlisted option to perform the work the organisation actually finds difficult. A polished tour of a sample site mainly demonstrates that the vendor can present its preferred features.

Prepare a small, consistent scenario pack using representative content and rules. Ask each option to demonstrate how it would:

Create and relate the organisation’s most complex content types
Let an editor reuse approved content without creating uncontrolled duplication
Route a sensitive change through realistic permissions and approval
Publish a localised or brand-specific variation while preserving shared standards
Handle a representative integration failure or unavailable data source
Preview, schedule, withdraw and restore content
Export content, media and relevant configuration for transition
Apply an upgrade or release without losing supported customisation

Include ordinary editorial tasks as well as unusual ones. A platform can look capable in a technical architecture diagram while making routine publishing slow and error-prone. Ask the people who will operate the CMS to complete tasks themselves where possible. Observe the number of steps, clarity of language, quality of validation and recovery from mistakes. Do not score only whether a feature exists.

Require the vendor or implementation partner to distinguish standard capability, configuration, custom development, extensions and external services. Record which product edition and commercial assumptions the demonstration uses. A capability shown through an enterprise add-on should not be scored as included in a lower-tier proposal.

Watch for selection red flags

Several patterns deserve further challenge:

The shortlist was chosen before the requirements were written.
One stakeholder’s familiarity has become the main decision criterion.
A long feature checklist gives equal weight to essential and marginal needs.
Security or accessibility is described as automatic rather than shared between platform, configuration, content and operation.
The implementation assumes extensions without reviewing their support, ownership or update path.
Integration claims rely on the existence of an API without validating fields, rules, authentication, limits and failure handling.
The proposal does not identify who controls hosting, domains, licences, repositories, provider accounts and recovery.
Content export is available in theory, but no one has tested what structure, media or relationships are preserved.
The business case counts implementation fees but not internal capability, licences, maintenance, upgrades or eventual exit.

No single red flag automatically disqualifies a platform. It identifies an assumption that needs evidence.

Finish with a decision record that states the selected option, rejected alternatives, evidence, trade-offs, responsibility boundaries and residual risks. The record is valuable after procurement because future teams can distinguish an intentional compromise from an overlooked requirement. It also prevents a later preference from being presented as though it had always been part of the selection rationale.

Test exitability before selection

Confirm how content, media, customer data, code, configuration and analytics can be exported or transferred. A platform may fit today but still create unacceptable dependency if the organisation cannot retrieve its assets or change partners safely.

Frequently asked questions

Which CMS is best for SEO?

No platform automatically produces strong search performance. The CMS should support crawlable output, metadata, redirects, structured content, performance and editorial control, but implementation and content remain decisive.

Is an open-source CMS cheaper?

Not necessarily. It may avoid or reduce certain licence fees while adding implementation, infrastructure, maintenance and specialist responsibility. Compare total ownership.

Is headless CMS better for an established business?

It can be suitable for multiple channels, specialist frontend needs or composable architecture. It can be unnecessary complexity for a controlled website. Use requirements, not modernity claims.

Should marketing or IT choose the CMS?

Neither should decide alone. Marketing, content, technology, security, operations and business owners should contribute to the criteria, with clear decision authority.

Can we retain the CMS and redesign the website?

Yes, if the CMS, content model, integrations and supportability fit the required future state. Validate retained constraints before approving the new experience.

Does CMS selection require Focused or Full Website Discovery?

Not always. Clear, controlled requirements may support direct selection and implementation planning. Focused or Full Website Discovery is appropriate when consequential uncertainty across users, content, systems, data or governance prevents a responsible choice.

How Emote can help

The CMS is not the strategy. It is an enabling system within a wider website, team and supplier model.

Select the system that can represent the business, support its people, connect required systems and remain governable through change. A shorter feature list with stronger fit is often more valuable than a broad platform used superficially.

If you are selecting or replacing a CMS, book an initial meeting with Emote. We can clarify the business requirement, known constraints and material unknowns, then recommend the appropriate next step. Detailed platform evaluation and architecture form part of an agreed engagement where required.