As part of the move to a new hosting provider I had to move my WordPress install to the new host. This proved easier than I expected and was problem free. My site was hosted on a shared server with Bluehost and I moved to a Virtual Private Server (VPS) at Slicehost. My site is registered with a 3rd party registrar but the DNS was managed with Bluehost. If you’re moving to a shared host or your current host is also your registrar you may have to handle DNS differently than I did, but the rest of the procedures should work just fine.
Prepare the New Host
My old site was already on the latest version of WordPress with updated plug-ins so to prepare the new site I just:
- Configured Apache to serve osquest.com and create the basic directory structure.
- Copy the WordPress install files to the root directory of my new site (they were in the root of my old site – the root of the site, not the root of the server)
- Copy the wp-content and Mint directories (and all their subdirectories to my new site). This includes the templates and plug-ins along with the images I’ve uploaded.
- The DNS entry still points to the old host so I edit the hosts file on the server so it points the domain to its own ip address. (See the Editing Hosts File section below for more information.) This may done differently depending on your host. Apache probably would have looked to itself for calls to the domain once I was in the website but I wanted to be sure it worked for all software and plug-ins.
- Change the hosts file on my local computer so it goes to the new host’s ip address for the domain. Since I run virtual machines on my Mac I made the change on one VM so I could access my new site through it, while still getting to the old site from the Mac itself.
- Install WordPress to create the basic structure. Instructions may vary by host, I used the standard WordPress install instructions. It isn’t necessary to duplicate the database name or user ID used on the old site. I used different different database and database user names without a problem. I went through the basic settings and made them match my old blog (this may have been unnecessary since I’d be restoring the DB but I wasn’t sure).
Backup the Old Site’s Database
I used the WordPress Database Backup plug-in to do the backup. After the database is backed up any changes made to the old site will be lost. This includes:
- New Comments (unless you use a third-party commenting service)
- New posts (easy enough to prevent)
- Modified posts (also easy to prevent)
- I use Mint for website statistics. Since these stats are kept in my WordPress database I’ll lose any data collected between the new backup and when the new site is active. While I could minimize this by doing this backup and restore later in the process but I decide to take the lazy easy route and do it with the rest of the WP database.
I’d had problems using older versions of the WP Database Backup Plug-in in the past so I haven’t been using it. The main problem is that my host would complain about CPU usage and cut me off. But this was a much newer version than I used in the past. Plus I figured I could backup a few tables at a time if I needed to. I wanted to avoid using the export command to get just the posts and comments.
PHP does have a file size limit on restoring the SQL data that I’ll hit in the restore section. Because the new host is totally under my control I’ll be changing this limit. If you’re moving to a shared host you may not be able to change this limit which was 2MB for me on Bluehost. If this is the case you may need to break up the tables into multiple backups.
Exclude Spam and post revisions from the backup. I don’t want them and there’s no need for me to take them with me. I didn’t take all the tables associated with plug-ins. Some were associated with plug-ins I no longer use. In the case of the search tables I still use the plug-in but I didn’t care about the search stats and it was easy to rebuild the index after the move. I included the Mint tables but not the mint backup tables. (Click the pics for full size)
When I clicked the Backup Now button I saved a 8MB file (compressed) to my hard drive. I extracted the file to my hard drive so I’d know the actual backup size, which was 12MB.
Restoring to the New Host
For this part I use my virtual machine that has the edited hosts file to connect to my new host when I use my domain name. I’ll be using phpMyAdmin to do the DB restore.
First I configure PHP to handle my 12MB file. Actually, since I’m the only server user I just configure it to accept a 25MB file. This is set in the php.ini file. To locate the php.ini file on your server you can create a file called phpinfo.php (or anything you want as long as the extension is .php) with the following contents:
Copy this file to your web server and load it in the browser. Among the data reported will be the location of php.ini. Delete the phpinfo.php file from the server when you’re done so info about your server can’t be easily found.
I open the php.ini file on my new server and change it to use the following values:
post_max_size = 25
upload_max_filesize = 25
I also change
max_execution_time = 120 as a safety measure but I return it to the default of 30 when the import is done.
After making these changes I reload Apache so they take effect.
I then load phpMyAdmin in my browser, select my WordPress database, and select the import tab.
I browse to the backup file that I previously downloaded to my PC as the file to import. I leave the rest as-is and click “Go”. The import is done in about a minute.
At this point my WordPress IDs and passwords match my old blog, not what I used during the new install. I logon to my WordPress admin panel and check things out. My plug-ins are all active and seem to be working just fine. All my posts and comments seem to be there as the total counts match the old site.
I had changed some of the privacy and discussion settings during my site testing (to not ping other sites or search engines). These weren’t overwritten by the restore so I switched them back. Everything else seems fine with no additional work or tweaking needed so I move on to updating my DNS to make the new site active. (I still haven’t finished the Mint move but I’m going to do that later since I’m not sure what will happen when it wants to validate my license.)
I go to my domain registrar and point the domain to the Slicehost name servers, replacing the Bluehost name servers. I also set up the DNS records on the Slicehost side. How this is done will vary by your registrar and hosting provider. Slicehost provides excellent DNS administration documentation. I don’t delete the DNS records from Bluehost at this time. Even after the the DNS name server change replicates I’ll still be able to access the old Bluehost site using a entry in my local hosts file.
It will take several hours for the name server change to replicate (up to two days is given as the typical delay). Even if I see the change on my end there may be other people out there who still go to the old Bluehost site for those couple of days. They’ll still see a site since it’s still active on the Bluehost server.
Telling Mint It’s Moved
I make this change right after updating the DNS name server record so the change hadn’t replicated anywhere yet. So it doesn’t appear the license validation has a problem and I could have done it earlier. To be safe I probably should have waited until the name server update had replicated, but I didn’t and it worked.
I’d already moved the Mint files themselves so all I needed to do was edit the
db.php file to connect to the new database since I’ve change the DB name and the DB user name. After that I visited
mint/?moved (with my browser) to let Mint know that it was moved. After this everything worked fine and it started collecting statistics when I tested. Because DNS hadn’t replicated yet it was several hours before I started getting any live statistics.
The Mint forum has a sticky posting on how to move Mint to a new host.
At this point the move is complete. I just need to wait for the DNS name server change to replicate. I can use my VM for testing until then because the hosts file directs me to the new host. It took about 6 hours for me to see the change and I saw visitors coming into the old site for about another six hours.
Once the DNS name server change replicated I edited the hosts file in my VM to point to my old Bluehost site so I could access it if needed. So far I haven’t deleted any files or modified any configurations for the Bluehost site.
The last section just provides more details on using the hosts file to pick which host I want to connect to without regard to the DNS settings.
Editing Host Files – Faking DNS
I was able to use hosts files on my PC (actually a virtual machine) and my web server to direct my domain to a different server than the “real” DNS entry would send it to. This allowed me to access the new site for testing before changing the DNS name servers themselves and still connect to my old site after the DNS changes propagated. This is easy enough to do. On Windows the hosts file is in
[Windows]System32Driversetc. On my server it was in
/etc. Both are text files and use the same format and in both cases (I’m using Vista in my VM) an administrator needs to edit it. I got lazy and changed permissions in Vista so I could edit it with my regular ID.
The Windows hosts files contains some example entries that can be used as example. For my website I added these entries to both my PC and the new server’s host files:
I added entries for both the root domain and the www sub-domain.
If your moving to a shared host you’ll have to check with your hosting provider to see if you can modify DNS before the name servers are updated. I didn’t modify (delete) my domain settings for Bluehost after I moved the site. I was still able to update the access the site with the host file pointing to it. But, if I was setting up a new site on Bluehost I would have had to go through a verification process but it does not appear they require that the DNS servers be updated first.
Other hosting providers may just require you wait until the DNS servers are updated. If this is the case then you’ll have some down time between the DNS change and when you get the new site up.
All-in-all it was a painless move since the backup & restore worked just fine. Key points are to make sure all the software is up to date and to maintain the same directory structure (if at all possible). The other potential problem is the size of the backup file that you’ll be importing so be sure to check for this limit on you new host before you begin. You can pull up the phpMyAdmin or WordPress import screens which will both give you the maximum file size.