Migrate from WordPress VIP to Drupal

Migrate from WordPress VIP to Drupal: what the move involves

Leaving WordPress VIP for Drupal is a content model and theme rebuild supported by a database and media export, not a lift-and-shift. The WordPress database and uploads can be exported, but posts, custom fields, templates and plugin behavior do not map one to one onto Drupal's entities, fields, view modes and modules, so the work is planned as a new site that receives migrated content. Most teams do this with an internal platform group working alongside an implementation partner, with the internal group owning the content model, editorial roles and cutover decisions, and the partner usually carrying the migration scripts, theme build and hardening. Drupal core and contributed projects are GPL-2.0-or-later, and there is no paid edition of Drupal itself, so the recurring cost is hosting, maintenance and people rather than a license. The WordPress code is GPL too, so licensing does not decide this move. The decision is about the platform, its content model and the team that will run it.

Effort and risk concentrate in three places: the content model, the theme and custom plugins, and the audit of what VIP provided. Start by inventorying custom post types, taxonomies, custom fields and every plugin your VIP code depends on, then decide which become Drupal content types, fields and contributed modules and which are dropped. Each custom plugin is rebuilt as a Drupal module or replaced by a contributed one, and the theme is rebuilt because Drupal cannot migrate WordPress themes. Check authentication as well: if editors sign in through SSO today, confirm the SAML or OpenID Connect path, and confirm the Drupal release and PHP version you will target against the Drupal core release schedule before any build starts. Ask your partner to state, in writing, which VIP-provided services (edge caching, media delivery, backups, code review) are rebuilt and who runs each one after launch.

Which WordPress VIP capabilities map to Drupal, and which need rework

This table maps each capability WordPress VIP customers typically depend on to its nearest Drupal equivalent and labels the effort as clean, needs rework or gap. Read the rows as planning inputs: a clean mapping still needs a module decision confirmed in your target environment. The main takeaway is that content structure and roles usually map cleanly, while plugins, themes and multisite behavior carry most of the rebuild work.

Capability	Drupal equivalent	Status and what to confirm
Posts and pages	Core content types with fields, revisions and text formats	Clean. Map each post type and meta field to a content type and field, then confirm the migration path with your developers.
Custom post types and custom fields	Custom content types and entity fields built in core, or contributed field modules	Needs rework. Each post type and ACF-style field group must be modeled by hand, and the data transformed during import.
Media library	Core Media module with media types, plus contributed modules for remote storage	Needs rework. Media files and metadata must be exported and re-attached; confirm your storage backend and image styles.
Menus and navigation	Core menus and menu blocks	Clean. Menu structure is recreated in the new site; confirm any mega-menu or custom walker logic separately.
Users, roles and editorial permissions	Core roles and permissions, with contributed workflow modules for approval steps	Needs rework. WordPress capabilities do not map one for one to Drupal permissions, so design the role matrix before migrating users.
Multisite network	Drupal multi-site (separate sites sharing a codebase), or one site with multiple language or section structures	Gap in structure. There is no direct one-to-one equivalent; confirm the site-per-network model with your architects.
Plugins	Contributed Drupal modules where a match exists, otherwise custom modules	Gap for many plugins. Where no Drupal module matches, the feature must be rebuilt as custom code and tested.
Themes	Drupal themes or Drupal CMS recipes and site templates	Needs rework. Themes cannot be migrated and must be rebuilt, usually by a front-end team.
Deploys from GitHub repository	Code in a Git repository with your own CI/CD pipeline	Needs rework. Confirm the pipeline, environments and review process you will run, since VIP handled these.

What moves from the VIP database export and what must be rebuilt

Leaving VIP for Drupal splits the work into three groups: what the documented export carries, what Drupal's migration tooling can move into a new site, and what has to be rebuilt or confirmed by hand. The cards below follow that order, so the export inventory drives the rebuild plan.

Full database export

VIP documents two routes to a full database backup: the VIP Dashboard and the VIP-CLI export sql command. The database holds posts, pages, revisions, taxonomy, users and most plugin settings, so it is the starting point for content. Confirm the retention window and the export format in your own VIP account before you schedule the final cutover export, and keep a dated copy outside the platform.

Media files and the code repository

The database stores attachment references, not the files themselves, so uploads must be copied separately from VIP storage. The GitHub repository VIP supplies for every application holds the theme, custom plugins, configuration and mu-plugins. Treat the repository as the source for theme and plugin rebuilds, and keep a record of which uploads map to which posts before you move them.

Content and media with Drupal migrate tools

Drupal's core Migrate, Migrate Drupal and Migrate Drupal UI modules, or Drush, can map source data into a new Drupal site. The Drupal.org upgrade documentation is written for Drupal 6 and 7 sources, so the WordPress path is a custom migration that you must build and test. Map each WordPress post type to a Drupal content type, map taxonomies and authors, and rerun the migration on a staging copy until counts and URLs match.

Theme and custom plugin rebuild

WordPress themes and plugins cannot be migrated into Drupal, so each template and custom feature must be rebuilt as a Drupal theme and modules. Inventory the custom plugin code in the repository, then decide which features are content types, which need views or blocks, and which need custom code. Expect this rebuild to be the largest share of the project, and scope it per feature in writing.

Single sign-on integration

VIP sites often authenticate editors through a corporate identity provider. On Drupal, the contributed SAML Authentication module (samlauth) lets the site act as a SAML service provider, and its latest stable release 8.x-3.14 supports Drupal 10.3 and later and Drupal 11. The OpenID Connect module is the alternative when your provider speaks OIDC. Confirm which protocol your identity provider uses and which roles must map on first sign-in.

Embeds, webhooks and passwords

Third-party embeds, such as video, forms and social widgets, and webhooks that notify search indexes, caches or downstream systems must be listed and re-pointed to Drupal endpoints. User passwords and active sessions are a separate question: confirm with your team and your VIP contacts whether password hashes can be carried over, or whether users will reset credentials. Any VIP-specific service integrations must also be confirmed in your own environment before cutover.

The migration sequence from inventory to decommission

The sequence moves the site from WordPress VIP to a Drupal build in controlled stages, so each content type, theme section and editorial workflow is proven before the live site switches. It ends with VIP decommissioned only after a rollback window has passed without needing to be used.

Inventory content, code and editorial roles
Catalogue every post type, custom field group, taxonomy, menu, widget, custom plugin, theme template, third-party integration and scheduled job on the VIP site. Map each WordPress role and capability to the editorial work it supports, since Drupal's permission model is different and roles will be redesigned rather than copied. Your team and the editors who use the site should sign off the inventory. It is done when every item has a stated fate: migrate, rebuild as a Drupal module, replace with a contributed module, or retire.
Build the Drupal target on the current major version
Stand up the target on Drupal 11, the current major version, rather than on a release that is not yet out. Drupal 12 is scheduled for the week of December 7, 2026, so confirm with the Drupal core release schedule which version applies on your timeline and plan an upgrade path if needed. Check that the hosting stack meets the PHP requirements for the chosen release and that the database is one of the supported options. Recreate content types, fields, taxonomies and roles from the inventory. It is done when a clean install passes your build pipeline and the content model matches the approved inventory.
Run a pilot with one content type and one theme section
Choose one representative content type, such as articles with their taxonomy and media, and one theme section, such as the header and article template. Migrate the data with the core Migrate modules, then rebuild the theme section as a Drupal theme, because Drupal cannot migrate WordPress themes. Editors should test authoring, scheduling, revisions and the permissions assigned to their role. It is done when the pilot content renders correctly, media references resolve, and editors have signed off on the workflow, with every defect logged against the inventory.
Migrate the full content set and integrations
Apply the lessons from the pilot to the full set: all content types, media, taxonomies, menus, users with reset-required credentials, and custom plugin logic rebuilt as modules. Connect identity through a contributed module such as SAML Authentication or OpenID Connect if the organization uses single sign-on. Rebuild scheduled jobs and third-party connections, and record which legacy behavior has no direct equivalent. It is done when a reconciliation report shows matching item counts by type and every integration has passed a test.
Run a parallel period with content sync rules
Keep WordPress VIP live while the Drupal site runs in staging or on a preview domain. Define which system is the source of truth for each content type during this period and document the sync method, since content edited on both sides will conflict without rules. Run the reconciliation script on a regular schedule and have editors check a sample of pages in both systems. It is done when the agreed sync rules have produced no unresolved conflicts over a period the owners have set and approved.
Cut over with DNS and a redirect plan
Freeze editing on VIP for a short, announced window, run the final content delta, and switch DNS to the Drupal origin. Apply the redirect map generated from the old and new URL structures, and confirm that feeds, sitemaps, canonical tags and analytics tracking still resolve. Keep the VIP site available in read-only mode. It is done when smoke tests on priority URLs pass, the redirect coverage has been checked against the old sitemap, and the owners confirm the site is serving traffic from Drupal.
Decommission VIP after a rollback window
Keep the VIP environment and the database export available for a rollback window that the owners agree in writing before cutover. Once the window closes with no rollback, archive the final database export, the code repository and media in storage you control, then cancel the VIP contract according to its terms. Remove DNS records, credentials and integrations that pointed at VIP. Confirm with your procurement and legal teams which records must be retained. It is done when the archive is verified, access is revoked, and the decommission record is signed by the business owner.

Rebuilding themes and custom plugins as Drupal modules

Treat theme and plugin work as a rebuild, not a port. The Drupal.org documentation on upgrading from Drupal 6 or 7 states that themes must be rebuilt because they cannot be migrated, and the same logic applies when the source is WordPress. Your WordPress theme is PHP templates tied to WordPress functions such as the_content() and the template hierarchy, so the markup, template files and styling need to be recreated in Drupal's theme layer, typically a Twig-based theme built on a base theme. Budget that work as design and front-end development, separate from the content migration. Start by inventorying which templates, template parts and CSS your editors actually depend on, because the rebuild is the natural point to retire layouts nobody uses.

Custom plugins are the harder decision. Most custom WordPress plugins combine three things: data structures (custom post types, taxonomies, custom fields), business logic (hooks, filters, scheduled jobs, REST endpoints) and presentation (shortcodes, widgets, blocks). In Drupal, the data structures map to content types, fields and taxonomy vocabularies, and much of the presentation maps to Views, blocks and display modes rather than custom code. Logic that cannot be expressed that way becomes a custom module, where hooks and services replace WordPress actions and filters. For each plugin, record what it stores, who reads it and whether a contributed module already covers it. Drop plugin logic that only supported a WordPress-specific workaround, such as a caching or editor UI patch, and keep logic that carries business rules. Confirm contributed module coverage on Drupal.org before you commit to custom code.

For editorial needs, check what content teams will actually do before choosing between a custom build and a more packaged starting point. Drupal CMS is a distribution built on Drupal core for marketers and content teams, offering recipes and site templates, the Drupal Canvas visual page builder (previously Experience Builder) and optional AI tools. Recipes can reduce the number of content types and views you build by hand, but they also set defaults you may need to change. Ask the editors which pages they assemble themselves today and which need developer help, then test Drupal Canvas against those pages before you decide how much of the front end to build as custom components. Confirm the current feature set and the status of Drupal Canvas against the Drupal CMS page, since these features are evolving.

How the migration differs by site size and starting point

A single-site publisher usually has the narrowest migration scope. The work centers on one content database, one media library, one theme and a defined set of editorial roles. The export from VIP is a single database backup plus the media files, and the main effort is mapping posts, custom post types, categories, tags and author records into Drupal content types, taxonomies and users. Because the site has one front end, the team can often cut over in one event after a staged content load.

Content model: Map posts and pages to Drupal content types, and map categories and tags to taxonomy vocabularies, before loading any content.
Media: Confirm how images are referenced in post bodies, since those references must be rewritten to Drupal media entities or files.
Themes: Plan a fresh Drupal theme, because WordPress themes cannot be migrated into Drupal.
Editorial roles: Map existing WordPress roles to Drupal roles and permissions, and test the workflow with real editors.
Redirects: Export the current URL structure so search rankings survive the move.

Before requesting a quote, confirm the number of content types, the volume of media files and whether any editors rely on plugins that have no Drupal equivalent.

Editorial roles and workflows on Drupal

WordPress VIP teams usually run editorial access through a handful of broad roles and a few plugins. Drupal separates site-wide roles, per-content-type permissions and workflow states, so the mapping has to be designed before content moves. The cards below cover the decisions that connect roles, moderation and access checks before cutover.

Map WordPress roles to Drupal roles

WordPress roles such as Administrator, Editor, Author and Contributor map loosely to Drupal roles, but Drupal grants permissions per action, per content type and per text format. Export the current user list and each user's capabilities from the VIP database, then write a role matrix that lists who can create, edit, publish and delete each content type. Expect some plugin-added capabilities to have no direct equivalent and decide each one explicitly.

Design content moderation states

Drupal's content moderation module lets you define workflow states such as Draft, Needs review and Published, with transitions limited to specific roles. Many WordPress sites rely on a status field and an editorial calendar plugin, so the states need to be agreed with editors before they are built. Test each transition with a non-admin account so that a reviewer cannot publish content they should only approve.

Set access by content type

Drupal can restrict editing and viewing by content type, field and taxonomy term, which is useful for sections owned by different desks or for unpublished embargoed material. Confirm which WordPress sections are managed by which team today, because those boundaries often live in informal habits rather than in the role settings. Record each restriction in the role matrix so auditors and editors can see the same rule.

Confirm revision history and rollback

WordPress post revisions usually migrate as the latest version only, so editors may lose the ability to compare or restore earlier drafts. Ask whether the migration will carry revisions or only current content, and whether Drupal's revision settings will be enabled per content type. Ask a sample of editors to restore a known older version on staging before cutover.

Run an editor access check before cutover

Before the switch, have each editor sign in to a staging copy with the role they will have in production and complete a fixed task list: create a draft, submit for review, publish, edit a shared block and open a restricted section. Record the results against the role matrix and fix any gaps. This test is the evidence that access was confirmed, not an assumption carried over from WordPress.

Train editors on the new workflow

Editors who used WordPress for years will notice changes in the admin screens, the media library and the publishing buttons. Plan short, role-specific sessions, a one-page guide for each role, and a support window for the first weeks after cutover. Ask the implementation partner for the training scope in writing, since time and format vary by team size and content volume.

What drives the cost and duration of the move

This table lists the factors that change how long a WordPress VIP to Drupal move takes and what it costs, along with the cost components themselves. Read the driver rows to find where your own estate sits, then use the component rows to shape what you ask for in a written quote. No durations or prices are stated because none were supplied; the drivers show which direction each one moves the work.

Driver or component	Why it changes cost or effort	How to keep it down or what to ask for
Custom post types and fields	Each custom type needs a Drupal content type, fields, view modes and a migration mapping. Field-heavy WordPress sites (for example, many ACF field groups) multiply mapping and QA work.	Inventory post types and field groups from the database export before quoting. Consolidate fields that are unused and ask the partner to price by content type.
Custom plugins	Plugins that hold business logic must be rewritten as Drupal modules because WordPress plugins cannot be carried over. Cost follows the number of features, not the number of files.	Separate plugins that only add display from plugins that hold rules or integrations. Retire unused plugins before the quote so only needed behavior is rebuilt.
Theme complexity	Drupal themes must be rebuilt, since WordPress themes are not migrated. Heavy template logic, custom blocks and page builders increase front-end and QA effort.	Ask for a template list with counts of unique layouts, not pages. Reuse a smaller set of components and freeze design changes during the build.
Media volume and metadata	Large libraries add transfer time, storage sizing, image derivative generation and checks for broken references in migrated content.	Clean the library before export, remove orphaned files and set a rule for which renditions Drupal will generate. Ask how media is validated after import.
Multisite count	Each network site may have its own content model, theme and users. Drupal multi-site setups need shared or separate codebases, and every site adds configuration and testing.	List sites by shared versus unique features. Ask the partner whether common modules and a shared theme will cover most sites.
SSO and identity integrations	SAML or OpenID Connect must be configured for each identity provider and tested for account creation, roles and sign-out. Contributed modules such as samlauth and openid_connect reduce custom code but still need configuration and testing.	Document every current login path and the attributes each one sends. Confirm module versions against the Drupal version you target.
Editorial workflow depth	Moving from WordPress roles to Drupal's permission model and any moderation workflow requires role mapping, test users and sign-off from each editorial group.	Write down the current roles, who approves what and where handoffs happen. Ask for a role matrix as a deliverable.
Parallel-run period	While the new Drupal site and the VIP site both serve or accept edits, VIP run-costs continue and content must be synced or frozen. Longer parallel runs add cost on both sides.	Agree a content freeze window and a cutover plan in writing. Ask which VIP plan, environments and support tiers will stay active, and for how long.
Internal staff time	Editors, product owners, security reviewers and developers are needed for content decisions, testing and approvals. This is usually the largest unplanned cost when internal time is not reserved.	Name owners and hours per role in the project plan. Ask the partner to show which tasks depend on internal sign-off.
Implementation partner fees	Fixed-scope work priced from the written scope covers discovery, migration scripts, module builds, testing and cutover support. Scope changes after signing are the main source of overruns.	Ask for deliverables, acceptance criteria, assumptions and a change-request process. DeployOpen issues quotes from the written scope only.
Drupal hosting and support	Hosting for Drupal (web servers, database, caching, object storage) recurs monthly or yearly. Support or upgrade retainers recur, and Drupal releases follow a fixed schedule that drives upgrade work.	Ask for a hosting bill of materials, sizing assumptions and the upgrade path for future Drupal major versions, including the PHP version each one requires.
VIP run-costs during parallel running	VIP subscription fees continue until the contract ends, so each week of overlap is an extra recurring cost on top of the new platform.	Confirm the VIP contract end date and notice terms in advance. Ask the partner to shorten the overlap by scheduling migration rehearsals early.

Questions teams ask before moving from WordPress VIP to Drupal

How much effort does a move from WordPress VIP to Drupal take?

The effort depends mostly on how much custom WordPress code, content structure and integration work you carry, not on the size of the site alone. Drupal does not run WordPress themes or plugins, so each custom theme and plugin is rebuilt as a Drupal theme or module, and content is mapped into content types, fields and taxonomies. Sites with few custom plugins, a simple content model and a small media library are usually the smallest jobs. Sites with heavy custom functionality, many authors, multiple languages or many integrations take the most work. Ask any provider to break the effort into content mapping, theme rebuild, module work, testing and cutover, and to tie each line to a named inventory of your plugins and templates.

How long does the migration run?

The duration is set in the written scope after an inventory of your code, content and integrations, so no general figure applies to every site. Drupal.org documents that a WordPress site is not upgraded in place but rebuilt as a new Drupal site, which means the timeline covers a parallel build, content migration rehearsals, editorial testing and a controlled cutover. The biggest schedule drivers are the number of content types, the volume and quality of media, the number of custom plugins and the number of people who must sign off. Ask for milestones with dates, a rehearsal count and a defined acceptance step before go-live.

Can our own team migrate from VIP to Drupal without a partner?

A capable internal team can do the work, but it needs skills that WordPress teams often do not use daily: Drupal's entity and configuration model, the Migrate APIs, Twig theming and PHP 8 development. The Drupal.org migration documentation covers the core Migrate, Migrate Drupal and Migrate Drupal UI modules and Drush, so the path is documented, but the mapping decisions and the rebuild are still engineering work. Teams with existing Drupal experience can often run it internally. Teams without that experience should weigh the cost of training and the risk of a late cutover against the fixed-scope cost of a partner. Either way, agree a written scope and acceptance criteria before the first sprint.

What does the work require from our staff?

Plan for three groups of people. Editors must review the new content model, test their workflows and approve the content migration samples. Developers must own the Drupal build, the custom modules and the theme, and they need PHP and Drupal knowledge. Operations staff must provision the web server, database and PHP runtime, and run backups and patching. Drupal supports Apache, Nginx, MariaDB, MySQL, PostgreSQL and SQLite, and the PHP minimum rises with each major version, so your platform engineers should confirm the PHP version they will run. Ask a provider which of these roles they will fill and which must come from your team.

Can Drupal and WordPress run side by side during the move?

Yes, they can run side by side. Drupal and WordPress are separate applications with separate databases, so you can keep the VIP site live while the Drupal site is built, tested and rehearsed on your own infrastructure. The common pattern is to route a test hostname or a subset of paths to the new site, run content migration rehearsals, and switch DNS or the load balancer at cutover. Plan redirects from old WordPress URLs to new Drupal paths, and keep the VIP database export as a fallback until the new site has been stable for an agreed period. Confirm the cutover and rollback steps in the written scope.

What happens to the GPL license of our custom code?

WordPress is licensed under GPLv2 or later, and the WordPress project treats plugins and themes as derivative works that must also be GPL. Drupal is licensed under GPL-2.0-or-later, and the GPL does not require you to share code that is only used to run a website. When you rebuild custom functionality as Drupal modules, the GPL obligations attach to the distributed code, not to code you run internally. If you distribute a custom module or theme to others, it must be licensed compatibly with the GPL. Confirm the rules for your own distribution, contractor agreements and any third-party code with your legal counsel.

How DeployOpen scopes a WordPress VIP to Drupal migration

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a move from WordPress VIP to Drupal, that means the new Drupal environment, the database and media migration, the rebuilt theme and module work, editorial roles and the multi-site structure are all designed and built in environments your organization controls. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts, and a quote follows from that written scope. Ask any provider to break the scope down by site, content type, custom plugin, theme and integration, because those items drive most of the effort.

Before signing, confirm what the written scope must name for this migration. List every WordPress site in the VIP network, every custom plugin that stores data or renders output, the content types and taxonomies to map, the media volume, the single sign-on method, and the translation or workflow requirements. Ask the provider to state which items are out of scope, such as Drupal 6 or 7 legacy data, third-party integrations or content cleanup by editors, and what happens if the database export proves incomplete. Also confirm whether the work includes hardening, backup configuration and upgrade planning for Drupal's release cycle, since those recur after launch and are priced separately from the build.

DeployOpen prepares systems, controls and evidence for compliance assessments, including documentation of configuration, access roles, backups and change records. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so if your organization needs a formal attestation for the new Drupal platform, plan that assessment as a separate engagement and ask the provider which evidence artifacts the written scope will deliver to support it.

How DeployOpen runs the move and supports it afterwards

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from WordPress VIP to Drupal, we scope the content, media, theme, plugin and editorial work in writing before any build starts.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which WordPress content types, media, custom plugins and theme features map to Drupal content types and modules.
We confirm which VIP-managed services, such as caching and media handling, need an equivalent in your target environment.
Each engagement is quoted from the written scope, so no price list applies to this migration.

How we build

We set up Drupal on your own web servers and database, with the PHP version supported by the Drupal release you choose.
We map WordPress exports into Drupal using the core Migrate tooling, then test each content type against sample records.
We rebuild themes and custom plugins as Drupal modules and themes, because WordPress themes cannot be carried over directly.
We configure editorial roles, workflows and SAML or OpenID Connect sign-in where your identity provider requires it.

How we hand over

Handover includes runbooks for deployment, database backups, media storage and restoring the site.
We document the content model, module inventory and the list of contributed projects the site depends on.
Your team receives the migration test results, redirect mapping and a list of open items agreed in the scope.
Acceptance steps are defined in the written scope, so you know what finished work looks like before we close.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover Drupal core and contributed module updates, timed to the Drupal release schedule and security advisories.
We can prepare the security testing and compliance evidence your assessors request for the new platform, without issuing audit reports.
Ask us to confirm response expectations and upgrade responsibilities in writing before the retainer starts.

Migrate from WordPress VIP to Drupal