WordPress VIP vs Drupal: when each fits and what the decision turns on
If your publication has outgrown WordPress, the first thing to settle is that leaving WordPress VIP does not force a change of codebase. Both WordPress and Drupal are GPL software, WordPress under GPLv2 or later and Drupal core and its contributed projects under GPL-2.0-or-later, so either can run on infrastructure you control. The choice therefore rests on four things: how your content is modeled, how editorial work moves through approval, how many languages you publish in, and what skills your team already has. Licensing will not separate them, and you should not let a licensing argument carry the decision.
WordPress VIP fits when your content model is mostly posts, pages and a moderate set of custom post types, your editors are comfortable in the block editor, and the main pain is hosting, deployment discipline or traffic spikes rather than the shape of the content. Staying on the same WordPress code keeps your themes, custom plugins and editorial habits intact, and the work is concentrated in operating the platform. Drupal fits better when you need deeply structured content types with many relationships, granular permissions by role, section or language, and workflows that editors and reviewers must follow in a fixed order. Confirm in writing which of these your requirements actually demand before you assume the move is necessary.
The decision turns on a few concrete checks. Inventory your custom post types, taxonomies and ACF-style field groups, and count how many templates depend on them. Map each editorial role to the actions it must take, then test whether WordPress roles and your current plugins express that without workarounds. For multilingual publishing, list every locale and whether translations are managed per entry or per site. Finally, price the rebuild realistically: themes and custom plugins cannot be moved as-is into Drupal, so each one becomes new development. Ask any implementation partner to separate that rebuild cost from the ongoing cost of running either platform, because the first is one-time and the second recurs.
Which platform fits which publishing scenario
This table maps common publishing scenarios to the platform that usually fits best, with the condition that would change that answer. Read each row as a starting point for your own team, content model and compliance obligations, not as a verdict. The main takeaway is that staying on WordPress code is often the lower-change choice unless structured content, multilingual depth or granular roles are central to the business.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Single editorial team publishing posts and pages | WordPress (self-hosted or VIP) | Editors already work in the block editor, and the content model is mostly posts, pages and media. Moving to Drupal only pays off if the team later needs structured types the editor cannot express cleanly. |
| Publisher with complex structured content and many content types | Drupal | Custom content types, entity references and fields are core Drupal concepts. Choose WordPress only if the custom post types stay simple and plugins cover the rest. |
| Multilingual newsroom | Drupal, if translation workflow is central | Drupal's core multilingual modules support translated content and language-specific routing. Confirm that your translation vendor and editorial process fit the module set before committing. |
| Team with heavy WordPress plugin dependence | WordPress (self-hosted) | Every plugin you rely on must be rebuilt as a Drupal module or replaced with a contributed one. Rebuilding is the main cost of moving, so inventory plugins before comparing platforms. |
| Regulated organization needing granular editorial roles | Drupal, if roles must map to fine-grained content rules | Drupal's permission model can restrict actions by content type and workflow state with contributed help. Ask an assessor which role evidence they expect before deciding. |
| Organization with SAML or OIDC single sign-on requirements | Either, with a tested integration | Drupal has contributed SAML and OpenID Connect modules. WordPress has its own identity plugins. Confirm the module versions against your Drupal or WordPress release before relying on either. |
| Site must stay on the same code during a short migration window | WordPress (self-hosted) | Keeping GPL WordPress code preserves existing themes and plugins. A later move to Drupal can be planned separately as a rebuild. |
Where your content and code live under each model
Both models can keep content inside infrastructure you control, but they differ in who runs the platform, which components you own and where identity and audit records sit. The cards below cover the decisions that follow from those differences and what to confirm before a renewal or move.
Hosting boundary and runtime
WordPress VIP runs WordPress on Automattic's container-based infrastructure, so the platform layer belongs to the vendor. Self-hosted Drupal runs on web servers such as Apache or Nginx that your team or partner controls, with the database on MariaDB, MySQL, PostgreSQL or SQLite. Confirm in writing which regions and facilities hold content, backups and logs under VIP, and which cloud accounts or data centers will hold the Drupal stack.
Database and backup custody
Under VIP, customers download full database backups from the VIP Dashboard or with the VIP-CLI command export sql. Under a Drupal move, the same content must be exported and loaded into a new database you operate, with restore tests and retention rules you set. Ask VIP how long each backup is kept, and plan who owns restore testing after cutover.
Code and licence position
WordPress and its plugins and themes are GPL, and Drupal and contributed projects are GPL-2.0-or-later. Because the GPL does not require sharing code used only to run a website, your custom code can stay private if you do not distribute it. Confirm with counsel which custom plugins, themes and modules you distribute, since that decides what must be published.
Identity and single sign-on
VIP-hosted WordPress authentication is tied to the platform's own access model, so enterprise SSO for editors may need vendor configuration. On Drupal, the contributed SAML Authentication module (samlauth) lets the site act as a SAML service provider, and the OpenID Connect module creates accounts on first sign-in. Map each editor group to a Drupal role and confirm that deprovisioning in your identity provider removes site access.
Audit trails and compliance evidence
Audit logs, access reviews and change records are the evidence assessors ask for. Under VIP, ask which audit logs the platform keeps, how long they are retained and whether you can export them. On a self-hosted Drupal site, DeployOpen can plan logging, access review procedures, change control and evidence collection so your team can present them, but auditors and certification bodies issue any assurance report. Confirm the evidence format your assessor accepts before the build starts.
Responsibility for patching and runtime
Under VIP, the platform team handles much of the runtime, while plugin and theme code still needs review and deployment discipline. Self-hosted Drupal moves OS, web server, PHP and database patching to your side, and PHP versions must match the Drupal major version in use. 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. Assign owners for each layer in the operating model before cutover.
Why both licenses are GPL and what that does not change
Both WordPress and Drupal are GPL, so neither license forces a move. WordPress is released under GPLv2 or later, and the WordPress project treats plugins and themes as derivative works that must also be GPL. Drupal core and contributed projects on Drupal.org are licensed GPL-2.0-or-later, and there is no paid edition of Drupal itself. Under either license, the code you run on your own servers is yours to operate, and you can change it. The licenses do not make a commercial Drupal distribution or a paid WordPress edition a requirement, and they do not change who owns your content.
The GPL also does not require you to publish code that is only used to run a website. Your custom WordPress plugins, theme code, and Drupal modules can stay private as long as you do not distribute them to others. Before you rely on this, have counsel confirm how your organization will handle any code you give to a partner, a vendor, or a subsidiary, because distribution is the point where GPL obligations attach. Also confirm which contributed modules and themes you actually use, and check each project's license on its Drupal.org or wordpress.org page, since a contributed project can carry a different license than core.
Licensing therefore settles only one question: whether you are free to run the code yourself. It does not decide whether Drupal fits your publishing model, whether your editors need its structured content types and granular workflows, or what a rebuild of your themes and plugins will cost. Your custom work stays yours to manage in either direction. Whether you stay on WordPress code or move to Drupal, you still own the review, patching, testing, and documentation of that work, so plan for those responsibilities explicitly rather than assuming the license covers them.
What each side costs to run and what drives those costs
On WordPress VIP, the platform fee pays for the managed container infrastructure, the hosting environment, database access and the dashboard tooling that Automattic operates on your behalf, according to the WordPress VIP infrastructure documentation. Your internal team still pays for development, plugin and theme work, content operations and any integrations, and those costs sit outside the platform fee. Ask your account team to itemize what the contract covers, including support hours, environments, storage allowances and any overage terms, so you can compare line by line.
- Platform fee: the recurring contract amount that covers hosting, environments and support as written in the agreement.
- Backups and exports: database backups are downloadable from the VIP Dashboard or with the VIP-CLI export command, so confirm retention and any charges for extra exports.
- Code and deploys: a GitHub repository per application is supplied, but code review and release work remain your cost.
- Growth terms: traffic, storage and environment tiers can change the fee, so request the pricing triggers in writing.
Before you compare, confirm exactly which components the current contract bundles and which ones you buy separately.
Self-hosting Drupal moves every platform component onto your budget. Drupal is licensed under GPL-2.0-or-later and there is no paid edition of Drupal itself, so the recurring costs are infrastructure, people and third-party services, not a license line. The web server, database (MariaDB, MySQL, PostgreSQL or SQLite, according to the Drupal system requirements), cache, CDN, object storage, backups and monitoring each need an owner and a budget.
- Hosting and database: cloud or data center capacity sized to peak traffic, with high availability if the site is business critical.
- CDN and object storage: edge caching and media storage, priced by the provider you choose.
- Backups and monitoring: tested restores, offsite copies and uptime alerting, all recurring.
- Security patching and module maintenance: core releases follow a fixed rhythm, with bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, per the Drupal core release schedule, and every contributed module needs its own updates.
- On-call and editorial training: staff or a partner must respond to incidents, and editors need onboarding for new workflows.
Ask any implementation partner for a quote that lists each of these lines separately with the assumptions behind them.
Moving to Drupal is mostly a one-time project, and the largest item is usually rebuilding what the WordPress site depends on. Drupal does not run WordPress themes or plugins, so each theme must be rebuilt and each custom plugin reimplemented as a Drupal module or configuration. Content, media and users also need a planned migration, with the Migrate modules in Drupal core and related tools doing much of the mechanical work.
- Theme rebuild: templates, components and front-end build tooling are recreated, typically the largest effort on a content-heavy site.
- Plugin replacement: each custom plugin is mapped to a contributed module or new custom code, with a decision on what to drop.
- Content and media migration: database and file exports are transformed, validated and reconciled against the source.
- Editorial roles and workflows: permissions, review steps and multilingual setup are configured and tested with editors.
- Parallel running: the old and new sites may both need funding during cut over.
Because these costs are one-time, ask the partner to separate them from the recurring run costs in the quote, and to state which items depend on your plugin count and theme complexity.
Several drivers change both sides of the comparison, and they interact. Traffic affects hosting capacity and CDN usage on either platform. Content volume and media size drive storage, backup duration and migration effort. Module count drives patching workload on Drupal, while plugin count and custom code drive rebuild effort on the move from WordPress. Team skills determine whether you buy support, hire, or train internally.
- Traffic peaks: campaigns and seasonal spikes set the capacity you must pay to hold, so model peak load, not averages.
- Content and media volume: more entries and assets increase migration time, object storage and restore duration.
- Module and plugin count: every dependency adds patch work and testing; audit both before quoting.
- Team skills: PHP and Drupal expertise, or the lack of it, changes whether run costs are internal salaries or partner retainers.
- Compliance scope: logging, access reviews and evidence collection add recurring effort in regulated environments.
Ask for a sensitivity view in the quote showing how each driver changes the total, and confirm the assumptions with your own traffic and content figures.
How a move from WordPress VIP to Drupal runs at a high level
The sequence takes a WordPress VIP site from an inventory of what it does today to a Drupal site that editors have tested and that owns its cutover date. Each phase produces a artifact that the next phase depends on, so skipped steps usually reappear as rework later.
Inventory content, plugins and custom code
Your team and the Drupal partner list every content type, custom post type, taxonomy, menu, plugin and integration the site uses, and mark which ones editors actually depend on. The VIP code repository and the VIP Dashboard show what is deployed, and editors should confirm which features they use day to day. The step is done when the inventory has an owner for each item and a keep, rebuild or retire decision recorded beside it. Themes are included in the inventory because they cannot be migrated and must be rebuilt as Drupal themes.
Map WordPress content to Drupal fields
Map each WordPress post type, custom field and taxonomy to a Drupal content type, field, vocabulary or media type. This is where structured content types and fields become a deliberate design rather than a copy of WordPress meta keys, so the team decides which fields become typed references, which stay as text and how multilingual fields are handled. The output is a signed-off schema document and a set of sample records that the migration team can test against. Ask the partner to show this document before any migration code is written.
Export the database and media from VIP
Download a full database backup from the VIP Dashboard or with the VIP-CLI export sql command, and copy the media files from the storage the site uses. Keep a dated copy of both in a location your organization controls, and confirm that the export includes the content your schema map covers. The step is complete when a restore of the export into a non-production environment reproduces the site content, which confirms the backup is usable before any migration work relies on it.
Migrate content with Migrate modules or Drush
Build the migration with the core Migrate, Migrate Drupal and Migrate Drupal UI modules, or with Drush, reading from the restored WordPress data and writing into the Drupal content types from the schema map. Run the migration repeatedly in a staging environment, comparing record counts, media links and URLs after each run. The step is done when repeated runs produce the same results and a sample of editors can find their content in the right fields. Plan for the migration to be rerun as content changes during the project.
Rebuild themes and custom plugins as modules
Rebuild the front end as a Drupal theme and move the custom plugin logic into custom Drupal modules, because WordPress themes and plugins cannot be migrated into Drupal. Contributed Drupal modules can replace some plugin functions, and each replacement should be checked against the inventory. The effort depends on how much custom logic the site has and how closely the design must match today's pages, so ask the partner for a written estimate based on the inventory. The step closes when every inventory item marked keep has a working equivalent in staging.
Configure editorial roles, workflow and access
Define Drupal roles and permissions for authors, editors, reviewers and administrators, and set up any moderation workflow the editorial team needs. Test each role with real accounts to confirm it can create, review and publish only what it should. Configure authentication at the same time, for example through the contributed SAML Authentication module or OpenID Connect module, so that editors sign in through the organization's identity provider. The step is done when a test script of editorial actions passes for every role.
Configure multilingual content and authentication
If the site publishes in more than one language, configure Drupal's language and translation settings, then confirm that each translated node, menu and URL resolves correctly in staging. Check that authentication settings, redirect rules and search indexing behave as expected for each language. Agree on which language versions editors maintain and which are managed by translators. The step is complete when a translated sample page renders and a reviewer signs off the translated content list.
Run in parallel and cut over
Run the Drupal site beside the VIP site for a period agreed in your project plan, with editors working in one system at a time and reconciling content differences. Prepare the DNS, redirect and caching change, then cut over during a window your change process approves, with a rollback path to the VIP site kept available. The step is done when traffic, forms, search and editorial workflows work on the Drupal site and the VIP site is retained according to your retention policy.
Questions buyers ask before choosing Drupal over WordPress VIP
How much does a move from WordPress VIP to Drupal cost?
No public figure for a Drupal move is available from our sources, so the cost depends on scope. The main drivers are the number of content types you need to model, how many custom plugins and the theme must be rebuilt as Drupal modules and themes, the volume of content and media to migrate, and how many locales you publish in. Costs split into one-time items (discovery, schema design, theme and module build, migration, testing and cutover) and recurring items (hosting, Drupal and module maintenance, security patching and support). Ask any provider for a fixed-scope quote that lists each content type, plugin and locale, and separates one-time work from recurring run costs.
How long does a move from WordPress VIP to Drupal take?
The timeline depends mainly on how much of your WordPress code has a direct Drupal equivalent. Themes cannot be migrated and must be rebuilt, so front-end complexity and the number of design templates set a large share of the effort. Custom plugins that hold business logic take time to re-implement, and content models that stay close to WordPress posts and fields are faster to map than ones that need new structured types. Editorial workflow, multilingual setup and integrations with identity or analytics systems add further work. Ask for a written plan with phases, a parallel run period and a cutover window before committing to a date.
Can our in-house team run a move from WordPress VIP to Drupal?
A team can run the move in-house if it already has Drupal experience, but most publishers that move off VIP need outside help for at least part of the work. Drupal development uses a different model from WordPress: content types, fields, view modes, roles and modules are configured and coded differently, and the team must also learn Composer-based builds and Drush. Assess your team against the specific skills in the plan: content architecture, Drupal theming, module development, migration tooling, DevOps and security operations. Gaps in any of these are the usual reason a move stalls.
What does our team need to provide during a Drupal migration?
Your team is the source of truth for the content model and the editorial rules, so its time is the first requirement. Expect to supply access to the WordPress codebase, a current database export and media library, a list of plugins and their business purpose, and named content owners who can approve schema, roles and workflow decisions. Editors will need to test migrated content and sign off on the new authoring experience. Ask the provider to list these inputs in the scope document, with the person responsible for each, so gaps surface before the build starts.
Can Drupal match the code review and deploy process that WordPress VIP provides?
Drupal can support a similar process, but you must build it. WordPress VIP supplies a GitHub repository for every application and runs its container-based infrastructure, so code review and deploys follow a platform-defined path. On your own infrastructure, you set up the Git hosting, branch rules, pull request review, automated tests, a staging environment and a deploy pipeline. Drupal's Composer-managed codebase and configuration export work well with this model. Confirm with your provider which environments, approval gates and rollback steps they will hand over, and who will operate them after go-live.
Do WordPress plugins and themes carry over to Drupal?
Generally, no. Drupal is a different application, so WordPress plugins do not run on it, and themes must be rebuilt because they cannot be migrated. The practical approach is to inventory each plugin and decide whether it is replaced by a contributed Drupal module, a core feature, a custom module or no longer needed. Content and media move through migration tooling, but plugin-specific data often needs its own mapping. Ask for a plugin-by-plugin table that names the Drupal replacement for each item and flags anything that will need custom build work.
How does Drupal's upgrade cycle affect planning for a move?
Drupal's release schedule should shape the target version and the maintenance budget. Drupal 11 is the current major version, and the core release schedule states that Drupal 12 is scheduled for the week of December 7, 2026, and that Drupal 10 reaches end of life on December 9, 2026. The schedule also sets bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, and new major versions typically arrive about every three years. Confirm which version your provider will build on, which PHP version it requires, and how contributed modules will be kept current across those releases.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For WordPress VIP vs Drupal, that means scoping the decision with your content, editorial and compliance requirements before any build starts.
How we scope
- Inventory your content types, fields, editorial roles, workflows and languages before comparing platforms.
- Agree a written scope covering which WordPress code, plugins and themes stay, and which are rebuilt.
- Confirm the Drupal version, PHP runtime and hosting targets your team can support over time.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Map each VIP-hosted feature to a Drupal module, a contributed project or a custom build.
- Rebuild themes and custom plugins as Drupal modules and themes, testing each against editorial workflows.
- Configure SAML or OpenID Connect sign-in against your existing identity provider where required.
- Run security testing of the application and its APIs before content migration reaches production.
How we hand over
- Deliver architecture, deployment, backup and restore runbooks written for your own operations team.
- Document content migration results, role mappings and any content that could not be carried over.
- Provide a handover session covering upgrades, Drupal security releases and PHP version planning.
- Prepare the systems, controls and evidence your compliance assessors will ask for, without issuing attestations.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Drupal core and contributed module upgrades on the schedule your team agrees.
- Ask any partner to confirm response expectations and service levels in the written scope, not in general terms.
- Quotes follow from the written scope, so request one that itemizes build, migration, testing and support.
