8 checks for WordPress website migration
(Photo by Looi ZF.)
WordPress website migrations – the stuff that does not go away, yet.
Its the modern day web. Web 2.0? Web 3.0? And in today’s web, I would have thought that performing site migrations would get even better.
Well, its already much better than before, in the days where we had to go down to the database, export all tables and data, and port them into the fresh database in the new host. Then again worry about the physical files, emails, bla bla.
Today, we have plugins like Duplicator that greatly aid in this manual process. If all goes well, things can be done pretty quickly. My client thinks its just a matter of copying files over to the new host. Well technically yes and no. Its more like an export and import, plus a number of other overheads, that somehow seem to creep in. (with some after-thought, I was thinking hey yeah, when can we get a simple drag-and-drop for this whole process. Then we would suffer less from vendor lock-in and all that stuff.)
So I present to you below my list of highlights to check regarding WordPress site migrations in no particular order. Some of the points apply to other site platforms as well of course.
1. Pre-setup check in local server
Having a local setup can help achieve some things. It helps iron out some issues if you don’t have access to the new hosting yet. It can give you access to configurations that an online hosting plan won’t give you to try things out. It will also give you an opportunity to do dry runs of your backup and restore procedures so that you are all set for the actual migration day. Furthermore, having a local server allows you access to debug mode to solve any problems much faster. (I won’t cover setting up a local setup here as there are plenty of good resources out there)
2. Migrate files (multi GB upload folder) and database
(For simple WordPress sites, just sticking with Duplicator plugin is great. For bigger stuff, read more.)
With content sites and multi transaction businesses, things are getting bigger everyday. Especially when you have video, images, and more. For migrating files, Its much easier to compress all of them into a single file for transfer. Whether to use zip, gzip, bzip, lzma, the type of compression depends on what is supported, and if you prefer the slight advantage of speed versus compression size. There are some interesting comparisons out there which you can take a quick reference to. The conclusion from Tukaani claims that gzip is a good overall choice. Also consider other options like host to host transfer that some providers do provide as a service if you want to save on this work.
For migrating of database, it can become a hassle quickly. Some things to the rescue are things like BigDump, that can perform staggered export and importing of database dumps. This is especially god send when working with restrictive php and server timeouts that are beyond your control. Things get to breathe easier if you have access to the shell command line. “mysqldump” commands can then be used for really big database export/importing (in GB size).
Also, don’t forget the in built backup utility in Cpanel if you have it so. This can help backup whole directories and databases.
3. Verification that migrated website is working
Beyond the obvious, like running it through verification tools for broken links and missing files, is whether you are indeed checking the right links in the first place. This is often misleading and confusing to many at first, because if your domain name is still pointing to your old site, and your migrated website also has links with your existing domain URLs, then of course things will still work. Because your new site may still be retrieving stuff from your old host. So beware.
You would want to ensure that your domain name is already pointing to the new host before verification. You can help ensure this by accessing a new or different file that exists only in the new host.
Also, check for plugins and functionality that has stopped working. Some plugins and functionality may depend on external or other configurations beyond what you were aware of. Re-configure and reset as necessary. This is also especially so for cache and URL rewriting plugins that use your .htaccess file.
4. Email Setup
Many administrative works goes into this step. Setting up the same set of email accounts in the new host, including any email forwarding, then migrating the actual emails. SiteGround has a nice article on this. Again, do check that emails sent out and received are working in the new host, not the old. New mails should be received only in the new host, and appear in the sent logs of the new host.
5. Error Check
Check whether your php error log file is growing!
If possible, you may want to turn on php error logging for WordPress as well. This can be set in the wp-config file in your installation root folder. This is especially helpful just after migration to check for any abnormalities. There is also a growing number of debug plugins that are pretty useful in this endeavor which you can checkout from the plugin directory.
6. Unexpected Support or non-Support
Unfortunately, certain things we take for granted also can help to screw things up for us. Sometimes new errors start appearing only after migration that leaves us baffled as we have followed all instructions and done our due diligence.
My story was of an e-commerce plugin that kept spewing errors only when running on the new host. This really puzzled me as it ran fine in my local setup. Until I realized that the new host ran on a more updated version of php, which had stricter rules. For this I would need to either fix myself, or contact plugin support.
7. Transition Work
This is especially tricky for sites with a combination of high visitor counts and live transactions. If it’s mainly a content website that you are migrating, then things are easier. But even content sites nowadays have user comments and all sorts of user contribution.
Things to consider would be your communications plan to your users. What is your transition plan, what to do in terms of failure and roll-back. Do you need some down time, or will you just migrate the de-sync in data as a second phase.
Taking the time to plan through the process and scenarios will go a long way in preventing frantic calls for help and ultimately unhappy customers.
8. Cron Jobs and more
Background operations are often the forgotten part of the picture. And which will only trigger frantic disaster recovery action when we realize a little too late, after a customer complains that something they expected did not happen on schedule.
So definitely, remember to check for any cron jobs both in WordPress and Cpanel and migrate them as necessary.
Finally, regarding the “more” in the header of this last point. This will boil down to your individual settings and configurations which you would have to go through and check that nothing important is left out. This part I won’t be able to list down for you.
If you have good suggestions or tips to share, do leave it below!
Simplify and gear up your business today.