When working on a Drupal to WordPress migration project, I like to migrate into a set of intermediary WordPress tables that live in the Drupal database. These are working tables where I can run various scripts to process and clean up the content before exporting to a working WordPress installation. It’s not necessary to do this but I find it convenient to run scripts on the same database rather than deal with two separate database connections.
Note that some people suggest renaming the table prefixes to improve security. My use of the table prefixes is simply to create temporary containers for the migration. While non-standard prefixes might help prevent ‘script kiddie’ attacks, I find it isn’t worth the disadvantages that come with this sort of security through obscurity (or more precisely, security through minority) approach. Here are two articles give a deeper explanation of topic:
SQL queries to change the WordPress table prefixes
You can start with a freshly installed WordPress database. Dumping this and importing to your Drupal migration database will give you all the tables with the correct WordPress schema. I use the acc_ prefix but you can use whatever you want.
Rename the tables with these queries:
RENAME table `wp_commentmeta` TO `acc_commentmeta`;
RENAME table `wp_comments` TO `acc_comments`;
RENAME table `wp_links` TO `acc_links`;
RENAME table `wp_options` TO `acc_options`;
RENAME table `wp_postmeta` TO `acc_postmeta`;
RENAME table `wp_posts` TO `acc_posts`;
RENAME table `wp_terms` TO `acc_terms`;
RENAME table `wp_termmeta` TO `acc_termmeta`;
RENAME table `wp_term_relationships` TO `acc_term_relationships`;
RENAME table `wp_term_taxonomy` TO `acc_term_taxonomy`;
RENAME table `wp_usermeta` TO `acc_usermeta`;
RENAME table `wp_users` TO `acc_users`;
Testing the migration results
If you need to point a WordPress installation to these tables for testing, you’ll need to do two things:
Update the $table_prefix setting in the wp-options.php file
Update the options and usermeta tables
Updating the $table_prefix setting in the wp-options.php file is straightforward. Open the file and edit the line:
$table_prefix = 'acc_';
In WordPress, prefixes are saved as entries in the options and usermeta table. Check for entries containing the prefix:
SELECT * FROM `acc_options` WHERE `option_name` LIKE '%wp_%';
SELECT * FROM `acc_usermeta` WHERE `meta_key` LIKE '%wp_%';
When you have all the entries, update them with the new prefix. The query will probably look something like this:
UPDATE `acc_options` SET `option_name` = 'acc_user_roles' WHERE `option_name` = 'wp_user_roles';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_capabilities' WHERE `meta_key` = 'wp_capabilities';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_user_level' WHERE `meta_key` = 'wp_user_level';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_user-settings-time' WHERE `meta_key` = 'wp_user-settings-time';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_user-settings' WHERE `meta_key` = 'wp_user-settings';
UPDATE `acc_usermeta` SET `meta_key` = 'acc_dashboard_quick_press_last_post_id' WHERE `meta_key` = 'wp_dashboard_quick_press_last_post_id';
A word of warning: it’s easy to forget to change the prefixes back to match the final WordPress installation. If you do, the WordPress user accounts will have problems, such as the Dashboard controls not being visible after logging in. Because of this, I tend to have a separate testing installation that gets an import of the working tables.
If you’ve ever migrated a WordPress site, either to another URL or for a Drupal to WordPress migration project, you’ll know that WordPress stores the domain name in its database. This means you’ll have to jump through some hoops when moving WordPress to another environment. A critical step is to update the database to reflect the new domain. My favourite tool for this used to be the database search and replace script from interconnect/it. The script is PHP-based so runs on all environments that host WordPress. I now prefer WP-CLI’s wp search-replace command when on my own development environment, or for client hosting that supports it. Nevertheless, interconnect/it’s tool is still my fall-back option for clients of my Drupal to WordPress migration service since many use hosts that don’t offer command-line access.
In nearly all cases, updating the siteurl and home fields in the wp_options database table achieves the bare minimum to get the site working after migration. Running a search-and-replace across the WordPress database (in particular, the wp_posts table) will resolve broken links containing absolute URLs.
wp-admin still redirects to the old site after updating wp_options?
Once-in-a-while, I’ll encounter a migration project where wp-admin still redirects to the old site even after running through the obvious steps of:
updating the database;
clearing the browser cache;
clearing the server cache.
It happens very rarely so I have yet to discover the cause. I suspect it’s something to do with sites that had a caching plugin installed, such as W3 Total Cache.
If you ever find yourself in this situation, the best workaround is to add the following two constants in wp-config.php:
This isn’t a nice long-term solution but it should at least enable you to log in for some basic site administration. Once you’re able to log in to the WordPress Dashboard, disable any caching plugins after first clearing their cache.
Attaching media the WordPress Media Library are one of those things that many clients don’t realise can add lots of time to a Drupal to WordPress migration project. The reason is a little detailed and involves some knowledge of WordPress’ inner-workings.
When you upload a file to the WordPress Media Library, WordPress does some magic behind the scenes and creates different bits of metadata. If you upload, say, an image, it creates thumbnail versions of the image based on the settings in Settings > Media Settings > Image sizes. It also adds a bunch of serialized data in WordPress’ attachment table (wp_attachment_metadata). If you get this information wrong, displaying attachments will fail. For example, Featured Images in posts will not display because the theme has no reference for which thumbnail to display when a post is delivered.
Because of the necessary metadata that needs to be generated, attaching media to the Media Library is therefore not feasible through a database migration using purely SQL queries. If you’d like media attached, a separate custom script is needed to pick up all your files under the Drupal file directory and attach them using different mechanisms, such as XML-RPC, WP-CLI or a custom plugin. It adds to the cost so many of my clients see this as a ‘nice-to-have’ rather than a necessity.
As an alternative, my clients and I have come up with different ways to handle the Drupal files and media items when migrating to WordPress:
Leave the Drupal file directory path intact on the WordPress installation server. This is the easiest option which most clients take because it’s cheaper. No changes are needed to the post and page content because the already embedded path will still be valid. However, we may have to make changes to the WordPress theme so that it knows the path to legacy Drupal file path. Future uploaded files will be fine but legacy posts will point to the Drupal file paths. This is not nice and a bit of a hack but it’s a cheap and quick solution. Media items will not appear in the WordPress Media Library.
Move the Drupal file tree to the WordPress wp-content directory. We then need to do a search-and-replace to amend the link path within the post content. There’s a small risk of broken links if we don’t get the search pattern right but generally it’s a straightforward process. Media items will not appear in the WordPress Media Library.
Use a plugin or custom WordPress code to attach files from an external URL. The client’s developer normally handles this work in-house so I can’t offer much feedback on this method. It seems to work reasonably well.
Manually upload all the files to the WordPress Media Library. This is of course the most tedious and time-consuming option. Nevertheless, those with smaller sites or have gone this route. If you’re trying to save on budget and have lots of time on your hands, you might want to consider it.
Graphic courtesy of and copyright morguefile.com user Ladyheart
In a previous post, I wrote about exporting data from Bare Bones Software’s Yojimbo and using Tomboy as an alternative. My migration script scraped the content from Yojimbo Sidekick and wrote XML files in Tomboy Note format. Though there were some drawbacks, such as tags being unavailable in Yojimbo Sidekick, I thought Tomboy’s search feature would be adequate. A couple of weeks trialling Tomboy proved that it wasn’t going to be a Yojimbo killer. Tomboy can’t compete in terms of overall usability and though it’ll work on my Linux and OS X machines, note synchronisation takes some setup that didn’t warrant further time investment.
Once again I turned to WordPress as an easy solution. There’s a risk of seeing WordPress as my hammer for everything that looks like a nail but it has taxonomies, a reliable-enough search functionality and being web-based, works across all my devices. I’m very familiar with the platform and have already built up my own set of tools to export and migrate content. Why not use WordPress? Getting data out of Yojimbo was another issue. The quick and easy Yojimbo Sidekick route already proved inadequate so it was time to dig in and reverse engineer Yojimbo’s storage mechanism.
Analysing and exporting the Yojimbo database
‘Reverse engineering’ turned out to be too lofty a term for the task. It was obvious after quick look that Yojimbo uses an SQLite database to store information. Firing up DB4S to analyse the tables and bit of analysis revealed the tables, columns and relationships that are important for exporting our notes. The columns are a little oddly named but it didn’t take long to figure out the necessary fields for migrating to WordPress.
This looks like an ID
The Yojimbo note title
The ID to the Z_15TAGS relationship table
The Tag ID
The tag name
String for unencrypted item
It became a simple matter of tweaking my Drupal to WordPress migration queries to extract from the Yojimbo database and create WordPress posts. Unlike with the Tomboy Notes route, it was possible to recreate the tags, which is what makes Yojimbo so useful. One drawback is that I haven’t figured out how to extract encrypted notes but I didn’t use Yojimbo to store important encrypted information so that wasn’t a priority.
WordPress as a Yojimbo alternative
Using WordPress as a Yojimbo alternative might not work for everyone but after several months use, I’ve found it to be an excellent cross-platform replacement. The installation and database runs on a NAS drive connected to my local network so is accessible to all my devices. Standard WordPress taxonomies, search and plugins makes content management simple once you’ve imported the Yojimbo content. In fact, by migrating away from Yojimo, I’ve ended up creating my own full-blown personal knowledge management system.
If you need to export your Yojimbo notes to a cross-platform alternative, give WordPress a try. You can grab my migration script from GitLab but please keep in mind that it was a quick hack to achieve a specific one-time objective. You may need to hack it to suit your own setup.
Delicious is one of those services that few people know about but loved (and probably hated in equal measure) by those who use it. Their offering is easy to grasp: Delicious is a social bookmarking service that lets you “Save, organize, and remember the links you find interesting or useful around the web.” I’m sure you’ve been in a situation where you’ve tried to remember the source for a particular factoid or needed to cite an article but lost track of the link. The obvious place to save links is in the browser bookmarks but this quickly becomes unwieldy if, for example, you’re doing research on lots of different topics. Unless you install bookmark syncing software, browser-based bookmarks are also cumbersome if you run different browsers and computers. I used Delicious to store thousands of links over the years, all of which where tagged and easy to call up when needed. They say in their about page, “Delicious remembers so you don’t have to. It’s easy to build up a collection of links, essentially creating your own personal search engine.” It was great at that and absolutely invaluable if, like me, you have a poor memory. Programmers, bloggers, researchers, anyone who needs to save a link for future recall needs something like Delicious. Founded in 2003, it’s also a veteran in an industry where anything that lasts more than a couple of years is considered successful.
Sadly, this glowing opening isn’t to recommend the service. You’d think its longevity would be a sign of a rock-solid, mature platform but no: Delicious’ loyal user-base has been rewarded with outages, lost data and broken features. That people persisted despite years of problems shows just how useful a service it provides. When the site went down again earlier this year (2016), I decided it was time to make a move. Unfortunately I couldn’t find an alternative trustworthy enough for several years-worth of carefully curated bookmarks. Free web services are notorious for disappearing into a black hole with all your data. As the saying goes, you get what you pay for.
After a long search, I began to realise there wasn’t anyone out there who could be trusted. This isn’t just Delicious and bookmark curation problem though. These past few years has shown that The Cloud hasn’t lived up to its promise. Data breaches, surveillance, data collection, outages, and catastrophic meltdowns; we can’t really trust a third-party service, especially if they don’t have a clear business model. I grudgingly conceded that cobbling together my own solution was the only option.
The rest of this post describes my solution, why I chose WordPress and how you can convert your WordPress site to host a personal bookmarking service. This will be valuable even for those who’ve never used Delicious but would like a way to curate links.
Exporting the bookmarks
Before doing anything else, the bookmarks need to be in form that’s easy to manipulate. Delicious had a feature to export all your links, tags and notes into a HTML file Netscape bookmark format. At the time of writing this has been ‘temporarily disabled due to server load’ (really, Delicious?). Fortunately I was in the habit of making frequent backups due to Delicious’ unreliability so my export file was only a few weeks old. I threw together a quick Python script called DeliciousPy to scrape the file and save the results into a local MySQL database. Feel free to grab the source over on GitLab.
It was a one-use tool so a little rough and undocumented. (Sorry, it wasn’t written with the intention of public release!) Anyone with basic Python knowledge should be able to easily figure out how it works. Essentially, I parse the Delicious export file using Thibauld Nion’s Netscape bookmark parser that is part of his Water On Mars! project. Everything is then inserted into three MySQL database tables:
bookmarks: the table storing bookmark title, url, note, creation time and privacy flag.
tags: all the tags associated with the Delicious bookmarks.
tag_relationships: the relationships between the bookmarks and tags.
After doing a pip install to install the requirements, you run DeliciousPy with the command: $ ./deliciouspy.py -p /path/to/delicious/export_file.html
Running the script exports:
Getting the Delicious bookmarks into a database opens up options for importing the data into a different platform. You can roll your own custom tool or use a content management system. I chose WordPress.
WordPress as a personal social bookmarking service
My wish list for a Delicious replacement was short:
Save links with accompanying notes.
Tagging and search to easily call up previously saved links.
Simple, bare-bones functionality free of unnecessary features.
Set links to private for personal research or public for sharing.
Avoid relying on a third-party service.
It didn’t take me long to settle on WordPress. I already have expertise with importing data into WordPress from my Drupal to WordPress migration service. It’s grown into a mature content management platform with a huge user and developer base, apparently powering 25% of all websites. It has excellent documentation, can run on a standard hosting package, has a simple user-interface and a flexible taxonomy system. The code is open source so if you self-host the site, you won’t run into the third-party service problems of getting locked out of your data. WordPress has all the components for a home-brew bookmarking service.
My Bookmarks plugin
I’d originally hoped to avoid building my own plugin but none of those in the WordPress Plugin Directory suited my needs. Most were too feature-packed and I wanted something lightweight: just have some way of saving and tagging links for later retrieval. Putting together simple bookmark storage isn’t difficult: ‘bookmarks’ can be nothing more than a post with a single custom field to store the URL. To keep them separate from standard blog posts, I created a custom bookmark content type and packaged it into a plugin called My Bookmarks. (I’m not very imaginative when naming things.)
Delicious has a social bookmarking aspect that lets you publish your links, follow other users and discover pages those in your network have saved. Social bookmarking wasn’t compelling for me so I didn’t attempt to include this functionality. In my opinion, publishing the links on a blog is social enough and any anyone who wants to ‘follow’ can subscribe to the RSS feed built into WordPress.
Bookmark sharing id controlled through the normal WordPress Visiblity setting. Set to Public so the bookmark gets posted on your blog; set to Private so it’s visible only after logging in to WordPress.
One great thing about Delicious was a handy bookmarklet that allowed you bookmark your browser’s current open page. Rather annoyingly, this feature broke for me at some point after it was acquired by one of its many owners. I implemented this functionality in the form of a WordPress-style Press This bookmarklet. Code from the now seemingly abandoned Linkmarklet plugin by Jonathan Christopher does most of this work.
Experience so far
The My Bookmarks plugin hasn’t been published to the WordPress Plugin Directory as of now. I’m still trialling it to make sure everything works as expected before releasing but you’re welcome to grab the source and tinker with it for your own needs. Note: As of December 2016, the My Bookmarks plugin is temporarily hosted over on GitLab.
Currently the plugin is installed on my internal WordPress-based Knowledge Management System on my local network. It serves up thousands of bookmarks from around 10 years worth of links. I replicated everything that made Delicous so useful for me without all the drawbacks of a third-party service. So far so good. The bookmarks that I’ve spent years curating are now fully under my control—and under my responsibility. Backups are still important but bookmarks are now included with my usual automated WordPress database dumps. All-in-all, I think it was a good move to finally migrate from Delicious.
Performing a Drupal to WordPress migration can be very complex, especially if you have many content types. You’ll make the process easier if you create a migration mapping document beforehand. A common migration mapping is to convert Drupal pages to the WordPress page type and Drupal stories to the WordPress post type. However, many Drupal sites also have custom content types so the mapping won’t always be obvious. Will they be converted to WordPress pages or posts? Do they have custom fields? How about views and panels? Perhaps you may need to develop a new WordPress content type to support them.
Your Drupal to WordPress migration mapping document will give everyone involved a clear idea about how the Drupal content will be migrated to its equivalent in WordPress. If you’re running the migration yourself on a simple blog or company site, there might not be much need to spend the extra effort but sometimes running through the process uncovers aspects of the site that you may have overlooked. I’d say this is vital for migrations where you’ve hired someone else or if you have a content-heavy or news-based site. Not only will the document make it easier for someone to quote for the job, you’ll also have a specification for reference when checking the results post-migration.
Creating the content mapping
Creating the mapping needn’t be complex. The easiest way is draw up a table with at least two columns. On the left column, list down all your Drupal content types. Next write down equivalent WordPress content type on the right column for each row of Drupal content types. You might find it helpful to have a third column for writing notes, such as whether or not you need do develop a new custom WordPress content type. If your Drupal content type has custom fields, simply add rows below each type listing the fields.
Sample content mapping table
Developers responsible for the migration can also add additional sections specifying back-end table and field names where the relevant content can be found.
Creating the functionality mapping
Follow a similar procedure to create the functionality mapping. Instead of content type names, list down Drupal modules and equivalent WordPress plugins.
Preparing for your migration project
The migration mapping document will have helped prepare you for your project and provide you with a specification for the migration. You might also find the following articles useful:
If you do a lot of exporting and importing to different database servers, you’ll be familiar with the frustration of encountering MySQL import errors. Every so often when importing a WordPress dump file into a client’s database, I will encounter an Unknown collation error like the following:
Unknown collation: 'utf8mb4_unicode_ci'
Sometimes it will come up as:
Unknown collation: 'utf8mb4_unicode_520_ci'
This is caused by a difference in encoding types between the source and destination databases. It usually happens when you export from a newer MySQL database (MySQL 5.5.3 and above) which uses utf8mb4, then attempt to import into an older version using utf8. If you are importing from a dump file generated from a MySQL 5.6 database, you may get the utf8mb4_unicode_520_ci message. The 520 refers to MySQL’s use of Unicode Collation Algorithm 5.2.0. Unknown collation errors may also happen if you are trying to import a MariaDB database into MySQL. I tend to get unknown collation errors with my Rackspace Cloud accounts after Rackspace started offering MariaDB as a database option.
Ideally one would upgrade the older destination database but this isn’t always a realistic option. There are a number of discussion threads on the WordPress forum about what to do. Fortunately, many web hosting accounts have a phpMyAdmin interface which provides an easy work-around for the problem.
Format-specific options during a phpMyAdmin database export
Log in to your database server using phpMyAdmin
Make sure you select your database and go to the “Export” tab
Select the “Custom” radio button
Go the section “Format-specific options” and in the setting for “Database system or older MySQL server to maximize output compatibility with:” select MYSQL40.
Since many of my WordPress database migrations are under my migration service, I don’t always have control over the client’s platform. The phpMyAdmin export format method is often the simplest solution.
Side-effects of a character encoding downgrade
You might be wondering about the purpose of encoding types and if there will be any side-effects of downgrading. Character encoding allows support for a set of characters, such as the Western alphabet, Asian scripts and non-alphanumeric symbols. Older utf8 databases support a smaller set of characters whereas utf8mb4 includes emojis, musical notation and Chinese Han characters. If you’ve ever exported a website from one CMS to another and found random characters scattered throughout the copy, it’s because of an incompatible character encoding.
Solving the unknown collation error as described here could mean you’ll end up with unsupported characters after your site migration. However, as with many of my Drupal to WordPress migration clients, in all likelihood you’ll be migrating from an olderutf8 Drupal database to a newerutf8mb4-supported WordPress database. In this case, your old content will not have characters that will cause a problem after an encoding downgrade.
Any successful project requires careful planning and a Drupal to WordPress migration is no exception. If you haven’t already read my Drupal to WordPress Migration Guide, I recommend you first head over there to get an idea of what’s involved. It can be tempting to get straight to setting up WordPress, trying out new themes and experimenting with plugins. Nevertheless, some basic preparation beforehand will save you lots of work.
Website owners and administrators know their content is important but it’s often treated as 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.
Avoid problems by planning 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.
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
Just as in Drupal, the WordPress theme 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:
Redesign the WordPress site entirely.
Create a custom theme based on your existing Drupal design.
Use one of the many pre-made free or premium WordPress themes.
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.
When looking for an SEO specialist, keep in mind that the techniques for migrations aren’t that much different from SEO considerations during a site redesign. At a minimum, you should be looking for someone who has good grounding in:
Technical SEO auditing: This is to give you a baseline of how the current Drupal installation looks from an SEO standpoint. These audits will help figure out how to recover if you see a drop in traffic after the migration to WordPress.
User experience (UX) optimisation: User experience is a big factor in SEO. A change in the site structure will almost certainly affect user experience.
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:
How to access your server
What kind of content you have
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.
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:
On the server filesystem
Types of content include:
Static HTML files
Embedded media like videos, images and audio
User profile information
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.
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
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.
Send through secure channel e.g. password manager
What are the database login details of your hosting provider?
You’ll need these to export your Drupal database to perform the migration.
Send through secure channel e.g. password manager
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.
I know how to export my database to a dump file
I need help exporting my database to a dump file
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.
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
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
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
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
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
Do you expect to have multiple aliases referencing the same post?
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
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
“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.
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;
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.
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.
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 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.
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.
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.
WordPress permalinks have more constraints
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.
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.
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.