Selecting a CMS for a Complex Multi Site Organisation

Enterprise CMS selection for a multi brand, multi language organisation should start with the operating model: who creates content, who approves it, who publishes it and who owns each site. Score candidate platforms against those workflows rather than against feature lists, and the right shortlist usually becomes obvious. Most failed CMS programmes chose a capable product that did not fit how the organisation actually works.

This guide sets out a requirement scoring method for groups running several brands, markets or business units, often in English and Arabic, and shows how to weigh governance, localisation, integration and total cost.

Why multi site organisations choose differently

A single brand company picks a CMS mainly for its editors and its website. A group with many sites has extra questions that only appear at scale:

• Which components, templates and assets are shared, and which can each brand change?
• Do local teams publish independently, or does a central team approve everything?
• How is the same content kept consistent across markets and languages?
• Who pays for the platform, and how are costs shared between business units?

These are organisational questions first and technical questions second. A CMS can enforce a workflow, but it cannot invent one. Before scoring any product, write down how content should flow.

Map the operating model before the requirements

Step 1: list every role that touches content

Typical roles in a multi site group include central brand managers, local marketing teams, translators, legal or compliance reviewers, product owners, developers and agency partners. For each role, note which sites they work on, what they create or change, and what they must never be able to touch.

Step 2: choose a governance model

Most groups in the UAE and wider GCC land on a federated model. It keeps brand consistency while letting local teams respond to market news, promotions and regulatory updates without waiting for head office.

Step 3: draw the approval paths

For each content type, sketch who drafts, who reviews and who publishes. A product page might need marketing and legal sign off; a news item might need only the communications lead. Note where approvals differ by market, for example where a regulated sector needs compliance review in one country but not another. These paths become your content governance requirements.

Building the CMS requirements list

Turn the operating model into requirements grouped by theme. Keep each requirement testable: a vendor should be able to demonstrate it, not just tick a box.

Governance and workflow

• Roles and permissions per site, per section and per content type.
• Configurable approval workflows with different paths by market or content type.
• Scheduled publishing and expiry, with an audit trail of who changed what.
• Locked brand components that local teams can use but not alter.

Multi site structure

• Shared component library and design system across sites.
• Shared content that can be reused or inherited by local sites, with controlled local overrides.
• Central management of domains, redirects and site settings.
• A clear model for launching a new brand or market site from a template.

Language and localisation

• Full right to left support for Arabic in the editor, previews and front end.
• Linked language versions so editors can see which translations are missing or outdated.
• Translation workflow, either in the CMS or through a connected translation service.
• Correct language signals for search engines, such as hreflang annotations between localised versions.

Integration

• CRM and marketing automation for forms and lead routing.
• Product, pricing or course data from ERP, PIM or LMS systems.
• Single sign on for staff, and identity options for customer accounts where needed.
• Search, analytics and consent management.

Compliance and accessibility

• Personal data handling that suits the UAE Personal Data Protection Law, and DIFC or ADGM rules where your entities sit in those jurisdictions. Confirm specifics with counsel.
• Hosting and data location options that match your policies.
• Accessibility support so editors can publish content that meets WCAG 2.2 success criteria, such as alt text prompts and accessible components.

How to score enterprise CMS options

Weight each requirement group by its importance to your operating model, then score each candidate on demonstrated capability.

Set the weights

Give each group a weight from 1 to 5. A federated group with strict legal review might weight governance at 5 and personalisation at 2. A group of consumer brands focused on campaigns might reverse that. Agree weights with stakeholders before vendor demos so the scoring cannot be bent to favour a preferred product.

Score on evidence

Multiply each score by its group weight and total the results. The totals rarely decide the outcome alone, but they make trade offs visible. A platform that scores highly on personalisation but poorly on Arabic editing is a warning, not a winner.

Hypothetical example

Hypothetical example: a GCC hospitality group runs six hotel brands, each with English and Arabic sites, managed under a federated model. It weights governance at 5, localisation at 5, multi site structure at 4, integration at 3 and personalisation at 2. During demos, one DXP shows strong personalisation but awkward Arabic editing; a headless CMS shows clean right to left editing and flexible roles but needs a custom approval step. The weighted scores favour the headless option, with the approval workflow added as a defined piece of build work.

Platform families for multi site organisations

Three families appear on most enterprise shortlists. Our guide to CMS options across WordPress, DXP and headless covers the basics; here is how each handles multi site needs.

WordPress Multisite

WordPress Multisite runs several sites from one installation. Sites can share themes and plugins while keeping their own content, and the network can use subdirectories, subdomains or separate domains. It suits groups with similar sites and a modest number of brands. It becomes harder when brands need very different features or strict separation of data and permissions.

Enterprise DXP

Platforms such as Sitecore and Adobe Experience Manager are built for many sites, markets and approval chains, with personalisation and asset management included. They suit groups with a funded platform team and mature marketing operations. The common risk is licensing a broad suite and using a small part of it.

Headless CMS

A headless CMS manages structured content centrally and delivers it to any number of front ends. It suits groups that publish to websites, apps and other channels, and want different front ends per brand on one content backbone. Workflow and preview depth vary by product, so test them hard. For a direct comparison of open source and structured options, see WordPress versus Strapi for multi channel publishing, and for an executive view, headless WordPress, Sitecore and AEM for CIOs.

Understanding CMS total cost

Licence fees are only one part of CMS total cost, and often not the largest. Model costs over five years across these drivers:

• Licences and subscriptions: platform licence, environments, user seats, usage tiers and add on modules.
• Implementation: design system, templates, integrations, content migration and testing.
• Hosting and operations: cloud infrastructure, CDN, monitoring, backups and security patching.
• People: platform owner, developers, content operations and training for every new local team.
• Change over time: major upgrades, new sites, redesigns and the cost of leaving the platform later.

Ask each vendor or implementation partner to price your specific scenario, including the number of sites, languages, editors and integrations. Generic price lists hide the variables that matter most for a multi site group. The same applies to ecommerce platforms, as covered in our guide to enterprise ecommerce platform requirements.

Running the enterprise CMS selection

1. Document the operating model and approval paths, signed off by central and local stakeholders.
2. Write scenario based requirements with weights agreed in advance.
3. Issue a brief to a shortlist of three or four platforms or partners, with your scenarios attached.
4. Run scripted demos using your content, including Arabic pages, a multi step approval and a new site launch from a template.
5. Hold a hands on trial where real editors from central and local teams complete everyday tasks.
6. Check references from organisations with a similar governance model and number of sites.
7. Model five year total cost and agree ownership of the platform before signing.

Content governance after go live

The selection only pays off if governance continues once the sites are live. Agree these routines before launch so they are part of the operating model rather than an afterthought.

A content governance board

A small group with central brand, digital, legal and one or two market representatives meets regularly to approve new components, review requests for exceptions and settle disputes between brands. It keeps decisions visible and stops each site drifting in its own direction.

Standards that editors can find

Publish editorial, accessibility and Arabic style guidelines inside or next to the CMS, with examples of approved page layouts. New local editors should be able to learn the rules in their first week.

Regular content audits

Schedule reviews of outdated pages, broken links, missing translations and orphaned assets on each site. Multi site platforms collect clutter quickly, and an audit cycle keeps search performance and user trust intact.

Mistakes that undermine enterprise CMS programmes

• Selecting before agreeing governance. The platform ends up configured around whoever shouts loudest.
• Treating migration as an afterthought. Content audits and clean up often take longer than the build.
• Testing only in English. Arabic layout and editing issues surface after launch, when they are expensive to fix.
• No platform owner. Without a named owner, standards drift, plugins or modules multiply and local sites diverge.
• Ignoring training for local teams. A federated model only works if every market knows the guardrails.

Plan your multi site platform with Codeeo

Codeeo provides website design and development, CMS builds on WordPress and headless stacks, site migration and dedicated development teams. With a team of 80+ across Dubai, Riyadh and Karachi, Codeeo can help you document the operating model, score platforms against it and deliver the chosen build. Explore web development, site migration and dedicated developers, or meet the team at the Dubai office to discuss your sites.