The migration of files should be a seemingly easy task, and I guess you could say it is, but when you are dealing with complex ecosystems like CMS’s, it can get a little dicey.
This article is not an instructional guide on how to migrate WordPress files, but aims to address a few things you should know and prepare before doing so.
1. Prepare your client.
Many developers already know that clients often seem to think tasks are easy in web development. “Just add this to the website” clients often say, without giving further parametres as to design or content strategy. This perception of simplicity is slowly changing in the digital age as the general public becomes more versed with computers on mass, but for the most part, it still exists.
For this reason, prepare your client. It’s not his/her fault that s/he doesn’t understand the complexity. Let your client know that migration is not a task or any kind of solution to take lightly.
I give the analogy of a migration being like anaesthesia for humans to my students. In medicine, anaesthesia is not a matter to take lightly. You only do it if there’s no other option, because there is always a small risk with anaesthesia that the patient will never wake up. When it comes to the world of computers (mainly due to the small chance of file corruption) whenever you move or migrate files, especially complex ecosystems of files like websites and CMS’s, there’s always a chance that the website will never wake up, or will “wake up”, but with severe deficiencies!
Always approach migration with caution, and advise your client to do the same.
2. Separate all the interfaces and environments in your mind
So that you don’t get confused, know the environments you’re going to work with. You’re most likely going to be dealing with about 6 different interfaces and environments during a migration.
- Your local server and files (such as XAMPP / WAMP / MAMP or another test server online)
- The FTP interface and/or your files on the production server
- Cpanel on your production server
- Your local database admin program (such as MySQL, or phpMyAdmin)
- Your production server database admin program (such as MySQL, or phpMyAdmin)
- The local WordPress Admin interface
- The production server WordPress Admin interface
There can even be yet more interfaces such as the interface for managing your domain (if you’re going to be using a new domain) and so forth.
3. Be vigilant of usernames, passwords, paths, and file naming conventions
It’s best to have a uniform strategy in dealing with all of these before even attempting a migration. Most of the typical problems you’ll encounter after a migration will be related to these issues, including:
- Broken links, pages, or images (because you hard-coded or baked paths into your HTML or PHP)
- Getting locked out of the admin interface of your WordPress installation on the production server (because the database still contains the old URL of your old server, and not the new production server URL)
- Forgetting your password and not having a system or naming convention to keep track of it, then having to go into the production server database and manually set a new one.
The better you get at migration, the more you’ll manage all these issues and nip them in the bud before they manifest themselves.
When you have successfully completed a migration, always check as much of the site as you can to make sure it’s working. Don’t just trust that it works. You can think of it a bit like Gordon Ramsey in the kitchen. He always asks his chefs to taste the dishes they prepare before sending them out to the customers. Don’t just go on faith, especially when your WP site has potential vulnerabilities with security, such as on an e-commerce site.
Once you’re done testing, ask your client and fellow developers to test it too, in case you missed anything.
Migrating a WordPress site can be finicky, but if you budget the necessary time for preparation and troubleshooting after, the whole process can go a lot smoother.