What’s the most important thing every website owner wants in their migration?
No downtime, of course!
That’s what your clients tell you anyway. And, its nearly impossible to completely avoid any downtime at all (I’ll get to that later). But, what do they REALLY want?
Accuracy!
Accuracy in migrations is ensuring that there is no loss of data, and that the target server runs the website in the same way as it does on the source server. Which brings me to the first major tenet of migrations:
Replicate your environment as accurately as possible
If you pick up all of your website files and dependencies and put them down on an identical server with the exact same binary files and the exact same versions for all software, and the exact same plugins and modules, it will work GREAT (assuming your coding is not dependent on a specific IP address. You don’t code by IP address, do you?)
So, making sure that your environment is prepared to host the type of website you are running will set you up for success before you even install your site files. The best way to ensure you have a good migration is to have a good plan in place. The best way to get a good plan is to understand your current server and website configurations, and how they work together. You can then focus on these areas during your migration.
Of course, depending on your reasons for migrating, a perfectly accurate representation of the source server may not be possible. For instance, if you are running a very old OS like RHEL 4 (which has received no updates since 2012), some of the software you have installed may also be very out of date, and an upgrade for security will be required, or custom compilation of certain software versions should be investigated. (I don’t recommend circumventing security, though!)
When you change versions of software in a big way, or even in a small way, there is only one way to ensure complete compatibility, and that happens to be my second tenet:
Test the migrated data thoroughly
Set yourself up for success again by seeing how the new server reacts to your website. There are several methods you can use to check out a copy of a website, be it mod_userdir, an external proxy, or even by changing the code of the site to use an alternate domain name or subdomain temporarily. However, each of these methods has its shortcomings. The best and most accurate way (there’s that word again) is to send a real request for the real domain name to the server through the channels it will eventually use for live traffic, and the best way to accomplish that is to skip DNS lookups and have your computer’s browser query the server directly. Much more info on that to come.
This would be the appropriate time to look at how the site reacts on the new server, look for major flaws in compatibility, adjust settings and the environment accordingly, and make any other necessary tweaks to get more accuracy and compatibility out of the target environment.
My final tenet for migration:
Ensure everyone has appropriate and realistic expectations
Your client may have a good idea of what they want to see in a migration. You may also have a good idea of how you want your migration to go. Your server’s technician and your developers and your customers, too, all want the migration to go a certain way (even though they may not know it, or even be aware of a migration at all). Getting everyone on the same page and disseminating information to the right people from the start will prevent costly delays, angry clients, bewildered developers, or worst of all, lost customers.
Migrations can happen overnight, or even in a few hours (but they almost never work that way). Migrations can happen completely hands off for your clients and developers (but its much better if they are involved). Migrations can occur with no loss of data (but downtime will be expected), and migrations can occur with no downtime (but loss of data will be expected).
This circles back to having a good plan in place, and getting that plan in front of all of the stakeholders in your project. What the heck; bonus tenet!
Have a well thought out migration plan in place before you begin
This sounds like a lot of work, huh? Well, to be truthful, it is. But the successful and smooth transition onto your new server will be very much worth it. Check out a few of the other posts and guides on this site to get details about gathering information about your server, developing a good plan, passing it to your clients (in a way that they will read and understand), executing it, troubleshooting it, and finishing your migration with as little data loss and downtime as possible.
You can do it! Tiny turtle believes in you!