Enterprise CMS RFP questions to ask before you choose a partner
If you run a large multi-site web estate on Drupal or WordPress and need a partner to build, govern, secure and migrate it, send the same written questions to every bidder, score the written answers against the same criteria, and then verify the most important claims in a reference environment before you sign. Written answers are cheap to compare and hard to reinterpret later, and a demonstration in a sandbox shows what a sales conversation cannot. The questions below are the ones that separate partners who have run estates like yours from partners who have only installed the software.
Drupal core and WordPress carry no license fee, so the partner's invoice is the real cost of the platform. Ask each bidder to split its quote into design and build, multi-site architecture, migration, accessibility remediation, hosting and CDN, security release work and ongoing support, and ask which lines are one-time and which recur. Confirm the Drupal branch each bidder proposes against the current release schedule, including the Drupal 10 end-of-life date and the Drupal 12 timing shown on the Drupal core release schedule, and ask how the bidder will handle security releases on the third Wednesday of each month.
DeployOpen is a Chainscore Labs company that implements self-hosted open-source platforms, so it is one of the bidders this page is meant to test, and the questions apply to it in the same way. This page does not recommend a CMS, a hosting provider or a partner. For the functional requirements that these questions depend on, read the enterprise CMS hub and the sibling enterprise CMS requirements checklist, then build your own scoring sheet from them.
Drupal or WordPress: which platform questions to ask and what a good answer contains
Why choose Drupal or WordPress for a large multi-site estate?
A good partner gives a written comparison that starts from your content model, editor count, languages and integrations, not from preference. Both platforms are licensed under GPL-compatible terms: Drupal and its contributed modules are GPL-2.0-or-later, and WordPress is GPLv2 or later, so neither carries a license fee for the core. Ask the partner to score each option against your top ten requirements, to name the Drupal or WordPress version they would start from, and to explain which requirements would change the answer. Ask for the comparison in writing before design begins.
How does a partner test the platform choice against our content model and editors?
The partner should model a representative slice of your content, such as a product page, a location page and a long-form article, and build it on both candidate platforms or at least map it on paper. They should count editor roles, review how many languages and sites share components, and list every integration with its data flow. Ask for the output: a content type inventory, a role and permission map, and a list of integrations with the module or plugin each one needs. Treat any option that depends on many unmaintained plugins as a risk to record.
Which PHP and database versions does the chosen Drupal version require?
Drupal 10 requires PHP 8.1 or later, 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. Drupal runs on Apache or Nginx with MariaDB, MySQL, PostgreSQL or SQLite. WordPress recommends PHP 8.3 or greater and MariaDB 10.11 or greater, or MySQL 8.0 or greater. Ask the partner to state the exact versions in the proposal, confirm that your hosting provider offers them, and confirm that every contributed module or plugin supports the same PHP version.
How will the partner handle Drupal 10 end of life on December 9, 2026?
Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so a site still on Drupal 10 after that date will stop receiving core security fixes. A good answer includes an inventory of the current version, PHP version and contributed modules, a compatibility check against Drupal 11, and a dated upgrade plan that places a test environment and a rollback point before cutover. Ask whether the partner will upgrade in place or rebuild, and what the plan does if the site cannot move before the deadline.
How does the plan account for Drupal 12 scheduled for the week of December 7, 2026?
According to the Drupal core release schedule, Drupal 12.0.0 is scheduled for the week of December 7, 2026. Because the release is a new major version, the partner should check the deprecations in Drupal 11 and the contributed modules you depend on before committing to a target version. Ask for a plan that moves to Drupal 11 first, then assesses Drupal 12 once its release and module support are confirmed. Also ask how the partner will track the schedule, since release dates can shift.
Can we run the platform decision and build ourselves, or do we need a partner?
Your team can run the decision if it has Drupal or WordPress engineers, a hosting team that can operate PHP and database services, and staff who can review security releases on schedule. Most organizations with large estates bring in a partner for the initial architecture, migration and accessibility work, then keep some operations in-house. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks, usually under a fixed-scope written agreement. Ask any partner to separate one-time build work from recurring support.
What does the platform decision cost, and what drives that cost?
The license fee for Drupal and WordPress core is zero, so the cost lies in design, build, multi-site architecture, migration, accessibility work, hosting, and ongoing security updates and support. The largest drivers are the number of sites and languages, the number of integrations, the degree of migration from an older version, and the level of accessibility testing required. Ask the partner for a quote that separates one-time work from recurring costs such as hosting, monitoring, retainers and upgrades, and that states what is excluded. DeployOpen does not publish a price list, and a quote follows from the written scope.
How multi-site governance works on Drupal and WordPress
A single multisite installation runs many sites from one codebase, one database layer and one update cycle. On Drupal, this is usually built with a shared core and per-site configuration and content, while WordPress offers its own multisite network model. The appeal is that a security update or module change is applied once and verified across the network. The trade-off is that one faulty change can affect every site, so the partner must show how it isolates risk.
- Provisioning: Ask how a new site is created from a documented template, which settings are inherited, and how the new site is added to monitoring and backups.
- Central updates: Ask how core and contributed or plugin updates are tested on a staging copy of the network before they reach each site, and who signs off.
- Delegated roles: Ask how per-site editors are limited to their own sites and sections, and how central administrators keep control of shared settings.
- Shared components: Ask how a common component library or theme is versioned so that one site can pin an older version while others move forward.
- Failure isolation: Ask how a broken module on one site is contained, and how rollback works for the whole network.
Check that the written answer names the environments, the test gates and the rollback steps, not only the feature list.
Separate installations give each site its own code base, database and release schedule. This suits brands or agencies with very different requirements, regulatory boundaries that require separate data, or teams that need to upgrade on their own timetable. The cost is that every update, security patch and accessibility fix must be repeated for each site, so the operating model matters more than the software.
- Provisioning: Ask whether new sites are created by automation from a base profile or manually, and how long the partner expects that process to take in its own experience.
- Central updates: Ask how the partner runs a single patch campaign across many installs, including the order of rollout and how failures are reported.
- Delegated roles: Ask how identity is shared across installs, for example through central SSO, and how editor roles are reviewed per site.
- Shared components: Ask how the design system is published as a package that each install consumes, and how breaking changes are announced.
- Operating capacity: Ask how many installs the proposed team can patch within the security release window the policy requires.
Ask the partner to show a sample patch run across several installs with the reporting it produces, and to state in writing who performs each step.
A shared design system defines the components, tokens, layouts and accessibility patterns that every site uses. It keeps brand consistency and reduces repeated accessibility defects, but only if the components are maintained as a product with owners and a release process. Without it, each site drifts and remediation becomes a site-by-site task.
- Component ownership: Ask who maintains each component, how requests are triaged, and how design and accessibility reviews are built into changes.
- Versioning: Ask how component releases are numbered and whether sites can adopt a new version on their own schedule.
- Per-site flexibility: Ask which parts of the theme are locked and which can be changed by a site team, and how exceptions are approved.
- Accessibility baseline: Ask how each component is tested against the accessibility standard the organization has adopted before it is published.
- Documentation: Ask for a component catalogue, editor guidance and a change log that site owners can read without a developer.
The partner should provide a written ownership model and a sample component lifecycle, and explain how a per-site editor can publish content without changing shared structure.
Per-site editors need to publish within their own sites while central teams keep control of shared structure, security settings and the content standards that apply everywhere. On Drupal, this is typically done with roles, permissions and content-type restrictions per site. On WordPress, it depends on the network role model and the plugins chosen. The governance model should be written before the first site is built.
- Role model: Ask for a matrix that maps each role to the sites, content types, workflow states and settings it can change.
- Delegation: Ask how site owners can add or remove their own editors within limits set by the central team, and how those changes are logged.
- Review and audit: Ask how role assignments are reviewed on a schedule and how removed users lose access across all sites.
- Content standards: Ask how required fields, review dates and accessibility checks are enforced for every site, not left to individual editors.
- Training: Ask who trains per-site editors and how the partner documents the permitted actions for each role.
Request the role matrix and a sample audit log in writing before the partner is selected.
How accessibility is tested in the release process
Accessibility is only defensible when it is tested on every release, not once at launch. The cards below cover the target standard, the testing layers, the content and template work, and the records a buyer should expect to receive.
WCAG 2.1 Level AA as the target
The ADA Title II rule requires state and local government web content and mobile apps to meet WCAG 2.1 Level AA, so that level should be the written acceptance criterion in the RFP. Ask the partner to map each template and component to the specific success criteria it must pass, and to state which content types are out of scope. The compliance dates differ by population: April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities and special districts.
Automated and manual testing stages
Automated checks catch missing alternative text, contrast failures and broken form labels early in the pipeline, but they cannot judge whether a page makes sense. Manual review by a trained tester should cover keyboard navigation, focus order, headings and reading order on each new template. Ask where each stage runs, whether a failing automated check blocks a merge, and who signs off the manual review before a release reaches production.
Assistive technology test coverage
Automated tools do not replace testing with real screen readers and voice control software. Ask the partner which screen reader and browser combinations are tested, which versions are pinned, and which user journeys are scripted, such as login, search, form submission and checkout. Coverage should be written down per release so a reviewer can see what was actually exercised, not only what the vendor claims is supported.
Remediation of vendor and editor content
Accessibility problems often come from third-party embeds, editor-entered content and plugins rather than core code. The RFP should require a rule for each: which embeds are allowed, how editors are trained on headings and alternative text, and whether the content workflow blocks publication when required fields are empty. Ask who fixes a defect in a vendor-supplied widget, and whether that fix is tracked against the release that introduced it.
Accessibility statement and feedback channel
Public bodies need a published accessibility statement that describes conformance status, known gaps and a route for users to report barriers. Ask who owns the statement text, how often it is reviewed after each release, and where reports are logged and answered. A feedback mechanism without a tracked queue and a response owner will not show diligence to an auditor, so request the process document as part of the proposal.
Evidence retained for each release
A buyer should receive a record for every release: the test scope, automated scan results, manual test notes, assistive technology results, defects found and the fix or accepted risk for each. DeployOpen prepares this evidence for compliance assessments but does not issue audit reports or certifications, so the agreed evidence pack should name the independent auditor or certification body that will review it. Confirm the retention period and storage location in writing.
How SSO is added to editor accounts without weakening the estate
This sequence moves editor sign-in onto the organization's identity provider in a tested, reversible way, so that every editor's access follows the same controls as the rest of the workforce and no site is left with a shadow login.
Confirm the identity provider and its owner
The partner records which identity provider the organization uses for staff, who administers it, which groups already exist, and whether multi-factor authentication and session lifetime policies are enforced there. The owner of the identity provider signs off on the list of applications that will trust it. The step is done when the organization can name the IdP, its administrator and the group names editors will be mapped from, in writing.
Choose SAML or OpenID Connect for each site
The partner compares what the identity provider supports with the modules available for the CMS. For Drupal, the contributed SAML Authentication module (samlauth) lets a site act as a SAML service provider, and its 8.x-3.14 release supports Drupal 10.3 and later and Drupal 11. The contributed OpenID Connect module provides built-in clients for generic OAuth 2.0, GitHub, Google, LinkedIn, Facebook and Okta, so the team should confirm whether the organization's provider fits a built-in client or needs a generic configuration. For WordPress, the partner should name the SSO plugin it proposes and confirm its support for the IdP and the WordPress version in use. The output is a short decision record per protocol, with reasons.
Prove the integration on a non-production site
The partner configures the chosen module against a staging copy of the CMS, using test users and a test tenant or application registration at the identity provider. It checks sign-in, sign-out, session expiry, failed login handling and the behavior when a user is disabled at the IdP. Configuration files and secrets are kept out of the code repository. The step closes when a test script covering these cases has been run and the results are attached to the change record.
Map identity provider groups to CMS roles
Editor, reviewer and administrator access should come from identity provider groups, not from manual assignment in the CMS. The partner drafts a mapping table from each group to a Drupal role or WordPress role, and the organization's content owners approve it. Administrative roles are kept to a small named group, and the mapping is reviewed for any role that can publish, change permissions or install code. The output is an approved mapping table and a test showing that removing a user from a group removes the matching CMS permission on next sign-in.
Control first sign-in account creation
Modules that create accounts on first sign-in are useful, but they can create accounts that were never approved. The partner decides whether first sign-in creates an account, only links an existing account by a verified attribute, or is blocked unless a provisioned account exists. The chosen rule is tested with a user who is in the IdP but not in any editor group, and that user should receive no editing rights. The step closes when the rule and its test result are documented.
Plan fallback and break-glass access
If the identity provider is unavailable, editors still need a way to publish urgent content, and administrators need a way to repair the SSO configuration. The partner proposes a small set of named local emergency accounts, stored under dual control, with strong authentication, used only under a logged procedure and disabled between uses. The organization confirms who may invoke them and how usage is reviewed. The output is a written break-glass procedure and a test that the emergency path works without the IdP.
Roll out with monitoring and a documented review
The partner moves the approved configuration to production, enables logging of sign-ins and permission changes, and sets an alert for repeated failures and for administrator role grants. The change is recorded with the module versions in use, and the partner confirms that the module will be updated through the same monthly security release process as the rest of the site. The step is complete when the first production sign-ins are reviewed against the test script and the organization accepts the runbook.
How monthly security releases are applied across the estate
Your partner should be able to show, in writing, how each monthly release moves from notice to production across every site. For Drupal, the core release schedule sets bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so the estate needs a standing window that accepts both. For WordPress, only the most recent release in the 7.1 series is actively maintained (7.1.3 was released on October 6, 2026), and the WordPress.org API controls which plugin and theme updates apply automatically. That means your estate cannot rely on auto-updates alone. Ask the partner to list every plugin and theme with its source, version, owner and whether it is covered by automatic updates, and to keep that inventory current in version control.
Ask how each change is tested before it reaches production. A typical path runs through a staging copy of the estate, with the core and contributed or plugin updates applied there first, followed by automated regression checks on key templates, forms, search and single sign-on login, and a manual accessibility spot check on pages that changed. Confirm which tests are automated, which are manual, and who owns the test scripts after handover. Rollback should be a tested procedure, not a promise: ask for a database and file snapshot taken before each deployment, the commands or pipeline step that restores it, and the time the partner expects a restore to take on your hosting. Confirm these figures in the partner's written runbook rather than accepting a verbal estimate.
Decide sign-off before the first release. A practical model names a technical owner who approves the staging result, a content owner for each high-traffic section who checks that pages still render and publish, and a security or compliance reviewer who confirms that exceptions are documented. Set a rule for out-of-cycle fixes, such as a critical vulnerability disclosed between scheduled windows, and agree who can authorize it. Ask the partner to produce a release record for each cycle that lists the versions applied, the tests run, the approvals and any rollbacks, because that record is the evidence an assessor or auditor will request.
Security release questions and the answers that show control
This table lists the security release questions to put to an enterprise CMS partner, what a sound answer contains, and the evidence to request. Use it to separate partners who describe a process from partners who can show one. A strong answer names the patch window in the contract, shows how changes reach staging first, and produces restore test records rather than only backup logs.
| Question | What a good answer contains | Evidence to request |
|---|---|---|
| Patch window commitment | Named response windows for security releases written into the statement of work, with the trigger for each and who approves exceptions | Draft contract clause, a sample patch calendar and the last three security cycles with dates applied |
| Staging validation | Every core, module and theme update is applied to a production-like staging copy, with automated tests and editor smoke tests before promotion | Staging environment description, test suite list and a sample release sign-off record |
| Emergency patch procedure | A defined path for out-of-cycle fixes covering on-call contacts, approval shortcuts, rollback steps and post-patch review | Written runbook, escalation roster and an anonymized record of a past emergency change |
| Plugin and module vetting | Dependency inventory, review of maintainer activity and advisory history, and a rule that only approved contributed or third-party code enters production | Current module and plugin inventory, vetting checklist and the approval log for recent additions |
| Backup and restore testing | Scheduled restore tests to a separate environment, with recorded recovery times and data integrity checks, not only backup job success | Restore test reports, backup retention settings and the agreed recovery objectives in writing |
| Logging and monitoring | Centralized logs for authentication, administrative changes and publishing actions, retained for a period agreed with your security team | Log source list, retention configuration, sample alert rules and who reviews them |
| Version support path | A stated plan for moving to the next supported major or minor release, tied to the vendor's published end of life dates | Upgrade calendar and the partner's method for confirming the current end of life dates from the vendor |
| Accountability and reporting | Named owner for each control, a monthly report on patches applied, open findings and exceptions | Sample monthly report and the RACI matrix for patching and incident response |
How Drupal 10 sites move before end of life on December 9, 2026
The sequence turns an aging Drupal 10 estate into a tested Drupal 11 or later site with a documented cutover, redirect map and support plan before end of life arrives. Drupal 10 reaches end of life on December 9, 2026, so the plan should be agreed in writing early.
Inventory modules, themes and integrations
The partner lists every core and contributed module, every custom module, each theme and every integration (SSO, search, forms, CRM, analytics, CDN). For each item it records the version in use, whether a Drupal 11 compatible release exists, whether the project is maintained and who owns it internally. The output is a written inventory with a keep, replace, upgrade or retire decision for each item, approved by the client's content and technical owners. Confirm that the target runs PHP 8.3 or later, as Drupal 11 requires.
Run the Drupal 11 compatibility check
The team builds a copy of the production site on a Drupal 11 target in a non-production environment, using a recent database and file snapshot. They run Drupal's upgrade status checks, update Composer dependencies, and resolve deprecated API calls in custom code. The check closes when the site installs cleanly, the automated test suite passes and the remaining issues are logged with owners. Ask the partner to show the compatibility report, not just a statement that the site is ready.
Rebuild the theme on the new stack
Themes cannot be carried across major versions in the way modules can, so the design system, templates, components and front-end build are rebuilt or ported to the target theme framework. The partner works from the approved design files and the existing markup, and checks that accessibility behavior such as focus order, heading structure and color contrast is kept or improved. The step closes when visual regression screenshots are reviewed and signed off by the design and accessibility owners.
Rehearse content migration
Content types, fields, taxonomies, users, roles and media are migrated into the new site at least twice in rehearsal, with each run timed and checked against a record count and sample review. Editors review a set of high-traffic and high-risk pages, forms and workflows in the rehearsal environment. The output is a migration runbook and a list of exceptions with agreed fixes. Ask the partner to state how it will handle content created after the last rehearsal.
Map redirects and SEO elements
The partner exports the current URL inventory, including paths from the search console and analytics, and maps each one to a destination on the new site. It carries over page titles, meta descriptions, canonical tags, sitemaps and structured data where they exist. Redirects are tested in staging and checked for chains and loops. The step closes with a signed redirect map and a crawl report showing that old URLs return the intended responses.
Freeze content and cut over
The client and partner agree a content freeze window, after which editors work only on the new site or log changes for a final delta migration. The partner runs the final migration, switches DNS or the load balancer, clears caches, and confirms hosting, TLS, email and search functions. The cutover closes with a go or no-go record, a rollback plan that was tested in rehearsal, and sign-off from the business owner. Confirm the exact freeze and cutover dates in the written plan rather than relying on general timing.
Support the site after launch
For a defined period in the written scope, the partner monitors errors, performance and redirects, fixes defects and handles editor questions. It hands over runbooks for routine security updates, which Drupal publishes on its security release schedule, and for restoring backups. The step closes with a handover session, updated documentation and an agreed support model that covers who applies future releases, who approves them and how the client receives the next major upgrade plan. Ask for the post-launch plan with named milestones and owners in writing.
Answers that should worry you
Partners rarely lie outright. They more often give confident answers that skip the hard parts: certification promises, fixed prices without scope, overlays, unplanned end-of-life dates, and a single point of failure in the team. Each card below names the answer to watch for, why it matters, and the follow-up question that exposes it.
Promised certification or audit pass
A partner who says the site will be certified or will pass an audit is making a claim that only an independent auditor or certification body can make. DeployOpen prepares controls, configuration and evidence for assessments but does not issue audit reports or attestations. Ask which controls the partner will document, who performs the assessment, and which evidence the assessor will receive at the end of the build.
Fixed price without written scope
A single number quoted before the estate is inventoried usually hides unknowns: how many sites, languages, templates, integrations and content items must move. Accessibility remediation and migration effort swing widely with those inputs. Ask for a written scope listing deliverables, exclusions, acceptance criteria and timelines, and ask how changes after kickoff are priced and approved.
Accessibility treated as an overlay
An overlay script that claims to make a site accessible does not change the underlying markup, keyboard behavior or content. Regulators and auditors evaluate the delivered pages against WCAG 2.1 Level AA, which is the level the ADA Title II rule requires for state and local government web content. Ask how the partner tests templates with assistive technology, how defects are tracked to closure, and what the accessibility statement will say.
No plan for Drupal 10 end of life
Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so any estate still on it needs a dated upgrade path. Drupal 11 is the current major version, and Drupal 12 is scheduled for the week of December 7, 2026. A partner who says upgrades will happen later, without naming a target version or a test cycle, is leaving the estate exposed. Ask for the upgrade sequence, the PHP version each stage requires, and who signs off on the cutover.
No staging or rollback for security releases
Security releases for Drupal arrive on a published monthly cadence, and WordPress security fixes can arrive in bugfix releases or auto-updates. A process that patches production directly, with no staging copy, regression test or tested rollback, turns each patch into an outage risk. Ask how a security release moves from advisory to staging to production, how long a rollback takes, which tests run before promotion, and who approves a deferred patch.
Single developer or no named support model
When one engineer holds the build knowledge, the estate has a single point of failure in staffing, access and incident response. Multi-site platforms also need named roles for editors, platform operators and on-call responders. Ask who the named engineers are, how knowledge is documented in runbooks, what the response path is for a critical vulnerability, and what happens to the estate if the primary contact leaves the partner.
What buyers ask before hiring outside help on an enterprise CMS
Why does an enterprise Drupal or WordPress project still cost money if the software is free?
Drupal and WordPress carry no license fee, so the budget goes to people and services: design and theme build, multi-site architecture, content migration, accessibility work, integrations, hosting and CDN, and security updates. Drupal core is licensed under GPL-2.0-or-later and there is no paid edition of Drupal itself, so the cost question is really about effort and who performs it. Ask every bidder to split the quote into one-time build work and recurring operations, because the recurring part often runs for the life of the site. Compare proposals on the same scope list rather than on total headline numbers.
How long does a migration to an enterprise CMS take, and what drives it?
Duration depends on the volume and condition of content, the number of sites and languages, how much design is rebuilt, and how many integrations must be re-connected. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They are migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and themes must be rebuilt because they cannot be migrated. Drupal 10 reaches end of life on December 9, 2026, so any Drupal 10 estate should be scheduled early. Ask for a written inventory and a phased plan with a named timeline for each site group before accepting any date.
What does the client's own team need to provide during the engagement?
The client team usually supplies decisions, not labor: content owners who sign off on information architecture, a security reviewer who approves hosting and access rules, an identity team that provides SSO metadata or client registration, and editors who test workflows and content before cutover. Someone must own the editorial roles, permission map and content review dates, because no partner can decide those for the organization. Ask the bidder to list each client role, the hours or sessions expected from it, and the decisions that must be closed before build begins.
Can our team run monthly security releases in-house after launch?
Yes, if the team has the skills, time and a tested release process. Drupal bugfix releases come out on the first Wednesday of each month and security releases on the third Wednesday, so a team must be able to apply patches on that cadence. WordPress only actively maintains the latest release in its 7.1 series, and by default automatic updates apply to plugins and themes only in special cases chosen by the WordPress security team, so plugin and theme patching still needs a process. Ask the partner which parts it hands over, which it runs on a retainer, and what staging and rollback steps the handover includes.
What should a written quote for an enterprise CMS engagement contain?
A usable quote states the scope in writing before work starts, with each site, language, template, integration and migration source listed. It should separate one-time build phases from recurring hosting, support and release work, and name the deliverables for each phase. Ask for the assumptions behind every line, the client responsibilities, the acceptance criteria for accessibility testing, the handling of out-of-scope requests, and how changes are priced. DeployOpen works from a fixed scope agreed in writing, and its quotes follow from that scope rather than from a published price list.
What is the minimum PHP and database baseline a new enterprise build should expect?
Current versions set the floor for hosting. Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, and no supported Drupal version runs on PHP 7. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. Drupal runs on Apache, Nginx and other web servers with MariaDB, MySQL, PostgreSQL or SQLite. Ask the partner to confirm which runtime versions the hosting plan supports, how PHP upgrades are scheduled, and who is responsible for them after launch.
How do we add single sign-on for editors and what does that work involve?
Single sign-on is added with a contributed module or plugin that matches your identity provider. For Drupal, the SAML Authentication module (samlauth) lets the site act as a SAML service provider, and its latest stable release 8.x-3.14 supports Drupal 10.3 and later and Drupal 11. The OpenID Connect module offers built-in clients for generic OAuth 2.0, GitHub, Google, LinkedIn, Facebook and Okta and creates accounts on first sign-in. The work includes role mapping, account deprovisioning and testing, so ask the partner how departing editors lose access.
How DeployOpen scopes and supports an enterprise CMS evaluation
DeployOpen starts an enterprise CMS evaluation with a written, fixed scope before any work begins. That scope names the sites in play, the Drupal or WordPress versions being assessed, the authentication sources, the hosting target and the deliverables, such as a proof of concept, a migration plan or a production build. Because the scope is agreed in writing, a CIO or procurement lead can compare proposals on the same terms. DeployOpen does not publish a price list. A quote follows from that written scope, so the reader should expect the number of sites, languages, integrations and accessibility work to shape it. Ask each bidder to state which of these items are included and which are priced separately.
Every implementation is hosted inside the client's own environment: their cloud accounts, data centers or air-gapped networks. That placement determines who holds the database, the file system, the editor accounts and the form submissions, so it should be decided in the evaluation rather than after go-live. DeployOpen's testing covers the application, its APIs and the hosting boundary, and it produces the accessibility and security results the client's own team can review. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Confirm early which evidence your assessor expects, and ask the partner to map each item to a named control owner.
After launch, support is usually handled through a retainer covering security updates, upgrades to supported core releases, monitoring and continuous testing. Retainers recur, while the initial build and any migration are one-time work, so the quote should separate the two. Ask for the response expectations in writing, who applies core and contributed module updates, how a Drupal or WordPress patch is tested in staging before production, and how the team will handle a planned upgrade to the next major version. Those written answers become the basis for your internal change calendar and your procurement file.
How DeployOpen works with enterprise CMS teams
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an enterprise CMS RFP, we turn the questions in this page into a written scope, build and test against it, and hand over the documentation and evidence your team needs to run the site estate.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- We confirm the Drupal or WordPress version, PHP and database targets, and the number of sites and languages in scope
- Authentication, accessibility conformance level and hosting boundary are written into the scope as named requirements
- We record which editorial roles, workflow states and integrations are included and which are excluded
How we build
- Multi-site architecture, shared theme components and content types are built and reviewed before per-site rollout
- SSO integration is tested against your identity provider in a non-production environment with sample editor accounts
- Accessibility testing is part of the release process, with findings logged and tracked to closure
- Security update procedures and staging-to-production promotion are configured and tested before go-live
How we hand over
- Architecture, configuration, runbooks and update procedures are documented for your platform and operations teams
- Accessibility test results, configuration baselines and access reviews are delivered as evidence for your assessors
- Editors and administrators receive role-based training matched to the permissions defined in the scope
- Handover includes a written list of open items, owners and the next scheduled Drupal or WordPress release review
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build
- Monthly security releases are reviewed and applied to staging first, with rollback steps documented
- Major version moves, such as Drupal 10 to a supported release, are planned as separately scoped projects
- We confirm with you which party owns hosting, CDN and third-party add-on contracts before support begins
