Drupal to WordPress: Lessons from FleetNet America's Move

Context

Among publicly documented Drupal-to-WordPress migrations, one of the few with named, verifiable details is FleetNet America, described as part of the Cox Automotive network of sites. According to rtCamp's published case study and handbook, the site moved from Drupal 9 on Acquia to WordPress VIP, and the new site was integrated into an existing WordPress Multisite environment. The stated drivers were Cox Automotive's goals of global compliance, standardization, and budget efficiency — the classic pattern where an org running a one-off Drupal instance folds it into a shared, governed platform rather than maintaining a separate stack.

The published outcome is a 2x improvement in Core Web Vitals (described elsewhere as a 2x performance increase), delivered in a project the agency says was completed in just a few weeks. A quote attributed to Samantha Blum, Digital Marketing Manager, credits the migration with elevating user experience and functionality.

That is essentially the full set of load-bearing public facts. Other vendor write-ups in this space describe the same shape of project in general terms — for example, an organization needing to preserve existing content, maintain established URL structures, and match existing branding and design — without naming the org. We flag that distinction on purpose: the transferable lessons below are grounded in what these sources actually claim and in well-understood mechanics of this migration path, not in invented metrics.

What broke

The sources do not publish a defect log for FleetNet, so we won't pretend to one. What the sources do emphasize is where this class of migration concentrates risk, and it maps to what reliably breaks when teams move off Drupal:

Redirects and URL structure

Drupal's URL aliases, path patterns, and node IDs rarely map one-to-one onto WordPress permalinks. The Freshy source explicitly frames "maintaining established URL structures" as a core requirement — which is a tell that, left unmanaged, this is exactly what fails. Broken redirects silently shed ranking equity and create soft 404s that search engines interpret as decay.

Content model mismatch

Drupal content types, fields, and view modes are more granular than WordPress's default posts-and-pages model. Without deliberate mapping to custom post types, custom fields, or blocks, structured content collapses into unstructured HTML. That's the moment you lose the machine-readable signals — clean headings, field-level data, consistent templates — that both classic SEO and answer-engine extraction (AEO) rely on.

Taxonomy gaps

Drupal's taxonomy vocabularies and term hierarchies don't automatically become WordPress categories and tags. Multi-vocabulary tagging, term relationships, and term-based URL paths are common casualties, which fragments navigation and internal linking.

Multisite integration friction

rtCamp notes that migrating an additional site into an existing Multisite environment requires careful planning. Shared themes, plugins, user roles, and platform policies on WordPress VIP mean the incoming site must conform to conventions it never had on standalone Drupal — a constraint that surfaces late if you treat the move as a straight content copy.

What worked

The documented positives are worth reading closely because they point to the levers that mattered:

• Performance jumped measurably. A 2x Core Web Vitals improvement is consistent with moving from a bespoke Drupal/Acquia stack to a managed, opinionated platform (WordPress VIP) where caching, delivery, and code standards are enforced by the environment rather than assembled per project.
• Standardization was the goal, not an accident. Folding the site into an existing Multisite let the parent network apply consistent compliance and governance — the stated business case — instead of carrying another unique deployment.
• Scope stayed tight. A migration completed in weeks implies a constrained, well-defined content set and a clear target model, not an open-ended redesign bolted onto a replatform.

Lessons

1. Treat URLs as a first-class deliverable. Export every live Drupal path before you touch anything, then build a redirect map from old alias to new permalink. Validate it against real analytics and search-console data, not just the sitemap.
2. Design the WordPress content model before importing. Map each Drupal content type and field to a WordPress custom post type or field. If you can't name the target for a field, you don't understand it yet — and it will land as orphaned markup.
3. Migrate taxonomy deliberately. Decide up front which vocabularies become categories, which become tags, and how term hierarchies and term URLs carry over.
4. Protect structured/SEO/AEO signals. Preserve heading structure, metadata, canonical tags, and structured data. Unstructured HTML blobs are cheaper to import and far more expensive to rank.
5. Plan Multisite conformance early. On a shared or VIP environment, inventory the platform's theme, plugin, role, and code constraints before mapping content, because they dictate what the target model can even be.
6. Let performance be an explicit target. The documented win here is Core Web Vitals. Set a measurable performance baseline pre-migration so "faster" is a number, not a vibe.
7. Keep scope narrow. Migrate first, redesign later. Bundling the two is how "a few weeks" becomes several quarters.

Before you make this move

A short pre-flight checklist distilled from the above:

• Full URL inventory exported and reconciled with traffic and ranking data.
• Redirect map drafted, with a plan to test for redirect chains, loops, and soft 404s.
• Content-type-to-post-type mapping documented field by field.
• Taxonomy mapping agreed, including term hierarchies and term URLs.
• SEO/AEO signal audit: titles, meta, canonicals, structured data, heading structure.
• Target-platform constraints (Multisite, managed hosting, plugin/theme policies) confirmed.
• Performance baseline captured so you can prove the gain — or catch a regression.
• Content freeze and rollback plan for the cutover window.

Mapping these risks before committing to a target model is precisely the pre-migration intelligence work Replatform Radar exists to support: surfacing the URL, content-model, and taxonomy exposure early, while there's still time to design around it. The public FleetNet record shows the upside is real — measurable performance gains and a cleaner, governed platform — but the sources are equally clear that the hard part is planning, not the import button.