Enterprise CMS requirements checklist

Drupal and WordPress both carry no license fee for the core product, so the platform decision turns on requirements, hosting and support. Drupal core and contributed modules derived from it are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. WordPress is released under GPLv2 or later. Neither license tells you how many sites you can run, how fast security fixes reach you, or who answers when a module breaks, so those questions belong in the requirements phase, not the procurement cost line.

Version currency becomes a concrete requirement the moment you look at the release calendar. Drupal 11.4 was released the week of June 29, 2026, Drupal 12.0.0 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. A estate still on Drupal 10 therefore has a fixed deadline that falls weeks after the next major version ships. On the WordPress side, WordPress 7.1.3 was released October 6, 2026, and only the most recent release in the 7.1 series is actively maintained. Ask each candidate partner to name the version each site runs today, the date that version leaves support, and the upgrade path they will follow. For each of these, record the answer in your requirements document: the supported PHP and database versions for the target release, whether a bugfix or security patch can be applied without a full upgrade, and who in the estate owns the upgrade calendar. Because updates for both platforms depend on those choices, the team that will run the estate needs to confirm them before a build contract is signed.

Drupal 7 security support ended on January 5, 2025, and Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. Each of these sites has to be migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and the themes must be rebuilt because they cannot be migrated. Treat this as a rebuild of the presentation layer and a content and configuration move, not an upgrade. Start by inventorying every Drupal 7 site in the estate, including sites that a department runs outside the central team, and record which contributed modules, custom code and editor-facing features each one depends on, since many of those modules will need replacements in the new version.

Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so any estate still on Drupal 10 needs a dated plan to move to a supported release before that date. Confirm the target version with your team and check the PHP requirements for it: Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. A PHP upgrade can affect hosting, server images and custom modules, so confirm these against your own environment before you pick a target. If a Drupal 7 or 10 site cannot move in time, the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites in that position. Ask any provider for the scope of patches, the period covered and how fixes reach your environment, and treat that cost as recurring until the migration is complete.

Every requirement on this checklist should have a named verification method and a named owner before a contract is signed. Claims about multi-site governance, SSO or accessibility are cheap to make in a proposal and expensive to discover in production, so ask the implementation partner to prove each one on your estate. Start with a written content inventory and content model: list every site, language, content type, shared component and integration, and check that the partner's proposed model covers them without forcing editors into workarounds. Ask for the inventory to be reviewed by the content owners, not only by IT, because they will find the gaps first.

Next, run a proof of concept on one representative site. Choose a site that carries the hardest combination of your needs, such as a multilingual section, a form that posts to a CRM, and a template your design system must match. Require the partner to build the editorial workflow, the role mapping and the publishing path on that site, and to show a scheduled publish and a revision rollback during the demonstration. Pair this with a scripted accessibility test on a sample of templates, covering navigation, forms, media and dynamic components, and ask for the test results and the remediation log, not a summary score. Confirm which WCAG version and conformance level the test targets, because public-sector deadlines are tied to specific versions (see the ADA Title II web rule).

Verify identity and recovery in person or on a live call. Ask for a demo of SSO with your own identity provider, using a test tenant and a non-production account, and check how roles are assigned from group claims, how a leaver loses access, and what happens when the identity provider is unavailable. Then require a restore test from backup into a separate environment, timed and documented, including the database, the uploaded files and the configuration. Record every result in the scope document as an acceptance criterion with a pass condition, an evidence artifact and a sign-off owner. A requirement without a recorded test is an assumption, and assumptions should not survive into the statement of work.

The most useful question to put to any Drupal or WordPress partner is how multi-site governance is enforced, not whether it is supported. Ask who can create a new site, which shared components sit in the design system and who can override them, and where those rules live: in code review, in a shared configuration repository, or in editor habit. A strong answer names the controls. For Drupal multisite or a shared codebase, expect a description of locked components, a process for theme changes, and a record of which sites run which module versions. For WordPress, expect the same questions answered for plugins, which are the usual source of drift across a network. If the answer depends on editors remembering the rules, the governance is not enforced.

Ask how accessibility is tested inside the release process, not after launch. A good answer places automated checks against WCAG 2.1 Level AA in the build pipeline, lists which templates get manual testing with assistive technology, and says who signs off a release when a check fails. Ask whether the partner will hand over the test results and remediation log as evidence, because that record is what auditors and public-sector buyers will request. Be wary of any answer that relies on an overlay product to close the gap. Similarly, ask how SSO is added and tested: a credible partner describes the protocol (for example, SAML through the contributed samlauth module, or OpenID Connect), how editor roles map from identity groups, how account creation on first sign-in is controlled, and what happens to access when someone leaves. Ask to see a test plan that covers failed logins, expired sessions and deprovisioning.

Security releases are the question that most often reveals whether a partner runs a program or a project. Ask how patches are applied on a fixed calendar, who watches the security advisories for core and contributed modules or plugins, how a patch is tested on a staging copy before production, and how long the window is from advisory to deployment. For Drupal, the release cadence is published, with security releases on the third Wednesday of the month, so a good answer maps its process to that schedule. Ask how Drupal 10 sites move before end of life: the Drupal core release schedule lists Drupal 10 end of life on December 9, 2026, and the answer should show a dated migration plan to Drupal 11 or 12, not a promise to upgrade later. Finally, ask what the hosting boundary is and what backup restore evidence looks like. Request a documented restore test with its date, the recovery time measured, the scope of what was restored, and who approved it. Confirm with the partner which data stays in your accounts and which third-party services receive form submissions or analytics.