Drupal to WordPress Migration: Pre-launch, go-live and follow-up
For this part of the Drupal to WordPress Migration Guide, I cover essential steps for quality assurance, troubleshooting common issues, and selecting the right hosting environment. I also look at critical post-launch considerations including SEO preservation, manual adjustments, and long-term content maintenance.
1. Content quality assurance
Even if you decide to outsource the content migration work, you should still allocate resources within your in-house team to perform the quality assurance (QA) tests. Your own content editors, being most familiar with the site content, will be the best people to review and check the migrated data. External migration consultants will not have the same familiarity with the nuances of how your content ought to be structured. They will often miss obvious discrepancies that a content editor will spot at a glance.
It can be tricky to adequately test sites with many thousands of posts. This is very much a manual process that needs a human to ‘eyeball' the migrated content. The big problems, such as broken links and missing fields, may be immediately obvious. Other issues, like text encodings and foreign language character set discrepancies can take a while to surface.
Expect to spend considerable time with back-and-forth communication between your migration team and QA team as they try to resolve issues. An iterative migration workflow will simplify the process but sometimes you may have to accept that certain problems need old-fashioned manual resolution. In other words, someone might just have to edit a bunch of specific posts to fix the problems over time, after the site has launched.
2. Post-migration troubleshooting
The complexity of many projects means that you may encounter problems with your WordPress installation after migrating content. There could be any number of reasons for these errors but checking my Drupal to WordPress migration notes might point you in the right direction. Alternatively, browse through my migration troubleshooting posts where I keep a record of problems that regularly arise.
Here are a some common errors, along with a link to a possible solution.
- Incorrect domain in URLs: This is a very common error where you may have forgotten to replace the old domain or development URL with that of your live site.
-
Clicking on author's link gives 404: Invalid characters may have been migrated into the WordPress
user_nicenamefield. - Gateway timeout when enabling plugins: The WordPress upload path directory may be set incorrectly.
- WordPress redirects to old site after updating database: Sometimes a caching plugin redirects you to the old domain or development URL.
- Post migrated but navigating to post shows ‘Not found' error: Usually an invalid character in the WordPress slug or .htaccess not enabled in the Apache configuration
- Dashboard controls not visible after logging in: table prefixes may not have been updated.
3. WordPress hosting for site migration projects
Search the web for WordPress hosting and you'll find a ton of articles with reviews, recommendations and feature listings. Instead, I'll focus on web hosts I've personally used specifically for Drupal to WordPress migration projects.
WordPress runs on pretty much any standard hosting package on the market. A hosting company has to go out if its way not to support WordPress. You might even run your own servers in-house that are ready to host both the migration and production environments. Keep in mind that a good hosting environment streamlines the migration process by offering tools to make your life easier. Poor hosting will plague your project with connection timeouts, failed database imports and manual configuration of basic utilities.
Managed WordPress hosting
Of all the hosting packages I've used over the years, managed WordPress hosting services have given me the best migration experience. Managed WordPress hosting is certainly more expensive than regular hosting but there's no need to stay on the package after going live. If your budget allows, you might the benefits worthwhile and decide to stay. In alphabetical order, I have used and will be happy to use again the following:
Speaking from my own experience, all of these companies have responsive and helpful customer support. All offer the basic tools needed for Drupal to WordPress migrations involving remote teams such as secure remote access, WP-CLI, and database client. Pantheon is a little different from the others listed in that their environment enforces a Dev/Test/Live workflow that requires some documentation trawling. It took me a while to get used to Pantheon but I like their offering.
4. SEO for Drupal to WordPress migrations
Drupal to WordPress migrations follow the same SEO considerations as other types of migrations. I therefore won’t detail them in this guide as site migration SEO is an in-depth area. There are plenty of online articles from dedicated SEO specialists that will do a better job. Furthermore, if search traffic is important for your site, you will likely have been working on it throughout the project. You have thought about the SEO considerations, right? Too many clients come to me at the end of their site development efforts and optimistically ask that I:
- Migrate their content, hopefully within a week;
- and, oh yeah, ‘migrate the SEO'.
The pre-launch stage is too late to start thinking about SEO but if search traffic is important for your site, this is a reminder is for you not to leave it for post-launch.
If you’d like to know more about some specifics of preserving SEO during a Drupal to WordPress migration,scroll down to the Appendix section for my guide for preserving SEO during a Drupal to WordPress migration.
5. Manual adjustments
Sometimes it's impractical to automate every aspect of a migration. For example, some quick adjustments using the WordPress user interface just before launching may be simpler than writing code to script a task. The particular tasks themselves depend on your migration requirements but most projects have an element of manual fixing-up prior to going live. It's important to leave time in the pre-launch schedule and identify a person, usually a technically-minded content editor or intern, to do the job.
It can also be the case that you'll need to do the adjustments after go-live as part of your long-term content curation process. For example, I once had a client whose authors manually embedded HTML advertisements in their content body. The code didn't match a well-defined pattern so removing the adverts through a script or SQL query risked silently breaking HTML in some posts. The client decided it made more sense to fix these over time as they pruned their content.
Be practical in your migration approach and keep in mind that a low-tech solution can be the answer to some problems.
6. Go-live and follow-up
Going-live isn't usually the end of a migration project. As mentioned above, there may be some long-term adjustments and content cleaning needed. Remember also to allocate time and budget for any post-migration SEO analysis. Nevertheless, the bulk of the work will be done and you can enjoy the advantages of running WordPress. These may include:
- A more user-friendly interface for non-technical users.
- Lower development costs through plugins and more affordable developer rates.
- Lower hosting costs.
- Easier maintenance.
Gauge the project’s success by reviewing your goals for migrating to WordPress and follow up to see if those expectations were met.