Enterprise CMS & Content Operations

Start from the editorial model, not the product list

Before comparing platforms, describe the operation: how many editors, in which departments, publishing what kinds of content, in how many languages, with which approval steps and which legal or brand review. Most CMS disappointments trace back to a platform chosen for its feature list and then bent around an editorial reality it was never modelled for. Once the editorial model is written down, platform comparison becomes concrete. Each candidate is scored against the workflows you actually run rather than a generic evaluation matrix.

Content types, roles and workflow

The structural work is where content operations succeed or fail. Content types should mirror meaning, not page layout, so the same content can serve a listing, a detail page, a search result and an API consumer.

• Content type modelling — structured fields, reusable blocks, clear required versus optional rules.
• Editor roles and permissions mapped to real departments and responsibilities.
• Draft, review, approval and scheduled publishing steps that match internal governance.
• Versioning, audit trail and rollback for regulated or high-scrutiny content.
• Reusable components with guardrails, so editors compose pages without breaking the design system.
• Media operations: asset naming, alt text discipline, image derivatives and rights metadata.
• Preview across breakpoints and languages before publishing.

Multi-language and multi-site

Multi-language is a modelling problem before it is a translation problem. Language variants need a defined relationship: which fields are shared, which are localised, what happens when the source changes, and how a secondary language is prevented from silently falling behind. Multi-site raises the same question at group level. Subsidiaries usually need local autonomy over content but shared governance over components, brand and technical standards. A federated setup — shared design system and content types, separate editorial spaces — usually keeps both sides workable.

Keep, upgrade or replace: a criteria-based decision

Replacing a CMS is expensive and disruptive, so it should be argued rather than assumed. We assess the current platform against a short set of criteria and recommend the least invasive option that solves the real problem.

• Keep — if editors can work, the model is sound and the pain is design or performance related rather than structural.
• Upgrade — if the platform is capable but the content model, workflow or component set has degraded over time.
• Replace — if licensing, security, integration limits or the content model itself block the operating model you need.
• Headless — when the same content must serve several front-ends, apps or channels, and your team has development capacity.
• Custom — when governance, integrations or editorial workflow are too specific for an off-the-shelf model to fit without heavy workarounds.

Integrations and migration

Enterprise content rarely lives alone. CRM, marketing automation, search, DAM, HR systems, investor data feeds and single sign-on all shape the architecture, so integration points are mapped early and owned explicitly. Migration is treated as an editorial project with engineering support, not a database export. It starts with an inventory and a keep/rewrite/retire decision per item, then mapping to the new model, redirects for every retired URL, and a verification pass on structure, metadata and internal links after the move.

Frequently asked questions

Do you recommend a specific CMS? Not before the editorial model is defined. We evaluate candidates against your content types, workflow, language and integration needs, then recommend the option that your team can operate with the least friction. Is headless always the better option? No. Headless helps when content must serve multiple front-ends or channels and there is development capacity to support it. For a single corporate site with a large editorial team, a well-modelled traditional or hybrid setup is often easier to run. How do you avoid losing SEO value in a migration? By inventorying every existing URL, mapping redirects one to one where possible, preserving titles, descriptions and structured data, and verifying the result page by page after launch. Can our own team manage the CMS afterwards? That is the goal. We deliver role-based training, a written editorial guide and component guardrails so routine publishing does not require developer tickets.