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.
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.
“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.
UPDATE wp_new_usermeta SET meta_key = REPLACE(meta_key,’oldprefix_’,’newprefix_’);
UPDATE wp_new_options SET option_name = REPLACE(option_name,’oldprefix_’,’newprefix_’);
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:
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.
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.
After logging in as admin, go to Dashboard > Appearance > Themes.
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.
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.
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.
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.
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.
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:
A MySQL dump file or access to your database.
How you want to divide up the content types into pages and posts.
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.
In a Drupal to WordPress migration post by Sam Michel, reader Jean-Philippe commented that why he couldn’t find the tables mentioned. I started composing my reply but for some reason the page wouldn’t let me post.
Rather than waste the time it took to compose the reply, I thought it would be good to post it here instead.
This probably isn’t relevant to you anymore but I’m posting this for the benefit of anyone else who stumbles across your comment.
The tables names have changed in Drupal 7. ‘taxonomy_term_data’ and ‘taxonomy_term_hierarchy’ are all Drupal 7 tables. If you don’t see the tables mentioned in this post, it’s almost certainly because you don’t have Drupal 6 installed.
In Drupal 7, ‘term_node’ has been replaced with ‘taxonomy_index’.
I’ve started documenting the table mapping between Drupal and WordPress in a series of posts here: https://anothercoffee.net/drupal-to-wordpress-migration-posts-table-mapping/
Since I also used Scott Anderson’s SQL, anyone reading Sam Michel’s series might find it useful too. (Thanks to Sam and Scott!)
Drupal stores both node authors and comment authors in the users table. WordPress handles things differently. Page and post authors are stored in the wp_users table but comment authors are stored in wp_comments together with the comment data.
This is part three of a series of posts documenting the table mappings for a site migration from Drupal 6 to WordPress 3. For more information, please see the first article in the series.
Table mapping for WordPress comments
Converted from UNIX timestamp
Truncated to WordPress limit of 200 chars
A note about the different ways Drupal and WordPress store comment author information: Drupal stores comment authors in its users table alongside site users like node authors. In WordPress, comment authors are stored in its wp_comments together with the comment data. WordPress comment authors are not entered into the wp_users table.
Privacy & Cookies Policy
Traffic analytics cookies help me improve my website. They don't give me any personal information about you but feel free to opt-out by adjusting the settings below.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.