How to prepare for your Drupal to WordPress migration project

Any successful project requires careful planning and a Drupal to WordPress migration is no exception. It can be tempting to head straight to setting up WordPress, trying out new themes and experimenting with plugins. Website owners and administrators know their content is important but it can sometimes become an afterthought in the excitement to play with the new content management system. After all, you can use the Drupal site as the template and simply export over all the content over, right? For some site owners that’s all there is to it. However, you should be aware that site migrations can have hidden pitfalls that turn an apparently simple project into one fraught with complications.

The key to avoiding problems is to plan your Drupal to WordPress migration before you even touch your server. Whether you migrate the site yourself or hire me to help you, this guide will give you a head start with your planning. Keep in mind that general project planning principles apply but there are already many resources on this topic. I will focus on the areas important specifically for a migration from Drupal to WordPress.

Drupal to WordPress migration planning

Step 1: Consider why you are migrating to WordPress

There are many content management systems available and I’m going to assume you have already thought carefully about why you’ve chosen WordPress. For the sake of completeness, I’ll include this step because your reasons will determine whether or not the migration project will be a success.

In case you need a reminder about the merits of either CMS, here are a few Drupal vs WordPress posts:

If you haven’t already put together a migration requirements document, go ahead and create one now. I go through this migration requirements checklist with my own clients and it might help you too.

Step 2: Decide on your approach to building the WordPress theme

The WordPress theme, just like in Drupal, is what handles how your site looks. A migration to a new CMS often goes hand-in-hand with redesigning the site. I’ve put this step early on because a site redesign could be an entirely separate project. You might want to run in parallel with the migration or it could be something you’d want to start before kicking off the content migration.

You have three options:

  1. Redesign the WordPress site entirely.
  2. Create a custom theme based on your existing Drupal design.
  3. Use one of the many pre-made free or premium WordPress themes.

If you have a successful site, any change, whether it’s a redesign, restructure or move to another content management system should be carefully considered. This article at Search Engine Journal gives an excellent overview of the things you should keep in mind: How To Avoid SEO Disaster During a Website Redesign – Top Marketer Concerns

Step 3: Be aware of any SEO impact when migrating to WordPress

WordPress has an excellent reputation for being SEO-friendly but beware of taking this for granted. The Search Engine Journal post linked in step two should have given you a sobering outlook on how making changes to your site will affect your SEO. In my experience, preserving SEO takes a large part of the time and budget of many migration projects. Sometimes the cost will outweigh any benefit of trying to preserve the SEO customisations on your Drupal installation. This is often a commercial rather than technical decision. If you run a site that relies on search traffic, I recommend that you hire an SEO consultant to advise you. In fact, I will often work with and take direction from a client’s SEO consultant during a typical Drupal to WordPress migration project.

For more information about the kind of work involved, see Preserving SEO during a Drupal to WordPress migration. This SEO checklist will help get you thinking about any SEO impact the migration will have to your site.

Step 4: Gather as much information as you can about your Drupal installation

Knowing as much as possible about your Drupal installation will help me come up with a more precise estimate for your migration project. If you’re doing the migration in-house, it will help you plan how much time to set aside and which team-members need to be involved.

Site owners who built and manage the site will likely have records of some information but not necessarily all the details of how Drupal is configured. Site owners also come to me with a site built by a third-party. They have working knowledge on how to manage it and add content but not anything else. I can help you discover the information needed for the migration if you are in this position but you can save budget by doing some investigation yourself. Use my Drupal to WordPress migration worksheet as a guide.

The formal name for this is a site audit but essentially you need to find out about two areas:

  1. How to access your server
  2. What kind of content you have

Server audit

You’ll need your FTP server details to access your Drupal installation, media files and to upload the WordPress package. When running a migration, I like to download a full working version of the Drupal site on my local development server. This isn’t necessary but can be useful for figuring out formatting problems that crop after content migration. For example, you may find missing bits of text on WordPress and some investigation on the Drupal installation will show the text will be from a custom field or block.

The database server is necessary for exporting your Drupal database and setting up WordPress when the migration is complete. Some hosting providers offer access through a cPanel interface, a separate phpMyAdmin link or by command line. Gather all these details ahead of time will help get your project started quickly.

Content audit

The content audit helps you discover what type of Drupal content do you have. Drupal, like most other content management systems, keeps content in two places:

  • The database
  • On the server filesystem

Types of content include:

  • Nodes
  • Views
  • Blocks
  • Panes
  • Taxonomies
  • Static HTML files
  • Embedded media like videos, images and audio
  • File attachments
  • User profile information
  • Content metadata

You may be surprised where the different bits of content that make up your site ends up being stored. A content audit will avoid unnecessary complications with trying to hunt down bits of data mid-migration. My Drupal content audit checklist should get you started.

Step 5: Write a Drupal to WordPress migration mapping document

The migration mapping document will help both with quoting for project as well as keeping track of everything that needs to be done during the migration. It gives everyone involved a framework to work on.

I know, this sounds like a mouthful and so very tedious. Truth be told, few people find writing specification documents fun but it is a necessary step if you want to avoid unexpected costs and delays. The more detailed you are, the fewer surprises there will be for everyone during the actual migration. Your investigations during step 4 will lay the groundwork for the migration specification.

I will write another post on how to write migration mapping document but the document doesn’t have to very formal. All it needs to do is clearly convey the state of your Drupal site and what you’d like migrated to WordPress.

Ready for your migration project

Running through these steps will put you in a good position for your migration from Drupal to WordPress. Admittedly, there have been projects where I or the site owner didn’t bother to do any detailed planning and we were able to get by. Usually, this was because of limited budget or a rush to launch the new WordPress site. However, the projects where we took some time out to plan ahead were always closer to the estimated budget and posed fewer surprises.

A little plug to keep the lights running. If you think all of this work is too much trouble, please consider hiring me for your Drupal to WordPress migration project.

Drupal to WordPress migration service

Drupal 6 and Drupal 7 · All content · Custom content types · SEO · Plugins

If you’re not sure how to make the appropriate changes or would simply like someone else to do the work, please contact me and ask about my Drupal to WordPress migration service.

Get a quote

Planning graphic courtesy of and copyright Free Range Stock, artist: Jack Moreh

Drupal to WordPress migration worksheet

If you are using my Drupal to WordPress Migration Tool or have hired me for Drupal to WordPress migration service, it’s important that you gather as much information as you can about your Drupal installation. The more detailed you are in your investigation, the fewer surprises there will be during the actual migration. You may have hired a web development company or freelancer to build your site and they’ll sometimes be able to provide you with the necessary information. However, gathering this information can involve some work so they may be reluctant to provide help without an extra fee.

You can use the questions below to help structure your investigation process. I can help you with this if you’re not able to run the investigation yourself. Please ask for details.

Note: You may print out this worksheet as a guide so you can record your investigations. It is not an online form. I will send you a link to my online form if you’d like me to quote for your migration project. You may also download a PDF version of my online form.

Drupal Installation Questions

  1. What are the FTP login details of your hosting provider?

    You will need these details to make a backup of your Drupal site. When the migration is complete, you’ll need them to install WordPress on your server.

    FTP Credentials
    Host  
    Port  
    Protocol  
    Username  
    Password Send through secure channel e.g. password manager
  2. What are the database login details of your hosting provider?

    You’ll need these to export your Drupal database to perform the migration.

    Database Credentials
    Host  
    Port  
    Database name  
    Username  
    Password Send through secure channel e.g. password manager
  3. Do you know how to export your database to a dumpfile?

    If you’re unsure how to export your database to a ‘dumpfile’, please contact your hosting provider. They will likely have tools such as phpMyAdmin and help articles to guide you through the process.

      Yes/No
    I know how to export my database to a dump file
    I need help exporting my database to a dump file
  4. What version of Drupal are you running?

    The database column names differ slightly between Drupal versions. This means that a different set MySQL queries will be needed to perform the migration. You can sometimes find this information using your installation’s CHANGELOG file at http://[YOURDOMAIN.COM]/CHANGELOG.txt. Some developers remove this file as part of their security hardening process so it may not exist in your installation.

    Drupal version
  5. List your Drupal modules and site functionality

    Can the functionality can be handled with existing WordPress plugins? Will you need to develop custom plugins?

    Drupal modules and functionality
     
  6. How many custom content types do you have set up?

    Additional migration MySQL queries will be needed for each Drupal custom content type. WordPress supports page and post content types as standard. Additional development work will be needed to support other content types.

    Drupal custom content types
     
  7. How many custom fields do you have set up?

    As with custom content types, custom fields in your Drupal installation will need additional work to support them under WordPress.

    Drupal custom fields
     
  8. Do you have blocks, views and panes with important content?

    Many Drupal sites display content in blocks, views and panes. These will also need additional work to support under WordPress.

    Drupal blocks, views and panes
     
  9. How many nodes do you have?

    The number of Drupal nodes you have does not usually play a big factor in the complexity of the migration. However, it will still be useful to get an idea of the number since many nodes can have an impact on how long it takes to troubleshoot migration problems.

    Approximate number of Drupal nodes
  10. Do you expect to have multiple aliases referencing the same post?

    Drupal supports multiple URL aliases for nodes. These will need to be resolved when migrating to WordPress. For more information, please see my article Preserving SEO during a Drupal to WordPress migration.

    Brief description of what to do with multiple aliases
    It’s OK if you don’t know. We can discuss your options.
     
  11. Do you expect to have duplicate terms?

    Duplicate Drupal terms can cause problems during a migration. For more information, please see my article Handling Drupal terms during a Drupal to WordPress migration

    Brief description of what to do with duplicate terms
    It’s OK if you don’t know. We can discuss your options.
     
  12. Will your terms exceed the WordPress’ 200 character length?

    WordPress has a 200 character limit for terms. Any Drupal terms longer than 200 characters will need to be truncated.

    Brief description of what to do with problem terms
    It’s OK if you don’t know. We can discuss your options.
     
  13. How many users do you have?

    The number of users doesn’t play a big factor during a migration but it may be useful to know.

    Approximate number of users
  14. How many user roles do you have?

    Your Drupal user roles may need to be converted into WordPress roles.

    List and brief description of user roles
    It’s OK if you don’t know. We can discuss your options.
     

WordPress Installation Questions

  1. Will preserving SEO be an important part of the project?

    For more information, please see my article Preserving SEO during a Drupal to WordPress migration.

      Yes/No
    Preserving SEO is important for this project
  2. Aside from migrating to WordPress, do you also plan to redesign the site?

    Redesigning the site will obviously involve more work as it will require a custom WordPress theme. Some site owners are happy to use a free or premium off-the-shelf theme template.

    Ideas for the WordPress theme
    e.g. list the names, URLs and prices of any pre-made template candidates
     
  3. Are there existing WordPress plugins that match your Drupal functionality?

    If you’re happy to be flexible, you may find WordPress plugins that closely match any Drupal modules you have installed on your existing site. Set aside some time to search the WordPress Plugin Directory. If you don’t find anything suitable, you may have to consider setting aside some budget for custom plugin development.

    List some possible WordPress plugins you may have found
     

Preserving SEO during a Drupal to WordPress migration

This article is about preserving SEO during a Drupal to WordPress migration. It’s not about which platform is better. A web search will bring up many articles about the relative SEO merits of Drupal versus WordPress. I’ve found the best summary on that topic in a forum post by Drupal.org user and developer, John Birchall:

“The consensus that WordPress has better SEO is a guess…WordPress fans will guess one way, Drupal fans the other. In my opinion, WordPress SEO plugins work better for sites which are short on skill or time or money. If you want to give your clients hand-made quality, Drupal does rather a good job. This also goes for SEO. Nevertheless, lack of developer skill and client budget does sometimes mean we are better off simply ‘reheating’ and rolling out the wonderful prepackaged solutions available for WordPress.” (Slightly paraphrased for clarity.)

If you’re reading this post, I will assume that you’ve already decided to migrate your site to WordPress. Rather than re-hashing the Drupal versus WordPress SEO debate, I’ll focus on some technical details that affect your SEO efforts when migrating from Drupal to WordPress. First, let’s start with some basics.

One-way traffic sign to symbolise preserving SEO during a Drupal to WordPress migration

Can I preserve my SEO during the migration?

The quick answer is, ‘Yes’. It is possible to preserve search engine optimisation during a migration. However, it can be easy to overlook the idea that you might end up with better SEO by revisiting your approach entirely. I’ve had site migrations where replicating optimisations from the Drupal version wouldn’t have made a significant impact in the business—or at the very least, where SEO was something that could be improved after the migration. If your site falls into this category, I would not recommend putting too much into preserving your Drupal optimisations. The money spent hiring me or anyone else may be better spent on improving the WordPress SEO after exporting your Drupal content.

There are some easy and low-cost approaches you can take such as:

  • Using or building an SEO-friendly and responsive WordPress theme.
  • Installing SEO WordPress plugins.
  • Creating higher quality content.
  • Improving page load times. WordPress is a lighter CMS so you should get this ‘out of the box’ but you can lose any gains if, for example, you replicate calls to third-party libraries.

Of course, you should consult an expert if you rely heavily on search traffic. Preserving SEO may be vital for your site but it’s worth making a conscious assessment about the investment needed.

What kind of work is involved in preserving SEO?

The underlying differences between Drupal and WordPress mean preserving SEO often takes the bulk of a migration budget. The amount of work needed depends on what you’re trying to preserve. To give an example from a past migration project where SEO was vital, tasks included:

  • Pre-migration auditing, mapping and analysing links on the Drupal site;
  • Developing an SEO-friendly custom theme;
  • Creating redirects for every URL that would change on WordPress;
  • Ensuring we preserve on-page optimization for all high-value pages;
  • Making further adjustments as directed by an SEO consultant after she analysed her webmaster tools.

Remember that SEO isn’t a one-time effort. The project needed multiple months of on-going work. Further, I was taking direction from the client’s SEO consultant who incurred her own separate fees. Thus the client allocated a sizeable budget for SEO alone. In his case it was worth the money because the Drupal site earned him many times that amount on revenue from search traffic. Minimising any negative impact on SEO after migrating to WordPress was a priority.

How much time and money you’ll need to allocate for your migration depends on a range of factors that are very specific to your site. You’ll only know after doing some in-depth analysis and documentation. Here’s an article on Search Engine Journal that I send to clients when they ask about the SEO impact of a CMS migration: How To Avoid SEO Disaster During a Website Redesign. It’s worth a read and afterwards you can think about how much SEO should play a part of your site migration project.

SEO considerations

What exactly will affect SEO during a typical Drupal to WordPress migration? Here are a few SEO considerations to keep in mind for your migration project. It’s certainly not an exhaustive list but paying attention to these points should cover the basics.

On-page SEO

A lot of the on-page SEO comes over as a natural side-effect of most content migration processes. For example, page titles, content keyword optimisation, sub-heading tags, image file names and internal linking are all embedded into the Drupal node content. These remain intact when the nodes are imported into WordPress, unless content cleaning or other manipulation is part of the project.

Other areas, such as URL structure, meta data and load speed will need work due to the differences of the two systems.

Off-site SEO

Off-site SEO will be unaffected by a CMS migration as long as you have the necessary redirects set up to catch URL changes for any backlinks. This is an effort that’s external to the site so not within the scope of this article.

Drupal aliases vs WordPress permalinks

URL structure is one of the SEO areas that will change after a CMS migration. A big part is because of some important differences between how Drupal and WordPress handle URLs. Drupal creates URLs using either the node ID or a URL alias stored in its database’s url_alias table. Take a look at some sample entries.

Drupal url_alias table
Drupal url_alias table

You’ll see an entry for node/28 associated with a URL alias projects/april. This means that under Drupal, the page with node ID 28 can be accessed using either http://example.com/node/28 or http://example.com/projects/april. Not shown is that content can have multiple aliases. The site could therefore also have another entry node/28 associated with URL alias projects-april and yet another with my-projects/april. You will always be able to find a page by appending the URL alias entry in the url_alias table to the site’s domain name.

WordPress has a different mechanism for creating URLs. Rather than relying on database entries, it generates rewrite rules and builds the permalink dynamically depending on your permalink settings. WordPress’ closest equivalent to the Drupal url_alias is its permalink slug stored as the post_name in the wp_posts table. Under my standard Drupal to WordPress migration, I migrate over the Drupal aliases by converting them into WordPress post name slugs. (See the table mapping in a separate article, Drupal to WordPress migration: posts table mapping.) If you have the Post name structure set in the WordPress Permalinks Settings, you’d then find the Project April page at either http://example.com/?p=28 or http://example.com/april/. Note that this would cause an SEO problem because the new WordPress link does not match the old Drupal link.

WordPress wp_posts table
WordPress wp_posts table

We would have to do some extra work to solve this problem. For example, if the april node was a page, we could create and link to a parent Projects page to create the Drupal http://example.com/projects/april structure. Alternatively, if it was a post, we could create a projects category or tag and set the Category base or Tag base setting. We could also create .htaccess redirects or use one of the many WordPress redirection plugins. The exact solution would depend on your project’s requirements.

Aside from the differences in how URLs are stored and generated, you should also be aware of WordPress permalink constrains. These will have a big impact on the amount of work needed to preserve your Drupal SEO when migrating to WordPress. I’ll briefly summarise them below.

  • The Drupal URL alias has a 255 character limit but the WordPress the post_name field stores only 200 characters. Make sure to keep track of any truncated posts names and create a corresponding redirect.
  • Since there’s no WordPress equivalent of the Drupal url_alias table, you’ll need to decide which alias will be converted into the post name. You should create separate redirects for the other aliases.
  • WordPress slugs which create the permalink are essentially a URL-friendly version of the post title. WordPress automatically cleans up the post title to create slugs for new content but you may encounter problems when migrating Druapl aliases into slugs. Characters that would be valid within a Drupal alias are invalid as a WordPress slug. For example, you cannot have forward slashes, accented characters and quotes in your WordPress slug. You’ll need to clean up and keep track of any problem aliases, otherwise WordPress will not be able to serve the page.
  • As previously mentioned, under Drupal you will always be able to find a page by appending the URL alias entry to the site’s domain name. WordPress does not store any records of its URL structure. You will end up with broken links and a potential SEO nightmare if you change the Permalink structure settings without consideration.

Remember your Drupal taxonomies

It’s easy to forget Drupal’s powerful taxonomy system is capable of generating listings that attract valuable traffic. Use webmaster tools to audit your site traffic to pick up on any such listing pages. Unlike Drupal which allows for multiple vocabularies, WordPress only offers one set of categories and tags out of the box. Replicating your Drupal taxonomy listings in WordPress may take considerable development but a quick fix may be to manually replicate the important listings pages. Obviously the size of your site will dictate if this will be feasible.

Menu and breadcrumb navigation

Menu structure and breadcrumb navigation is often an important part of your SEO. Ensure that your selected WordPress theme both supports breadcrumbs (some don’t) and the same type of breadcrumbs e.g. hierarchy, attribute and history-based breadcrumbs.

Migrate metatags generated by Drupal metatag modules

Also remember that you may have installed modules that generate metatag information contributing to your SEO. Export these from the relevant Drupal table and import them into the WordPress database using the format for your preferred WordPress metatag plugin. For example, if you used the Drupal metatag module and would like to use the WordPress Add-Meta-Tags plugin, you’ll need to extract data from the metatags table and insert them into wp_postmeta table as a meta_key and meta_value pair. Keep in mind that some investigative work will be necessary to find out how your preferred modules and plugins store their data.

Search engine visibility

WordPress has a setting to discourage search engines from indexing site. It can be found in Settings > Reading > Search Engine Visibility. It’s normal to have this checked during development but make sure you disable it when launching.

Load speed

WordPress, in general, requires fewer hosting resources than Drupal. You could very well find that a slow site on an under-performing server running Drupal becomes more responsive under WordPress. Don’t take this for granted, however. Use the migration as an opportunity to make improvements. Thoroughly vet plugin candidates to make sure they’re not pulling in third-party scripts that will increase page load times. Also avoid bloated page-builder themes. In my experience, these can be terrible for load speed as they try to cram in every conceivable bit functionality, thereby drastically slowing down what could have been a nimble site.

Preserving SEO during a Drupal to WordPress migration can be lots of work

As may have gathered by now, the amount of work and budget needed will reply on many factors. It’s not possible to prescribe what will be necessary for your site without in-depth detail about your configuration and requirements. Nevertheless, I hopefully will have given you enough information to get started with planning an approach.

A little plug to keep the lights running. If you think all of this work is too much trouble, please consider hiring me for your Drupal to WordPress migration project.

Drupal to WordPress migration service

Any Drupal version · All content · Custom content types · SEO · Plugins

If you’re not sure how to make the appropriate changes or would simply like someone else to do the work, please request a quotation for my Drupal to WordPress migration service.

Get a quote

One-way photo courtesy of and copyright Free Range Stock, photographer: Gratisography / Ryan McGuire

Yojimbo to Tomboy Notes migration tool

I’m a huge fan of Bare Bones Software’s Yojimbo, an extremely useful tool for keeping information organised. It has been one of my most important applications since around 2008. I rely on Yojimbo as my ‘Anything Bucket‘ to save scraps of information, from code snippets and troubleshooting notes to project logs and research sources. A downside is that it’s only available for Apple Mac OS X and therefore was a factor in tying me to the Mac OS X platform.

hicolor_apps_256x256_tomboyWhen I started moving back to Linux for day-to-day development work, finding a Yojimbo replacement was a top priority. A colleague pointed me towards the GNOME project’s Tomboy application which runs on Linux, Unix, Windows, and Mac. Tomboy is a basic though perfectly usable cross-platform alternative but of course, I still needed to find a way of migrating my old Yojimbo notes.

Fortunately, Yojimbo has a sharing feature called Sidekick that exports your data to a set of web pages. Digging in to the Tomboy Note XML format showed me that Sidekick together with a bit of Python and some BeautifulSoup magic would provide a quick solution. I threw together pyYojimbo2Tomboy which I’m releasing under the The MIT License on GitHub in case anyone else needs it.

Keep in mind that Sidekick does not export the Yojimbo note metadata, like tags and modification times, but you can to migrate the title and note body over to Tomboy. Time permitting, I would like to find a way to save the extra metadata in a future version.

Though Bare Bones Software hasn’t released any updates and new features in a while, I still highly recommend Yojimbo for anyone on Mac OS X who needs an information organiser. It’s a little dated and doesn’t offer modern features you’d expect like an easy way to sync to the cloud and across devices. Personally, I find this one of Yojimbo’s strengths. An app in 2016 that doesn’t keep pestering you to push your information to some remote data centre with questionable privacy policies is somewhat refreshing.

Hopefully having a way to export data to a multi-platform open source alternative will reassure anyone worried about getting locked-in.

Download pyYojimbo2Tomboy

GitHub-Mark-64px

Post-migration steps: what to do after a Drupal to WordPress migration project

From time-to-time I get clients who ask me to only export the content to a WordPress database, after which they’ll complete the remaining setup themselves. If this applies to your project, you can use these migration notes to help get your new WordPress site running properly.

Import the database dump file

Please see these notes for importing the WordPress dump file.

Administrator credentials and email address

I will have changed your content management system (CMS) administrator password and email address to help with debugging. It’s important that you change these to your own as soon as possible.

Drupal and WordPress user passwords are encrypted so I won’t be able to view them. However, for your peace of mind, I recommend that you ask all your users to reset their passwords after your new WordPress site is live.

Server credentials

Please remember to change any database, (S)FTP, SSH server and control panel credentials you may have given me.

Migrating to a live server

I perform most Drupal to WordPress migrations on a development server. For help on how to move WordPress to your live server, please see: WordPress Codex: Moving WordPress.

Common errors after moving to a live server

Please see below for some common errors you may experience after migrating your new WordPress site to a new server.

Incorrect domain in URLs

WordPress stores domains in the database. If you performed the migration on a local or development server, there’s a good chance that the links will be incorrect after migrating to your live server. Use the Interconnect IT utility to run a search and replace on your database. This will also correct changed database prefixes.

More information can be found on the interconnect/it Search Replace DB page.

“You do not have sufficient permissions to access this page”

If you receive this error after logging in to your new WordPress installation, it’s possible that the database prefix on your new WordPress site is not set correctly. This may happen if you move your WordPress installation to a host that uses a different database prefix.

Try running one of the queries below. Replace wp_new_usermeta, oldprefix_ and newprefix_ as appropriate.

Option 1:

UPDATE wp_new_usermeta SET meta_key = REPLACE(meta_key,’oldprefix_’,’newprefix_’);

UPDATE wp_new_options SET option_name = REPLACE(option_name,’oldprefix_’,’newprefix_’);

Option 2:

update wp_new_usermeta set meta_key = ‘newprefix_usermeta’ where meta_key = ‘wp_capabilities’;

update wp_new_usermeta set meta_key = ‘newprefix_user_level’ where meta_key = ‘wp_user_level’;

update wp_new_usermeta set meta_key = ‘newprefix_autosave_draft_ids’ where meta_key = ‘wp_autosave_draft_ids’;

update wp_new_options set option_name = ‘newprefix_user_roles’ where option_name = ‘wp_user_roles’;

Please note that these queries may not work for you. Success depends on your specific setup.

For more information, please see the following pages:

Further help

I’ll be very happy to provide support you if have difficulties after migration. For a quotation, please contact me. I also offer customised hosting and maintenance packages. Please ask for details.

Importing your WordPress dump file after a Drupal to WordPress migration

If you hired me to run a content export only, you’ll be responsible for setting up WordPress on your own server. Here are some notes to help you with importing the migrated WordPress database.

Import the database dump file

I will deliver either a MySQL database dump file or login credentials to the phpMyAdmin control panel for your project. The first thing you’ll need to do is import the WordPress database into your hosting environment.

Update the database for your domain

WordPress stores domain settings in the database. Since we run the migration and testing on a development server with a temporary sub-domain, you’ll need to update the settings to match your live domain. The easiest way to do this is to use a search and replace utility by Interconnect IT.

It’s pretty straight forward and only takes a few minutes. In the search and replace section:

  • Search for: the domain for your test server
  • Replace with: the domain for your live server

Change the login credentials

I use my own admin email address and password during the migration. For security, please change the administrator user details for your live site. After updating the domains, go directly to the login page to make additional adjustments.

  • http://YOUR-DOMAIN/wp-login.php
  • username: [Your username]
  • password: [Your password]

Your temporary administrator username and password will be sent separately.

Set your WordPress theme

Set the WordPress theme to one that you have installed. I use one of the standard WordPress themes for the migration. However, if the new WordPress site isn’t set to use to a theme you have installed and configured, you may get a blank screen while browsing the site.

  1. After logging in as admin, go to Dashboard > Appearance > Themes.
  2. Select the theme you want to use.

Handling Drupal terms during a Drupal to WordPress migration

When migrating Drupal terms into WordPress, it’s important to understand exactly what terms are and how the two systems handle categorising information.

A primer on Drupal taxonomies

One of Drupal’s most powerful features is its ability to organise content with taxonomies. Unfortunately, the taxonomy system is also notorious as one of the trickiest things about Drupal for beginners to understand. You can find a more detailed explanation here but essentially, a taxonomy is the practice and science of classifying things. In content management terms, you would mostly use taxonomies to organise and categorise articles or posts.

Taxonomies in Drupal uses the concept of vocabularies and terms. Terms are just a list of words that describe a particular type of content. They’re grouped together into vocabularies, which can be thought of as ‘containers’ for a set of terms. Vocabularies may be assigned to any content type. Drupal allows you to arrange the terms within a vocabulary using a parent-and-child hierarchical structure or they can be a flat list, with each term being on the same level as the others.

You can have many vocabularies in Drupal, each containing any number of terms. Vocabulary names must be unique and you cannot have duplicate term names within a vocabulary. It’s possible, however, to have the same term name appear in different vocabularies. Fig. 1 shows an example Drupal taxonomy with three vocabularies, Music, Movies and Books. The Movies and Books vocabularies both have the term Sci-Fi.

An example of Drupal vocabularies and terms
Fig 1: Drupal vocabularies and terms

For more information about the Drupal taxonomy system, please see Organizing content with taxonomies.

WordPress categories and tags

WordPress’ system for organising content is simpler. You have the option of categories–which can be hierarchical–and tags which are flat, or non-hierarchical. In general, categories in WordPress are used as a way of broadly organising posts and tags are used for more detailed descriptions.

Unlike Drupal, where you can have many containers in the form of vocabularies, a standard WordPress installation offers one container for categories and one for tags. Also as standard, categories and tags can only be assigned to the WordPress post content type. A WordPress developer can extend this by creating custom content types with their own categories and tags.

Fig. 2 shows show you’d organise the Music, Movies and Books categorisation in WordPress.

WordPress categories and tags
Fig. 2: WordPress categories and tags

Migrating Drupal terms as WordPress categories and tags

When running a Drupal to WordPress migration, we need to map Drupal’s more complex multi-vocabulary taxonomy system into the simpler WordPress model of categories and tags. How we do this depends on how you want to organise your new WordPress site. For example, we can:

  • convert Drupal vocabulary names into WordPress categories and Drupal term names into WordPress tags;
  • convert Drupal terms into WordPress categories and sub-categories;
  • vocabularies and their associated terms.

It’s all up to you and we figure this out during the requirements gathering stage of the project. For many sites, converting Drupal vocabulary names into WordPress categories and Drupal term names into WordPress tags, as shown in Fig. 3, seems to be the most sensible option. The important thing to know is that the migration may require us to ‘collapse’ or combine your taxonomies.

Merging Drupal and WordPress taxonomies
Fig 3: Merging Drupal taxonomies into WordPress

Since WordPress doesn’t support duplicate category or tag names, another thing to consider is how to handle any duplicate Drupal terms. Normally, the easiest solution is to append a unique number so that you can filter them out post-migration. We can do some clever merging and re-assigning of terms to posts but frankly, it’s probably not worth incurring the extra fees. Unless you have a great number of duplicates, you can probably do the job yourself quite easily via the WordPress Dashboard controls.

Organising your categories and tags in WordPress

Now that we know what’s involved in converting Drupal’s taxonomy over to WordPress, the next obvious question would be, “What’s the best way to structure categories and tags in WordPress?” While I cannot prescribe exactly how you should organise your site, I can point you to this excellent article so you can decide for yourself: Categories vs Tags – SEO Best Practices for Sorting your Content. Generally you should only have a few categories, maybe five or ten in total. Any more and they can become unwieldy and difficult to manage. These categories will reflect the main themes of your site. Tags can then further describe the details of each post and link specific topics together. You can have any number of tags.

The chances are that you probably want to avoid any drastic changes to the site structure when migrating from Drupal to WordPress. A simple mapping of vocabularies to categories and terms to tags is usually the closest equivalent in WordPress.

Getting started with a Drupal to WordPress migration project

A Drupal to WordPress migration can sound daunting, especially if you have a large or long-established site. From my experience, a migration project is actually not very difficult in terms of technical challenge. It can, however, be time-consuming, tedious and sometimes finicky with the data mappings. It’s my job to make the process easy for you.

To help with this, I write custom scripts to automate the bulk of your content migration. Once we have most of the data transferred, we can refine different aspects of the new WordPress site until you feel the job is done. These scripts save time by allowing us to repeatedly run the migration steps after building-in layers of improvements.

The thing to remember is that it’s often unnecessary to make an exact copy of your Drupal site in WordPress. We only need to prioritise the highest value content and functionality. Following the Pareto principle, or the 80–20 rule, 80% of your site’s value may come from only 20% of what’s in your Drupal installation. We can expend time and budget on getting everything into WordPress but it might not be worth the investment. The migration is therefore be a good time to clean-up your site of any un-needed bloat. Your main challenge during the migration project is to understand which parts of your Drupal site is valuable so you can instruct me on what to convert into WordPress.

Questions to define migration requirements

To help focus your efforts at the beginning of your Drupal to WordPress migration, here’s list of questions to ask yourself or your content management team:

  • Which content types do you want to migrate?
  • Which of the above content types should be converted to WordPress pages and which should be converted to WordPress posts? If you’re unfamiliar with the differences between posts and pages, see Post vs. Page on the WordPress support site.
  • Are any custom WordPress content types required?
  • Do you want to export some Drupal vocabularies or terms as WordPress categories? Generally, you should have relatively few categories and the remaining should be exported as WordPress tags.
  • Do you want to migrate comments?
  • Do you want to migrate authors?
  • What should be the WordPress default category?
  • What are your search engine optimisation (SEO) requirements?
  • Do you want to convert your existing design into a WordPress theme, do you want to design new theme or will you be happy with a ready-made theme?
  • How much of the Drupal site’s functionality can be replicated by existing WordPress plugins? If you’re willing to be flexible, it might be unnecessary to build any custom plugins

What’s needed to get started

Many of the above are simply things to think about during the early stages of the project. We won’t need answers to them immediately. To get started on a Drupal to WordPress migration, just send me the following:

  1. A MySQL dump file or access to your database.
  2. How you want to divide up the content types into pages and posts.
  3. How you want to divide up the terms into categories and tags.

Once we’re underway, I will guide you on what’s needed for each step of the process.