Migrating WordPress to a New Host – SiteGround

How often have you thought to yourself that you need to migrate your WordPress hosting account to another provider, but were just too afraid to go ahead with it? After all, everything is working fine right now – so why mess it up? Sure, you may be paying a little extra or you’d like to take advantage of some of the cool features offered by other hosts, but is it really worth the hassle? There might have been a time once when you had the technical know-how to do it, and you can probably do it again. But all that effort… And what if something goes wrong? You’ll be left with a broken site and hours upon hours of hard work in front of you! Much easier to just hit the “Renew” link for another year and forget about it right?

We’ve all gone through the above thought process – specially if we don’t do this kind of thing for a living. These are all valid concerns. However, with a little bit of forethought, we can pull it off without too many hassles. All we require is a clear transition plan and a step-by-step guide for proceeding. Well, I’ve just finished migrating my WordPress site from BlueHost to SiteGround, and have documented every step of the process from start to finish. So here’s how you go about it.

The site migration of WordPress to another server (while still retaining the same URL) consists of the following sections:

1. Replicating the environment;
2. Migrating the databases;
3. Migrating the files;
4. Testing the site using a temp URL;
5. And finally changing your DNS servers.

In this article, I’m going to run through the first three steps. Taken together, they consist of all the heavy site migration requirements. The remaining two are the finishing touches, and I’ll deal with them later since they don’t require the involvement of the original source web hosting server. So let’s get started!

Replicating the Environment

First we need to make sure that the recipient environment has a configuration that matches your original hosting provider as much as possible. This is true for migration of applications in general. And for WordPress, what we really need to look out for is the PHP environment. Most of the time you shouldn’t have any problems with PHP, but certain functions and structures require a specific PHP version. Here’s how to check what it is on your source environment and replicate it at the destination.

Log into your source cPanel account – in this case BlueHost – and click the icon called “PHP Config”.

You can see that this brings up a number of PHP versions, out of which the one you’re currently running will be selected. In this example, my source environment was running PHP 5.2 (on second thoughts, I really need to upgrade that!).

If this level of versioning is not sufficient for you, you can easily get the exact PHP version number using the phpinfo() function as described in one of my earlier articles.

It turns out, that my new SiteGround hosting account doesn’t have any PHP version set by default. But I can change the version depending on the directory! So I log into my SiteGround account and navigate to the cPanel dashboard. Over here, I scroll down and click on the icon called “PHP Version Manager”.

This brings up a tree view of the current folder structure.

In order to set the PHP version for a particular folder, we just need to click it. This will bring up the following screen:

You can see that SiteGround allows you to choose from a huge number of different PHP versions ranging from 4.4.9 to 5.5.17 as of now. For my example, 5.2.17 is the closest version I saw in my BlueHost PHP configuration screen, so I selected it for the topmost folder that will contain my blog. After having saved my changes, I’ve taken care of the first step – the environments of the two servers match as closely as possible.

Time to move on to migrating the databases.

Database Migration

To move entire databases from one server to another, we need to take the following steps:

1. Create an SQL dump of the old database
2. Create the existing database structure on the destination server
3. Upload and import the SQL dump from step 1

Starting with the first step, log into your source server’s cPanel account and hit the “phpMyAdmin” icon.

As you can see in the resulting screen, I have two databases that need to be transferred.

That’s because I actually run two separate WordPress blogs on my domain. If like most people you have just one, then you will have just one database. You can expand the databases on the left-hand side to figure out which one contains your WordPress blog. In my example, it’s the first item in the list. Click it, and it will open up in the right-hand pane with the entire database structure. To export an SQL file, click the Export tab as shown here:

If you simply click “Go” without further ado, phpMyAdmin will attempt to download the complete SQL file to your desktop. However, if you have a somewhat large SQL file, the download has a very real chance of breaking in between and you’ll be left with an incomplete SQL dump. In the “Output” section of the screen above, you have an option to save the SQL file on the server itself. If you have write permissions in the specified location, make use of it and download the complete SQL dump onto your desktop from the server after the export is complete.

If you don’t have write permissions, download and install the WordPress plug-in called SQL Export. Once installed, you can access it from the “Tools” menu of the WordPress dashboard and download your SQL dump that way. In this manner, you can be sure that you have a complete unbroken SQL file.

Once that’s done and you have the SQL dump of your existing database sitting on your desktop, Navigate to the File Explorer icon of the same source server and go into your WordPress blog directory. Locate the wp-config.php file, right-click on it and select “Code Edit” as shown below.

Once the file is open, scroll down till you find the database information such as the name, username, and password as shown here:

Make a note of these details – we need to re-create the exact same database with the same credentials on the destination server. You can do this easily using the “MySQL Database Wizard” in cPanel as shown here. Sometimes, you won’t be able to create a database using the exact same prefixes that you had. In which case, you need to change the wp-config.php file after the site has been migrated to reflect the actual database name and user.

Now that the database has been exported and the new structures created on the destination server, it’s time to initiate the import process. For this, open up phpMyAdmin on your destination server via cPanel, and select the new database we just created in the previous step. It won’t have any structure yet. Click the “Import” tab.

Now simply hit “Choose File” and select the SQL dump from your local PC. Note that the maximum file size is 50 MB which is quite large considering that we are dealing with text files. But in case your SQL dump is over this limit, we need to use another technique for migration which we’ll look at in a future article. As things stand however simply choose the file and initiate the import process. If all goes well, your SQL dump should upload without a hitch and soon you have a perfect replica of your database in your new location.

Now that step two has been taken care of, we need to perform the last major operation – transferring the files.

Migrating the Files to the New Server

This can be one of the most difficult and time-consuming stages if you have a large blog and you don’t have SSH access in your new account. The reason is that to do this step manually, you have to zip your entire WordPress directory, download it onto your local PC, and then upload it to the destination server. Let’s look at these steps one by one.

Access your source cPanel account and click “File Manager”. navigate to your WordPress folder and select everything you see using the “Select All” checkbox as shown below:

When everything is selected, right-click and choose “Compress”. Click OK, and all the contents of your directory should be compressed into a single file. This is beneficial because transferring such a large volume of files by FTP is out of the question. A single file gets downloaded much faster.

Even with compression, the resulting size of my zipped file was over 170 MB. Ideally, we would simply be able to make a direct server to server transfer without having to act as the middleman. With SSH access, this is possible. You can see for example that using a single command, I was able to transfer the entire 170 MB file from one server to another in less than 10 seconds at an average speed of 12.9 MB/s.

This is because the pipes connecting servers are much fatter than the ones connecting them to us. How to obtain SSH access will require a separate article by itself, and some hosts like BlueHost don’t give it to you unless you manually requisition at first. So in the absence of SSH, you’re stuck with doing it the slow way. Download your zipped file onto your local PC, log into your destination server cPanel “File Explorer”, and painstakingly upload it again. With a large file size like the one I had, this should take you at least a couple of hours, if not more.

Once you finally done transferring the zip file onto your new server either via SSH or manually by downloading and uploading it, it’s time to extract it. Make sure that you’re in exactly the same location on your destination directory as you were when you zipped the file in the first place. The extraction process will overwrite everything that it conflicts with. Right-click on it from the File Explorer, and click “Extract”.

The whole process should be over in a matter of seconds, and you’re done! We’ve performed the three most important and time-consuming steps of migrating a WordPress blog from one server to another. Namely replicated the environment, cloned the databases, and transferred over all of our files.

In the next article, we’ll take a look at how to perform the finishing touches on the WordPress installation such as testing it out on a temporary URL, and finally sealing the deal by changing the DNS servers.

Next: Migrating WordPress from BlueHost to SiteGround – Part 2