Drupal to WordPress Migration Planning
This section of the Drupal to WordPress Migration Guide, focuses on critical preparation steps for a successful transition, from content mapping to user migration strategies. I link to detailed checklists for content auditing, technical requirements, and maintaining SEO during the switch.
1. Before you start a CMS migration project
Drupal to WordPress migration projects are often complex and need to be handled carefully. Rather than jumping in head-first, take some time to plan your approach. Before starting the migration project itself, I highly recommend reading my guide, How to prepare for your Drupal to WordPress migration project. The migration checklists below will help make sure you're considering areas that often come up during migration projects. Furthermore, you may want to check the resources section for additional worksheets and guides. Also keep in mind that not all aspects of a migration are practical to automate. In many cases, you may need to make manual adjustments post-migration using the WordPress interface.
Basic migration planning
At any rate, you should at least take some basic planning steps before you begin:
- Consider why you are migrating to WordPress.
- Decide on your approach to building the WordPress theme.
- Be aware of any SEO impact when migrating to WordPress.
- Gather as much information as you can about your Drupal installation.
- Write a Drupal to WordPress migration mapping document.
Incidentally, it's easy to overlook the fact that you don't need to make an exact copy of your Drupal site in WordPress. Prioritise the highest value content and functionality if time and budget is tight. To that end, putting together migration requirements will help focus your efforts.
2. How long will a site migration take?
There are automated migration services that claim to do a great job in 15 minutes. In my opinion, this severely underestimates the scope of the work necessary and overlooks the importance of pre-migration planning and auditing, as well as post-migration quality assurance. One common remark I hear from people who have gone through the process is that it ended up being much more work and taking much longer than they expected.
While automated tools and scripts will speed up transferring your content, be aware that manual adjustments will be necessary in almost every project. There is currently no way to automate the work performed by skilled content strategy experts, editors and quality assurance testers.
Hours and timelines for the average migration project
From experience with my own migration projects, I've found that a small site can take anywhere from 20-30 hours. The average content-focused site, such as a blog or news site, can take me between 50-100 hours to complete. Complex migrations for e-commerce sites can take 80-130 hours. Your experience will differ but it's certainly much more than 15 minutes.
In terms of time to launch, I always recommend leaving at least three months from project kick-off. Six months to one year for a large, business-critical site with lots of stakeholders requiring sign-off approval is not uncommon.
3. The three main components of a CMS migration
There are three main components of a site migration:
- Site content
- Design templates
- Functionality
Web developers experienced in either Drupal or WordPress platforms will be familiar with these aspects of a site but I’ll give a brief overview for site owners and business-focused staff.
Site content
The content, such as the pages, articles, blog posts, and media uploads, make up the core material for your site. Content is separate from the design aspects like the textures, buttons and other bits of ‘eye-candy' that go into making the site visually appealing.
Content migration is nearly always the primary focus of any CMS migration project. Both Drupal and WordPress store content in a database that supports widely-used open source technologies. While they share the same basic technologies, Drupal uses a different database structure, or schema, which cannot be directly copied into a WordPress database. The technology's open-source nature makes it feasible to export content from one system to the other but our challenge is in knowing the best way to translate those different storage structures.
Design templates
Design templates display your content with a specific look and feel. Under Drupal and WordPress, these design templates are called themes. When you first created your site, the main building effort would have been for a designer to come up with a look that you like and for the developer to translate that look into web code. The designer and developer may have been the same person but design and code are separate tasks.
In my experience, site owners usually take the opportunity to update the site design during a migration. Some hire a designer to come up with a custom look but those on a budget tend to download a pre-made theme. Arguably, a big part of WordPress' success lies in its wide range of professionally designed, easy to install, easy to use, and easy to customise theme selection.
Functionality
Under Drupal, site functionality comes in the form of modules. WordPress calls these plugins. Both modules and plugins are additional software components that extend the core content management system's utility. The vast majority are created by independent developers and web development shops. Modules and plugins help create feature-rich websites quickly and at a lower cost than programming from scratch but they have an important downside: site owners can face a serious problem if the original developer abandons their efforts.
I have found many long-running Drupal sites to be cluttered with out-dated and abandoned plugins. In fact, the push to migrate often stems from concerns about dependencies and the inability to upgrade without breaking the entire site, mostly due to a critical but abandoned module. Just as WordPress offers a wide range of themes, it also offers a rich ecosystem of plugins and plugin developers. Site owners can replicate legacy Drupal functionality by building a custom WordPress plugin or by installing one of the many free or premium offerings.
4. Migrating Drupal users to WordPress
Unsurprisingly, migrating user accounts is a high priority for owners of membership and community sites. Whereas most areas of a site migration can be run behind-the-scenes, it’s important to know that user account migration will need action from people with login access. This might present you with an extra user management challenge after the migration. First, here’s an overview of the user components that need to be mapped in the database:
-
User data and metadata: This includes elements such as the user ID, username, email address and associated profile fields. In most cases, Drupal user fields can be mapped fairly easily into the WordPress
userandusermetatables. - Roles and permissions: Drupal’s roles and permissions are more flexible when compared to WordPress roles. Nevertheless, it’s possible to shoehorn a Drupal site’s access control model into standard WordPress roles with a bit of creativity. WordPress has many access control and user management plugins if you need to set up more complex login permissions.
-
Content authorship: Assigning post authorship is straightforward by setting the posts’
post_authorfield with the appropriate user ID. - Credentials: Due to the different password hashing algorithms used by Drupal and WordPress, the user password cannot be easily migrated.
Password hashing and why it matters for your migration
To understand why you can’t easily transfer the password field when migrating Drupal users to WordPress, you need to know about password hashing. Hashing is a method of irreversibly scrambling text: password text is converted using a mathematical operation into a set of alternative characters (the ‘hash’) but you can’t use that operation to convert those characters back to the original password. It’s a one-way process that’s as strong as the mathematical operation, or the hashing algorithm. Some methods make reversing the process more difficult by adding a ‘salt’, which is an additional random bit of text. The hash and salt technique is often used to secure passwords in the event of a data breach.
Drupal 7 and Drupal 8 use a hashing algorithm called SHA-512 with a salt while Drupal 6 uses MD5 without a salt. WordPress, on the other hand, uses MD5 with a salt. The different hashing mechanisms means that as far as WordPress is concerned, any text migrated into the password field is unusable. It has no way to get back to the original password. When a users tries to log in, it can’t tell if the entered password is correct.
Plan your post-migration password reset process
The consequence is that there’s no simple way to seamlessly migrate user passwords. I mean this in the ethical ‘white-hat’ sense. Malicious hackers can use other techniques to crack the password but these aren’t viable for a migration project. If it were, we’d be presented with a security failure as anyone with access to the database could reconstruct user passwords without too much effort.
After the migration, your users will therefore need to reset their passwords on the new WordPress platform before they can log in. If you have many users on the legacy Drupal site, it’s worth considering how to manage this process during your migration planning stage.
5. Migrating Drupal views and blocks to WordPress
Drupal views and blocks are among the most powerful and regularly used features available to Drupal developers. They help web builders create data-rich displays by showing content listings on different areas of the site. Note, however, that views and blocks aren’t bits of content themselves but a method of presenting content in different ways. Nevertheless, they’re sometimes important considerations during a site migration because of their close relationship to how visitors experience the site. It’s worth taking a bit of time explaining what views and blocks are and how to transfer them to WordPress.
Migrating Drupal views to WordPress
Views are simply groups of content organized into listings. For example, you can have a view that lists recent comments, top articles by month, posts from users, or terms in a particular vocabulary. They’re controlled by the Drupal Views module which allows site builders to query the database without writing code. Essentially, Drupal Views is a point-and-click wrapper for some powerful database queries that pull out and sort content.
WordPress developers usually build these types of content listings by querying the database in code using the WP_Query programming interface. There have been WordPress plugins, such as Query Wrangler and Query Posts, offering similar functionality to Drupal views. Unfortunately, these now seem to be abandoned projects. Toolset, a plugin mentioned in the Drupal to WordPress Migration plugins section below, offers a views query builder for WordPress but you’ll have to pay a yearly licence fee.
I prefer to ‘migrate’ a Drupal view into WordPress by coding it into a child theme template. The WP_Query interface is a standard theme developer tool so a lighter-weight approach makes more sense to me. Installing plugins to handle views functionality may lead to unwanted dependencies and licence renewal costs in the future. On the other hand, any experienced theme developer can adjust theme templates without too much trouble when needed.
Migrating Drupal blocks to WordPress
Drupal blocks are boxes of content that can be placed on different areas of a page. Drupal views are usually displayed in blocks so the two features tend to work together. WordPress has a direct equivalent for blocks: Widgets.
As with views, blocks fall into the theme and development domain but people often ask about migrating Drupal blocks into WordPress. They are best considered part of the theme or plugin development effort rather than the content migration phase.
6. Drupal to WordPress Migration checklists
Migrating websites to a different content management system is notoriously complex but even seasoned developers still underestimate the amount of work involved. Drupal to WordPress migrations can be especially tricky because they target very different types of users. Consequently, their platform architectures are also very different. You can quickly run into trouble if you forget some key areas during your migration process.
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 project’s impact on project resources. Over the years I’ve compiled a set of questions and considerations specifically for Drupal to WordPress migrations.
They’re organised as checklists of three main areas that often concern my clients:
- Understanding their migration requirements
- Auditing the existing Drupal site
- Addressing any SEO impact of the migration
I regularly update them to include new items that often come up and you can find them in the Appendix section of this guide.
A web search will also bring up many detailed migration checklists targetted to website migration SEO.
Whether you use a pre-defined checklist or compile your own from scratch, I strongly recommend that your migration project be based around some sort of checklist framework. No matter how many CMS migration projects you’ve completed, it’s easy to forget important tasks without them.
View my sample Drupal to WordPress migration checklists.
Drupal to WordPress migration service
All content · Custom content types · SEO · Plugins
Migrating content from a site and need a specialist? Please contact us for a quotation. Whether you're a media agency who needs a database expert or a site owner looking for advice, we'll save you time and ensure accurate content exports.