Drupal cost of ownership and editions

What Drupal costs to own and which editions exist

Drupal core and the contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. The cost of owning a Drupal site is therefore labor, hosting and maintenance. Budget requests should itemize those lines rather than list a license fee of zero, because the recurring work is where most of the spend sits: applying monthly bugfix releases, reviewing security releases on the third Wednesday of the month, upgrading PHP, moving to each new major version, and keeping contributed modules compatible with the core version you run.

People use the word "edition" for two different choices. The first is the starting codebase: Drupal core, or the Drupal CMS distribution built on core for marketers and content teams, which bundles recipes, site templates, the Drupal Canvas visual page builder (previously Experience Builder) and optional AI tools. Drupal CMS 2.0 is the current major release. The second is paid extended security support for Drupal 7, which ended its community security coverage on January 5, 2025. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. Confirm current terms, coverage and pricing directly with each provider, because extended support is a stopgap, not a version of Drupal you can keep running indefinitely.

The short answer is that most organizations with a stable internal team and a single site can own Drupal in-house, while organizations that need a fixed-scope build, a Drupal 7 exit or an external support commitment usually benefit from a partner for at least the first project. The triggers that move this decision are a budget request that needs a multi-year figure, Drupal 7 end of life, and Drupal 10 end of life on December 9, 2026. Each one creates a dated piece of work, so start the cost model by listing which of these apply and when your team can absorb them.

What a cost of ownership study includes

A cost of ownership study turns the Drupal decision into a written inventory, a schedule and a model that your finance team can test. DeployOpen prepares the model and evidence, and your finance team owns the budget decision.

Inventory of the site or planned build

For an existing site, the inventory lists Drupal core version, contributed modules, custom modules, themes, PHP and database versions, hosting layout and integrations such as SSO. For a planned build, it lists the intended content types, modules and integrations. Each item is tagged with its owner and its upgrade dependency, so later cost lines trace back to something concrete.

Recurring activities by type

The study lists recurring work by category: core and contributed updates, PHP and database upgrades, hosting, monitoring, backups and support hours. Each category gets a frequency, an owner and a note on whether the work is done in-house, by a partner or by the hosting provider. This list is the basis for the recurring cost lines in the model.

Schedule against the core release calendar

The schedule maps recurring work to the Drupal core release calendar: bugfix releases on the first Wednesday of each month, security releases on the third Wednesday, and major versions about every three years. It also marks end-of-life dates for the Drupal and PHP versions in use, so the model shows when a forced upgrade will land in the budget period.

Written cost model with assumptions

The cost model separates one-time costs, such as the build or a major migration, from recurring costs, such as hosting, maintenance and support. Each line states its assumptions, including release frequency, module count and staffing hours. Ask for the model in an editable format so your team can change assumptions and see the effect on the total.

Risks and open decisions

The study records risks that move the cost, such as contributed modules without an active maintainer, custom code that depends on deprecated APIs, or a Drupal 7 site that needs extended security support as a stopgap. Each risk has an owner and a decision date, so finance sees which costs depend on choices not yet made.

Ownership of the budget decision

DeployOpen prepares the model, the inventory and the supporting evidence. Your finance team decides the budget, the accounting treatment and the approval path. Confirm early which assumptions finance will set, such as staffing rates and the planning horizon, so the model reflects their policy rather than a default.

What drives the cost of a Drupal site over time

Each row names a driver that moves the multi-year total of a Drupal site, why it matters and what to do to keep it under control.

Driver	Why it changes cost or effort	How to keep it down
Contributed modules	Each contributed module needs compatibility checks at every Drupal major version and security release, and some lose maintainers over time.	Keep a written contributed module policy that approves modules by maintenance activity, release history and Drupal version support before adoption.
Custom code volume	Custom modules, hooks and theme code must be tested, reviewed and rewritten for deprecated APIs at each major upgrade, and only your team or partner knows them.	Prefer configuration and established contributed modules where they fit, and keep custom code small, documented and covered by automated tests.
Identity and SSO integrations	SAML or OpenID Connect integrations depend on identity provider changes, certificate rotation and role mapping rules that must be retested after each upgrade.	Use the SAML Authentication or OpenID Connect module with a named owner for the identity provider configuration and a test login in every release check.
ERP, CRM and other system integrations	Each external system adds API versions, credentials, data mapping and failure handling that change when the other system changes.	Document each integration's contract, data owner and monitoring, and limit synchronization to the fields the site truly needs.
Number of environments	Every additional environment (development, test, staging, production) needs hosting, deployment runs, data refreshes and sometimes separate licenses or services.	Agree on the minimum environments needed and use configuration management so changes move through the same pipeline each time.
Traffic and caching needs	Higher traffic usually requires more web capacity, a shared cache such as Redis or Varnish or a CDN, and load testing before peaks.	Set performance targets early, measure cache hit rates and size hosting to the measured load rather than to peak estimates.
Content volume and migration debt	Large content sets raise hosting, search indexing and backup costs, and legacy content from older sites often needs cleaning and mapping.	Audit content before migration, archive or delete stale material and set retention rules for media and revisions.
Compliance evidence requirements	Regulated organizations need documented change records, access reviews, backup restore tests and vulnerability tracking, which take recurring effort.	Ask the assessor which evidence they expect, automate exports from the pipeline and assign evidence collection to a named role.
Edition and starting point	Drupal core, Drupal CMS and older major versions carry different build effort. Drupal 7 has no security support after January 5, 2025 and must be migrated, not updated in place.	Confirm the edition against your requirements and plan the next major version (Drupal 11 now, Drupal 12 after December 2026) before the current one reaches end of life.
Upgrade cadence	Bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, so an irregular cadence builds backlog and risk.	Adopt a single fixed upgrade cadence with a standing maintenance window and a documented rollback plan.

Phases of a cost of ownership assessment

The sequence turns an inventory of your current or planned Drupal estate into a written cost model with named owners and review dates, so the comparison between approaches rests on your own facts.

Inventory the current or planned state
Record every Drupal site, its Drupal version and PHP version, hosting platform, database, contributed and custom modules, themes, integrations, and who maintains each one today. For a planned build, record the intended starting point and the modules expected. Output: a site register that lists versions, components and maintainers, which your team checks against the systems it actually runs.
Decide the edition and platform baseline
Choose between Drupal core and Drupal CMS as the starting point, then set the Drupal major version and PHP version the estate will run. Check each against the Drupal core release schedule and the PHP requirements page, including the end-of-life dates that apply to your chosen version. Output: a written baseline naming the edition, major version, PHP version and the dates that will force the next upgrade.
Build the recurring activity model
List the activities that recur on the chosen baseline: monthly bugfix release windows, security releases on Wednesday windows, major version upgrades, contributed module compatibility checks, PHP upgrades, hosting, backups, monitoring and content or configuration changes. For each, record the frequency, the role that performs it and the skills it needs. Output: a recurring activity calendar with a named role for each line item.
Compare the delivery scenarios
Model the same activity list under three scenarios: your in-house team, a partner-supported model, and extended security support as a temporary stopgap for a Drupal 7 estate that cannot yet migrate. Extended support covers security patches, not new features or compatibility work, so its cost is paid alongside the migration it delays. Output: a side-by-side table of who does each activity, what each scenario costs in its own terms, and where each one leaves gaps.
Hand over the model with owners and review dates
Assign an owner to every assumption, cost line and recurring activity, and set a review date for each. Ask the implementation or support partner for a written timeline and a written quote that match the model's scope, so the figures can be checked against the agreed work. Output: a signed-off model document with owners, review dates and the quote references that feed it.

Recurring and one-time costs after go-live

This table lists each Drupal cost category after launch, whether it is one-time or recurring, who usually pays for it, and what to request in a quote so the figures can be compared.

Cost category	One-time or recurring, and who pays	What drives it and what to ask for in a quote
Build and migration	One-time. Paid to the implementation partner or internal team under the written scope.	Content model, custom modules, theme, integrations and any Drupal 7 migration. Ask for a fixed-scope breakdown by phase, the assumptions behind it and the exclusions.
Hosting and database operations	Recurring. Paid to your cloud provider, data center or hosting vendor, plus internal or partner operations time.	Web and database tier sizing, caching, storage, traffic and environments (staging, test). Ask which items are infrastructure charges and which are labor, and who patches the operating system and database.
PHP and Drupal core upgrades	Recurring in effect, incurred in steps. Major Drupal versions arrive about every three years, and the PHP version must also be supported. Paid to internal staff or a support partner.	Major upgrade effort depends on custom code, deprecated API use and contributed module readiness. Ask for an upgrade estimate per major version and how PHP upgrades are scheduled alongside them.
Monthly bugfix and security releases	Recurring. Paid to internal staff or a support retainer. Bugfix releases come on the first Wednesday of each month and security releases on the third Wednesday.	Testing effort per release window, including automated tests and staging deployment. Ask how many release windows the retainer covers and how out-of-cycle security patches are billed.
Contributed module maintenance	Recurring. Paid to internal staff or a partner, plus any license cost of commercial add-ons.	Number of contributed modules, how many are custom forks, and whether they have a maintained release for the current core. Ask the provider to list each module with its maintenance owner.
Security monitoring and advisories	Recurring. Paid to internal security staff, a managed monitoring service or a retainer.	Dependency tracking against Security Team advisories, log monitoring and incident response procedures. Ask who reviews advisories, how quickly critical advisories are actioned and what the escalation path is.
Backups and recovery testing	Recurring. Paid to the hosting provider or internal team for storage and to the operator for restore tests.	Backup frequency, retention period, storage location and restore test frequency. Ask for evidence of a completed restore test and the recovery time the team has verified.
Support retainer hours	Recurring, optional. Paid to the support partner under a written retainer. Hours are agreed in advance and unused hours depend on the contract terms.	Hours per month, response expectations, included upgrades and what falls outside the retainer. Ask for the hour pool, rollover rules and the rate for extra work.
Drupal 7 extended security support	Recurring, optional, only while a Drupal 7 site remains in service. Paid to a listed extended support provider. Drupal 7 security support ended on January 5, 2025.	Provider terms, coverage period and the migration plan that the support bridges. Ask each listed provider for pricing, contract length, coverage scope and what happens at exit. This page does not list prices.
Internal skills and training	Recurring in staff time. Paid through internal salaries or by the partner's team under the retainer.	Number of engineers who can maintain Drupal, Composer, Drush and CI pipelines. Ask the partner what knowledge transfer and documentation is included and what it costs.

How the cost picture changes by starting point

A new build on Drupal core has no license fee, so the cost is mostly the one-time build plus recurring operations. Build effort covers content modeling, custom modules, theming and integrations, and is paid to the team that does the work, whether internal or a partner.

One-time: discovery, content model, theme, custom code and integration build.
Recurring: hosting, monthly bugfix and security updates, and contributed module maintenance.
Cost driver: the number of custom modules and integrations you choose to own.
Cost driver: how much of the site is covered by contributed modules that are already maintained.
Ask any quote to separate build, hosting and a support retainer so each recurring line is visible.

What usually goes wrong in Drupal cost planning

Drupal has no license fee, so most overruns come from work that was left out of the estimate. The six failures below are the ones that most often surface after launch, each with the step that prevents it.

Budgeting only for the build

Drupal core ships bugfix releases on the first Wednesday of each month, security releases on the third Wednesday, and a new major version roughly every three years. Each of these needs review, testing and deployment effort. Model the recurring release work and at least one major upgrade across the planning horizon, and ask any partner to price a retainer or upgrade phase separately from the build.

Ignoring PHP version requirements

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. No supported Drupal version runs on PHP 7. Check the PHP version on your current hosting against the target core version before approving the budget, and include any hosting, container image or runtime upgrade as a line item.

Assuming Drupal 7 updates in place

Drupal 6 and 7 sites cannot be updated directly to Drupal 10 or later. The content and configuration move 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. Estimate the migration as a project with its own audit, mapping, theme rebuild and cutover phases.

Relying on extended support without a date

Drupal 7 security support ended on January 5, 2025. The Drupal Association lists certified Extended Security Support providers, including HeroDevs and Tag1 Consulting, for sites that cannot migrate yet. Extended support is a recurring cost that buys time, not a destination. Set a written migration date, confirm the provider's coverage terms and budget the migration against that date.

Leaving contributed modules unmaintained

Contributed modules often determine whether an upgrade is cheap or expensive. Before the upgrade, inventory every module, check its release status and its compatibility with the target core version, and confirm the module still receives security fixes. For example, the SAML Authentication module's latest stable release supports Drupal 10.3 and later and Drupal 11. Budget for replacements or custom code where support has lapsed.

Treating Drupal CMS as free of custom work

Drupal CMS is a distribution built on Drupal core with recipes, site templates, the Drupal Canvas visual page builder and optional AI tools. It reduces the starting effort but does not remove custom work such as integrations, business rules, bespoke content types or theme requirements. Map each requirement against the template and recipes, then cost the gaps separately.

What the client needs to provide for an accurate estimate

Start by giving the estimator a complete inventory of what runs today. Record the current Drupal core version and the PHP version on each environment, and confirm whether the site is on Drupal 7, which has been out of security support since January 5, 2025, or on a supported line. Next, export a list of every contributed and custom module with its version, its maintainer or owning team, and whether it is actively maintained on Drupal.org. Custom modules with no owner are the most common source of unscoped effort in an upgrade or cost model.

Then supply the hosting and data picture. Include the web servers (Apache or Nginx), the database engine and version (MariaDB, MySQL, PostgreSQL or SQLite), the hosting location and whether it is cloud, virtual machines or bare metal, and any caching, CDN or file storage layers. Add traffic figures from your analytics, peak periods, content volumes by content type, media library size, and the number of editors and their roles. These drive hosting sizing and the recurring maintenance load.

Document integrations and compliance requirements next: each external system the site reads from or writes to, its authentication method, and any data classification, retention or accessibility obligations that apply. Name the internal owner who will approve Drupal updates and security releases, and the budget window in which the work would be funded. Confirm who signs off on the cost model. Three decisions must be made before scoring can finish: the edition or starting point (bare Drupal core or Drupal CMS), the hosting model, and the support level, such as an in-house team, a support retainer or an extended security support arrangement.

Frequently asked questions about Drupal cost

Does Drupal have a license fee?

No. Drupal core and the contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. Your costs come from the work around the software: building the site, hosting it, keeping PHP and Drupal versions supported, maintaining contributed modules, monitoring security advisories and paying for the people who do that work. Confirm any third-party modules, themes, hosting or support contracts you add separately, since their licenses and fees are set by their own vendors.

What are the main costs of running a Drupal site?

The largest costs are usually the initial build, then recurring effort to stay supported. Recurring items include hosting and database, PHP and web server updates, monthly bugfix and security releases, contributed module compatibility checks, and a major version upgrade roughly every three years. Ask every partner to split a written, fixed-scope quote into one-time build work and recurring support work, and to state who pays for hosting, licenses of any add-on services, and testing environments.

Is Drupal CMS a paid product?

Drupal CMS is a distribution built on Drupal core for marketers and content teams, and it includes recipes, site templates, the Drupal Canvas visual page builder and optional AI tools. It is open source like Drupal core, and the Drupal CMS page on Drupal.org describes Drupal CMS 2.0 as the current major release. Whether a starting point saves build effort depends on how closely your requirements match its recipes, so confirm the distribution's license and any optional services you plan to use before you budget.

How often do Drupal upgrades arrive, and what do they cost in effort?

Bugfix releases arrive on the first Wednesday of each month, security releases on the third Wednesday, and new major versions typically every three years, according to the Drupal core release schedule. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Effort depends on how many contributed modules and custom modules you run, and on whether your PHP version and deprecated API usage are current. Ask for the monthly and major upgrade work to be listed separately in any quote.

Can our own team maintain Drupal in-house?

Yes, if you have people who can handle PHP, Composer, Drush, testing and the monthly release windows. Most in-house teams need a named owner for security advisories, a staging environment that mirrors production, and a process for contributed module updates. Plan for a skills gap if your team has not run a major upgrade before, since Drupal 6 and 7 sites cannot be simply updated and must be migrated. Ask a partner to quote a support retainer alongside a handover plan so you can compare doing it yourselves with paying for ongoing support.

How do I compare Drupal implementation partner quotes?

Compare quotes on scope, not headline totals. Check that each one lists discovery, content modeling, custom modules, theme work, integrations, hosting setup, testing, documentation, training and post-launch support, and that the assumptions about your environment are written down. Ask whether the quote is fixed-scope with agreed deliverables and timelines, how changes are priced, what the recurring support covers and what you must provide, such as accounts, content, approvals and access. DeployOpen does not publish a price list, so request a written, fixed-scope quote from each candidate and compare those documents directly.

How DeployOpen scopes and supports Drupal cost work

DeployOpen treats Drupal cost of ownership as a written scope of recurring work, not a license line, because Drupal core and contributed projects are GPL-2.0-or-later and carry no paid edition. We plan the work, build it inside your infrastructure, and document what your team needs to run it over the years ahead.

How we scope

The written scope lists the Drupal version, PHP version, database and web server your site will run on.
We itemize build, hosting, upgrade, contributed module maintenance and security monitoring as separate scope lines.
Engagements are fixed-scope, so the recurring work each line covers is agreed in writing before any build starts.

How we build

We inventory contributed modules and check each one against the Drupal version and PHP version you plan to run.
Custom code is kept to what contributed modules cannot cover, so future upgrade effort stays measurable and contained.
Environments, deployment steps and update procedures are built in your infrastructure, tested before cutover, and recorded.

How we hand over

Handover documentation sets out the upgrade calendar, including monthly bugfix and Wednesday security release windows.
Your team receives a list of contributed projects, their maintainers and the compatibility checks to run before each update.
We record which tasks your team keeps in-house and which ones a retainer would cover, so the ownership cost is visible.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped to the lines agreed in the original plan.
A support scope can cover applying security releases, monitoring advisories and planning the next major version upgrade.
Ask any partner for the quoted effort per recurring line, the named responsibilities and the notice period for changes to scope.