Drupal or WordPress: when each one fits your site
Drupal fits when your marketing site is turning into a content system. If you need structured content types with governed fields, fine-grained permissions across editorial roles, and integrations that feed content in and out of other systems, Drupal's content modeling and access control are built for that work. It also suits a team that can plan a major upgrade every few years, since Drupal 11 is the current major version and Drupal 12 is scheduled for the week of December 7, 2026. Before committing, confirm your in-house PHP skills and whether you have a partner who can run that upgrade cycle.
WordPress fits when content is simpler and features arrive through plugins. A site built around posts, pages, a short list of roles and a few well-known plugins can be run by a small team that wants minor and security updates to arrive with little ceremony. WordPress applies automatic background updates for minor releases, and new sites have automatic major release updates enabled by default since WordPress 5.6. Plugin updates are different: WordPress applies them automatically only in special cases chosen through the WordPress.org API, so the plugin list is where you should plan your own update process and review.
The decision turns on four questions, not on license. Both projects are GPL-licensed, so the license will not separate them. Ask how complex your content model is, what PHP and site-building skills you already have, how much upgrade work your team can absorb on a planned schedule, and which systems the site must integrate with. Check each integration against the module or plugin you would rely on, and get a written view of the upgrade effort from any implementation partner before you choose.
Which scenario favors which platform
This table matches common Drupal and WordPress scenarios to the platform that usually fits better, with the reason and the condition under which the other platform still makes sense. Read each row as a starting point and test it against your own content model, permission rules and team skills.
| Scenario | Better fit and reason | When the other platform still fits |
|---|---|---|
| Campus or agency site with many content types and editorial workflows | Drupal. Its content modeling, field structure and workflow tools are built for many content types with varied review paths. | WordPress can work if the content model stays simple and editors accept custom post types built through plugins or code. |
| Small team running a brochure or blog site | WordPress. Automatic background updates for minor and security releases and a smaller administrative footprint suit a team without dedicated platform staff. | Drupal fits if the site must grow into a structured content platform later and the team can staff regular module and core updates. |
| Site needing strict role-based permissions across departments | Drupal. Granular permission and role configuration across content types and departments is a core strength, which matters when several teams edit separate sections. | WordPress fits when a few roles are enough and a plugin you have reviewed covers the remaining access rules. |
| Site relying on a large plugin catalog for marketing features | WordPress. Its plugin ecosystem covers many marketing, forms and SEO needs with fewer custom builds. | Drupal fits when those features are better built as contributed modules or custom code that your team will maintain. |
| Organization with a PHP team | Either platform. Both are GPL PHP projects, so existing PHP skills transfer, but Drupal rewards developers who understand its entity and configuration system. | Choose the platform your PHP developers already maintain in production, since familiarity lowers upgrade and support effort. |
| Organization with no PHP skills in house | WordPress is usually easier to staff through agencies and freelancers. Drupal projects typically need experienced developers for builds and upgrades. | Drupal fits if you plan to contract a partner for implementation and ongoing support under a written scope. |
| Multi-site or multilingual publishing across regions | Drupal. Its core multilingual modules and multi-site handling reduce the need to stack plugins or run one WordPress site per language. | WordPress fits a small number of languages where a vetted multilingual plugin covers the translation workflow. |
| Team planning for major upgrades on a fixed cycle | WordPress. Rolling updates on the current release line reduce the chance of a large, scheduled migration project. | Drupal fits when you can plan major upgrades, since Drupal 10 reaches end of life on December 9, 2026 and Drupal 12 is scheduled for the week of December 7, 2026. |
How Drupal and WordPress are built and deployed
Drupal and WordPress both run on PHP and both can sit on the same database families, but they organize content and run operations differently. The cards below cover the data model, the hosting stack, and what each choice means for patching and caching once the site is live.
Entities, fields and permissions
Drupal core is a framework built around entities, fields and a permissions model. Content types, taxonomies, users and custom entities share one structure, and access rules can be set per role, per field and per entity. WordPress centers on posts, pages and custom post types, with a theme and plugin model layered on top. Check whether your access rules need field-level or entity-level control, since that decides how much custom code you will own.
Drupal 11 database support
Drupal 11 runs on MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later, or SQLite 3.45 or later, with Microsoft SQL Server and MongoDB available through contributed modules. Pick the engine your database team already patches and backs up. Confirm the contributed module status for any non-core engine before you commit, since support depends on that module's maintainers.
WordPress hosting baseline
WordPress.org recommends PHP 8.3 or greater with MariaDB 10.11 or greater or MySQL 8.0 or greater. Most shared and managed hosts run this stack, so the hosting bar is low. The operational risk sits in the plugins, which run with the same privileges as core. Ask your host which PHP and database versions it will keep current, and who applies them.
PHP versions and Drupal 12
Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later. A Drupal 12 move therefore means a PHP upgrade in the same window as the core upgrade, which affects every contributed module and custom code. Test your module set against PHP 8.5 early, and confirm your hosting platform offers that runtime before you plan the date.
Patching and caching operations
WordPress applies minor and security background updates by default, and newly created sites also receive automatic major release updates. Drupal updates are applied by your team through Composer and a deployment pipeline, with security releases on a fixed Wednesday. Caching differs too: Drupal's page and render caches rely on cache tags and need a reverse proxy or CDN configured for invalidation, while WordPress caching is usually a plugin or host layer. Plan one owner for each.
How content modeling and permissions differ in practice
Drupal's entity and field model suits organizations whose content has several distinct shapes, such as product sheets, policy documents, locations and staff profiles, each with its own fields, validation and display rules. Content types, fields, view modes and taxonomy are configured in the core interface and stored as configuration, so a new type can be added without custom theme work. Role-based access control then works at the level of content type, field and operation, which matters when a regional editor may update only their office pages and a legal reviewer may publish only policy pages. The condition is complexity: if you expect dozens of content types, many roles and departments that must not see each other's drafts, the model earns its setup cost. If you have a handful of page types and two or three roles, it is usually more structure than you need.
WordPress's post types and roles cover a large share of marketing and publishing sites. Custom post types, custom fields and the built-in Author, Editor and Administrator roles are often enough for a team of a few editors who share most content. The gap appears when the business needs fine-grained rules, such as limiting one role to a single field or a single section of the site. That usually means adding a field-management or role-editing plugin, and you should inventory each plugin for how it stores permissions and whether it is still maintained. Editorial workflow is the sharper question. Drupal's workflow capabilities depend on the modules you enable and the version you run, while WordPress relies on plugins for approval chains. Before you commit, confirm the specific workflow, moderation and revision features against the current documentation for the Drupal and WordPress versions you plan to deploy, and test an approval path with your real roles in a staging site.
Capability comparison for shortlisting
This table compares licensing, release cadence, runtime requirements, identity integration, multilingual handling, extensions and automatic updates for Drupal and WordPress. Read each row as a question to put to both platforms, and treat the WordPress identity and multilingual cells as starting points to confirm against the plugins you plan to use.
| Capability | Drupal | WordPress |
|---|---|---|
| License | GPL-2.0-or-later for Drupal core and contributed projects on Drupal.org, with no paid edition of core | GPLv2 or later, from the Free Software Foundation |
| Release cadence | Bugfix releases on the first Wednesday of each month, security releases on the third Wednesday, new majors about every three years; Drupal 11.4 released the week of June 29, 2026 | Only the latest release is officially supported; WordPress 7.1 released August 19, 2026, and 7.1.3 on October 6, 2026 |
| Database requirements | MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later or SQLite 3.45 or later for Drupal 11 | MariaDB 10.11 or later or MySQL 8.0 or later (recommended by WordPress.org) |
| PHP requirement | Drupal 11 requires PHP 8.3 or later; Drupal 12 requires PHP 8.5 or later | PHP 8.3 or greater recommended by WordPress.org |
| SAML single sign-on | samlauth lets the site act as a SAML service provider; latest stable 8.x-3.14 supports Drupal 10.3+ and 11 | Confirm with the SSO plugin you choose; SAML support is not part of core |
| OpenID Connect sign-on | OpenID Connect module ships clients for generic OAuth 2.0, GitHub, Google, LinkedIn, Facebook and Okta, and creates accounts on first sign-in | Confirm provider support and account provisioning in the specific plugin's documentation |
| Multilingual handling | Four core multilingual modules cover interface, content and configuration translation | No multilingual support out of the box; confirm plugin choice or one site per language on multisite |
| Extension ecosystem | Contributed modules on Drupal.org, maintained by the community and governed by the project's release rules | Large plugin and theme directory; quality and maintenance vary by plugin, so review each one before adoption |
| Automatic updates | Updates are applied through a planned release and module-by-module process, typically run by your team or partner | Background updates for minor and security releases, with automatic major updates on sites created since WordPress 5.6; plugins and themes update automatically only in cases the WordPress.org API selects |
What is free and what is paid on each platform
Drupal and the contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under the GNU General Public License, version 2 or later (GPL-2.0-or-later). There is no paid edition of Drupal itself, so the core carries no license fee. Your spending goes to the people and infrastructure that build, host and maintain the site.
- No license fee for core: You can download, run and modify Drupal without buying a license from the project.
- Paid parties are your team and vendors: Internal staff, agencies and hosting providers are paid for building, hosting and operating the site.
- Hosting stack: Drupal 11 requires PHP 8.3 or later and supports MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later or SQLite 3.45 or later. Drupal 12 requires PHP 8.5 or later.
- Major upgrades carry project work: 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 budget the upgrade as recurring work.
Ask for the target Drupal version and the upgrade approach to be written into the quote.
Drupal CMS is a distribution built on Drupal core for marketers and content teams. It includes recipes, site templates, the Drupal Canvas visual page builder (previously Experience Builder) and optional AI tools, and Drupal CMS 2.0 is the current major release. Its licensing follows the same GPL foundation as core, but each recipe, module and optional AI tool needs its own check. Contributed modules add features, and most are hosted on Drupal.org under the same license terms.
- Distribution is free to start: Drupal CMS gives you a packaged starting point without a license purchase.
- Contributed modules are maintained by different people: Check each project page for its license, maintenance status and release history.
- Identity modules are free to install: The samlauth and OpenID Connect modules cost nothing to download, but configuring and testing them is paid work.
- Optional AI tools have their own costs: Confirm the license of each tool and any fees it requires from model or service providers.
- Commercial add-ons exist outside Drupal.org: Some vendor modules are sold separately, so confirm their terms before you buy.
Ask your partner to list every module and recipe in the build with its license, maintainer and version.
Drupal 7 security support ended on January 5, 2025. Sites that cannot migrate yet can use vendors in the Drupal Association's Extended Security Support Provider Program, which lists HeroDevs and Tag1 Consulting as certified vendors. This coverage is paid, and it buys time for a migration rather than replacing one. Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later, so the migration is a rebuild with its own project cost.
- Extended coverage is a paid service: Vendors charge for security patches, so request the scope, duration and price in writing.
- Coverage is a bridge: Extended support delays the migration spend but does not remove it.
- Migration is a rebuild: Content moves with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, and themes must be rebuilt.
- Hidden project work: Content audits, data mapping and quality assurance are paid to your team or a partner.
- Vendor scope varies: Coverage may apply to some modules and not others on a given site.
Confirm which modules and versions the vendor covers before you sign, since that list drives the migration plan.
WordPress is released under the GPLv2 or later from the Free Software Foundation, and there is no paid core edition. Automatic background updates have been available since WordPress 3.7, and since WordPress 5.6 newly created sites have automatic major release updates enabled by default. Only the latest version is officially supported, although the WordPress Security Team backports critical fixes to older versions as a courtesy. Those backports should not be read as a support contract.
- No license fee for core: WordPress is free to download, run and modify under GPL terms.
- Automatic updates are configurable: Check the update settings on your install, since defaults differ for new and existing sites.
- Backports are a courtesy: Older versions may receive critical security fixes, but the official support window covers only the latest release.
- Hosting baseline: WordPress recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater.
- Operating labor is paid separately: Hosting, backups, monitoring and staff time carry the recurring cost.
Ask your hosting and agency partners for a written update and rollback procedure before go-live.
Each WordPress plugin and theme carries a license set by its author, and the core license does not decide those terms for you. Free plugins and themes come from the WordPress.org directory or from other sources, while premium extensions are often sold with their own subscription terms. By default, plugins and themes update automatically only in special cases determined through the WordPress.org API, which the security team controls to patch critical vulnerabilities, so most extension updates still need your process.
- Author-defined licenses: Confirm the license file and listing for each extension before you install or modify it.
- Premium subscriptions recur: Ask for the renewal price, the update terms and what happens to the site if you stop renewing.
- Limited automatic patching: Plugin and theme updates happen automatically only in special cases, so schedule regular reviews.
- Testing is paid labor: Compatibility testing across extensions is an internal or partner cost that grows with the plugin count.
Inventory every plugin and theme with its license, source and update path before you estimate the run cost.
What Drupal major upgrades cost compared with WordPress rolling updates
The main cost difference is not the release process but how much of each site has to be re-tested when the platform moves. WordPress applies minor updates automatically in the background, and sites created since WordPress 5.6 also receive major release updates by default. Plugin and theme updates are not applied automatically in general: by default, WordPress only updates them in special cases determined by the WordPress.org API, which the security team controls to patch critical vulnerabilities. That means your team still owns the plugin inventory, compatibility checks and any update that falls outside those cases. Check which plugins on your site are actively maintained and whether your auto-update settings match the risk you accept.
Drupal works on a published calendar. Bugfix releases ship on the first Wednesday of each month and security releases on the third Wednesday, and new major versions typically arrive about every three years. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12.0.0 is scheduled for the week of December 7, 2026, with Drupal 12 requiring PHP 8.5 or later. Drupal 10 sites therefore need a dated upgrade plan well before that end-of-life date. Confirm the current schedule on the Drupal core release schedule page before you set milestones, since dates can change.
A Drupal major upgrade is mainly a compatibility project. Each contributed module, custom module and theme must be checked against the new core version, and the upgrade status tooling and deprecation reports help identify what needs rework. Plan a staging environment that mirrors production databases, files and configuration, then test content workflows, roles and permissions, search, caching and every integration such as single sign-on through the SAML Authentication or OpenID Connect modules. Your cost drivers are the number of custom modules, the number of contributed modules without a release for the target version, and the depth of your test coverage. Ask any implementation partner to price the audit, the rework and the regression testing as separate line items in a written scope.
Where extensions and single sign-on add risk
Both platforms run most of their functionality through third-party code, so the security and maintenance risk sits largely in what you install and how you connect it to your identity provider. The cards below cover the review work, the single sign-on paths and the ownership questions that decide how exposed you are over the life of the site.
Contributed module review
Drupal contributed modules are hosted on Drupal.org and carry the same GPL-2.0-or-later terms as core, but their maintainers vary widely in capacity. The risk matters most when a module sits on a content path that handles authenticated users or sensitive forms. Before committing, check the module's maintainer history, its release cadence against core, and whether its supported Drupal versions include the major version you plan to run.
WordPress plugin vetting
WordPress plugins are the main extension risk on that platform, because the WordPress Security Team backports fixes to core but does not control third-party plugin code. By default, automatic updates for plugins and themes apply only in special cases chosen by the WordPress.org API. The question for a plugin is whether your team will apply its updates promptly, which means checking its update history, its install base and whether it has a clear owner.
SAML and OpenID Connect on Drupal
Drupal reaches enterprise single sign-on through contributed modules rather than core. The samlauth module lets a site act as a SAML service provider, and the OpenID Connect module authenticates users from external providers and creates accounts on first sign-in. Confirm that the module version you choose supports your Drupal release, and test account provisioning and deprovisioning before go-live, since first sign-in account creation affects who can reach the site.
Identity options on WordPress
WordPress does not ship a SAML or OpenID Connect client in core, so enterprise single sign-on depends on a plugin or a platform-level integration chosen by your team. The condition that makes this matter is a requirement to enforce corporate identity and group-based access on a public or internal site. Confirm with the plugin vendor which protocols it supports, how it maps groups to roles, and how it behaves when the identity provider is unavailable.
Abandoned extensions
An extension that stops receiving updates becomes a fixed liability once the core platform moves on. On Drupal, a module that lacks a release for the current major version blocks the upgrade path until someone replaces or patches it. On WordPress, an abandoned plugin can keep running on a current core release with unpatched flaws. Check the last release date, open security issues, and whether a maintained alternative exists before you build on it.
Custom code ownership
Custom modules, themes and plugins written for one site become your maintenance burden, and that burden grows if the original developers leave. Drupal custom code must track core API changes at each major upgrade, while WordPress custom code must track more frequent minor releases. Ask your implementation partner for written ownership of the repository, coding standards, automated tests and a documented upgrade procedure as part of the agreed scope.
Moving a site from WordPress to Drupal or the reverse
The sequence runs from inventory to retirement of the old stack, so each move ends with a tested site, mapped content and a documented permissions model. It also shows what transfers as data and what must be rebuilt as code, theme and extension logic.
Inventory content types, plugins and modules
The site owner and a developer list every content type, custom field, taxonomy, form, user role, integration and active plugin or module on the current site. For a WordPress source, this includes custom post types and the plugins that add them. For a Drupal source, it includes content types, contributed modules and custom code. Each item gets one label: move as content, rebuild as configuration, or retire. The step is complete when content owners and the developer have signed off the list and every plugin or module has a named replacement or a retirement decision.
Map content and permissions to the target
A developer and the content lead map each source content type to a target content type, and each custom field to a target field with its data type. Taxonomies, menus, authors and media references get their own rows. Roles and capabilities on the source are mapped to target roles and permissions, including who can publish, edit other people's content and manage users. Ask your developer or implementation partner to present the mapping as a spreadsheet with one row per field. The step is done when every source field has a target or a retirement note and security has reviewed the permissions matrix.
Decide which parts to rebuild
Themes and plugin or module behavior do not carry over as working code. A WordPress theme's templates and a Drupal theme's templates must be built again for the target, so the design system and page layouts become a separate build task with their own review. Drupal.org guidance says Drupal 6 and 7 sites are migrated into a new site and their themes rebuilt, which matters only if your source is one of those versions. See the upgrading from Drupal 6 or 7 to Drupal 8 and newer guide. The step is done when the rebuild list is agreed, each item has an owner and every extension that stays has a confirmed equivalent.
Migrate content and media into staging
Run the content migration against a staging copy of the target, starting with a small sample of each content type so errors surface early. The developer checks record counts, field values, authors, dates, internal links, image and file references and taxonomy terms against the source export. Confirm which migration module or script supports your exact source platform and version before you commit, since support differs by migration path and must be verified in your own environment. The step is done when a reconciliation report shows matching counts and a content owner has signed off a sample from each type.
Test integrations, identity and redirects
Test every integration the old site used, including email, forms, search, analytics, CRM or payment connectors and single sign-on. If the target needs SAML, the contributed samlauth module lets a Drupal site act as a SAML service provider, and its latest stable 8.x-3.14 release supports Drupal 10.3 and later and Drupal 11. Map every old URL to its new address and test the redirects in staging. The step is done when each integration has a passing test case and the redirect report shows no unexpected 404 responses for priority pages.
Cut over and monitor the new site
Freeze editing on the old site, run a final delta migration for anything changed since the test run, then point DNS or the load balancer at the new stack. The operations owner watches error logs, 404 volume, search results, form submissions and cache behavior through the monitoring period set in the cutover plan. Keep the old platform reachable for rollback until the owner and the security lead agree it can stop, and record that decision. The step is done when the cutover checklist is signed off and monitoring shows no open priority issues.
Retire the old stack and set updates
Archive the old database and files under your retention policy, cancel any paid plugin or license tied to the old platform, and remove the old hosting resources once rollback is no longer needed. Then set the update routine for the new site. Drupal core bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, so the owner needs a standing patch window. Newly created WordPress sites have automatic major release updates enabled by default since WordPress 5.6, while plugin and theme updates happen only in cases the WordPress.org API selects. The step is done when the old stack is archived and the update calendar has a named owner.
What implementing each platform involves and where projects run long
Implementation effort differs more in the content model and integration work than in the install itself. For Drupal, the work usually covers hosting setup on a stack that matches the Drupal database requirements, a custom or contributed theme build, a content model made of content types, fields, taxonomies and roles, and then a migration of existing content. Integrations such as SAML through the contributed samlauth module or OpenID Connect through its contributed client need identity testing, and permission rules need role-by-role review. For WordPress, the install is quick, but the effort concentrates in theme or block development, plugin selection and configuration, custom post types, and the staging and backup routine. Ask each partner to split the written scope into these lines so the two options can be priced on the same work.
The delays that hit both platforms most often are unclear content models, plugin or module gaps found late, identity integration, and the upgrade calendar. A content model that is not signed off before build forces rework in templates, migration mappings and permissions, and on Drupal it also changes which roles and fields the workflow needs. Module or plugin gaps are common when a requirement such as multilingual publishing, granular moderation or a specific SSO flow is assumed to be covered by a free extension that turns out to be unmaintained or not yet compatible with the target version. Confirm each required capability against the exact module or plugin version and its release status before the build starts. Also confirm the upgrade window for the chosen major version, since the Drupal core release schedule and the WordPress releases archive set different support rhythms.
Ask for a written scope that names the deliverables for hosting, theme or front end, content model, migration, integrations, testing, documentation and handover, with acceptance criteria for each. Request a test plan covering permissions by role, form and workflow behavior, search, caching, backup restore and upgrade rehearsal on a copy of production. Ask who maintains the content model documentation after handover and how the team will run updates, including who applies security releases and who signs off on a major upgrade. Quotes should show which items are one-time (build, migration, initial integration) and which recur (hosting, retainers, upgrade cycles, module or plugin maintenance). Effort estimates for either platform should come from the written scope, not from a generic template.
Questions buyers ask before hiring help
What drives implementation cost on Drupal and WordPress?
Cost follows the amount of custom work, because both Drupal and WordPress are GPL software with no license fee for the core. Drupal projects usually carry more cost in content modeling, role and permission design, theming and identity integration, since these need experienced builders and careful testing. WordPress projects often cost less to start, but cost rises when many plugins need configuration, conflict checks and ongoing review. The recurring items are hosting, staff time and any external support you buy. A fixed-scope quote should list content types, roles, integrations, theme work, migration volume and testing so that you can compare offers on the same basis.
How long does planning a Drupal major upgrade take?
Plan against the dates in the Drupal core release schedule and an inventory of your own site. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12.0.0 is scheduled for the week of December 7, 2026. A major upgrade means confirming that every contributed module has a release for the target version, checking the PHP version (Drupal 12 requires PHP 8.5 or later), and testing custom code. Sites still on Drupal 6 or 7 cannot be updated in place. They are migrated into a new site and their themes are rebuilt. The effort depends on module count, custom code and content volume, so ask for a written plan with a dated inventory before agreeing any timeline.
Can an in-house team run Drupal or WordPress without outside help?
Yes, an in-house team can run either platform, but the workload differs. WordPress core receives automatic background updates, while plugin and theme updates apply automatically only in special cases chosen through the WordPress.org API, so someone still reviews plugin choices and tests updates. Drupal core releases follow a schedule, with bugfix releases on the first Wednesday of each month and security releases on the third Wednesday. Your staff must apply them and manage contributed modules through each major version. Check whether you have people with PHP skills, a staging environment and time for upgrade cycles. If that capacity is missing, an external partner can cover planning, implementation or a retainer for ongoing support.
What does our team need to supply for this project?
The project needs input from several roles. Content owners define content types, editorial workflow and who edits which sections. Security reviewers approve roles, authentication (for example SAML through the contributed samlauth module or OpenID Connect), hosting configuration and the list of modules or plugins. Engineers need PHP skills for custom code and theming, and someone must own the database, web server and backup operations. The PHP requirement follows the platform version: Drupal 11 requires PHP 8.3 or later, and WordPress.org recommends PHP 8.3 or greater. Name one decision owner early, because scope changes after design usually add work and cost. Confirm these responsibilities in writing before the build begins.
Can we swap plugins or modules later without rebuilding the site?
Often yes, but the answer depends on how much the site relies on each extension. Content stored in core fields usually survives a swap, while features that store data in custom tables, or themes built around one extension's output, need a migration plan. Drupal contributed modules are GPL-2.0-or-later and maintained by separate teams, so check each module's release history and Drupal version support before depending on it. WordPress plugins carry the same kind of dependency, and default automatic plugin updates apply only in special cases. Ask for a dependency map that lists each plugin or module, the data it owns and its replacement path, then test the swap in a staging environment.
What should a fixed-scope quote for this work include?
A fixed-scope quote should list deliverables in writing so you can compare offers. Ask for the sites, languages, content types, user roles, integrations, theme work, migration source and volume, testing, documentation and handover. Ask which items are excluded, such as content entry, third-party licenses, hosting and post-launch support. Ask how changes after sign-off are priced and approved. DeployOpen does not publish a price list. A quote follows from the written scope, and scope, deliverables and timelines are agreed in writing before work starts. Ask what happens to the timeline if an upstream release, such as a new Drupal major version, lands during the project.
Who handles updates and security patches after launch?
Post-launch work includes security updates, core and extension upgrades, backups and monitoring. Decide whether your team performs that work or buys it. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and it plans, implements, hardens, backs up and documents platforms as fixed-scope engagements. For Drupal, schedule upgrades against the release windows and end-of-life dates. For WordPress, confirm which updates apply automatically on your site and which need review. Ask any provider how it tests updates before production, who responds out of hours and how the retainer scope is written, so internal and external duties are clear.
How DeployOpen helps you choose, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Drupal vs WordPress, we work through the choice in the same order you will live with it: scope, build, hand over, then support.
How we scope
- We confirm which content models, editorial roles and permission rules the site needs before comparing platforms.
- We document the hosting stack, database and PHP version your environment must run for either option.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We build a proof of concept on the shortlisted platform using your real content types and a sample of your plugins or modules.
- We integrate identity, such as SAML or OpenID Connect, and test the permission model against your access rules.
- We run security testing and hardening on the built site, including the plugin or module set you intend to keep.
How we hand over
- We deliver written architecture notes, configuration documentation and an update runbook for your team.
- We walk your administrators through the upgrade path, including how Drupal major upgrades or WordPress rolling updates will be handled.
- We prepare backup and restore procedures and the evidence your compliance reviewers may ask for.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover scheduled Drupal core upgrades or WordPress release testing, matched to the scope you agreed.
- Ask any provider, including us, to confirm in writing which versions and release windows their support covers.
