/resources/drupal-wordpress-migration/
What We Do
Digital Platform MigrationsKey SolutionsManaged ServicesStaffing SolutionsIndustriesProducts
OnePress
Unify multiple brands on one governed WordPress platform.
Design & UI/UX
Gutenberg-native UX, UI, and design systems for visitors and editors.
WordPress Modernization
Modernize WordPress for better performance, architecture, and AI readiness.
WordPress as a DXP
WordPress as a composable DXP when monolithic systems no longer cut it.
Headless WordPress
Omnichannel content delivery without sacrificing marketing autonomy.
Frappe/ERPNext
Build scalable ERP and custom applications, from implementation to ongoing support.
Discovery
Strategic consultancy & project roadmap
Growth Services
On demand development & consultation
Site Maintenance
Annual maintenance. Done for you
QE Services
Testing across SDLC for assured quality
Hosting Migration
Move to a performant hosting with zero downtime
WooCommerce
Enterprise commerce delivered without lock-in
AI
Unlock real use cases and integrations
All Services
A suite of services for any need
Technology STACK
eCommerce
Scale your e-commerce with WooCommerce, integrations, and custom extensions for growth.
EasyEngine
Server management tool that makes using WordPress on Nginx easy.
Web Auditor
Performance Audit & Insights for your Website.
rtMedia
A complete media management plugin for WordPress.
Resources
About Us
CLEAR
Resources How enterprises migrate from Drupal to WordPress (without breaking SEO, workflows, or integrations)
Topics
On this page
- How enterprises migrate from Drupal to WordPress (without breaking SEO, workflows, or integrations)
- Content migration
TL;DR
Why enterprises leave Drupal
Drupal vs WordPress at a glance
What Drupal really costs
How to plan the migration from Drupal to WordPress
Audit the Drupal stack
Align stakeholders and define governance
Set the scope and split the work
Set up the environments
Drupal to WordPress migration risks
Drupal to WordPress migration process and timeline
Drupal to WordPress frontend migration
Drupal to WordPress backend migration
Drupal to WordPress content migration
Drupal to WordPress SEO migration
Testing and QA
Launch and post-migration
Drupal to WordPress migration case study: FleetNet America
Turn the migration into your AI head start
Get the 20-hour free discovery
Frequently asked questions
Is WordPress actually an enterprise platform, or are we downgrading?
Our Drupal content model is complex. Won't WordPress flatten it?
Will editors break the design once they can edit freely?
We've been burned by insecure plugins. What's the vetting process?
Will we lose our search rankings?
Is the Drupal end-of-life date really forcing migration now?
Last updated on Sep 16, 2026
How enterprises migrate from Drupal to WordPress (without breaking SEO, workflows, or integrations)
Drupal 7 reached end of life on January 5, 2025. Support stopped (security patches included) more than a year ago, but nearly 190,000 sites still run on it. A small industry now exists just to keep those sites patched and running, without moving them forward.
Drupal 9 is already unsupported, and Drupal 10 reaches end of life on December 9, 2026. If you’re on Drupal 7, reaching a supported version means a rearchitecting project. Acquia’s own guidance puts a Drupal 7 to Drupal 10 move at 16 to 30 weeks of developer time. When the bill for staying current matches the bill for leaving, the real question stops being which version to upgrade to and becomes whether the next five years belong on infrastructure you own.
This Drupal to WordPress migration guide covers that second path from the business case through launch and everything after. rtCamp has completed 500+ enterprise WordPress engagements, including migrations off Drupal, AEM, Kentico, and Sitecore. We’re a WordPress VIP Gold Agency Partner, SOC 2 Type II compliant and ISO 27001 certified, and VIP routes complex migrations to us.
TL;DR
- Drupal 7 is end-of-life and the clock is running. Support ended in January 2025, Drupal 9 is already unsupported, and Drupal 10 reaches end of life in December 2026. Staying means paying for extended patches that keep a site running without moving it forward.
- The upgrade often costs what a migration costs. Acquia puts a Drupal 7 to 10 move at 16 to 30 weeks of developer time. When staying current costs what leaving would, migrating becomes a real question.
- The real Drupal bill is hidden in engineering time. No license fee, but senior Drupal developers average ~$170K a year, Acquia hosting starts near $100K against WordPress VIP’s ~$25K, and every major version brings another rebuild. rtCamp calls the cumulative version the Platform Tax.
- WordPress keeps the structure and hands editing back to the team. Custom Post Types, ACF, and custom taxonomies cover Drupal’s content model, while Gutenberg and Full Site Editing let marketing publish without a developer ticket and backward compatibility ends the rebuild-every-version cycle.
- The failures are specific and preventable. Broken node-reference links, lost vanity URLs, flattened Paragraphs, and passwords that don’t survive the hash change all have known fixes, which is why enterprise migrations use custom scripts rather than a bulk-import plugin.
- SEO holds when it’s a pre-migration deliverable. Every indexed URL mapped and redirected, metadata and canonicals carried across, staging crawl checked against the live baseline before cutover. FleetNet America kept its rankings and came out with roughly 2× better Core Web Vitals.
- Timelines scale with complexity, and the site stays alive throughout. A single site runs a few weeks; enterprise migrations with heavy integrations or multilingual content run three to six months. The Drupal site serves traffic until the DNS cutover, with rollback provisioned. The first 20 hours of discovery are free.
Why enterprises leave Drupal
Enterprises love Drupal for many reasons. It handles complex content models, granular permissions, and multilingual publishing, and it does all of that with a developer community that has kept large sites running for years. But as of today, the question for many is if this reasoning still holds.
Three things tend to push enterprises toward the exit.
The upgrade costs like a full migration. Every major version jump asks for rearchitecting, and the bill lands on a schedule the platform sets. As we mentioned, Drupal 7 to Drupal 10 runs 16 to 30 weeks of developer time. Later jumps are lighter, but staying on the current version costs a budget most teams would rather put toward the roadmap. Naturally, when that budget approaches what leaving would cost, the platform question reopens on its own.
Publishing needs a developer. Drupal’s editing experience assumes the person at the keyboard understands how the system is built. Layout Builder, Paragraphs, and custom field configurations are powerful in trained hands and slow going for everyone else. A marketing team that wants to change a layout or ship a campaign page has to file a ticket and wait. That dependency is quiet but expensive, which eventually shows up in missed deadlines, postponed experiments, and a roadmap that fills with CMS maintenance instead of growth.
The rebuild keeps coming back. Drupal 7 to 8 was a full architectural rewrite. The jumps since aren’t that large, but each still asks for planning, testing, and reworking on the platform’s timetable. If you’re absorbing that effort every couple of years anyway, it’s worth asking what the upgraded platform actually gives the people who use it every day.
All things considered, Drupal optimizes for developers, while WordPress optimizes for publishers. That isn’t a knock on Drupal’s engineering, just a difference in who the platform is built to serve. When rtCamp consolidated Crikey, The Mandarin, and SmartCompany onto a single WordPress multisite for Private Media, each editorial team kept its own subscribers and workflows and published without waiting on engineering, on a shared codebase that cut development costs by 50%.
That said, leaving isn’t always right. If a migration would derail a bigger project already in motion, or if regulatory commitments make changing the setup hard, staying makes sense. For everyone else, the approaching end-of-life date is a good moment to compare the cost of staying with the cost of migrating to WordPress.
Drupal vs WordPress at a glance
Let’s look at Drupal from the technical side. Its Field API models structured content tightly, with WordPress being able to match only with Advanced Custom Fields. Views gives site builders filterable, relational content displays inside core, which doesn’t require a plugin or custom query. For teams that think in entities and reference fields, that structure does look appealing.
The trade-off is that Drupal’s power sits with developers, and most of the work an editor wants to do, such as build a campaign page, reorder a layout, or publish without a ticket routes back through them. WordPress flips that. The content model still holds (Custom Post Types and ACF cover Drupal’s content types and fields, taxonomies cover vocabularies), but composition moves to the editor through Gutenberg and Full Site Editing. And it holds that structure without the rebuild-every-major-version tax, because WordPress kept backward compatibility where Drupal broke it at 7.
Most Drupal capabilities have a direct WordPress counterpart. A few don’t map one to one, and those get decided during discovery rather than assumed. For details, take a look at this table
CapabilityDrupalWordPressContent modelContent types + Field API (core)Custom Post Types + ACFStructured layoutsParagraphs, Layout BuilderGutenberg blocks + block patternsPage compositionLayout Builder, PanelsFull Site Editing + block editorContent queries / listingsViews (core, filterable)Query blocks or custom WP_QueryTaxonomiesVocabularies + hierarchical termsCategories, tags, custom taxonomiesMultilingualContent translation (core)WPML or PolylangMultisite / multi-brandDomain / Group modulesWordPress multisite / OnePressEditorial workflowContent ModerationCapabilities + workflow codeEditorial autonomyDeveloper involvement typicalEditors work independentlyHeadless / API deliveryJSON:API, GraphQLREST API (core), WPGraphQLUpgrade pathRearchitecting on major jumpsBackward-compatible coreHostingOpen, self-managed or AcquiaOpen, self-managed or WordPress VIP (SOC 2, FedRAMP)LicensingOpen source, no feeOpen source, no fee
Drupal still leads in two places. Views out of the box beats WordPress query blocks for complex relational listings, and Drupal’s entity model is more structured than anything WordPress ships without ACF.
A word on how the content actually moves, because the method matters more than it looks. Off-the-shelf plugins exist for this, the best known is FG Drupal to WordPress, and for a small site with standard posts, pages, and tags, they do the job. As for Drupal, custom content types, entity references, Paragraphs, fielded taxonomies, and module-specific data are the things a plugin either skips or flattens, and a flattened structure is expensive to rebuild once the site is already live.
rtCamp migrates enterprise sites with custom scripts for that reason. The pattern is Drupal’s own Migrate API on the source side and WP-CLI on the destination, run as a rerunnable pipeline, which is what makes the field-by-field mapping, the node-reference rewriting, and the verified record counts covered above possible in the first place. It’s more work than clicking a plugin, and for a site that has many posts and with entity references and Paragraphs, it’s the difference between a migration that holds and one that looks fine until someone opens a page.
The step-by-step of exporting, mapping, and importing each content type is covered in our Drupal to WordPress content migration walkthrough. But once WordPress checks out technically, the conversation moves to budget. What does staying on Drupal actually cost over five years, and how does that compare to leaving?
What Drupal really costs
Drupal’s software is free, but the cost to stay on it shows up in payroll, in hosting, and on the rebuild schedule the platform sets. rtCamp calls the cumulative version of this the Platform Tax, the running cost of staying on a platform that no longer matches how the organization works. On Drupal, that tax is paid in engineering time, and over five years it adds up to more than most budgets expect.
Start with the people. A mature Drupal build depends on a small group of senior engineers who know the system deeply, and in the US a senior Drupal developer averages about $170K a year, with the typical range running from $129K to $227K. Complex implementations often need two or three of them. Beyond salary, there’s a knowledge-concentration risk, meaning that if the engineer who built your custom modules leaves, it takes time and money for a new engineer to figure out how everything works.
Hosting is the next variable, and it depends entirely on where the site lives. Self-managed Drupal keeps it modest. Acquia doesn’t. Based on our own cost comparison, Acquia starts around $100K a year against WordPress VIP’s ~$25K, and Acquia Site Factory reaches $123K-$394K a year at multi-site scale. WordPress keeps hosting prices in check because dozens of enterprise-grade managed hosts compete for the work. Drupal has a handful.
Last but not least is the recurring rebuild. Every major version jump asks for planning, module replacement, and testing, on the platform’s timetable rather than yours. Keeping in mind a Drupal 7 to 10 move that takes 16 to 30 weeks of developer time, and at a senior engineer’s rate the labor math writes itself.
Drupal still earns its cost in specific places: multi-channel architectures, site-factory operations at hundreds-of-sites scale, and compliance environments where Acquia’s certification track record is a hard requirement. If that’s the profile, the tax may be worth paying. But for most teams publishing content and running campaigns, it isn’t.
Want a number against your actual setup? rtCamp’s DXP TCO calculator models your current Drupal spend-hosting against a comparable WordPress build.
How to plan the migration from Drupal to WordPress
Most migrations go wrong at the planning stage. It’s clear how you can plan the content transfer, as that part’s visible, but the other things like who owns the block library after launch or which integrations depend on a Drupal module and have no WordPress equivalent can be missed.
rtCamp treats discovery as the most crucial one. We offer a free 20-hour audit that lets our team create the scope, the ownership model, and the migration plan the rest of the project runs on.
Audit the Drupal stack
Discovery starts with a full inventory of what’s actually running. Every content type gets documented with its purpose. Taxonomies and their relationships get mapped. The team traces how content is structured across Drupal’s node and entity system, and catalogs the fields, forms, and configuration attached to each type.
Integrations get their own pass. Forms, CRM, analytics, single sign-on, payment, search each one is a connection that has to be rebuilt against its underlying data contract instead of assuming them to have a drop-in WordPress equivalent. Some Drupal modules map cleanly to a plugin, while others need custom code. Discovery is where that gets decided, because finding out mid-build is how timelines slip.
User roles and permissions get audited the same way. Drupal’s granular access model rarely maps one-to-one onto WordPress capabilities, so the mapping is worked out on paper before anyone writes code.
Align stakeholders and define governance
Governance decides which team controls the block library, who signs off on new templates, who’s responsible for editorial workflows, and what the escalation path is when engineering and marketing disagree. A platform without an ownership model drifts. Six months in, the block library has forty near-duplicate variations and nobody remembers which one is canonical.
For multi-brand organizations, this is also where the standardization question gets settled-how much of the platform is shared across brands and how much stays brand-specific. rtCamp’s OnePress framework is built for exactly this: a governed shared core that keeps brands consistent without flattening what makes each one distinct.
Set the scope and split the work
Once the audit and governance model are settled, the migration scope gets divided into three categories: fully automated, semi-automated with human verification, and manual.
Migration approachWhat goes hereHow it’s handledFully automatedBulk content with clean, consistent structureMigration scripts move it at scaleSemi-automatedContent with edge cases or irregular fieldsScripted migration plus a human checkManualHigh-value or one-off pagesMoved and rebuilt by hand
Deciding this split up front is what keeps the migration predictable, instead of discovering halfway through that a “simple” content type has twelve exceptions.
Set up the environments
Migration runs across three environments to make sure the live site is never at risk:
EnvironmentRoleWhat happens hereDevelopmentBuildMigration scripts get written and tested against real dataStagingValidationMirrors production and preserves content and integrations in sandbox mode. The team validates everything and editors get hands-on time with their migrated contentLiveCurrent siteThe existing Drupal site stays up and serving traffic the whole time
Nothing switches over until staging is signed off. The DNS cutover comes as the last step, you mustn’t treat it as the first one.
Drupal to WordPress migration risks
A Drupal migration has a handful of failure modes that a generic export-import tool walks straight into. Each one is invisible at launch and expensive later.
Broken internal links are the most common. Under every clean Drupal URL sits a node reference-links between content are stored as /node/123, for example, which is unreadable to a visitor. A bulk import that doesn’t resolve those references launches fine, then six months later an editor finds thousands of posts pointing at Drupal paths that no longer exist. The fix is to rewrite every internal link inline during the transfer, so each post points at its real WordPress URL. The transfer has to account for this, since node can’t know its target’s new ID until that target moves, so the migration runs in ordered passes and gets verified before launch.
The URLs are the second slip. Pathauto generates paths from tokens, but editors layer hand-set vanity URLs on top, and those usually carry the most SEO weight. A generic redirect catches the predictable patterns and misses exactly the ones that matter, so every indexed URL gets mapped by hand before launch.
Then there’s structure. Drupal’s Paragraphs have no clean match in WordPress-each type maps deliberately to a Gutenberg block or pattern, with nested Paragraphs the hardest case. A tool that flattens them produces pages that pass a spot-check and fall apart the moment an editor touches them. This gets decided type by type in discovery.
The quietest risk is the module nobody inventoried. Years of custom and contributed modules pile up, and some have no WordPress equivalent. When one turns out to power a live integration (a form, a feed, an SSO connection) finding out after cutover is expensive. The integration audit exists to catch these early specifically.
RiskWhy it happensHow it’s preventedBroken internal linksDrupal stores links as /node/123 references instead of readable pathsInline link rewriting during transfer, verified against a record countLost vanity URLsHand-set aliases carry SEO weight a generic redirect skipsEvery indexed URL mapped by hand before launchMangled ParagraphsNo clean 1:1 to Gutenberg; nested ones break under bulk toolsEach Paragraph type mapped to a block or pattern in discoveryHidden module dependenciesA module quietly powers a live integrationIntegration audit inventories every module before the build
One more locks people out on day one: Drupal and WordPress hash passwords differently, so accounts can’t bring theirs across. They migrate without passwords, and a global reset is planned into launch rather than discovered when nobody can log in.
Drupal to WordPress migration process and timeline
rtCamp runs migrations through a set arc: Audit → Pilot → Phased Build → Enablement → Hypercare → Evolution. Discovery that we’ve already covered sets the plan, a Pilot migration proves it a small slice of real content before it touches the full site, the Phased Build runs the frontend, backend, and content workstreams in parallel, and the last three phases carry the team from launch into steady operation.
The rule that holds across all of it: the live Drupal site stays up the entire time. The WordPress build happens alongside it on staging, and nothing moves until the cutover is signed off. A blue-green deployment keeps rollback available at the switch, though a migration planned this way rarely needs it.
Timelines depend on complexity. A straightforward single-site migration runs a few weeks. rtCamp moved FleetNet Americas, part of the Cox Automotive network, from Drupal 9 on Acquia to WordPress in exactly that window. Enterprise migrations with custom integrations, multilingual content, or heavy workflow translation typically run three to six months. The 20-hour discovery audit allows us to get the specific number before any contract is signed, so the timeline is scoped against your actual architecture rather than a generic estimate.
Drupal to WordPress frontend migration
Drupal and WordPress build pages differently, so the frontend is a translation rather than a copy. The core structures map across, but none of it is a one-to-one export, and treating it that way is how sites end up with layouts that look right and behave wrong.
DrupalWordPressNotesLayout Builder, PanelsFull Site Editing + block editorPage structure moves to the editorRegionsTemplate partsHeader, footer, sidebar zonesViewsQuery blocks, or custom WP_QueryCustom code when the original logic is complexTwig templatesBlock templates + PHPNeed to be rebuiltTheme layerBlock-based theme built on ElementaryrtCamp’s FSE starter theme
At this point, editorial independence is also decided. Moving off Drupal is supposed to free the content team from filing a ticket every time they want to change a layout. rtCamp builds block-based themes for enterprise migrations rather than classic PHP themes, because block-based is what lets an editor rearrange sections, swap components, and assemble a new page from ready-made parts without touching code.
Every theme is built on Elementary, rtCamp’s open-source Full Site Editing starter theme. Elementary keeps the codebase current with WordPress core and the block editor’s direction, so the platform doesn’t drift out of step with where WordPress is heading.
Freedom without guardrails is its own problem, though. Hand an editor a blank canvas and you get 40 versions of the same section and a site that’s lost its brand overnight. The answer is governed blocks: custom Gutenberg blocks that let editors compose freely while holding to the typography, color, and layout rules set during design. Each block carries its constraints inside it, so editors pick from components that are already on-brand instead of building off-brand ones by accident.
The whole frontend build gets documented as it goes, including the block library, the template hierarchy, the mapping between Drupal regions and WordPress template parts, and any custom queries that replaced Drupal Views. Each block is written up with its purpose, options, and an example of how editors should use it, so the team that inherits the platform can actually run it.
Drupal to WordPress backend migration
The backend is everything that made the Drupal site work beyond its content, with the modules, the editorial workflows, and the integrations wired into other systems. Each one gets rebuilt against what it actually does, using the inventory from discovery as the checklist.
DrupalWordPressNotesContributed module (common)Established pluginDirect swap where a mature equivalent existsContributed / custom module (no equivalent)Purpose-built custom codeRebuilt to match the original behaviorContent typesCustom Post TypesRegistered in a pluginContent Moderation / WorkflowsCapabilities + workflow codeDraft → review → approved → published states preservedUser roles & permissionsRoles + capabilitiesMapped during discoveryIntegrations (CRM, analytics, SSO, forms)Rebuilt against each data contractAudited in discovery
Modules are the first pass. Some map cleanly to an established plugin, and some have no equivalent and get built as custom code. The platforms work alike enough that this goes smoothly, as both extend the core through a hook system. What matters is deciding module by module which path each takes, and that gets settled in discovery.
Editorial workflows come next. Drupal’s Content Moderation runs content through defined states, with permissions controlling who can move a piece from draft to review to published. WordPress rebuilds that on its capability system, adding custom workflow code where the process is specific enough to need it. Approval chains, reviewer assignments, and scheduled publishing all map to the roles set during discovery, so an editor who could send a draft for review on Drupal does the same thing on day one in WordPress.
Integrations are the part handled against their data contracts. Forms, CRM, analytics, single sign-on — each connects to WordPress on its own terms, rebuilt to match what it actually sends and expects. Some ride on a Drupal module with no WordPress twin, which is why the discovery audit inventories each one before the build starts. An integration found in discovery is a line item, while the same integration found after cutover is a bad week.
Drupal to WordPress content migration
Content migration is where the site’s content itself and everything attached to it moves to WordPress. It’s also where “just move the database” might fail, because Drupal and WordPress store content in fundamentally different shapes. The work is field-by-field mapping, decided in discovery and executed in verified passes, and shouldn’t be treated as a single bulk dump.
The core entities map in a predictable way. Drupal nodes and their revisions become WordPress posts, pages, or Custom Post Types, with editorial history preserved. Vocabularies become categories, tags, and custom taxonomies, and navigation menus carry across to WordPress menus.
The one piece that needs deliberate handling is relationships: Drupal sites use Entity Reference fields to link content (for example, a product to its reviews, an article to related pieces) and those connections have to be rebuilt in WordPress with ACF relationship fields rather than assumed to survive the move. Users come across with author attribution intact on every post.
Fields are where the storage difference bites. Drupal creates a separate database table for each field; WordPress keeps everything in one wp_postmeta table. So Drupal’s Field API data has to be transformed into postmeta, mapped to Advanced Custom Fields where the content model needs structure beyond a plain custom field. This is the step a generic importer skips, which is how a site launches with 12,000 posts whose fields imported as raw text nobody can query or template against.
DrupalWordPressNotesNodes + revisionsPosts, pages, CPTsEditorial history preservedField API (field_data_* tables)wp_postmeta + ACFTransformed field by fieldUsersWordPress usersAuthor attribution kept; passwords reset (see below)Vocabularies + termsCategories, tags, custom taxonomiesHierarchy retainedBody HTML with <drupal-media> tagsCleaned block markupDrupal embed tokens don’t render in WordPress raw
A thing worth noting is that Drupal stores body content as HTML filtered through a text format, and that markup often holds Drupal-specific tokens and media embed tags like <drupal-media>. Dropped into WordPress as-is, those tags don’t render. The text survives, the embedded image or video does not. Each one has to be resolved to its WordPress equivalent during the transfer.
Media runs in two passes for the same reason. The first pass moves the files themselves, with deduplication, thumbnails, alt text, and file names preserved. The second pass goes back through every migrated post and rewrites the inline references, so an image that lived at /sites/default/files/ now resolves to /wp-content/uploads/ instead of breaking. PDFs and other documents Google has already indexed get explicit redirects, so a resource that ranked doesn’t vanish on launch day.
One challenge to address is passwords. Drupal and WordPress hash them differently, so accounts migrate without passwords and a global reset is built into launch. Handled up front, it’s a routine email to users. Discovered at launch, it’s a support queue full of people who can’t log in.
Drupal to WordPress SEO migration
A migration should be invisible to Google, with the same content at the same addresses, or a clean redirect where an address has to change. In the migration risks section we’ve covered why URLs are the fragile part and why every indexed one gets mapped by hand. Here’s how the rest of the SEO signal gets protected around that mapping.
It starts with a baseline, captured before anything moves. rtCamp crawls the live Drupal site with Screaming Frog and exports every URL with its response code, canonical tag, metadata, and schema, then pulls backlink data from Ahrefs or Semrush to flag the URLs carrying real link equity. Keyword positions for the top queries get recorded too. After launch, that baseline becomes the comparison set, and anything that moves outside the expected variance gets investigated.
Redirects are set before the site goes live. Every baseline URL maps to its WordPress destination, and the method scales with volume: the Redirection plugin handles smaller sets from the admin and logs stray 404s, while high-volume sites get server-level rules through .htaccess or Nginx, which resolve faster at scale. Indexed non-HTML files, or PDFs and documents that show up in search, each get their own 301.
Metadata moves field by field where it should and gets regenerated where that’s cleaner. Drupal sites usually manage it through the Metatag module, but on WordPress, Yoast or RankMath generate canonicals, Open Graph data, and structured data automatically, often more consistently than a direct copy.
Canonicals get their own audit. The pre-migration crawl records every page’s canonical, and after launch each one is verified against that record. Then the staging site is crawled with the same settings as the baseline and compared side by side, before the DNS cutover, while the old site is still alive to compare against.
But even with a clean redirect map, Google re-evaluates a site that has structurally changed, so a brief dip in the first weeks is normal rather than a sign something broke. This is the process that kept FleetNet Americas intact through its move off Drupal 9 on Acquia — search rankings held, and Core Web Vitals came in about 2× better than before, measured on the same launch.
Testing and QA
Testing runs on staging, against the live Drupal site as the reference, before the DNS cutover. The goal is to catch every problem while the old site is still up and there’s something to compare against, so nothing surfaces for the first time in production. rtCamp runs this through a dedicated Quality Engineering practice rather than leaving it to the developers who built the site, with test cases written during discovery.
Test area****What it checksContent integrityEvery page present, fields populated, media resolving, verified against source record countsFunctionalForms, logins, search, workflows, navigation, and integrations behave as they did on DrupalPerformanceCore Web Vitals measured against the pre-migration baseline, under realistic loadAccessibilityWCAG 2.2 AA, automated and manual, with a pre-migration audit so old issues don’t carry overCross-browser & deviceConsistent across Chrome, Firefox, Safari, Edge, and real screen sizesSEOSide-by-side crawl vs. baseline (see the SEO section); staging stays noindex until launchEditor UATEditors build and publish on staging with their own migrated content
Functional testing confirms the site does what the old one did. Every integration, form, login, and on-site search gets exercised against the behavior documented in the audit. At the same time, regression testing catches internal links that resolve, navigation that holds together, and checks features that worked on Drupal and have to keep working on WordPress.
Content integrity is checked at scale. Migrated content is verified against record counts from the source, so 12,000 posts in Drupal become 12,000 posts in WordPress, with fields populated, media resolving, and taxonomies intact. This is also where the schema check lives. Rich snippets like FAQs, breadcrumbs, and review markup are tested so the SEO-critical structured data survives the move.
Performance is benchmarked before and after on the same footing. The pre-migration crawl captured the Core Web Vitals baseline, while staging is measured against it under realistic load, which is how a result like FleetNet’s 2× improvement becomes a measured number.
Accessibility is tested against WCAG 2.2 AA with automated tooling and manual checks. rtCamp audits accessibility during the pre-migration phase specifically so existing issues on the Drupal site don’t get carried across and inherited after launch. Cross-browser and device testing runs alongside it, so the site behaves the same wherever someone opens it.
The last check is human. Editors work on staging with their own migrated content before launch, building a page and running it through the workflow, which surfaces the practical gaps a functional test cannot. Everything found along the way goes into a tracker, gets prioritized, fixed, and retested, and the site doesn’t move toward launch until the critical issues are cleared and every stakeholder group has signed off.
Launch and post-migration
If the whole migration process was well-planned, the launch should go smoothly. The WordPress site was built and tested in parallel while Drupal kept serving traffic, so going live is a simple DNS change. In the days before cutover, the DNS TTL is lowered so the switch propagates in minutes, a final backup of the live Drupal site is taken as the last-resort fallback, and a dry run against a test subdomain catches domain-specific issues like cookie settings and API callbacks before they matter.
The cutover itself runs on a weekday in business hours with both teams present, on a blue-green deployment that keeps the old environment alive alongside the new one. Rollback is instant and provisioned; rtCamp has never had to use it.
Editors aren’t meeting WordPress for the first time at launch. Enablement runs beforehand with role-based training built around the client’s actual implementation and recorded for people who join later. Editors get hands-on time with the block library built for their site; administrators get a separate session on roles, capabilities, and plugins. The goal is a team that owns the platform on day one rather than one waiting on a manual.
The first 24 hours are watched live for traffic, error rates, Core Web Vitals, and Search Console anomalies. If you partner with rtCamp, the next step is Hypercare. Our Hypercare includes 30 days of dedicated support, a single point of contact, a bug-triage SLA, and daily standups that taper as the site settles. The Drupal environment remains available through it, decommissioned only once the new site has proven stable. After Hypercare, the relationship moves into whatever fits, be it an ongoing retainer, periodic support, or a clean handoff to an in-house team now equipped to run the platform itself.
When rtCamp moved the Psychopharmacology Institute off a custom Django and React platform, the switchover took under six hours with zero downtime. 3,000+ subscribers carried across, and the operations team had full control on day one. That last part is the real measure. A migration succeeds when the team running the site afterwards doesn’t need the people who built it.
And that’s how you migrate to WordPress and get a cheaper, editor-friendly platform. Here’s what it looks like when a real enterprise runs it.
Drupal to WordPress migration case study: FleetNet America
FleetNet America runs fleet repair and maintenance across a network of more than 60,000 service providers. Being a part of the Cox Automotive group, their site ran on Drupal 9 on Acquia while the rest of Cox Automotive’s brands lived on a shared WordPress VIP multisite. The goal was to bring FleetNet into that multisite without disrupting the design its users knew or the search rankings the business depended on.
The design constraint mattered as much as the technical one. FleetNet’s team wanted the same site on better infrastructure. So the migration preserved the existing design while rebuilding it on WordPress, moving every page, media asset, and content relationship into the Cox Automotive multisite structure with its shared codebase and standards. rtCamp verified the transfer against the source so nothing was dropped in the move.
The results were then measured. Core Web Vitals came in about 2× better than the Drupal site. PageSpeed moved from 48 to 93, and the site went from failing Core Web Vitals to passing. Search rankings held through the cutover, protected by the URL mapping and metadata work that ran before launch. And the whole migration completed in a few weeks, with zero downtime and no data loss, because the WordPress build ran in parallel while the Drupal site stayed live until the DNS switch.
Joining the multisite is what turned a platform move into a business outcome. FleetNet stopped being a separate site with its own maintenance overhead and became one brand on infrastructure Cox Automotive already governed — the same consolidation logic that put eight Cox brands on one WordPress platform, published and maintained without a separate engineering track for each. As FleetNet’s team put it, WordPress proved an excellent fit for their enterprise B2B needs.
See more enterprise migrations we have run and the results they delivered
But the strongest reason to move now to WordPress is what that platform sets you up for next: being ready for AI.
Turn the migration into your AI head start
If you want your platform to be ready for tomorrow, you should also take care of AI readiness. As 42% of enterprise AI pilots died before production in 2025 (up from 17%), the platform foundation those pilots depend on becomes the deciding factor.
rtCamp frames the work to make the platform AI-ready through the 5 AI Dimensions Framework: content discovery on LLMs (AEO), AI-led editorial, AI-led personalization, WordPress as an AI-integrated platform, and AI-accelerated development.
They all sit on one AI-ready foundation, which is the point as most enterprises only see one or two, solve for those, and hit a wall on the rest. A migration planned around all five produces a platform ready for each.
Our team also contributed three AI connectors to the native AI layer in WordPress 7.0, which is the foundation the wider ecosystem will build on. So the direction isn’t new for us.
Get the 20-hour free discovery
We’ll audit your Drupal platform, tell you what needs rebuilding, and help you build a migration roadmap.
Book your free discovery session
Top Partner Innovator Award
WPVIP 2022
Frequently asked questions
Is WordPress actually an enterprise platform, or are we downgrading?
It runs a big share of the enterprise web already, including NASA, TIME, and a large part of the news industry publish on it, and WordPress VIP is FedRAMP-authorized. So WordPress isn’t downgrading, but for successful migration, you should choose your partner wisely.
Our Drupal content model is complex. Won’t WordPress flatten it?
This is a common worry from teams coming off Drupal or AEM, and it’s usually based on an outdated picture of WordPress. Custom Post Types, Advanced Custom Fields, and custom taxonomies model structured content and relationships as richly as Drupal’s entity system does. Where a Drupal structure has no clean WordPress equivalent, for instance, nested Paragraphs, it gets mapped deliberately during discovery rather than flattened by a bulk tool.
Will editors break the design once they can edit freely?
Not with governed blocks. Teams want editorial freedom in principle and worry about it in practice, so the platform is built with the guardrails inside the components. Editors compose pages from blocks that already carry the brand’s typography, spacing, and layout rules, with locked templates and role-based permissions where they’re needed.
We’ve been burned by insecure plugins. What’s the vetting process?
A fair concern, and the answer is process. Plugins are checked against vulnerability databases, run through rtCamp’s own WP Plugin Compare tool, and gated through a CI/CD install workflow, never added ad hoc. On WordPress VIP, there’s an additional platform-level review layer. The plugin count matters far less than the discipline controlling what gets in.
Will we lose our search rankings?
Not if SEO is treated as a pre-migration deliverable. Working with our team, you can expect every indexed URL mapped and redirected, metadata and canonicals carried across, and a staging crawl is compared against the live baseline before cutover.
Is the Drupal end-of-life date really forcing migration now?
For Drupal 7, effectively yes. It lost support in January 2025, and staying on it means paying for extended patches that keep the lights on without moving anywhere. Drupal 9 is already unsupported, and Drupal 10 reaches end of life in December 2026. Later versions upgrade more smoothly, so the pressure is sharpest for teams on 7, but every version arrives on the platform’s schedule, which is the deeper reason to weigh a move.
Credits
Aviral Mittal
Author
Aviral Mittal
Author
Aviral Mittal is the Chief Marketing Officer at rtCamp, where he established and leads the marketing function, building and growing a team of 20+ specialists across content, SEO, design, and growth…
Good Work. Good People.
Industry partnerships
Compliance certifications
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Company
Solutions
Subscribe to our newsletter and get a few email updates every month.
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Cookie Consent
We value your privacy
We use cookies to give you the best possible experience. By clicking “Accept,” you consent to our use of cookies to improve site functionality, analyze usage, and personalize content and communications. Your privacy matters to us, and we are committed to handling your data responsibly and transparently. Please check our Privacy Policy for more details.
Manage PreferencesDon’t AllowAllow All
Why do we use cookies?
×
By clicking "Accept" or "Decline All" at the bottom, you consent to the use of cookies and other tools as described in our Cookie Policy in accordance with your settings and accept our Terms of Service.
Toggle EssentialEssential
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Geolocation Config
This cookie is used to store the consent settings based on the visitor's location.
30 days
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
Toggle CloudFlareCloudFlare
CloudFlare provides web performance and security solutions, enhancing site speed and protecting against threats.
Service URL: developers.cloudflare.com (opens in a new window)
Name
Description
Duration
cf_clearance
Whether a CAPTCHA or Javascript challenge has been solved.
session
Toggle CommentsComments
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
Toggle GodamGodam
GoDAM" is primarily a specialized WordPress plugin and media management service designed to enhance video hosting, marketing, and asset management directly within the WordPress dashboard.
Service URL: godam.io (opens in a new window)
Name
Description
Duration
user_image
Temporarily stores the path to the user's avatar or profile picture for quick rendering in the website header.
session
user_id
Stores the numerical ID of the logged-in user to maintain session continuity and basic site operations.
session
full_name
Stores the logged-in user's display name to personalize the site interface without needing database queries.
session
system_user
First-party cookie used to store basic application state identifying the current system user role.
session
sid
A generic session ID cookie used to maintain user state and functionality as the visitor navigates through the site.
session
Toggle Google reCAPTCHAGoogle reCAPTCHA
Google reCAPTCHA helps protect websites from spam and abuse by verifying user interactions through challenges.
Name
Description
Duration
_GRECAPTCHA
Google reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis.
179 days
Toggle Google Tag ManagerGoogle Tag Manager
Google Tag Manager simplifies the management of marketing tags on your website without code changes.
Name
Description
Duration
cookiePreferences
Registers cookie preferences of a user
2 years
td
Registers statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
session
Toggle StatisticsStatistics
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Toggle Factors AIFactors AI
Factors.ai is a B2B account intelligence and marketing analytics platform that helps Go-To-Market (GTM) teams identify anonymous website visitors, track buyer journeys, and measure the ROI of marketing campaigns.
Service URL: www.factors.ai (opens in a new window)
Name
Description
Duration
_fuid
It is sent to capture session details and track user behavior across your website to provide behavioral data and intent signals.
1 Year
Toggle Google AnalyticsGoogle Analytics
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
Name
Description
Duration
FPGSID
Stores a session or user identifier to track how visitors interact with a website. This helps Google Analytics measure website performance, user engagement, and usage patterns.
Session
FPLC
Used by Google Analytics to link visitor interactions and sessions across multiple related domains.
20 hours
FPID
A server-side Google Analytics cookie used as an alternative user identifier when third-party cookies are restricted.
2 years
_ga
ID used to identify users
2 years
_ga_
ID used to identify users
2 years
Toggle Jetpack StatsJetpack Stats
Jetpack's built-in visitor analytics. It records page views, referring sites, search terms, and outbound link clicks, and also carries the shared visitor-tracking library used by Jetpack Instant Search and WooCommerce Analytics.
Service URL: automattic.com (opens in a new window)
Name
Description
Duration
tk_aip
Stores a list of anonymous visitor IDs so they can be merged into one identity once a visitor is recognized.
Up to 5 years
tk_tc
Used once per page load to work out which cookie domain the Tracks library should use, then removed as soon as it's read back.
Session (deleted immediately after use)
tk_qs
Queues analytics events for Jetpack's Tracks library so none are lost if the page closes before they can be sent.
30 minutes
tk_ai
Stores a randomly-generated anonymous visitor ID so Jetpack's Tracks analytics library can link tracking events to the same visitor.
Session in wp-admin; up to 5 years on the frontend
Toggle Microsoft ClarityMicrosoft Clarity
Clarity is a web analytics service that tracks and reports website traffic.
Service URL: clarity.microsoft.com (opens in a new window)
Name
Description
Duration
CLID
Identifies the first-time Clarity saw this user on any site using Clarity.
12 months
ANONCHK
Indicates whether MUID is transferred to ANID, a cookie used for advertising. Clarity doesn't use ANID and so this is always set to 0.
Session
_clck
Persists the Clarity User ID and preferences, unique to that site is attributed to the same user ID.
12 months
_clsk
Connects multiple page views by a user into a single Clarity session recording.
12 months
Toggle Parse.lyParse.ly
Parse.ly is a content analytics platform that helps publishers optimize audience engagement and content performance.
Name
Description
Duration
_parsely_session
JSON document storing information identifying a browsing session according to Parsely’s proprietary definition
30 minutes
_parsely_visitor
JSON document uniquely identifying a browser and counting its sessions
13 months
cookies.js_dtest
This cookie determines whether the browser accepts cookies.
session
Toggle MarketingMarketing
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
Toggle Bing / MicrosoftBing / Microsoft
Bing, powered by Microsoft, is a search engine providing web, image, video, and map search capabilities.
Name
Description
Duration
MR
Used to collect information for analytics purposes.
6 months
ANONCHK
Used to store session ID for a users session to ensure that clicks from adverts on the Bing search engine are verified for reporting purposes and for personalisation
10 minutes
SM
Used by Microsoft in synchronizing the MUID across multiple Microsoft domains to track users for advertising.
session
MUID
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
Toggle DoubleClick/Google MarketingDoubleClick/Google Marketing
A comprehensive digital advertising platform for managing campaigns, optimizing performance, and analyzing audience data.
Name
Description
Duration
IDE
This cookie is used for targeting, analyzing and optimisation of ad campaigns in DoubleClick/Google Marketing Suite
2 years
ar_debug
Store and track conversions
Persistent
Toggle LinkedInLinkedIn
LinkedIn is a professional networking platform for job seekers, employers, and industry connections.
Name
Description
Duration
bscookie
Used by LinkedIn to track the use of embedded services.
1 year
AnalyticsSyncHistory
Used to store information about the time a sync with the lms_analytics cookie took place for users in the Designated Countries
30 days
bcookie
Used by LinkedIn to track the use of embedded services.
1 year
li_sugr
Used to make a probabilistic match of a user's identity outside the Designated Countries
90 days
lidc
Used by the social networking service, LinkedIn, for tracking the use of embedded services.
1 day
UserMatchHistory
Used by LinkedIn Ads to synchronize and match user IDs across different ad networks and data providers.
30 days
Toggle LinkedIn InsightLinkedIn Insight
LinkedIn Insight is a web analytics service that tracks and reports website traffic.
Service URL: www.linkedin.com (opens in a new window)
Name
Description
Duration
li_sugr
Used to make a probabilistic match of a user's identity.
90 days
lidc
Used for routing and session management.
24 hours
Toggle LiveIntentLiveIntent
LiveIntent provides a platform for email advertising and identity-driven marketing solutions.
Name
Description
Duration
_lc2_fpi_js
Companion cookie to _lc2_fpi used by JavaScript to facilitate cross-domain ad tracking and user identification.
1 year
_lc2_fpi
First-party tracking cookie usually associated with LiveRamp to identify users across devices for targeted advertising.
1 Year
_li_ss
Sets a unique ID for the visitor, that allows third party advertisers to target the visitor with relevant advertisement. This pairing service is provided by third party advertisement hubs, which facilitates real-time bidding for advertisers.
1 month
lidid
Collects data on visitors' behaviour and interaction - This is used to make advertisement on the website more relevant. The cookie also allows the website to detect any referrals from other websites.
2 years
Toggle Cookie PolicyCookie Policy
You can find more information in our Privacy Policy.
Allow AllDecline All
Accept