The enterprise CMS replatforming scorecard

Enterprise CMS selections often begin after years of accumulated frustration. Publishing is slow. The platform is expensive. Integrations are fragile. Editors work around the system. An upgrade is due, and every alternative promises speed, composability and a lower total cost.

That is exactly when a feature matrix is least useful.

The organisation is not choosing software in isolation. It is choosing a future operating model, a migration burden and a new set of constraints. The right scorecard must test the whole decision: what improves, what merely moves and what new dependency the organisation is willing to own.

Gate zero: should you replatform at all?

Before scoring vendors, score the case for change.

Separate platform limitations from implementation and operating problems. If publishing is slow because every release needs six approvals and a weekly deployment window, a different CMS may not help. If editors cannot find assets because taxonomy is unmanaged, migrating the library will reproduce the problem. If costs are driven by custom integrations, a cheaper licence may be irrelevant.

The replatform case should identify:

• which business outcomes are blocked today;
• evidence that the current platform is a material cause;
• what can be fixed without replacement;
• the cost and risk of remaining in place;
• the capability that a new platform must provide; and
• the organisational change required to realise it.

A replatform is justified when the combined constraint of platform, architecture and operating model cannot be corrected at acceptable cost and risk. “The current CMS feels old” is not a business case.

How to score without pretending everything is equal

Use weighted categories and minimum gates. A platform should not win because excellent API scores compensate for an unacceptable security or editorial outcome.

We recommend a 1–5 score for each criterion:

• 1 — unacceptable: cannot meet the requirement without fundamental compromise;
• 2 — weak: possible only through significant customisation or operating burden;
• 3 — adequate: meets the requirement with understood limitations;
• 4 — strong: meets the requirement with limited adaptation; and
• 5 — differentiating: demonstrably improves the target operating model.

Security, compliance, recoverability and core author journeys should be pass/fail gates before weighted scoring. Weights should reflect business priorities agreed before product demonstrations begin.

Scorecard dimension one: business and content fit

Evaluate whether the platform supports the experiences the organisation actually operates: markets, brands, languages, channels, campaigns, products, regulated content and personalisation. Then test how it handles change.

Questions to score include:

• Can the content model express the domain clearly without excessive fragmentation?
• Can shared content vary safely by market or brand?
• Can teams see reuse and change impact?
• Are localisation, legal review and embargoes native to the workflow?
• Can the platform support the expected channel roadmap without speculative modelling?

Do not award points for theoretical omnichannel delivery if the organisation has no ownership or funding for those channels.

Dimension two: author and operator experience

Authors need more than an attractive interface. Test complete tasks with representative users and production-like content.

Score findability, editing context, preview fidelity, workflow clarity, bulk operations, accessibility, version comparison, scheduling, error recovery and support visibility. Include administrators: role design, environment management, audit, taxonomy maintenance and incident diagnosis often determine the true operating burden.

Measure the number of external tools and engineering interventions needed to complete routine work. Each one is a hidden integration and support cost.

Dimension three: architecture and delivery

The architecture score should reflect the organisation’s capability, not an abstract ideal.

Assess APIs, delivery patterns, extensibility, caching, search, media handling, environments, schema migration, webhooks, eventing, CI/CD, local development, observability and failure isolation. Examine vendor limits and throttling against realistic peak behaviour.

Ask what the organisation must build to turn the product into a working platform. Headless delivery may require preview, frontend hosting, routing, search, personalisation and orchestration. A suite may provide more integrated capability but create tighter coupling and a larger upgrade or commercial dependency. Neither is automatically better.

Dimension four: migration and transition risk

Migration deserves its own score because a strong target product can still be a poor transition choice.

Profile the source estate: pages, assets, versions, languages, metadata, forms, redirects, users, permissions, components, workflows, integrations and archives. Ask vendors to demonstrate how difficult examples move, not how a clean sample imports.

Score transformation tooling, validation, incremental migration, coexistence, freeze requirements, rollback, URL preservation, SEO controls and the availability of skills. Include the cost of content decisions. Pages without owners do not classify and approve themselves.

Dimension five: governance, security and compliance

Review identity integration, least privilege, separation of duties, auditability, encryption, data residency, retention, legal hold, consent, vulnerability management, supplier assurance and incident response.

Governance also includes change authority. Who may alter a content model, install an extension, modify a workflow or publish globally? Can policy be enforced without making the platform unusable? A control that everyone bypasses is not a mature control.

For AI-enabled CMS features, add clear questions about training use, data retention, model providers, prompt and output logging, regional processing, human review and the ability to disable the capability.

Dimension six: reliability and operations

Score the day-two system, not only the launch architecture.

Look for service-level commitments, maintenance behaviour, release communication, backup and restore, disaster recovery, observability, deployment rollback, support escalation, incident transparency and performance at expected scale. Model dependency failures: identity unavailable, webhook delayed, search index stale, media processor slow, frontend build failed.

Define which failures the vendor owns and which remain yours. “SaaS” is a deployment model, not an outsourcing of accountability.

Dimension seven: economics and exit

Build a five-year total-cost model using plausible growth and adverse scenarios.

Include licences, usage tiers, environments, implementation, migration, frontend and cloud services, search, CDN, extensions, integration, support, training, governance, observability and internal staffing. Price the authoring inefficiency that remains and the engineering dependency introduced.

Then score exit cost: content export, media originals, schema portability, API access, data deletion evidence, contract termination, skills availability and the effort required to replace proprietary capabilities. The best time to understand lock-in is before it becomes leverage in a renewal.

The proof-of-capability challenge

Shortlist vendors should complete the same scripted challenge using your representative content and constraints. Include normal and failure scenarios:

1. Create and localise a campaign using shared content.
2. Preview it in the real frontend.
3. Route it through legal and regional approval.
4. Change a shared item and identify affected experiences.
5. Publish on a schedule.
6. Trigger a failed integration or invalid entry.
7. Diagnose and recover without vendor coaching.
8. Export the content and audit record.

Score the evidence, not the presenter’s explanation of what could be configured later.

Avoid false precision

A scorecard supports judgement; it does not replace it. A final score of 4.18 versus 4.07 is not scientific certainty. Keep written rationale, assumptions, disqualifying risks and confidence beside every score.

Run sensitivity analysis. If a small change in weights changes the winner, the decision is not robust. Examine scenarios: acquisition, traffic growth, regional regulation, a doubled content estate, vendor price change or the loss of a key implementation partner.

The executive decision should explain the trade: “We are accepting higher delivery ownership to gain channel flexibility,” or “We are accepting suite coupling to reduce integration and operational burden.” That is more useful than calling one platform “best.”

Adovo’s view

Replatforming is an opportunity to remove accidental complexity, but only if the organisation refuses to buy its way around unresolved ownership.

Score the operating model you will have, the migration you must survive and the exit you may eventually need. Test with real work. Treat the scorecard as a record of deliberate tradeoffs. A platform selected this way may not win every category, but it will be far less likely to surprise the people who have to live with it.

Primary documentation and further reading

• Adobe headful and headless AEM models
• Adobe AEM Sites and Edge Delivery Services