Drupal CMS vs Drupal core: which starting point fits your new site
Start from Drupal CMS if the team building the site is led by marketers, designers and content editors who need recipes, site templates, SEO and lead generation tools, and the Drupal Canvas visual page builder on day one. Start from Drupal core if a developer-led team will model content types, fields and workflows itself and build the theme from the ground up. Both are licensed under GPL-2.0-or-later and there is no paid edition of Drupal itself, so neither route carries a license fee. The decision is about how much build effort you take on at the start and who owns the configuration afterward.
Drupal CMS is a distribution built on Drupal core, and after setup the site is standard Drupal with sample content and preconfigured features. Its modules and themes are updated like any other Drupal site, but the Drupal CMS distribution itself is not updated, so you should confirm how you will carry its preconfigured choices forward. Before you commit, check which recipes and optional AI tools your content team will actually use, and whether those tools fit your governance rules. Drupal core suits teams that want a smaller, unopinionated base and can accept the cost of designing content architecture, editorial workflows and the theme in-house or through an implementation partner.
Plan for the recurring work in either case. Both routes follow the core release schedule, with Drupal 11 as the current major version and Drupal 12 scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. Ask your vendor or partner how a Drupal CMS site will be moved onto a new core major, and whether the distribution's recipe choices will need rework. Ask whether your team has the PHP and Drupal skills to maintain custom code. Drupal CMS reduces early build effort, while Drupal core gives you full control over the model you will live with for years.
Which features ship in Drupal CMS and which you assemble on core
This table compares the capabilities Drupal.org describes for Drupal CMS with what Drupal core gives you as building blocks. Read it as a category view: the exact recipes, AI modules and page builder components depend on the Drupal CMS release you install, so confirm those before you plan. The main takeaway is that Drupal CMS packages marketing and site-building features on top of core, while core leaves those choices to your team.
| Capability | Drupal CMS | Drupal core |
|---|---|---|
| Starting point | Packaged site with pre-built recipes and site templates for common marketing sites | Framework of building blocks; you choose and configure the modules and content types |
| Recipes and site templates | Included as a named feature; confirm which recipes ship in the release you install | Not included; you build equivalent setups by hand or adopt community modules |
| SEO and lead generation | Described as a built-in feature area; confirm the specific modules in your release | Available through contributed modules you select, install and maintain |
| Visual page building | Drupal Canvas visual page builder is part of the package; confirm its maturity for your use | Not part of core; page layout is handled through your theme and chosen contributed tools |
| Optional AI tools | Offered as optional tools with governance controls; confirm which AI features are included and enabled | No AI package in core; any AI capability is added and governed by your team |
| Accessibility and privacy tools | Described as included feature areas; confirm the exact tools in your release | Core provides accessibility foundations; privacy and consent tooling comes from contributed modules |
| Who it suits | Marketing and content teams that want a working site sooner and accept a more opinionated setup | Advanced users and developers who need full control over architecture and module choices |
| Ongoing updates | Drupal CMS itself is not updated; its modules and themes are updated like any other Drupal site | Core and contributed modules are updated directly as part of your normal release process |
Licensing, support and update terms for each starting point
Drupal core and Drupal CMS share the same license and the same security process, so the differences sit in what you update and who you turn to. Each card below covers one term that changes how you run a site after launch.
Core license is GPL-2.0-or-later
Drupal core and contributed files hosted on Drupal.org are licensed under GPL-2.0-or-later. Starting from core or from Drupal CMS gives you the same license terms for the code you run. Check that any commercial module or theme you add from another vendor carries license terms your legal team has reviewed, since Drupal.org licensing covers files hosted there. Ask counsel to confirm how the license applies to your own custom code and deployment model.
Drupal CMS is listed as GPL v2.0
The Drupal CMS project page lists the distribution under GNU GPL v2.0, and it is built on Drupal 11 core. Read this as a listing on the project page, not as a separate contract. Confirm with your legal team which license text applies to each package you deploy, and keep a record of the project version you installed so license review is tied to an exact release.
No paid edition of Drupal
There is no paid edition of Drupal itself, so you do not buy a license tier to unlock core features. Your recurring costs come from hosting, your own staff or partners, and any paid contributed services you choose. Ask any vendor who offers a Drupal license to show exactly which product or support contract they are selling, because the open-source code does not require one.
Drupal CMS is not updated after setup
After setup, a Drupal CMS site is standard Drupal with sample content and preconfigured features. The distribution itself is not updated, so you do not wait for a new Drupal CMS release to patch your site. Plan to update its modules and themes individually, as you would on a core site, and keep a documented owner for each. Confirm this model with your own change control before you choose a starting point.
Modules and themes update like any Drupal site
Contributed modules and themes in a Drupal CMS site are updated individually, on the same cycle as on a core site. Your team owns testing, rollback and the upgrade path for each component. Core starting points put the same work on you from day one, so the difference is mainly the amount of preconfigured code you inherit at launch. Ask whether the modules you rely on are actively maintained before you commit.
Security releases follow the core schedule
Drupal core security releases come out on the third Wednesday of the month, and bugfix releases on the first Wednesday. The Drupal Security Team coordinates vulnerability handling for core and contributed projects. Whichever starting point you choose, subscribe your on-call team to Drupal security advisories and set a patch window that matches the core cycle, so a Drupal CMS site does not wait on a distribution release.
What changes after setup when you update module by module
After setup, a Drupal CMS site is standard Drupal. The Drupal CMS project page states that the site comes with sample content and preconfigured features, and that its modules and themes are updated like any other Drupal site. The part that does not get updated is Drupal CMS itself. Your team therefore owns a set of contributed modules and themes that move on their own release cycles, plus the configuration the recipes wrote into the site. Plan the first months around that ownership, not around a one-time installation.
Three decisions come early. First, decide what to do with the sample content. Delete it on a staging copy before any real editorial work begins, so that test pages and placeholder menus do not leak into production. Second, decide how configuration is tracked. Recipes apply settings to the database, so the site's configuration should be exported and kept under version control, and every change made in the admin interface should land in a reviewed commit. Without that discipline, a later module update can collide with settings nobody remembers making. Confirm the export and import workflow in the Drupal CMS documentation before you commit to a process.
Module updates should pass through a staging environment that mirrors production in code and data. Run the update, apply any configuration changes, and test the content types, views, forms and sign-in flows that the recipes configured. Custom code sits beside the recipe-provided pieces, so keep it in its own custom module or theme directory and document which recipe features it depends on. When a recipe-provided module changes, your custom code is the first thing to re-test. Confirm with the Drupal CMS documentation how recipe-applied settings behave when you update the modules they came from.
Choosing the starting point by team and situation
A marketing-led team usually needs landing pages, campaign pages, SEO tooling and a visual editor before it needs a custom content model. Drupal CMS is aimed at this group: it ships with recipes, site templates, SEO and lead generation features, visual page building with Drupal Canvas and optional AI tools with governance controls. Those features can shorten the first phase of building because the site starts with sample content and preconfigured features instead of a blank install.
- Early build work: Recipes and templates cover common page types, so the team spends less time assembling the first set of content types and pages.
- Visual editing: Drupal Canvas gives editors page-building tools that core does not provide out of the box.
- Optional AI tools: Enable them only if your governance policy allows it, and confirm which features your data handling rules permit.
- Core control trade-off: Core gives more control over the content model, but a marketing team starting there will build those editing experiences itself.
- Post-launch ownership: The site remains standard Drupal. Modules and themes receive updates like any other Drupal site, while Drupal CMS itself is not updated, so someone must track module updates and test them.
Check with your agency or internal team which Drupal CMS version matches your target Drupal core version before you commit to a recipe-driven build.
A developer-led team that wants full control of the content model, theme and deployment usually starts from Drupal core. Drupal.org describes core as the building blocks for advanced users and developers, while Drupal CMS is a more opinionated starting point. Core gives the team a clean codebase without sample content, recipes or preconfigured features that must later be removed or reviewed.
- Content model control: The team defines content types, fields, and workflows directly rather than inheriting them from a template.
- Theme control: Themes are built to the team's front-end standards, which matters if you plan a decoupled setup later.
- Dependency control: Fewer preinstalled modules means a smaller set of contributed projects to patch and monitor.
- Early build work: Expect more time on initial configuration, because nothing is preconfigured beyond core.
- Post-launch ownership: The team owns core upgrades, including the Drupal 11 to Drupal 12 path, which is scheduled for the week of December 7, 2026, and the PHP version each major release requires.
Before you start, confirm the Drupal core version and PHP version your hosting platform supports, and check the release schedule for the window you plan to operate in.
An agency or internal platform team builds the site, then hands it to a client or to an operations group that did not make the original choices. The starting point affects what the handover includes: a Drupal CMS site contains recipe-installed configuration and sample content that the client must understand, while a core build contains only what the agency added. Either route leaves the client with standard Drupal to maintain.
- Handover documentation: Record which recipes were applied and which sample content must be removed before go-live.
- Module inventory: List every contributed module, its maintenance status and who receives its update notices.
- Support boundaries: Agree in writing who handles core, Drupal CMS features and contributed module updates after launch.
- Reusable builds: A recipe-based start can speed repeat builds for similar sites, while a core build suits clients with unique data models.
- Ongoing ownership: The client's team must test and apply module updates, so confirm they have the skills or a support retainer before handover.
Ask the client's operations team which update cadence they can staff, then choose the starting point that matches it.
What drives the cost of each starting point
This table sets out the cost components of building on Drupal CMS and on Drupal core, row by row, so you can see who is paid for what and what recurs. Neither option carries a license fee, so the differences come from build effort, module upkeep, hosting and the eventual Drupal 12 upgrade. DeployOpen does not publish a price list, and a quote follows from the written scope.
| Cost component | Drupal CMS | Drupal core |
|---|---|---|
| Licensing | None. Drupal CMS is licensed under GPL v2.0, the same as Drupal core. | None. Drupal core is licensed under GPL-2.0-or-later with no paid edition. |
| Initial build | Starts from recipes and site templates with sample content. Effort goes into customizing what is already preconfigured. | Starts from a blank framework. Effort goes into designing the content model, views, theme and configuration. |
| Front-end theming | Visual page building with Drupal Canvas is included. Custom theme work is needed only where the templates do not match your brand. | A custom theme is typically needed. Budget for design, templating and accessibility testing from the start. |
| Module maintenance | Modules and themes are updated like any other Drupal site. The Drupal CMS distribution itself is not updated, so you maintain its included modules individually. | You choose each module and maintain every one. The module count is usually smaller at launch, but each add-on is yours to track. |
| AI feature setup | Optional AI tools with governance controls are part of the package. Setup, provider configuration and review of AI usage are added cost to confirm. | AI features are not part of core. Any AI capability is a separate contributed module or integration, scoped and tested on its own. |
| Hosting | Runs on Apache or Nginx with MariaDB, MySQL, PostgreSQL or SQLite. PHP 8.3 or later is required for Drupal 11. | Same web server and database options. Hosting cost is driven by the same stack, so the difference is in the size of the codebase you operate. |
| Upgrade to Drupal 12 | Drupal 12 requires PHP 8.5 or later. Plan module compatibility checks and the Drupal CMS distribution's own update path, which must be confirmed with the project. | Drupal 12 requires PHP 8.5 or later. Each contributed module and custom code path needs testing against the new major version. |
| What to ask for in a quote | Included recipes and templates, the AI feature setup and its governance scope, the full module list with versions, and the support window. | The module list with maintenance responsibility, the custom theme and content model scope, the upgrade plan for Drupal 12, and the support window. |
Moving a site from Drupal core to Drupal CMS, or back
This sequence tells a team which parts of an existing site move cleanly between Drupal core and Drupal CMS, which parts need rebuilding, and how to prove the change works on a copy before any production cutover.
Confirm the supported migration path first
Before any work starts, the site owner and the lead developer read the Drupal CMS documentation on drupal.org and confirm whether it describes a supported path in the direction you need, either adopting Drupal CMS on an existing Drupal 11 core site or moving back to core. Do not assume a path works because the modules look compatible. Record the answer, the Drupal CMS version you will target (the project page lists version 2.2.5 at the time of writing) and the core version underneath it. If the documentation does not cover your direction, the decision moves to a planned rebuild rather than an in-place change. Done when the team has a written note naming the documented path or the lack of one.
Inventory recipes, modules and themes
A developer lists every installed recipe, contributed module, custom module, theme and their versions, using the site's Composer manifest and the extension admin screens. For each Drupal CMS recipe, note which content types, views, fields, roles, blocks and menus it created, since those are the pieces a reverse move is most likely to remove or rebuild. Flag any contributed project that exists only in one edition's dependency tree. Done when the inventory is a spreadsheet or document that a second person has reviewed, with every item marked as kept, removed or rebuilt.
Separate configuration from code
The developer sorts what the site owns into three groups: exported configuration in the config directory, custom code in custom modules and themes, and content in the database and files directory. Configuration created by a recipe usually lives in the exported config and can be reviewed as text, while custom code must be version controlled and deployed separately. Mark anything that exists only in the live database, such as content created through the visual page builder, so it is not missed. Done when each item in the inventory has a category and the team can export the full configuration from a clean build and diff it against production.
Build the target on a fresh codebase
The developer creates a new codebase for the target edition from the same version control repository, installs it on a non-production environment, and imports the reviewed configuration. Errors at this stage usually point to missing modules, dependencies or config that depended on a recipe the team did not record. Fix these in version control, not by editing the live site. Done when a clean install builds from code alone and the configuration export matches what the team expects.
Rehearse the change on a staging copy of the database
The operations lead takes a recent copy of the production database and files, restores it to a staging environment that matches production's PHP version, web server and database engine, and runs the full update and any configuration changes there. The team checks the database engine and PHP requirements against the Drupal.org system requirements for the target version before the rehearsal. Record the steps, the time each one took, the errors and the fixes. Done when the rehearsal finishes end to end on a copy, a second run from a fresh copy produces the same result, and the steps are written as a runbook.
Decide how to handle sample content
The content lead decides, with the marketing and editorial owners, whether sample content installed by a Drupal CMS template or recipe stays, is deleted or is replaced by real pages. Sample content is a content decision, not a configuration one, so it should not be exported as part of the site. Removing it on staging first shows whether any menus, blocks or redirects point at it. Done when the team has a signed-off list of sample items to keep or remove, and the rehearsal confirms that removing them leaves no broken links or empty navigation.
Test, back up and cut over
The QA lead runs functional tests on the staging site covering authentication, forms, search, publishing workflows and the pages that depend on removed recipe pieces. Before production cutover, the operations lead takes a full database and files backup and confirms it restores. The release happens in a planned window, and the team checks the live site, logs and error reports against the test list. Done when the post-release checklist passes and the backup is verified and kept until the team agrees the change is stable.
Document the reverse path and ongoing ownership
The lead developer writes down what the site now owns after the change: which modules are updated individually, which recipe-provided pieces are now plain configuration, and who approves each update. If the team may move in the other direction later, the document lists the recipe pieces likely to be removed or rebuilt and the steps the staging rehearsal proved. Done when the document is stored with the runbook and both the site owner and the developer have signed it.
How Drupal 10 end of life and Drupal 12 affect the choice
The starting point does not change the core upgrade path. A site built on Drupal CMS or on Drupal core today runs Drupal 11, and both will need to move to a later major version as support windows close. Drupal 10 reaches end of life on December 9, 2026, and receives no new releases after that date. Drupal 12.0.0 is scheduled for the week of December 7, 2026, just before that date, and it requires PHP 8.5 or later, while Drupal 11 requires PHP 8.3 or later. If your hosting stack pins PHP to an older branch, schedule the PHP upgrade before any core work begins, because it is a prerequisite for the move.
Release timing should shape your maintenance routine. The core release schedule places bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so both dates belong on your patch calendar. This matters for Drupal CMS sites in a specific way. After setup, the site is standard Drupal with sample content and preconfigured features, and its modules and themes are updated like any other Drupal site. Your team therefore owns the module and theme upgrades that follow each core move, and a Drupal 12 move means checking every contributed project against the new core, whichever starting point you chose.
Before committing, confirm two things. First, check the Drupal CMS project page for when the distribution moves to Drupal 12, since that timing is separate from core's schedule and this page does not state it. Second, confirm that your hosts and build pipeline support PHP 8.5 and that the contributed modules and themes on your shortlist have Drupal 12 compatibility plans. Ask any agency or partner to show in writing how they will schedule the Drupal 12 move, including testing time before the Drupal 10 end-of-life date. Those checks determine whether the starting point saves work or adds it later.
Questions buyers ask before choosing a starting point
Is Drupal CMS a paid edition of Drupal?
No. Drupal CMS is a distribution built on Drupal core, and its project page lists it under GNU GPL v2.0. Drupal.org states there is no paid edition of Drupal itself, and Drupal and its derivative contributed files are licensed under GPL-2.0-or-later. The version listed on the project page is 2.2.5, released on October 14, 2026, and built on Drupal 11 core. Your cost comes from people, hosting, testing and support, not from a license fee for the distribution. Ask any partner to separate software licensing from services and from any third-party AI or hosting services you choose to connect, since the AI tools are optional and carry their own governance decisions.
Should a developer-led team start from Drupal CMS or Drupal core?
Start from core if your team wants to choose every module and shape the architecture before any defaults are applied. Drupal.org describes core as building blocks for advanced users and developers, and Drupal CMS as a more opinionated starting point for marketers and content teams. Drupal CMS can save setup time when its recipes match what you would build anyway, but your team then reviews and sometimes removes marketing modules, Canvas and sample content before the design is settled. A headless team serving a separate front end may gain little from page-building tools. Illustrative example: if the front end is built in React and the content model is custom, core usually gives a cleaner starting point.
How much effort does removing sample content and recipes take?
The effort depends on what each applied recipe created, not on the sample content itself. Recipes can add content types, views, menus, blocks, roles and configuration that other pieces of the site rely on, and removing one can leave dependencies behind. Drupal.org describes a Drupal CMS site after setup as standard Drupal with sample content and preconfigured features, so the work is configuration review and cleanup. Ask the partner for an inventory of what each recipe created, a decision for each item (keep, change or remove), and a removal plan tested on a staging copy first. Cost drivers include the number of recipes applied, how much they were customized and how much testing the content model needs.
What does a Drupal CMS site need from staff after launch?
A Drupal CMS site needs the same routine as any Drupal site. Drupal CMS itself is not updated; its modules and themes are updated individually, like any other Drupal site. The Drupal core schedule sets bugfix releases on the first Wednesday of each month and security releases on the third Wednesday. Drupal 11 requires PHP 8.3 or later, Drupal 12 is scheduled for the week of December 7, 2026 and requires PHP 8.5 or later, and Drupal 10 reaches end of life on December 9, 2026. Staff needs to read release notes, test updates in staging, plan PHP and database upgrades and own the content model. Ask for named roles and whether ongoing upgrades will be covered by a retainer, which DeployOpen offers.
Can a Drupal core site later adopt Drupal CMS features?
Often in part, but do not assume a whole-site switch. Drupal CMS is standard Drupal built on core, so its features come from contributed modules and recipes that can sometimes be added to a core site. Confirm version compatibility with Drupal 11 for each module, whether the recipe creates or changes content types, whether it replaces your theme and how existing content maps to the new structure. Canvas and the optional AI tools should be assessed separately, because they add governance and editorial decisions. Test each addition in a staging copy of the production site, and document which features came from which recipe so future updates stay traceable.
What should a partner scope include for a Drupal starting point?
Write the scope so the quote follows from it. DeployOpen's engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list. Include:
- The starting profile (core or Drupal CMS) and the recipes kept, changed or removed
- The contributed modules required, plus identity integration; the samlauth module supports Drupal 10.3 and later and Drupal 11, and the OpenID Connect module offers built-in clients for several providers
- The database, chosen from the supported list, and the hosting environment inside your own infrastructure
- Backups, staging, testing, handover documentation and post-launch update support
Ask for stated assumptions and exclusions, since they change effort more than any line item.
How DeployOpen scopes and delivers either starting point
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the starting point you pick is decided before any build begins. Whether you choose Drupal CMS or Drupal core, the work is agreed in a written, fixed-scope plan that names the modules, recipes, identity integrations and handover items involved.
How we scope
- We confirm whether the site needs Drupal CMS recipes and site templates or a core build with custom content types and modules.
- The written scope lists deliverables, timelines and which contributed modules and themes are in and out of scope.
- We record the hosting target, database engine and PHP version so the environment matches the supported Drupal release.
- Ongoing upgrades and continuous testing can be scoped as a retainer alongside the initial fixed-scope engagement.
How we build
- We install and configure Drupal CMS or Drupal core in your cloud account, data center or air-gapped network.
- Custom modules, theme work and SAML or OpenID Connect sign-in are built and tested against the agreed scope.
- Security hardening covers the web server, database, file permissions and the contributed modules the site depends on.
- Where Drupal CMS is chosen, we review which bundled tools you will actually keep, so the module list stays manageable.
How we hand over
- Handover documentation covers the install, module inventory, configuration decisions and the update procedure your team will follow.
- Backup and restore steps are documented and tested so your team can recover the site without DeployOpen present.
- Your team receives a record of which modules came from the Drupal CMS distribution and which were added by hand.
- We confirm with your own administrators how module-by-module updates will be run, reviewed and approved after go-live.
How we support
- Support can be scoped as a retainer covering upgrades, security patching and continued testing after launch.
- Upgrade planning follows the Drupal core release schedule, so Drupal 12 timing is planned into the retainer from the start.
- Questions about Drupal CMS releases, module compatibility and governance settings are answered against your written scope.
- Ask any provider, including DeployOpen, to confirm response times and support hours in the written scope before signing.
