Why open source enterprise CMS is a governance decision before a software decision
For a multi-site estate, choosing an open source CMS is less a software decision than a governance decision. Drupal and WordPress are the main self-hosted options for multi-site estates, and headless frameworks such as Strapi, Payload and Directus fit specific cases where the front end is built separately and content is served through an API. This page is for CIOs, CISOs, heads of digital and platform engineering who are reviewing a proprietary digital experience platform contract, often while many sites share templates, components and editorial teams, and while accessibility and security obligations apply to every page. The first question is who owns each site, who approves changes to shared templates, and who is accountable when a security release lands on a Friday.
Before comparing platforms, confirm the operating model your organization can sustain. Decide which team owns core and module updates, how often sites are patched, and whether a central team or each site owner can publish. Write down the accessibility baseline you must meet. For US state and local government entities, the ADA Title II web rule requires WCAG 2.1 Level AA, and the interim final rule published April 20, 2026 set compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. Confirm your own applicable date with counsel. These decisions shape the platform more than any feature list does.
The rest of this page covers governance and editorial workflows, security updates and release cycles, accessibility requirements, hosting and high availability, a reference architecture, build, partner or SaaS options, cost drivers, migration from proprietary DXP platforms, and the questions to put to an implementation partner. Use it to test whether an open source CMS fits your operating model before you ask a vendor for a demonstration. The most useful first step is a written inventory of sites, shared components, integrations and existing contract terms, because that inventory determines the scope of any quote.
Requirements to agree before choosing an enterprise CMS platform
Platform choice follows from a short list of decisions that most organizations have not yet made in writing. Each card below is a decision your leadership, content owners and security team must agree on before comparing Drupal, WordPress or a headless CMS. Answers in one area constrain the others, so settle them together.
Site and content governance
Decide who owns each site, who approves content before it publishes, and which roles can act across sites versus only within one brand or market. Write down the approval path for a regulated claim, a press release and a localized page, since these differ. Multi-site platforms such as Drupal multisite or WordPress multisite can share code and roles, but they do not decide ownership for you. Ask each candidate partner how they would map these roles into permissions, and whether they will test them with your real editors before go-live.
Security patch ownership and cadence
Name the person or team that applies core, module and plugin security updates, and set how fast a critical fix must reach production. Drupal 11.x receives feature releases every six months, and only the most recent WordPress 7.1 release is actively maintained, so a lagging site falls out of support. Decide whether your team, a managed hosting provider or your implementation partner carries this work, and whether it recurs as a retainer. Confirm the staging and testing path for each update.
Accessibility conformance target
Choose the conformance level and standard your sites must meet before design starts, and decide who tests against it. For US state and local government, the ADA Title II rule requires web content to meet WCAG 2.1 Level AA, with compliance dates that depend on population served. Private organizations may face other obligations under contract or sector rules. Agree on how content editors are trained and whether accessibility checks run before publishing, because a platform cannot guarantee accessible content on its own.
Hosting and availability expectations
Define uptime targets, recovery time and recovery point objectives, and whether the estate must survive a region or data center loss. Decide where the sites run (your cloud account, a private data center or a managed host), who patches the operating system and database, and how traffic peaks such as launches or public notices are absorbed. Ask any partner for their backup restore test history and the cache and CDN design, and do not accept availability figures that are not written into the scope.
Content volume and localization
Estimate the number of sites, page templates, content items, media assets and languages, and state which must share a single translation workflow. Volume drives database sizing, search indexing and media storage, while the number of languages drives translation vendor integration and review cycles. Confirm whether translated content is stored per site or shared, and whether machine translation is allowed for public pages. Request a sizing exercise from candidate partners before any platform is shortlisted.
Integration scope and data ownership
List every system that the CMS must read from or write to, such as identity provider, CRM, marketing automation, commerce, analytics, digital asset management and search. Decide which system is the source of truth for each data type, and who owns the integration code after launch. Each integration adds a patching and monitoring obligation, so each one needs an owner. Confirm how user data flows into the CMS and what is logged, since these choices affect your privacy and audit evidence.
Which open source CMS fits which kind of estate
This table compares Drupal, WordPress and three headless options (Strapi, Payload and Directus) on fit, licensing, release support and operating effort. Read each row against your own estate: the number of sites, the editorial model and whether content must be delivered to apps as well as web pages. The main takeaway is that licensing and support windows differ enough to change the operating plan, so confirm them before you commit.
| Criterion | Drupal and WordPress | Headless options (Strapi, Payload, Directus) |
|---|---|---|
| Best fit | Multi-site web estates with governed editorial workflows (Drupal) or smaller, plugin-based sites (WordPress) | Content APIs serving websites, apps and other channels, with developer-led content modeling |
| Licensing | Drupal and WordPress are open source projects; confirm the license of each contributed module and theme you plan to use | Strapi is MIT except its ee directories (Enterprise Edition). Payload is MIT. Directus uses MSCL-1.0-GPL, so confirm your intended use with the vendor or counsel |
| Current releases cited | Drupal 11.4.10 and 10.6.19 (October 14, 2026); WordPress 7.1.3 (October 6, 2026) | Strapi v5.58.0 (October 14, 2026); Payload v3.91.0 (October 15, 2026); Directus v12.5.0 (October 7, 2026) |
| Release support | Drupal 11.x gets feature releases every six months; WordPress maintains only the latest 7.1 release | Confirm the support window and upgrade path for your chosen version with the project or your partner before go-live |
| Enterprise features | Governed workflows and multilingual content are core to Drupal; WordPress depends more on plugins | Enterprise Edition or commercial features may be needed for SSO, audit or governance; verify which ones you require |
| Operating effort | Expect ongoing module updates, security patches and theme maintenance across every site | Expect a custom front end, API hosting and content model upkeep, which shifts effort toward engineering |
| Accessibility evidence | Confirm themes and modules support WCAG 2.1 Level AA, the standard referenced in the ADA Title II rule | Accessibility sits with your front end; the CMS supplies content structure, not compliance on its own |
How governance and editorial workflow differ across a shared estate
In a central model, one platform team owns the CMS instance, templates, component library and publishing rules, and local editors work inside those boundaries. Content ownership sits with the business unit, but structure and presentation are controlled centrally, which keeps brand, accessibility and legal review consistent across sites. Approval chains are short and predictable because the central team sets the standard path, and most changes flow through a single queue. The cost is throughput: every new template or component request waits for the central team, so backlogs are the usual failure mode.
- Content ownership: Editors own pages and copy for their site, while the platform team owns content types, taxonomy and workflow states.
- Design system: A single component library is versioned centrally, and sites consume it without local forks.
- Approval chains: One or two review stages are defined once and applied to all sites, with named approvers per content category.
- Role design: Editor, reviewer and administrator roles are standardized, with few site-specific exceptions.
- Security patches: The central team applies core and module updates once, tests them against the shared templates and releases them to every site in one window.
Confirm with your editors how many change requests they expect each month and whether the central queue can absorb them without delaying campaigns.
In a federated model, each site or business unit runs its own editorial team, approval chain and release calendar, and the platform team governs only shared foundations such as hosting, authentication and a common component package. Ownership is local, which speeds up publishing and suits brands that differ in tone and audience. The risk is drift: sites fork components, skip accessibility checks and install different modules, so the estate becomes expensive to patch and hard to audit. Strong written standards and a shared component contract are what keep federated estates coherent.
- Content ownership: Each site owner controls its content model, navigation and publishing decisions within agreed limits.
- Design system: Sites consume shared components through a published contract, and local customization happens through theme or configuration layers rather than forks.
- Approval chains: Each site defines its own review path, with mandatory checks (such as accessibility and legal review) set at the estate level.
- Role design: Roles are scoped per site, so an editor on one site has no rights on another, and platform administrators sit in a separate group.
- Security patches: Each site team schedules its own update, so the platform team must track versions per site and enforce a deadline, or the estate splits across several versions.
Confirm which checks are mandatory for every site and whether each site team has the skills to apply a core update without the central team.
Most large estates run a mixed model: the platform team owns the core, security baseline and shared components, while business units own content, certain templates and their publishing calendars. Governance is tiered, so a small set of rules applies everywhere and a larger set is delegated. This model works when the boundary between estate-level and site-level decisions is written down and enforced in workflow configuration, not left to convention. Without that written boundary, disputes about who can change a template become a recurring cost.
- Content ownership: Sites own content and local templates, while the platform team owns global content types that carry legal or accessibility obligations.
- Design system: Shared components are mandatory, and sites may add local variants through an agreed extension process.
- Approval chains: Estate-level checks run for every page, and site-level approvers handle editorial sign-off within their own sites.
- Role design: Roles are layered, with estate-wide roles for platform staff and site-scoped roles for editors and reviewers.
- Security patches: The platform team rolls core and shared module updates to all sites in a single window, and site teams retest only their local templates.
Confirm the exact list of decisions that stay central and those that delegate, and who arbitrates when a site requests an exception.
Reference architecture components and how they connect
A multi-site CMS estate is a chain of components, and a failure in one shows up in the others. The cards below cover the six components that most reference architectures for Drupal or WordPress need, with the decisions each one forces on the buyer. Read them in order: hosting sets the baseline, the pipeline and caching shape how changes reach visitors, and monitoring tells you when any link breaks.
Hosting and high availability
Hosting decides how many web nodes serve each site, where they run, and how sessions and uploaded files are shared between them. Drupal and WordPress both assume a shared database and shared file storage once you run more than one node, so the design must handle writes to media libraries and cron or scheduled jobs without duplication. Decide which regions or zones host production, how the database fails over, and who owns the cloud or data center account. Ask your implementation partner to show the failover test results, not only the diagram.
Release pipeline and environments
The pipeline moves code, configuration and contributed modules from development through test to production, and it is where most multi-site estates lose control. Keep configuration in version control, promote it through the same steps every time, and avoid editing production content structures by hand. Decide how many environments each site needs, who approves a release, and how security patches reach every site on the same day. Confirm that your Drupal or WordPress versions are still inside their support windows before you design the release calendar.
Caching and CDN
Caching absorbs most of the read traffic and keeps anonymous pages fast under spikes, but it can also serve stale or private content if the rules are wrong. The CDN sits in front of the origin and must respect cache tags, logged-in sessions and purge events from the CMS. Decide which content types may be cached for how long, how editors trigger purges, and what happens to forms, carts and personalized blocks. Test purge behavior on every site, since a single misconfigured rule can expose one site's pages through another's domain.
Search index
Site search and content discovery usually run on a separate index that the CMS updates whenever content is published or unpublished. Across many sites, the index needs a clear rule for which content each site can see, how language variants are stored, and how the index is rebuilt after a failure. Decide whether search is per site or shared, who maintains relevance settings, and how deleted or restricted pages leave the index quickly. Confirm the indexing approach with the module or plugin maintainers before you commit to a design.
Backup and disaster recovery
Backups protect the database, uploaded files and configuration, and disaster recovery defines how quickly each site returns after a loss. Keep the three data types in step, because a database restored without its matching media files produces broken pages. Decide the recovery point and recovery time targets per site, where copies are stored, and whether copies sit in a separate account or region. Restores should be rehearsed on a schedule and documented, since an untested backup is only an assumption. Set these targets with business owners, not with the infrastructure team alone.
Monitoring and security alerting
Monitoring shows whether the stack is healthy, and security alerting shows whether it is being attacked or misconfigured. Track uptime per site, response times, cache hit rates, cron failures, queue backlogs, certificate expiry and failed logins. Route alerts to a named on-call group, and send security events such as new admin accounts or module changes to the people who approve releases. Decide which logs are retained, for how long, and who can read them, because logs often hold personal data. Check that your monitoring covers the CDN and search index, not only the web servers.
Should you build in-house, use a partner, or buy a hosted CMS
This table compares running an open-source enterprise CMS in-house, with an implementation partner, or on a commercial SaaS or hosted DXP. Read each row as a question about who holds the data, who does the patching, and who is paid for each stage. The main takeaway is that open-source licensing removes the license fee, not the operating work, so the real choice is who carries the recurring release, security and hosting duties.
| Decision factor | In-house on open source | Open source with an implementation partner | Commercial SaaS or hosted DXP |
|---|---|---|---|
| Control over data and hosting | Full control. Your team chooses cloud account, data residency and network design | Full control retained in your own cloud, data center or private network, with the partner working inside it | Vendor hosts the platform. Confirm data location, subprocessors and exit terms in the contract |
| Core effort | Your team handles installs, module and theme upgrades, security patches and content workflow changes | Partner builds, hardens and documents the platform. Your team owns content, governance and sign-off | Vendor runs the platform. Your team configures within vendor limits and follows the vendor upgrade calendar |
| Skills you need | Drupal or WordPress developers, DevOps, security operations and accessibility testing, all retained in-house | A smaller internal team for product ownership, content operations and vendor management, plus a partner for specialist work | Platform administrators and content teams. Development skills depend on how far customization goes |
| Release and patch cadence | Your team tracks each core and contributed module release, such as Drupal 11.x feature releases every six months, and tests before deploying | Partner can run the patch cycle under written scope. Confirm which releases and which environments are covered | Vendor applies platform updates on its schedule. Confirm how custom code and integrations are tested against each release |
| One-time cost | Internal build time, architecture, environment setup and migration effort, which you carry as payroll and project time | Fixed-scope implementation fee paid to the partner, plus internal time for content modeling and acceptance testing | Implementation or onboarding fees paid to the vendor or its partner network, plus internal migration effort |
| Recurring cost | Hosting, licenses for any paid add-ons, staff time for patching, monitoring and on-call coverage | Hosting, optional retainer for support and upgrades, and internal content operations staff | Subscription or usage fees to the vendor, which often include hosting. Ask how traffic, storage and seats are metered |
| Accessibility and compliance evidence | Your team produces WCAG 2.1 AA testing evidence and audit records for the public sector deadlines | Partner can prepare controls and test evidence, but auditors and certification bodies issue any attestation | Vendor accessibility statements and audit reports depend on contract terms. Request the current documents before signing |
| Main exit risk | Low licensing lock-in, but knowledge concentrated in a few staff | Low licensing lock-in. Confirm handover of documentation, code repositories and runbooks at the end of the engagement | Higher lock-in through proprietary modules and data formats. Confirm export formats and migration support |
How a multi-site CMS rollout runs, phase by phase
The sequence moves a multi-site web estate from agreed requirements to a governed, patchable platform, with each phase closing on a written artifact that the next phase depends on. Sign-off gates keep scope, content quality and accessibility decisions visible to the business owners who will live with them.
Confirm discovery and requirements sign-off
Stakeholders from marketing, legal, IT security and each site owner document the current estate: sites, domains, templates, content volumes, integrations, editorial roles and traffic patterns. DeployOpen maps these into functional and non-functional requirements, including the Drupal or WordPress version policy, security response expectations and the sites that must share components. The phase closes when the requirements document and in-scope site list are signed off in writing, because every later estimate and change request is measured against them.
Design architecture and hosting
The team designs the hosting topology inside the client's own cloud account, data center or private network: web and database tiers, caching, file storage, search, backup targets, environments for development, staging and production, and the high availability model. Security controls such as network segmentation, secrets handling, admin access paths and logging are defined here. The output is an architecture decision record and a hosting design that the client's infrastructure and security teams review. Ask the team to confirm how the design matches your recovery objectives before build begins.
Model content and set governance
Editors, content owners and the web governance group agree on content types, shared components, taxonomy, multilingual needs, and which site-level fields can vary by brand or region. Workflow states, approval paths, roles and permissions are documented alongside the rules for who can publish global navigation or legal text. The phase produces a content model, a governance charter and a permissions matrix, and it closes when a pilot editor can complete a full publishing cycle on a sample site without developer help.
Build templates and integrations
Developers build the theme and component library, custom modules or plugins, and the integrations the requirements call for, such as single sign-on, CRM, analytics consent handling, search, forms and payment or commerce hand-offs. Code is reviewed, tested in the staging environment and tracked in version control with infrastructure defined as code where practical. The phase closes when integration tests pass against agreed test data and the security review of custom code has no open high-severity findings, which DeployOpen records in the build log.
Migrate content and run content QA
Content is extracted from source platforms, mapped to the new content model, transformed, and loaded in repeatable batches. Each batch gets reconciliation reports covering item counts, URL redirects, media references, metadata and broken links. Site owners check representative pages against sign-off samples. The phase closes with a migration report per site that lists exceptions, the owner who accepted each one, and the redirect map that will go live at cutover. Confirm whether legacy sites will be archived or retired, since that decision changes the scope of this step.
Test accessibility against the agreed standard
Accessibility testing runs throughout build, not only at the end. The team checks templates, components and representative content against WCAG success criteria at the level named in the requirements, covering keyboard operation, focus order, color contrast, form labeling, and screen reader behavior. For public sector estates, the ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level AA, so the test scope should match that obligation where it applies. The phase closes with a defect log, a remediation record and a list of known exceptions with owners and planned fixes, which the client's accessibility lead must accept.
Cut over and run hypercare
Cutover follows a written runbook that sets the freeze window, final content sync, DNS and certificate changes, redirect activation, cache warm-up and rollback criteria. After go-live, a hypercare period keeps the build team on call for defects, monitoring alerts and editor questions. Performance, error rates and redirect hits are reviewed daily during this period. The phase closes when the agreed exit criteria are met and the client accepts the hypercare report, which lists incidents, root causes and any open items moved into the support plan.
Hand over the patch and release runbook
The final phase transfers operating responsibility to the client team or to a support retainer. The handover pack includes the architecture and hosting documentation, runbooks for backup and restore testing, the Drupal or WordPress core and module update procedure, the release calendar process, and the staging-to-production promotion steps with approval points. Operators practice a patch cycle in staging and document how security advisories are triaged. The handover closes when the client's team completes a supervised patch release and a restore test, and both results are recorded in the runbook.
How to migrate from a proprietary DXP without losing content or SEO
The content audit decides the migration scope, so start there before any build work begins. Export the inventory from the proprietary DXP and classify every content type, template, workflow and integration as migrate, rebuild, retire or archive. Pages that receive no traffic and have no legal retention requirement are often the first candidates to archive instead of move. Map each proprietary content type to a Drupal content type with fields, or to a WordPress custom post type with metadata, and record the mapping in a shared spreadsheet that content owners sign off. Confirm with the vendor and your own team how the proprietary platform exports content, references, media and workflow states, because some exports drop relationships or localized variants and those gaps surface late if nobody checks them early.
Redirects carry most of the SEO risk, and they are usually written last and tested least. Before cutover, the buyer should provide a complete URL list from server logs or the analytics platform, the current XML sitemap, and the existing redirect rules, including any defined in the proprietary platform's admin console. Map each old URL to a new one in a version-controlled file, then test the mapping with a crawl of the old site so that chains and loops are caught before launch. Keep the old analytics property and search console access until organic traffic and indexed pages have stabilized, and ask your search agency to confirm the review window. Templating and component rebuild is the other main risk: rebuilt pages often lose structured data, metadata, heading order and accessibility attributes that the old templates produced, so the acceptance criteria should compare rendered output, not just content presence. Run the old and new sites in parallel for a defined period, with editors working in one system at a time and a named owner for each content area during the switch.
Systems the CMS must connect to and what each integration involves
A large web estate rarely stands alone. The CMS sits between identity, marketing, commerce or learning, measurement, search and media, and each connection carries its own data contract. Settle who owns each contract before build starts, because most integration failures trace back to an unclear owner rather than a technical fault.
Identity provider and editor SSO
Editors, reviewers and administrators should sign in through the corporate identity provider using OpenID Connect or SAML, with group claims mapped to Drupal or WordPress roles. Decide who owns the role mapping, how leavers lose access on the same day, and whether break-glass local accounts exist and are reviewed. Check how the chosen modules handle session lifetime and multi-factor enforcement, and confirm both against your own identity configuration rather than assuming the defaults hold.
CRM and marketing tools
Form submissions, consent choices and campaign attribution usually flow from the CMS into a CRM or marketing automation platform. The contract must name the fields, the consent state carried with each record, the retry behavior when the receiving API is down, and who answers when records are rejected. Marketing operations usually owns field definitions, while the CMS team owns the submission logic and its failure handling.
Commerce or learning platform
Where the estate includes a shop or course catalog, the CMS presents content while Magento, WooCommerce, Moodle or Open edX handles transactions or enrollments. Decide whether product data is authored in the CMS or in the commerce platform, and where the single source of truth for prices and course availability sits. Payment card data should stay out of CMS templates and plugins, which keeps payment scope in the commerce platform. Confirm the ownership split with each product team in writing.
Analytics and tag management
Analytics and tag managers load scripts on every page, so they are both a measurement dependency and a security exposure. Define which tags may be deployed, who approves changes, and how consent signals gate non-essential scripts before any personal data is collected. Restrict tag manager publishing rights to named roles and keep a change log. The analytics team owns event definitions, and the platform team owns the page-level loading rules and content security policy.
Search
Site search may run inside the CMS, on a separate search engine, or through a hosted service. Each option changes indexing jobs, access control for restricted content, and how quickly edits appear in results. Agree which system is authoritative for indexing, how unpublished or permission-restricted pages are excluded, and who monitors index freshness. Confirm the supported index update method for the specific CMS version before selecting a search product.
Digital asset manager
Images, video and documents are usually managed in a separate digital asset manager that holds rights, licensing and accessibility metadata. The CMS needs a stable connector or media reference so assets are not copied without their usage rights. Agree who owns asset metadata, how renditions are generated, and how alt text and captions move from the DAM into content. Assets retired in the DAM should trigger a review of the pages that reference them.
What buyers ask about open source enterprise CMS cost, effort and timelines
What drives the cost of running Drupal or WordPress across many sites?
Cost follows the number of sites, the number of content editors, the amount of custom code and the hosting model. Each site adds configuration, theme work, content migration, testing and monitoring, so a shared codebase with a multisite or distribution approach usually costs less to run than many independent installations. Open-source core and most contributed modules carry no license fee, so the recurring spend is labor, hosting, backup, monitoring and third-party services such as search or email. Ask any proposal to separate one-time build work from recurring operations and to list which sites share code.
Can an internal team run a multi-site Drupal or WordPress estate on its own?
Many organizations can, provided they have people who cover platform engineering, security patching, hosting operations and content governance. The gap is usually not the software but the release discipline: Drupal 11.x receives feature releases every six months, and WordPress maintenance only covers the most recent release in each series, so an internal team needs a repeatable upgrade calendar and test environments. Ask whether your team has capacity for that calendar, whether it can staff an on-call rotation, and which parts you would rather hand to a partner under a retainer.
How long does a CMS migration take, and what does it depend on?
Duration depends on the number of sites, the volume and structure of content, the number of templates and integrations, the quality of existing data and how many stakeholders must approve designs and workflows. Migrating from a proprietary digital experience platform adds time for content model mapping, redirects, and rebuilding personalization or workflow logic that the new platform handles differently. Partners normally provide a timeline only after a written scope exists, so ask for milestones tied to content audits, pilot sites, cutover and hypercare.
What does the work need from our content and IT teams?
Content teams must agree on content models, editorial roles, approval workflows and the owners of each site, and they must make decisions quickly during design and migration review. IT teams must provide cloud accounts or data center access, identity integration, DNS and certificate management, network paths to back-end systems, and change windows for cutover. Assign a named product owner on each side. Without those decisions, scope tends to expand during the build, which affects both cost and timeline.
How is security patching handled for a self-hosted CMS estate?
Security patching is an ongoing operating task, not a one-time event. It covers core releases, contributed or third-party modules and themes, PHP and database runtimes, operating system packages and the web server. A workable process tracks security advisories, applies updates in staging, runs automated regression and accessibility checks, and records each change for audit. The written scope should state which patch levels are covered, how emergency patches are handled, who approves production changes and how long the team has to respond to a critical advisory.
How does the end of Drupal 7 support affect legacy estates?
Drupal 7 support ended on January 5, 2025, so any site still running it no longer receives security coverage from the project. Remediation usually means moving content and configuration to a supported Drupal line or to another platform, which is a migration project rather than a simple upgrade. Start by inventorying every Drupal 7 site, its custom modules, integrations and traffic, then classify each site for rebuild, consolidation or retirement. Ask any partner to show how the inventory feeds a written migration plan.
What compliance work is included in a CMS engagement?
Compliance work covers the evidence and controls around the site, such as accessibility testing, access control documentation, change records and patch history. For public sector sites, the ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level AA, with an interim final rule published April 20, 2026 setting compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any attestation. Confirm with counsel which deadlines apply to your organization.
Questions to ask an implementation partner before you sign
Start with release and patch handling, because it decides how much of the platform's life you will be paying for. Ask how the partner tracks Drupal and WordPress security releases, how long a security patch takes to reach your staging environment, and who approves it for production. A good answer names the core release train you are on, describes a written patch window for both core and contributed modules or plugins, and explains how the partner tests patches against your custom code and theme before they reach production. Ask which release line you will be on in writing. For Drupal, confirm whether the partner covers Drupal 11 feature releases on the six-month cadence and how they handle the end-of-support date for any branch you inherit. For WordPress, ask how they follow the single actively maintained release series, since that changes how quickly you must move.
Next, pin down environment ownership and hosting. Ask who holds the cloud accounts, DNS, TLS certificates, backup vaults and CI/CD secrets, and whether your team holds the root or break-glass credentials from day one. A good answer places all environments (development, staging, production, and disaster recovery) in your tenancy, lists who can deploy to production and who can read logs, and states where content data and personal data physically sit. Ask how the accessibility testing will be done. A credible answer names the tools, the manual testing steps with assistive technology, the WCAG 2.1 Level AA criteria in scope, and the evidence you will receive, such as a defect log with severity and retest results. Vague claims of being accessible are not an answer.
How DeployOpen scopes, builds, hands over and supports enterprise CMS platforms
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For enterprise CMS work, that means starting from a written scope covering your sites, workflows and integrations, then delivering a platform your own teams can run after handover.
How we scope
- Inventory every site, domain, language and content type before choosing Drupal, WordPress or another platform.
- Document editorial workflows, approval roles and publishing rules that the written scope must cover.
- Agree the accessibility target, hosting location and integration list in writing before any work starts.
How we build
- Configure multi-site architecture, shared modules and theme components according to the agreed scope.
- Harden the installation, including access controls, update procedures and security configuration for each site.
- Run application security testing against the built platform and log findings with remediation status.
How we hand over
- Deliver runbooks covering deployment, backups, restore tests, upgrades and incident response for your operators.
- Document configuration, integrations and accessibility checks so your compliance team can collect evidence.
- Train your administrators and editors on the workflows and roles defined during scoping.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after the fixed-scope build ends.
- Apply core and module security releases in a tested cadence, following the vendor's published support windows.
- Confirm with us during scoping which support level, response expectations and retainer terms apply to your estate.
