Successful Host to Host Migration

When the decision was made to go forward with a full migration of 2 domains, each with WordPress Multiuser installs, a plethora of sub-domains, files that have accumulated over the last 2 decades and a dozen email accounts, I was sweating a long, drawn-out endeavor that would occupy all the time remaining before use of my old host lapsed and then some.

As it turned out, the entire ordeal lasted less than 2 days and only that long because of my slow connection speed and processor.

I basically considered 2 different approaches, both requiring a full backup of the files as well as the databases. The first alternative was to reconstruct the old configuration piece by piece, recreating new WordPress installations with new databases and loading each sub-site with individual WordPress exports from each old site. The second approach, and most straight forward, was to FTP everything to local and then FTP everything to the new server. I used the second approach using my Filezilla. The FTP from the old host to my local device was time-consuming (it took most of the night) and suffered less than a dozen failed transfers which were extraneous files. The FTP to the new server went even more smoothly, by running quicker and experiencing only 1 failed transfer which was easily remedied.

The next phase was migrating the databases. I created replicas of the databases from the old host on the new and proceeded to export in SQL format from the old. I had some hammering out to do to configure the options on the export side because the new import process allowed no options, just straight import from zipped SQL text files. After a few attempts, I finally got the process streamlined and replicated it for each of my main databases. Done!

At this point, I actually entertained the thought that perhaps a miracle would occur and the new site would “automagically “come up without a single SNAFU. Close, but not quite. After testing the new host configuration using temporary URLs, there was a problem with .htaccess because the DNS changes had not taken place yet, which was just a minor issue. The next hurdle was resolving the problem of each instance of database access initially receiving an error with the connection. One by one, I figured out what the problem was and in each case it was only a trivial change to fix a typo, inconsistent id or password. The entire connection dilemma was sorted out within a couple of hours. By evening, I was ready to point my domains to the new host. It took less than an hour for the DNS changes to take effect, which is amazing in and of itself because my registrar is in Melbourne, Australia. By the next morning, my new site was behaving exactly like the old and I had to double check to make sure that the changes had actually taken place and that it wasn’t pulling in cached copies of everything.

Sure enough, the operation was a complete success!

affiliate_link

I am going to be very happy with my new web host though they don’t use the familiar cPanel but their own, in-house, control panel which takes a little getting used to. The bottom line is that there is more left on the bottom line since the new hosting arrangement is only about half the cost of the previous and for twice as long.

The moral of the story is, sometimes it’s best to “go ahead with it” and don’t psyche yourself out when it comes to making a strategic business decision. Above all else, it is a great challenge and learning experience.

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: