What an enterprise CMS costs when the software is free
If you are renewing a licensed digital experience platform or facing a Drupal 10 or WordPress deadline, the budget question is not the software. Drupal is licensed under the GNU General Public License, version 2 or later (GPL-2.0-or-later), and WordPress is released under the GPLv2 or later, so neither carries a license fee to use, copy or run. Drupal has no paid edition of its own. That means the money goes to people, build work, hosting, accessibility remediation and ongoing support, and the total depends on how many sites you run, how many languages they publish in, how many systems they must integrate with, and how far each site has already fallen behind on versions.
Start by separating one-time costs from recurring ones. One-time costs include design system work, multi-site architecture, content migration, theme rebuilds and accessibility remediation of the existing estate. Recurring costs include hosting and CDN capacity, security patching, plugin or module maintenance, editor support and the upgrade cycle. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12.0.0 is scheduled for the week of December 7, 2026, so a Drupal 10 estate will need a planned move that is not a routine patch. Ask your partner to price the migration of each site, not a single lump sum, and to state which parts assume a shared theme and which assume per-site builds.
Ask each bidder for a quote built from a written scope: site count, languages, integrations, the current version of every site, hosting model, and who holds the security update responsibility. Compare that quote with the licensed platform's renewal and with a SaaS subscription on the same scope. A quote that omits any of these lines is not comparable, and the gap usually appears later as an unbudgeted change request.
Which cost components sit with in-house teams, partners and SaaS
This table compares who typically carries each enterprise CMS cost component under an in-house build, an implementation partner engagement, and a licensed SaaS or DXP subscription. Read each cell for the payer and whether the cost is one-time or recurring, because Drupal and WordPress remove the license line but not the build, hosting or upkeep. Confirm each allocation in your own quote and contracts.
| Cost component | In-house team | Implementation partner | Licensed SaaS or DXP |
|---|---|---|---|
| Design and build | Your staff pay salaries for design, front-end and back-end work; one-time for launch, then recurring as the team maintains it | Paid per fixed-scope project for design, theming and build; one-time, with optional retainers afterward | Usually bundled into subscription plus vendor or certified-partner services fees; confirm what the license includes |
| Multi-site architecture | Internal architects decide multisite versus separate installs; one-time design, with ongoing governance staff | One-time architecture design and shared component library, often scoped separately from site builds | Multi-site tiers and tenant limits set by the vendor; recurring subscription cost rises with site count |
| Migration from Drupal 7 or older versions | Staff rebuild themes and migrate content; one-time, and effort depends on the age of the estate | Scoped migration using core migration modules or Drush, including theme rebuilds; one-time | Migration tooling and services may be extra; confirm whether moving off a legacy platform is quoted separately |
| Accessibility remediation | Internal QA and remediation staff; one-time audit plus recurring testing in every release | One-time remediation and testing against WCAG 2.1 AA, with optional recurring regression testing | Vendor accessibility claims vary; ask for conformance evidence and who fixes defects in your templates |
| Hosting and CDN | Your cloud or data center spend and operations staff; recurring, scaled by traffic and sites | Hosting may be set up and run by the partner under your cloud account; confirm who owns the bill | Hosting usually included in subscription; recurring, with tiers tied to traffic, storage or environments |
| Security updates and support | Staff apply core and module releases monthly; recurring labor and on-call coverage | Retainer for patching, monitoring and release testing; recurring, scoped in writing | Vendor applies platform patches; check response times and whether custom code is covered |
| Extended support for end-of-life versions | Internal or third-party extended security support, if a legacy version must run longer; recurring | Partner can arrange or manage extended support providers; recurring and separate from core upkeep | Not typically applicable, since the vendor manages the platform version; confirm end-of-life dates in writing |
| Training and editor enablement | Internal enablement time; one-time onboarding plus recurring turnover training | One-time workshops and documentation as part of scope; recurring refreshers only if contracted | Vendor training courses or certification may cost extra; confirm seat, course and renewal terms |
What moves the enterprise CMS cost up or down
Drupal and WordPress carry no license fee, so the cost sits in the work around the platform. The drivers below decide how much design, build, migration and recurring upkeep an estate needs, and each one should be priced in the written scope rather than assumed.
Number of sites and languages
Each additional site adds templates, content types, editor accounts, redirects and testing, while each added language adds translation workflow, hreflang handling and review effort. Multi-site architecture on one shared codebase usually keeps recurring updates to one pipeline, whereas separate installs multiply patching work. Ask the partner to price the build around a site count and language count, and to state how new sites are provisioned after launch. Illustrative: ten sites on one codebase and forty sites on separate installs carry very different update workloads.
Shared design system and components
A shared component library and theme lowers the cost of every new site, but building it is a one-time investment that must be funded before the savings appear. Theme work is where migration costs often hide, because the Drupal documentation states that Drupal 6 and 7 themes must be rebuilt rather than migrated. Ask whether the quote includes component documentation, a visual regression suite and a plan for who maintains the library after handover.
SSO and search integrations
Editor single sign-on and public search are common integrations that add build and recurring cost. For Drupal, contributed modules such as SAML Authentication and OpenID Connect cover common identity patterns, but each identity provider still needs configuration, testing and a process for role mapping. Search may need a separate indexing service, which adds hosting and reindexing work. Confirm which identity provider, which search service and who owns the connector after launch.
Accessibility conformance target
The conformance level sets how much testing, remediation and editorial training the project needs. Public bodies in the US face WCAG 2.1 Level AA deadlines under the ADA Title II rule, and a higher target across many templates raises both build and ongoing content review effort. Ask the partner how accessibility is tested before release, which pages are covered by manual review, and what evidence is delivered at handover.
Migration from end-of-life versions
Drupal 7 security support ended on January 5, 2025, and Drupal 10 reaches end of life on December 9, 2026, so older estates may need a rebuild rather than an in-place upgrade. Migration cost depends on content volume, redirect mapping, custom code and theme rebuilds. Sites that cannot move in time may need paid extended security support, so ask for a dated migration plan and a fee estimate for that interim coverage.
Hosting boundary and data location
Where the site runs determines who patches the server, who holds backups and who answers for data location. Hosting inside the client's own cloud account or data center adds infrastructure engineering and monitoring work, while managed hosting shifts some of that cost into a recurring fee. Ask for a written responsibility split covering the CDN, database, backups, PHP and web server versions, and the cost of each layer.
Which costs are one-time and which recur every year
Most of the cost of an enterprise CMS on Drupal or WordPress is front-loaded. Design, the build of shared components and the multi-site architecture, content migration, theme rebuilds and the first accessibility remediation pass are one-time work. They end when the estate is live and signed off, and they are where a fixed-scope written statement of work pays off, because every deliverable and acceptance test is named before the money is spent. Ask any partner to split its quote into these one-time lines so you can see what you will not pay again.
The rest of the bill recurs. Hosting, the CDN, database and backup capacity, the application of security releases, module and plugin maintenance, and any support retainer run every year for as long as the site stays online. Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so a team that waits for quarterly windows will fall behind. WordPress states that only the most recent release in a series is actively maintained, which means the upgrade path is also a standing task. Together these create a steady operating load that should be budgeted as a permanent line, with a named owner for each monthly release.
Before you approve a budget, confirm three things with any partner or host: who applies each release and how long that takes in your environment, which module or plugin versions carry an ongoing maintenance commitment, and what happens to the estate when a major version reaches end of life. Drupal 10 reaches end of life on December 9, 2026, so a site still on it needs its upgrade budgeted in the same year as its next operating cycle, not as an afterthought. Write these recurring items into the contract so they are priced, scheduled and tested as carefully as the launch.
How to build your own enterprise CMS estimate
This sequence turns a vague budget conversation into a written, line-item estimate that separates one-time build work from recurring run and support costs, so bidders can be compared on the same scope.
Inventory sites, content and owners
Your web or digital team lists every site, domain, language version, content type and editing group in scope, and names an accountable owner for each. Include retired or microsites that still receive traffic, since they often carry legacy forms and redirects. The output is a site register with page counts, content owners and traffic priority. You know this step is done when every site in the register has an owner and a stated keep, merge or retire decision.
Classify the current platform and version
Your platform owner records the CMS, its exact version, the PHP and database versions, installed modules or plugins, and the custom theme code for each site. Compare each version against the vendor's published support status, such as the Drupal core release schedule or the WordPress release list. Older Drupal 7 sites must be rebuilt rather than updated in place, and themes must be rebuilt, which makes them a separate cost line. The output is a platform inventory with an end-of-support flag. Done means every site has a documented version and a migrate, upgrade or keep decision.
Set the accessibility target and deadlines
Your accessibility lead chooses the conformance target, such as WCAG 2.1 Level AA, and identifies which legal deadlines apply to each site. For US state and local government entities, the ADA Title II rule sets compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. Organizations outside that scope should confirm their own obligations with counsel. The output is a written target and a list of sites with their deadlines. Done means remediation of templates and high-traffic pages can be scoped and costed separately.
List integrations and identity requirements
Your architects list every system the CMS must exchange data with, including single sign-on for editors, CRM and marketing automation, search, commerce, analytics, consent management and forms. For each one, record the direction of data flow, the data classes involved and whether an existing module or plugin is known to fit. Mark anything that needs custom development. The output is an integration register that a bidder can price line by line. Done means every integration has an owner, a data class and a build or configure label.
Choose the hosting boundary
Your security and infrastructure teams decide where the sites, databases, file storage, CDN and form submissions will run, and which provider or jurisdiction owns each part. Record the hosting model, such as your own cloud account, a managed provider or an on-premises environment, and the staging and backup locations. Identify any third-party scripts or SaaS add-ons that send data outside the boundary. The output is a hosting diagram and a responsibility matrix. Done means each bidder is quoting against the same boundary, not an assumed one.
Price build, migration, run and support separately
Ask each bidder to price four lines on their own: design and build, migration from current versions, run and hosting, and security updates with support. Build and migration are largely one-time, while run, CDN, monitoring and support recur on a schedule. Ask who is paid for each line, such as your cloud provider, a hosting partner, a development partner or your own staff. The output is a comparison table with one-time and recurring totals per line. Done means the estimate shows which costs fall away if you stop using a partner and which stay with you.
Ask each bidder the same questions
Send every bidder the same written questions: how they will apply monthly or scheduled security releases, how they test accessibility in the release process, how multi-site governance and editor roles are configured, how SSO is added, how a version upgrade is planned and who signs off on it, and what happens to content and code if the engagement ends. Ask for named sample deliverables for each answer. The output is a set of comparable written answers. Done means no bidder answer relies on a claim that cannot be checked.
Write the scope that the estimate depends on
Before work starts, the written scope should state the sites and languages in scope, the target conformance level, the migration method and source versions, the integrations with owners, the hosting boundary, the deliverables and acceptance criteria, the support hours or response model, and the exclusions. It should also name who maintains content after launch and who receives security advisories. The output is a signed statement of work that a fixed-scope bid can reference. Done means a change to any of these items is handled through a written change request with a revised price.
When build, partner or SaaS fits your organization
An in-house build fits organizations that already employ Drupal or WordPress developers, site builders and an operations function that can handle patching. Because Drupal and WordPress carry no license fee, the spending goes to people, hosting and services. Your team carries design, theming, module selection, upgrades and the security response, so the recurring cost is mostly staff time and infrastructure rather than a vendor invoice.
- Who carries the work: your engineers own architecture, releases, incident response and editor support for the life of the site.
- Lock-in: low. The code is GPL-licensed, and you can move hosting or change developers without a license negotiation.
- Exit risk: concentrated in key people. Document theme structure, custom modules and deployment steps so a successor can maintain them.
- Upgrade load: major versions and security releases must be scheduled internally. Confirm your team can absorb the Drupal 12 timeline or the WordPress 7.1 maintenance cadence.
- Hidden cost: accessibility testing, load planning and 24-hour coverage are often underestimated when they sit inside existing roles.
Before committing, ask your team to name who will apply each security release and who can restore a site at night.
A partner-led model splits the work. An implementation partner plans the architecture, builds the first release, migrates content and hands over documentation, while your staff keep the product owner role, editorial governance and day-to-day decisions. This suits organizations that lack depth in Drupal or WordPress engineering but want to own the platform after launch. Costs fall into one-time items such as design, build and migration, and recurring items such as hosting, support retainers and upgrades.
- Who carries the work: the partner delivers against a written scope, and your team accepts deliverables and runs the platform afterward.
- Lock-in: moderate and controllable. Require source code, infrastructure definitions and credentials to sit in your repositories and accounts.
- Exit risk: lower than a proprietary platform, because the code is open source. Confirm which handover documents and training are included in the fixed scope.
- Support model: ask whether upgrades, security releases and testing are a separate retainer or part of the initial project.
- Quote basis: request line items for discovery, build, migration, accessibility work, hosting and post-launch support so you can see what recurs.
Ask the partner to show how a previous handover was documented, and confirm who holds production access at the end of the engagement.
A licensed digital experience platform or hosted SaaS CMS moves hosting, patching and much of the infrastructure to the vendor. You pay subscription or license fees, usually with support terms and a defined feature set, and you accept the vendor's roadmap and release timing. This model can suit teams that prefer a single contract and do not want to run their own hosting, but the commercial terms shape cost and flexibility for years.
- Who carries the work: the vendor operates the platform, while your team still owns content models, integrations and governance.
- Lock-in: typically high. Proprietary data models, templates and add-on components can be hard to move. Check export formats and API access in writing.
- Exit risk: check contract term, data return obligations, the notice period for renewal and the cost of retaining archived content.
- Pricing: no SaaS prices are supplied here. Ask for the fee basis (per site, per user, per traffic tier or per feature), overage terms and any charges for additional environments.
- Data location: confirm where content, editor accounts and form submissions are stored and which subprocessors receive them.
Ask the vendor to provide a full data export of a sample site before signing, and compare its total cost against the open-source models over the contract term.
Questions buyers ask before hiring outside help
How much effort does a Drupal or WordPress enterprise build take?
The effort depends on the scope more than on the software, because neither Drupal nor WordPress charges a license fee. The main drivers are the number of sites and languages, the design system and themes to build, the content types and editorial workflows to model, the integrations (single sign-on, search, forms, marketing tools) and the accessibility testing and remediation. A fixed-scope quote should list each of these as a line item with its deliverable. Ask the partner to separate one-time build work from recurring costs such as hosting, a CDN, security updates and support, since those continue after launch.
How long does a Drupal 7 or Drupal 10 migration take?
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. The timeline is set by the number of content types, the volume and quality of content, custom code, the number of integrations and the number of themes. Drupal 7 security support ended on January 5, 2025. Drupal 10 reaches end of life on December 9, 2026, so a Drupal 10 estate should confirm its move to Drupal 11 or 12 well before that date. Ask for a written inventory and a migration plan before agreeing on a timeline.
What does the client team need to provide during a CMS build?
The partner can build and operate the platform, but the client team still makes several decisions that drive cost and schedule. Content owners need to agree on content models, approval steps and who publishes what. Accessibility sign-off needs a named owner who accepts the test results and the remediation plan. The client must decide on single sign-on, including which identity provider the editors will use, and on the hosting location and provider, including whether the hosting must sit inside a particular jurisdiction. Name these owners in the statement of work so that delays do not sit with the vendor by default.
Can an internal team run a Drupal or WordPress estate without a partner?
Many organizations run a CMS with internal staff, and the question is whether they have enough people with the right skills for the whole lifecycle. The work includes applying core and contributed module updates, testing releases, managing PHP and database versions, hardening, backups, accessibility checks and handling vulnerability reports. Drupal core releases bugfix updates on the first Wednesday of each month and security updates on the third Wednesday, and WordPress maintains only the most recent release in its 7.1 series. Ask whether your team can absorb that cadence every month, not only at launch, and whether a retainer for support and upgrades is a better fit for the gaps.
Is Drupal or WordPress licensing really free?
Drupal core and its derivative contributed modules are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. WordPress is released under the GPLv2 or later. The license cost is zero, but the total cost includes design, build, hosting, a CDN, support and security work. Contributed modules and themes have their own maintenance status, and some integrations use third-party services that charge fees. Check each module's maintenance status and each add-on's license and data handling before you rely on it.
What do paid Drupal 7 extended security programs cover?
The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. These are paid arrangements that extend security coverage for an older version while a migration is planned. They are a bridge, not a replacement for migration, and they are a recurring cost that continues until the site leaves the unsupported version. Ask any provider which versions and modules it covers, how it delivers fixes, how quickly it responds to security reports, and how long the arrangement is expected to last.
Which costs recur after launch on a self-hosted CMS?
Most of the recurring cost is operational. Expect ongoing charges for hosting, a CDN, backups, monitoring, security and bugfix updates, module and theme maintenance, accessibility re-testing after content or design changes, and support hours. The one-time costs are design, build, migration and initial accessibility remediation. Ask the quote to show the recurring items separately, with the frequency of each, and the support hours included so that you can compare it with the cost of a licensed digital experience platform over the same period.
How DeployOpen scopes an enterprise CMS engagement
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For an enterprise CMS, that means the scope covers more than the Drupal or WordPress install. It includes the hosting environment, the CDN and caching layer, the multi-site configuration, the theme and component build, the migration from any older version, the accessibility testing, the SSO integration, the backup and restore procedure, and the handover documentation. Each of these is a line item that changes the cost, so a scope that names them explicitly is the basis for a comparison against a licensed digital experience platform.
Engagements are fixed-scope. Deliverables, timelines, responsibilities and acceptance criteria are agreed in writing before work starts, and a quote follows from that written scope rather than from a template. Ask any partner, DeployOpen included, to show which decisions are settled in the scope: the number of sites and languages, which editors need SSO, whether accessibility remediation covers the existing estate or only new templates, and who owns the security patch cadence after go-live. Where a decision is still open, the scope should state the assumption and the change process. DeployOpen does not publish a price list, so a number you see on a public page should be checked against the written scope it describes.
Ongoing support, upgrades and continuous testing are available as a retainer, which is separate from the build. Ask whether the retainer covers monthly security releases, core and module upgrades, backup restore tests, and accessibility regression checks, and what response expectations apply to each. Confirm with the partner which of these run inside your environment and which depend on access that your security team must approve. The retainer is where recurring cost lives, so compare it line by line against the recurring fees in a licensed platform's contract, not against the one-time build.
How we scope, deliver and support a fixed-scope CMS implementation
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Drupal or WordPress estate, that means agreeing the cost components in writing before work starts, then building, testing and handing over the site with its runbooks and evidence, and offering ongoing support as a retainer.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists each site, language, theme, integration, migration source and hosting component included in the estimate.
- We ask you to name which costs are one-time build work and which are recurring hosting, updates and support, so the quote can be compared with licensed platforms.
How we build
- We build the site on Drupal or WordPress in your environment, with the multi-site structure and shared theme set out in the scope.
- Accessibility testing, security hardening and performance checks are scheduled as named deliverables, not left to a final review.
- Migration from an older version, such as a Drupal 7 or Drupal 10 estate, is planned as its own work package with content and redirect checks.
How we hand over
- Handover includes configuration, deployment and backup documentation, plus the runbook for applying core and plugin updates.
- Editors receive role and permission mapping, so you can see who can publish, review and edit each section.
- We prepare the controls and evidence your internal team or independent auditor will request, without issuing any audit report or certification.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, sized to the scope agreed at handover.
- Retainer scope should state who applies monthly security releases, how the test window works and who approves production changes.
- Ask any partner, including us, to confirm in writing the response process for security advisories affecting your CMS version.
