Blog

Migrating websites to a different content management system platform is incredibly complex but developers and site owners often underestimate the amount of work involved. Drupal to WordPress migrations can be especially tricky because they target very different types of users. You can quickly run into trouble if you start a migration project without considering some key areas.

My own migration project framework starts off with an analysis phase designed to discover as much as possible about the client’s needs and the impact on project resources. Over the years I’ve compiled a set of questions and considerations specifically for Drupal to WordPress migrations.

Developers and site owners can use this list to better understand their project’s scope. I’ve rather cheekily referred to it as The ultimate Drupal to WordPress migration checklist but in reality, it’s more of a working document that’s continually refined. The checklist is currently organised into three main areas that often concern my clients: understanding their migration requirements, auditing the existing Drupal site and addressing any SEO impact of the migration.

Migration requirements

These migration requirements will help you estimate a budget for your project.

List of terms to export as WordPress categories (remaining will be exported as tags)

Do you want to migrate comments?

Do you want to migrate Drupal users?

What will be your WordPress default category?

How do you want to handle the Drupal legacy file directory?

Are there any content sources outside of the Drupal database? (For example, static HTML files or external databases.)

What will be your WordPress permalink structure?

How do you plan to handle URL redirects?

Do you expect any data cleaning to be necessary?

Do you want me to install and configure WordPress on your server?

Do you want me to import the migrated database to your live server?

If any problems occur with your hosting provider during the migration, do you need me to troubleshoot?

Will you be redesigning your site or do you plan to convert your existing Drupal theme to WordPress?

If you plan to redesign your site, will you be using a ready-made theme or custom theme?

Who will be responsible for developing and configuring your WordPress theme?

Do you need to merge multiple domains or sub-domains into a single WordPress installation?

Do you need to merge content and configuration from an existing WordPress installation? (This may be necessary if you have already started developing the WordPress site prior to content migration.)

Is there an e-commerce component to the migration?

What are your SEO requirements? (We may need to complete the separate SEO To Do list.)

Drupal content audit

Understanding as much as possible about your Drupal installation will help you come up with a more precise estimate for your migration project. The content audit may take some time to complete but the process will give you a better idea of how much work will be needed to migrate your site.

Have you created a site map of your Drupal site?

What is the approximate number of Drupal nodes to migrate into WordPress. The number of Drupal nodes 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.

Please list the Drupal content types to migrate into WordPress. 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.

Please list your Drupal custom fields. As with custom content types, custom fields in your Drupal installation will need additional work to support them under WordPress. We will need to specify how the field content is stored in WordPress, for example, by setting post meta key strings or custom tables.

Please list your Drupal modules and site functionality. Can the functionality can be handled with existing WordPress plugins? Will you need to develop custom plugins?
Do you have blocks, views and panes with important content? Many Drupal sites display content in this way. Your SEO may be affected if you receive lots of traffic to pages with blocks, views and panes.

Have you installed Drupal modules that generate metatag information contributing to your SEO?

Do you have on-page optimization coded within the Drupal theme templates that we need to preserve? This will be important for SEO. Usually, on-page optimization embedded into the content body will be preserved during a migration.

Please briefly describe what to do with multiple aliases. Drupal supports multiple URL aliases for nodes. These will need to be resolved when migrating to WordPress. How we approach this will have an impact on your SEO.

Are there URL structures in Drupal that you need to preserve for SEO?

Are any Drupal taxonomies particularly important? Some sites have taxonomy listings that attract valuable traffic so this may be important for SEO. Note that 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 need additional development.

Please briefly describe what to do with duplicate terms. Duplicate Drupal terms can cause problems during a migration.

Please briefly describe what to do with problem terms. For example, WordPress has a 200 character limit for terms. Any Drupal terms longer than 200 characters will need to be truncated. This may impact SEO if you receive lots of traffic from term indexes.

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. On some sites, users have associated pages that may be important for SEO.

Please list and brief description of user roles. Your Drupal user roles may need to be converted into WordPress roles.

SEO

These are tasks for projects where SEO is a major consideration. If SEO is critical to your site, you should hire your own dedicated SEO consultant.

Do not be tempted to debug by editing the code as it’s not the source of the error. Your problem will very likely be that the siteurl option value in your WordPress database does not contain a valid entry. In this case, the error message is telling you that get_option() receives a WP_Error object rather than a string that it’s expecting.

To fix this:

First check the siteurl option to verify that the value is indeed incorrect. Run the following SQL:SELECT * FROM `wp_options` WHERE option_name = 'siteurl';

Some hosting providers restrict customers to a single SSL/TLS certificate per socket. (In simple terms, a socket is the combination of IP address and port number.) Since Apache listens to port 80 for non-SSL connections and port 443 for SSL connections on the same IP address, customers usually need a separate IP address for each certificate.

At the same time, you can configure Apache for multiple domains to share a single IP address using virtual hosts. Each virtual host gets its own port and Apache listens to this port, redirecting connections to the appropriate domain.

The combination of the above behaviours can sometimes cause complications when you install a single SSL Certificate on a shared IP address. Secure connections to port 443 of an IP address will be directed to the virtual host and domain assigned to that port. Thus, if you try to make a secure connection to a domain on a shared IP address, Apache will create a socket to the actual domain listening to port 443. Depending on your configuration, this domain may be a default virtual host or one that is explicitly set to listen to port 443.

The possible solutions depend on the types of configurations supported by your hosting provider. These include:

According to the Drupal Shell site, Drupal is the second most hated CMS platform. I think this sounds a little harsh and digging into the source on stackoverflow, we find that it’s actually listed as the second most dreaded platform. While perhaps more even-handed, I’m still not at all surprised as a large chunk of my business is made up of people migrating from Drupal to WordPress. To be fair, WordPress fans don’t have much to cheer. Their platform of choice appears as number three of the Content Management Platforms (CMS) listed. Still, Drupal had (has!) such a loyal following so why does it draw out such a reaction from respondents?

First-mover advantage

Let’s take a quick look at the history of the major CMS platforms currently in use. Drupal was, in the first decade of the 2000s, arguably the top CMS for building websites. It had first-mover advantage, having launched as an open source project in 2001—years before its contemporary competitors. Drupal 4 was released in mid-2002 and started appearing on most developers’ radar by around 2004–2005. Its only real competitor was Movable Type which offered simple blogging capability. WordPress was at version 1 in 2004 and was then also more of a blogging tool. Magento and Joomla would come around quite a few years later, launching in 2007 and 2009 respectively.

CMS version 1 release timeline

2001

→

Drupal
Movable Type

2004

→

WordPress

2007

→

Magento

2009

→

Joomla

I remember my first foray into Drupal development in 2003. A freelancer colleague kept raving about how great it was and that I should give it a try. (Incidentally, he subsequently became very active in the Drupal community and ended up having his theme bundled in with core.) At that time, I’d been hand-coding websites and building custom ‘site generators’. CMS platforms hadn’t taken off so people were coming up with their own solutions from managing site content. For example, I worked with a top-tier mobile operator in the early 2000s who asked me to build a web-based knowledge management that stored content in Microsoft Access and published static HTML on their intranet using VBA.

When Drupal came along, it captured the entire range of the market. Hobby sites, small businesses, small and large charities, multi-nationals all adopted Drupal because its flexibility.

Features for free

Eventually, my colleague’s insistence overcame my resistance to learning new technology. As you can imagine, Drupal, in comparison to hand-coding from scratch, was an absolute dream. I could now build feature-rich websites with login functionality, CRUD and custom layouts in maybe one-fifth of the time and cost. Like my colleague, I started raving about Drupal and began recommending it to clients and colleagues.

Drupal was without any doubt the most powerful website development platform available. Nothing else in the open-source market could touch it. It was also fun building websites with Drupal. You could get instant gratification by installing and playing with the many available modules. Every developer facing a deadline and budget loves features for free when the alternative is hours of coding and debugging. Features for Free is great…unless you have to maintain all those features. More on this later.

Similarly, site owners—who often don’t care that much about the technology—loved that their developer could deliver a widgety-thingamajig-feature at a reasonable price. They’d request some functionality and the developer would say, “Yeah, we can do that with Views.” “Yeah, there’s a module for that, no problem.” “Oh, no module for that but we can build one without a huge site overhaul.” It was great until, well…

The Drupal can of worms

Well, fast-forward to 2018 and nearly every Drupal site I encounter is a huge can of worms. Those great Features for Free aren’t so great when the modules have been abandoned. They’re not great when, years after installation, no-one remembers which module controls what and how everything ties together. Sure, documentation and well-commented source code commits are best practice. Perhaps enterprises can afford to maintain a stable of diligent developers. But many sites are cobbled together on a legacy of little to no budget and a revolving door of budget developers with varying skills.

Over time, each person adds their own hacks and disappears. No-one willingly runs updates and upgrades because who enjoys having a nervous breakdown? Run an update and risk a WSOD. Spend hours tracking down some obscure, unsupported and misbehaving module that’s absolutely crucial to the way this particular site works…for free? No thanks!

Fully-documented sites and well-specified upgrades are what everyone in the industry aims for. However, real-life tends to go something like this:

Site owner: Hey, remember that site you built for me a couple of years ago? I’d like to…Developer: mumble…mumble…upgrade to Drupal 5…mumble…price….Site owner: Hmmm, I’m good for now…kthxsbye…
A couple of years later…

Site owner: Hey, this guy built a site for me. I’d like to…Developer: mumble…mumble…upgrade to Drupal 6…mumble…price….Site owner: Price???!!! kthxsbye…

A couple of years later…

Site owner: Hey, I have this site…Developer: Erm…Drupal 7…rebuild the site…Site owner: What???!!! kthxsbye…

A couple of years later…

Developer: Oh, how many thousands of monies did you say is burning a hole in your pocket? Because, you know, Drupal 8…

Upgrades and backward compatibility

Of course, poorly documented, buggy and abandoned add-ons are all too common in the WordPress world. The big difference is backward compatibility. WordPress has been great with ensuring problem-free updates: you see core, plugin or theme updates available; you click Update Now; a few seconds (or minutes at most) later you’re done. You can move on with your day and not give it another thought.

In contrast, updating Drupal can ruin your day. (Or night if you’re scheduling the work during off-peak hours.) Drupal updates can go horribly wrong. During the pre-Drupal 8 days, it wasn’t out of the ordinary to spend hours of site rebuilding after one of the module updates took down the site. Which module? Well, you’d have some trial-and-error testing a series of modules one-by-one until you find the culprit. Updating Drupal is often a dreadful experience.

Sensible developers test updates on a development server first, then get the site owner to test on staging before rolling out to live. This is best-practice. Everyone should be following this workflow regardless of the platform. Yes, if there’s money for it. This effort comes at a price and many, if not the majority, of smaller businesses, not-for-profits and hobby sites just don’t have the cash. People have found that WordPress lets them cheat the recommended workflow. If they see updates they just go ahead and do it live because there are rarely any problems.

Core upgrades for major Drupal versions are another level of pain for the site owner. Drupal 6, 7 and 8 are all so different in architecture from previous releases that upgrading essentially means re-building the site from scratch. This is too much to expect for many. No wonder site owners would rather hobble along with their outdated duct-taped CMS.

The dread

Keeping Drupal up-to-date is expensive for the owner and time-consuming for the developer. Site owners dread to think about the fees. Maintainers dread jumping through hoops just to run simple module updates. Newly hired developers dread what they might find when they peek under the hood.

I started Another Cup of Coffee as a Drupal development shop because it allowed us to offer powerful functionality at a reasonable price. Years later, although I’m no longer in the business of building Drupal sites, I do remember the feeling of dread when time came to tinker with a mature installation. I have every sympathy for those who list Drupal as their second most dreaded platform. It seems that everyone feels The Drupal Dread, unless of course, they make lots of money from support.

Content migrations usually involve running complex MySQL queries that take a long time to complete. I’ve found the WordPress wp_postmeta table especially troublesome because a site with tens of thousands of posts can easily have several hundred thousand postmeta entries.

If your query ends up taking more than a few minutes to complete, you may encounter the following error:

Error Code: 2013. Lost connection to MySQL server during query

This happens because the connection between your MySQL client and database server times out. Essentially, it took too long for the query to return data so the connection gets dropped. The MySQL documentation suggests increasing the net_read_timeout or connect_timeout values on the server. If this doesn’t solve the problem, you may need to increase your MySQL client’s timeout values.

MySQL Workbench

You can edit the SQL Editor preferences in MySQL Workbench:

In the application menu, select Edit > Preferences > SQL Editor.

Look for the MySQL Session section and increase the DBMS connection read time out value.

Migrating a site from Drupal to WordPress and need a specialist? Please contact me for a quotation. Whether you’re a media agency who needs a database expert or a site owner looking for advice, I’ll save you time and ensure accurate content exports.

Here’s one that caught me out on a recent Drupal to WordPress migration. As is common with my projects, there were three parties involved: the client, an external development team and myself. The WordPress site was first built on the development team’s server, after which it was migrated to my local environment. When everything was ready for beta testing, we moved the site over to the client’s staging server on a newly activated account over at Kinsta. Eventually, we’d move it over to a live server, also hosted on Kinsta.

After some initial tests on staging, I found that deactivating and reactivating plugins would cause the site to hang and show a ‘504 Gateway Time-out’ error. This happened when re-enabling some but not all plugins.

I initially suspected some misconfiguration at the hosting end because there were some hitches with the newly create account. At the outset, the account’s server had an issue which Kinsta support needed to fix. For convenience, we’d also made use of Kinsta’s free site migration service. This is where they’ll migrate an existing WordPress site into their environment. Though it would have been easy enough for me to do, we thought to give it a try. In hindsight, this was a bit of a mistake. The site migration service itself was fine but it did end up causing some confusion. First, a miscommunication in the migration request caused them to create a temporary domain we didn’t want. They helpfully solved this by giving us a second temporary domain. However, they’d also upgraded everything to PHP 7 in the process. All of these issues were possible suspects for the time-out error but turned out to be red-herrings.

It took some time to pinpoint the cause behind the Gateway Time-out error. I do have to say that Kinsta support were very responsive throughout the troubleshooting process. They eventually put a senior engineer on the case who found the problem. It turned out the problem wasn’t to do with Kinsta at all. There was a leftover setting from the original development team’s server server. It was a valid format so didn’t cause an issue on either my local server or my staging server. However, it apparently can cause issues with plugins and did on the Kinsta environment.

What was the setting? The WordPress upload path directory was set to the development team’s server path e.g. /home/dev/public_html/sitename. Throughout the migration, I’d been doing a database search-and-replace looking for their development domain. Somehow, as the site moved from different servers, that server path string remained in the database, only to cause a problem when the site landed in the destination server on Kinsta.

I’m not sure if there would have been any way to have caught this problem earlier. It’s one of those obscure errors that are easy to overlook and take time to resolve. There’s also no practical way to do a database search-and-replace for every imaginable string. I’ll have to rack this one up to experience.

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.

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.

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.

Table: ZITEM

Column

Description

ZBLOB

This looks like an ID

ZNAME

The Yojimbo note title

Z_PK

The ID to the Z_15TAGS relationship table

Table: ZTAG

Column

Description

Z_PK

The Tag ID

ZNAME

The tag name

Table: ZBLOBLSTRINGREP

Column

Description

ZBLOB

ID

ZSTRING

String for unencrypted item

Table: Z_15TAGS

Column

Description

Z_15ITEMS1

Relationship ID

Z_25ITAGS

Tag ID

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.