How to Prepare for Your Drupal to WordPress Migration

Updated (first posted )

The most successful migrations I've worked on share one thing in common: the site owner did their preparation before the project started. A few hours of groundwork on your side (auditing your content, gathering credentials, and clarifying your goals) saves significant time and budget during the migration itself. Here's what to have ready.

Clarify Your Migration Goals

Before discussing timelines or costs, the first question to answer is: what do you actually need from this migration?

  • What must come across? All content, or a curated subset? Do you need full order history, or just active products? Complete user accounts, or just administrators?
  • What can be left behind? Old drafts, test content, unused content types, and deprecated modules don't need to migrate. Stripping these out reduces complexity and cost.
  • Are you redesigning? If you're planning a visual redesign alongside the migration, the WordPress theme work can run in parallel with data migration. If you want to replicate the existing design, that's a different brief.
  • What's your timeline? A hard deadline (end-of-life pressure, hosting contract expiry, compliance audit) affects how the project is phased.

Clear answers to these questions shape the entire project scope. Ambiguity here is the most common cause of budget overruns.

Audit Your Drupal Content

The content audit is the foundation of the migration plan. I'll conduct a detailed technical audit once the project starts, but having your own understanding of what's on the site accelerates the process considerably.

Content Types

Log in to your Drupal admin and go to Structure > Content types. List every content type and roughly how many nodes exist for each. Pay particular attention to custom types. These are the ones that require the most migration work.

Taxonomy Vocabularies

Check Structure > Taxonomy. Note each vocabulary, the number of terms, and whether terms have custom fields or descriptions. Taxonomy structures often need restructuring for WordPress.

Media and Files

Estimate the volume of uploaded files: images, documents, PDFs, videos. Check whether files are stored in a public or private filesystem. Large media libraries need separate handling during migration.

Users and Roles

Note how many user accounts exist and which roles are in use. If your site has authenticated user features (member areas, customer accounts, editorial workflows), these need role mapping to WordPress equivalents.

Custom Modules and Views

List any custom-built modules and key Views configurations. Custom modules may store data in their own database tables, which won't be covered by standard migration scripts. Views-generated pages that drive traffic need equivalent WordPress implementations.

Gather Your Credentials

Migration requires access to several systems. Having these ready at the start of the project avoids delays:

  • Database access. Credentials for your Drupal database, via cPanel, phpMyAdmin, or direct SSH access. I'll need to export the database for analysis and test migrations.
  • File system access. FTP or SSH credentials to download your sites/default/files directory. This contains all uploaded media.
  • Drupal admin login. Administrative access to the Drupal backend for reviewing content types, modules, and configuration.
  • Hosting provider details. Your current hosting provider and plan, plus any planned changes. If you're moving hosting alongside the migration, coordination is needed.
  • Domain registrar access. For the DNS cutover at launch, you'll need access to update DNS records, or be able to instruct your registrar to do so.

If you don't have direct database access, your hosting provider can usually provide it on request. For managed hosting platforms, let me know the provider and I'll advise on the best approach.

Plan Your WordPress Architecture

These decisions don't need to be finalised before migration starts, but thinking about them early helps:

  • Theme direction. Are you using a custom theme, a pre-built theme, or a theme framework? If you want to replicate your current design, screenshots and a list of key page layouts are helpful.
  • Essential plugins. Identify functionality your Drupal site provides that will need WordPress plugin equivalents: forms, SEO, caching, e-commerce, membership areas.
  • Hosting environment. WordPress hosting requirements differ from Drupal. If you're staying with your current provider, confirm they support WordPress. If moving, hosting selection should happen early in the project.

SEO Preparation

If organic search drives meaningful traffic to your site, SEO preparation should start before the migration project begins.

  • Export your URL aliases. Your Drupal database contains a url_alias table with every URL path on the site. Export this. It's the starting point for your redirect map.
  • Export metadata. If you're using the Metatag module, export the meta titles and descriptions. These need importing into your WordPress SEO plugin.
  • Identify high-traffic pages. Use Google Analytics or Search Console to identify the pages that drive the most organic traffic. These get priority attention during URL mapping and redirect testing.
  • Document taxonomy pages. Check whether any Drupal taxonomy listing pages appear in search results and drive traffic. These need explicit redirect handling.

For a more detailed treatment of SEO during migration, see Preserving Your SEO During a Drupal to WordPress Migration.

What to Expect from the Process

A well-run migration isn't a black box. Here's what the process looks like from your side:

  • Initial audit. I analyse your database and content model, then provide a migration plan and quote. No work begins without your sign-off on the scope.
  • Iterative testing. You'll review test migration output at key stages. This is your opportunity to catch issues early: missing fields, incorrect mappings, content that needs restructuring.
  • Your involvement. Plan for a few hours per week during the active migration phase. You'll be reviewing test output, answering questions about content decisions, and signing off on milestones.
  • Launch coordination. The DNS cutover needs to happen during a low-traffic window. For e-commerce sites, I coordinate the final data sync and cutover to minimise disruption.

The total timeline depends on complexity. A straightforward content migration might take 4 to 6 weeks, while a complex site with e-commerce, custom content types, and extensive SEO requirements can run 8 to 12 weeks.

Related reading:

Ready to Start Planning Your Migration?

Send me a brief overview of your Drupal site and I'll provide a free initial assessment: what's involved, what to expect, and a ballpark timeline for your specific situation.

Get a Free Quote