Open-source CMS compared

The core software costs nothing to license, so the budget sits in everything around it. Drupal core, WordPress and Joomla are all distributed under GPL-family licenses: GPL-2.0-or-later for Drupal, GPLv2 or later for WordPress, and GPL version 2 or later for Joomla. Nobody invoices you for the core itself. What you pay for is planning the site, hosting it, building or configuring it, running upgrades, and getting support when something breaks. Those costs recur every year, and they are set by your team size, your hosting model and how many extensions you run. Ask each candidate partner or internal team to price those components separately in the written scope, so you can see what is one-time (implementation, migration, theme or template work) and what recurs (hosting, maintenance, upgrades, security monitoring).

The license covers the core, but contributed modules, plugins and themes each carry their own license and maintainer. Drupal contributed files hosted on Drupal.org are GPL-2.0-or-later, and WordPress plugins and themes are generally GPL-compatible, yet a plugin or module can be abandoned, handed to a new maintainer or stop tracking a new core release. Before you approve an extension, check who maintains it, when it last released, which core versions it supports and whether its security reports have a clear path. A support decision depends on that answer more than on the core license. Record the maintainer and support status for every extension in your inventory, and treat an unmaintained extension as a replacement or fork decision, not a background detail.

Drupal has no paid edition of core, so paid support comes from third parties or from your own team. Drupal.org lists no commercial tier for the core product, and the Drupal Association's Extended Security Support Provider Program names HeroDevs and Tag1 Consulting as certified vendors for sites that cannot yet migrate off an end-of-life version. WordPress and Joomla follow the same pattern: paid help is bought from agencies, hosts, extension vendors or in-house staff, and the terms are set by each provider rather than by the CMS project. Ask any provider which versions they cover, what response commitments they will write into a contract, and whether they can support the extensions you depend on. Confirm those answers in writing before you rely on them.

Switching later is cheapest when the site is loosely coupled and most expensive when themes, custom modules, content models and integrations are tightly bound to one platform. Before you pick a CMS, map which parts of your site would have to be rebuilt in a different system if you left, because that rebuild, not the license, is usually the largest future cost. Upgrade effort also differs by platform in ways you can plan for. WordPress applies automatic background updates, and since WordPress 5.6 newly created sites have automatic major release updates enabled by default. By default, plugin and theme auto-updates happen only in special cases chosen through the WordPress.org API, so most extensions still need your review and testing. Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, and it plans new major versions roughly every three years, so your team must schedule upgrades rather than rely on background patching. Joomla patch releases typically arrive every 4 to 8 weeks according to its roadmap, and the roadmap describes its dates as tentative.

Drupal 6 and 7 cannot be upgraded in place. Drupal.org documentation says those sites are migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and that themes must be rebuilt because they cannot be migrated. Budget for a rebuild of the front end and a content migration, and confirm the scope in writing with whichever partner you choose. Drupal 7 security support ended on January 5, 2025. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors, but those vendors are relevant only for sites that cannot yet migrate. They are a bridge, not a destination, and you should ask any provider what the extended support covers, how long it runs and what exit path it expects.

Check your upgrade exposure before you commit. Ask your team to list every custom module, theme, plugin, extension and integration, then record which ones are maintained and which version of the platform each one supports. For Drupal, confirm the PHP and database versions your target release needs, since the Drupal 12 requirement is higher than Drupal 10 and 11. For Joomla, confirm the version line and support window on the Joomla roadmap against your own release calendar. Ask any implementation partner for a quote that separates the one-time migration work from the recurring patching, testing and extension maintenance you will pay for each year.

Before a CMS goes on a shortlist, confirm its support window against your own calendar, not against the marketing summary. Drupal, WordPress and Joomla each publish different lifecycle rules: Drupal lists end-of-life dates for each major line in its core release schedule, WordPress maintains only the most recent release in a series according to its releases archive, and Joomla's roadmap describes security-only periods for older 5.x and 6.x lines, with dates it labels as tentative. Write down the end-of-support date for the version you would launch on, the version you expect to run in year three, and the date your current site stops receiving fixes. Joomla's dates in particular should be reconfirmed with the project before a contract is signed, because the roadmap says they can move.

Next, test every contributed module and extension you depend on against the target major version. Module compatibility is the most common reason an upgrade stalls, and it is rarely visible until a staging build fails. Build an inventory of contributed modules, custom modules, themes and plugins, and mark which ones have a release for the target version and which are maintained by a single person or a vendor you have not verified. For each identity-related module, such as the SAML Authentication module (samlauth) or the OpenID Connect module on Drupal, confirm the compatibility line on its project page and test sign-in against your actual identity provider in a non-production environment. Do not assume a supported protocol means your provider's specific configuration, claims mapping or group handling will work.

Finally, confirm multilingual and content workflow requirements with a written list drawn from your editorial process, then check whether each CMS supplies them in core or through add-ons. Ask who approves translations, whether content must move through staged review, how draft and published states are audited, and which languages need right-to-left layouts. Confirm the database and hosting stack with your own operations team as well, since WordPress publishes its recommended PHP and database versions on its requirements page and Drupal publishes its own database matrix. Ask each vendor or DeployOpen for a written scope that names the modules, languages, identity providers and environments being tested, so the quote reflects the work you actually need.