Will we lose our search rankings?

Nobody can promise a specific ranking outcome, and anyone who does is guessing. What can be controlled is the technical execution, and that is where migrations usually go wrong. Before anything moves, we crawl the existing site and record every URL, canonical tag and metadata value as a baseline. The redirect map is built from that crawl, not from pattern guesses, and one rule is enforced: no chains. A goes straight to C. After launch we re-crawl, compare against the baseline, and keep watching coverage and indexing until they settle.

What happens to our Drupal users and passwords?

Accounts come across with author attribution preserved, so historical content stays credited to the right person. Passwords do not come across. Drupal and WordPress hash them with cryptographically incompatible algorithms, so there is no way to carry them over. Accounts arrive without passwords and a coordinated reset runs at launch, communicated in advance so nobody is locked out by surprise.

How do our custom modules translate?

There is no one to one mapping between Drupal contributed modules and WordPress plugins, and pretending otherwise is how migrations lose their budget halfway through. The discovery audit goes module by module and sorts each one into a bucket: rebuilt as custom code, replaced by a WordPress core feature or an established plugin, or retired because nobody has used it in years. You see that list before development starts.

Can we keep publishing during the migration?

Yes. Frontend, backend and content migration run in parallel rather than in sequence, so your Drupal site stays live and editable while the new one is built. We agree on a content freeze date close to launch. Anything published after the freeze is picked up in a final delta pass, so the cutover happens with current content instead of a snapshot from weeks earlier.

What about our media library and PDFs?

Media moves in two passes. The first imports the files themselves with deduplication, so the same asset uploaded five separate times in Drupal does not become five entries in the WordPress library. The second pass rewrites every inline reference inside post bodies to point at the new locations. That is the step teams skip, and it is why migrated sites end up with broken images. PDFs and other indexed assets get explicit 301 redirects of their own, because they hold search visibility too.

Drupal to WordPress Migration

Migrate off Drupal without losing a single URL

Your Drupal site works. That is not the problem. The problem is that publishing a landing page still means opening a ticket and waiting for a sprint. We move enterprise sites to WordPress with the content model, the redirects and the editorial workflows intact, so your marketing team stops negotiating with engineering.

Book a discovery call See our migration service

Enterprise website migration in progress with teams maintaining live operations

The real problem

Your Drupal site is not broken. Your publishing process is.

The site loads. The content is there. What does not work is the part where your team wants a landing page live on Thursday and the answer is that engineering can look at it next sprint.

Every campaign gets scoped against developer availability. Marketing quietly stops asking for the things that are hard to get, and the roadmap starts to reflect what the CMS allows rather than what the business wants. That cost never shows up as a line in a budget, which is exactly why it survives so long.

What the migration covers

Everything that has to survive the move

A migration is not a content export. These are the six layers that decide whether the new site behaves like the old one on launch day.

Content model mapping

Drupal nodes become posts, pages or custom post types. Field API tables map to WordPress meta. Revision history comes across, so the editorial trail is not lost.

Taxonomies, users and roles

Vocabularies become categories, tags or custom taxonomies, mapped during discovery. Accounts import with author attribution preserved. Password hashes are cryptographically incompatible between the two systems, so accounts arrive without passwords and a coordinated reset runs at launch.

Media library

A two-pass process: files first, with deduplication, then a second pass that rewrites every inline reference inside post bodies. PDFs and other indexed assets get explicit redirects.

URLs and redirects

Drupal Pathauto patterns rarely match WordPress permalinks. The mapping table is built from a full crawl, not from guesses, and one rule is enforced: no redirect chains. A goes to C, never A to B to C.

Integrations

Contributed modules do not map one to one. The discovery audit decides, module by module, what gets rebuilt, what a core feature replaces, and what quietly retires.

Editorial workflows

Content moderation chains, reviewer assignment and scheduled publishing map onto WordPress roles and capabilities, plus custom workflow code where approval logic is complex.

What changes

From let me check with dev to it is already live

After the migration, the people who write the content are the people who publish it.

Blocks assemble into pages without a ticket. Editorial review happens inside the CMS instead of in a spreadsheet. Your development team goes back to work that genuinely needs developers. The point is not a nicer admin screen, it is removing engineering from the critical path of a marketing decision.

Team reviews CMS migration plan in office

The plan

How the migration runs

Six stages, in this order, with a decision point at the end of each one.

1

Discovery and audit

Full crawl of the existing site, content inventory, integration audit, and a baseline of every URL, canonical tag and metadata value before anything moves.

2

Pilot migration

A real slice of content migrated end to end, so the data mapping is proven before the full run.

3

Parallel build

Frontend, backend and content migration run at the same time instead of in sequence.

4

QA and validation

Cross-browser checks, integration testing, and editor workflow testing with the people who will actually use the CMS.

5

Launch

DNS cutover with the previous environment kept available, so rollback is a decision rather than a project.

6

Hypercare and handover

Post-launch support while rankings and traffic settle, then handover to your team or to ongoing support.

Before you commit

See what your migration actually involves

A discovery call walks through your content model, your integrations and your URL structure. You leave with a real scope, not a guess, and no obligation to go further.

Book a discovery call

FAQ

What teams ask before leaving Drupal

The five questions that come up on every Drupal migration call, answered without hedging.

Ready when you are

Stop waiting on the sprint to publish

Bring us your Drupal site and we will map the path off it: content model, redirects, integrations, and the workflows your team will use on day one.

Book a discovery call See our migration service