Recently I moved several of my websites from the dedicated cloud server I’d been using for the last year to a smaller shared host. I didn’t need the capacity any longer. What complicated the move is that the cloud server had cPanel Webhost Manager (WHM) which meant all my websites had their own cPanel accounts, but in a shared environment this would not be the case. Here’s how to do the move.
Because each domain on the dedicated server had its own cPanel account, each had its own set of MySQL databases. In a Cpanel environment, the host account becomes a prefix to the database name, so you’ll have a database for example called girifox_wordpress.
In a shared host, every database will have the same prefix even if the databases are for different subdomains (also known as virtual hosts). So my wife’s website’s MySQL database would need to change to something like girifox_laura whereas before it would have been laura_wp.
WordPress needs the name of the database – stored in one place sensibly – the config file at its root level.
I also had one domain which uses IMAP for its email (the others were all POP3), so I needed to move all that email from the old to new server. If I’d had a lot of users with IMAP, I’d have need to move their mail directories with shell, luckily it wasn’t a problem I had to solve.
Preparing to move
Cloudflare. A few days prior, I moved all my websites to cloudflare. Some had been using cloudflare for about six months and their availability has been rock-solid. This free (awesome) service provides your DNS, with massive benefit of blocking malicious attacks on your website, plus free static file hosting (like a CDN).
My new server has a static IP address, so this is simple. (There are a few hosting requirements and extra steps if you do not have a static IP on the shared host, which I won’t go into.)
Using Cloudflare I had very easy control of which IP address my domain names resolved to, and could set the TTL very low (one hour) so I could fallback if something went wrong.
So all websites on cloudflare, TTL for the domain name set to one hour (or less). All of this is easy to do, and doesn’t take too long after you’ve done it the first time. You’ll edit your registrar entry records for your domains to resolve to cloudflare’s DNS.
Do this change and be sure it’s propagated, before moving onto following steps.
Update: also check your SPF record is correct. If wrong, you will get bounced emails. It’s done as a TXT entry on cloudflare. I had mine set to a specific IPv4 address so had to change it. Liquidweb’s answers are fine. I set my domains to use
"v=spf1 a mx ~all".
Shared host DNS Zone
With Liquidweb, my provider and one I recommend, it’s quite easy to add the virtual domains which you intend to move over. Their interface lets me specify the domain names, and that lets Liquidweb route my traffic on the shared server to my virtual domains. So I did that.
Files. Moving the WordPress system or other html files is easy enough from source to target server. I used cPanel to zip up the entire public_html directory, download it (keep as an offline backup), then it’s ready to upload to the target server.
What you can’t do: do not use the complete home directory backup/restore feature, because your target server will have a different directory structure to the source – your virtual hosts will now be directories within the first level of your public_html folder, whereas before they were the first level.
MySQL databases. The best way I found to move these is with a neat feature in cPanel called partial backup/restore.
What didn’t work: I tried doing a MySQL export and import with phpMyAdmin but the problem was I had to change the name of the databases between source and target, as mentioned before, and this was messy as I had to find/replace them. Plus I had problems with the information schema on the target MySQL database and of linking a database user.
On the source server, withincPanel Backup, there is a partial backup option.
You simply click the name of the database required and it’ll download to your computer.
Next, moving it over.
To the new server
Files. I uploaded the files to the new server. Each domain which had its own cPanel account on the source server was now a subdirectory within my shared host environment. Unzip the files within their new directory home.
MySQL. On the new server, use cPanel Backup to restore the database you downloaded earlier. It will create a newly named database for you, very neat, and information schema will work fine.
I then used phpMyAdmin to rename the newly imported database to something shorter, since they all had fairly long names combining current and prior host names and database name.
Then within the cPanel “MySQL Databases” tool, I created a new database user, added him with all privileges to the newly imported database.
WordPress. Next up, edit the wp-config.php file for WordPress on the target server so it uses the new database name, database user and password you just set up. This is a standard setup task for WordPress.
Email. Remember to recreate your email users and forwarders on the new server. I had very low email usage, so this was fast to do manually. If you have a more serious email infrastructure, this part of the move is more delicate.
Remember your end-users SMTP and POP3 server names are likely to change, they may use the name of the new shared host or of the hosting provider itself. The end-users will likely have to change their settings. Plus they’ll have new passwords.
To move the server-stored email, I created a new user on the target server with the same username as on the source server. I then created email accounts on an end-user device (Apple mail app in my case) for both old and new server – this was possible because the POP3 server name was different, on source it was mail.mydomain.com and on the target it was mail.liquidweb.com.
I then simply dragged the emails from one account to the other, within mail app. I also moved sent mail and drafts. Like I said, this isn’t a scalable process for a big user base. I only had one IMAP user. But it worked very quickly. (I did read about moving the accounts mail directories as an alternative method for larger migrations, but wasn’t sure my Linux skills were up to it.)
I verified results using the host providers webmail interfaces for the two respective email accounts.
Test. You can test WordPress can see the database by browsing it before you’ve gone live. Your hosting provider may need to set this up for you, but on mine the formula for the testing URL is below.
- ‘~MyNewAccountName’ is the name the hosting provider gives your shared host, shown in the top-left of the cPanel interface as your ‘home directory’.
- Your virtual domain files will be in a directory within your public_html directory, and it’s probably been given the name of your virtual domain.
- To test further, you can edit your local hosts file on your computer if you want to check the whole site, and force it to use the new server’s IP address to resolve your tested domain name, rather than checking the internet DNS. Your host provider may have a how to for this in their FAQ, here’s mine.
I still have to move a phpbb forum with its domain, and worry a little about it using hard-coded paths. I haven’t done that move yet, but expect the above process will work if I also carefully do a find/replace in every file of the installation for any paths which will have changed.
Finally, change the IP address for your website within Cloudflare’s DNS Settings for your site. Enter the IP of your new server. That’s it.
Since the TTL was short, very quickly you and the rest of the world will be hitting your new server, not the old one. Note if you try to do a IP address check on the new server, to verify it’s working, you may find it resolve to Cloudflare’s CDN network address range.