Last week I made the decision to move my blogs from shared hosting to a virtual private server (VPS). While I’ve had self hosted blogs for a number of years, I still find myself learning new things all the time, and this was especially true when moving VPS. In my case I was only moving WordPress blogs. I can’t speak to the steps for other types of sites.
Why move and why VPS?
I had considerable problems with uptime during the month of December. Even when my traffic wasn’t particularly high, my site was going down. When I’d submit a trouble ticket, my hosting company at the time would inform me that it was my sites bringing down the server. They suggested I move to a more robust and more expensive VPS solution.
Now I’m not going to bash my former host, they were generally good. But when things would break, they would continue to break for several days or weeks. Finding a true fix didn’t seem to be their strong suit. I wasn’t particularly satisfied with their responses to this situation so I also decided to find a new host.
I set about on a search for a new host, and did some Googling. But I found Twitter to be a valuable resource. After posting the question about hosting providers I received a number of responses that helped me narrow down my search to a couple providers.
I ultimately chose LiquidWeb for 3 primary reasons:
- They offered a managed VPS solution. I’m not a server admin and didn’t want the responsibility for maintaining my server. That would be a recipe for disaster.
- Their support came highly recommended. This was evidenced when I first went to their site and a chat dialogue opened where I could talk with a sales rep about my needs and they could help me in my decision.
- They are a Michigan company. I’m based in Michigan, and our state has had a rough go of it lately. Being able to support a local company was definitely a factor for me.
Preparing to Move – Get Your New Service
The timing was fortuitous. If I’m making structural changes to my sites, the week between Christmas and New Year’s is definitely preferable. I’m off work, and so our many other people. So I have time, and not many people are coming to my sites anyways. When stuff goes wrong, I can respond quickly and not as many people notice.
Step one is to sign up for your new service. You’ll need a destination for everything. Things here will probably vary based on the host you choose. In my case I specified a main domain at the time of sign up. Once my server was set up, I then needed to create my other domains on the server. This includes creating the domain, and typically creating accounts for email addresses, FTP access, and SSH access.
Ideally, you don’t have to make DNS changes at this point and you can access your new server via the IP address they provide.
Collect Your Old Stuff
There are two main components to a WordPress blog, the wordpress installation itself (these are all the files on the server) and the MySQL database. I’ve found the quickest way to ready everything to move was via shell access.
I had never accessed the shell prior to this. You want to be careful because you can really break stuff, but we’re just going to use a few commands that will really make the process go quickly.
If you don’t have it already, get PuTTY which is a program you can use to access your shell. Once you have it downloaded and installed, start it up. For the host you’ll enter the server where your stuff is (this is the old server). If you’re self hosted (and if you’re not this whole article doesn’t really apply), you should know this from FTP’ing in the past. If you’re unsure contact your host for instructions on how to log in to SSH.
Once you’re logged in, the first thing to do is to navigate to the directory where your blog is. This is command line stuff, like DOS, but don’t be scared. To see where you are initially just type in
That will list the contents of the directory where you are. To move into a subfolder just use (and replace DIRNAME with the folder you want):
Once you’re at your WordPress installation, we’ll get a dump of the MySQL database. To do this, you’ll need to know the database name, the server, the username, and password. If you don’t remember this information, it is all in your wp-config.php file. To get the dump, enter the following, replacing the capitalized items with the appropriate terms (FILENAME can be whatever you want, just remember it) :
mysqldump –u USERNAME –p DATABASENAME > FILENAME.sql
You should now have a SQL file containing your database. To make sure it’s there you can use the ls command and it should be listed.
Next we want to compress all your blog stuff, and your SQL file into one file so it is easier to transfer. We’ll do this in SSH also. Assuming you’re in the correct directory, this will put everything into a file called blog.tar.gz
tar cvzf blog.tar.gz *
Again, you can check to make sure the file is there using the ls command. If it is, you’re ready to transfer things over.
Making the Move
At your new host you’ll need to create a database. This can usually be done through the control panel. In addition to creating the database, you’ll also need to create a database user account and a password. In the case of cPanel, which is pretty common, here is a tutorial.
Now it’s time to access your new host via SSH. You’ll want to do this with the IP instead of the domain name if possible. For the account information you should have already set this up.
Once you’re in, the first thing to do is to get to the directory where you want your blog installation to go. This may be something like public_html if it goes at the root, or you may need to create a sub folder like /blog.
Assuming you’re in the right spot, we’ll transfer in the blog.tar.gz file we created earlier. To do this use the following command:
You’ll then be prompted to log in to your old account. Upon successful login use the command:
It will transfer the file to your new server. You can type exit to leave the ftp prompt.
Next unzip the file using:
tar xvzf blog.tar.gz
You can check and see if everything came over by using the ls command.
The next step is to import your sql file you created earlier, into the database you just created. It’s another one line command:
mysql DATABASENAME –h DATABASEHOST –u USERNAME –p PASSWORD < FILENAME.sql
If everything worked, you should have a duplicate of your blog on your new server. If you can access the site via IP, you can test things out.
Make the DNS Change
If you’re confident (or semi-confident) everything is set up correctly, you can go to your domain registrar and change the nameservers to those provided by your new host. Within 2 days everybody typing in your domain should be getting your new site. Then you’re done. Woo Hoo!
Those are the steps I followed, but I did encounter a few hiccups.
- File permissions I ran into problems with the wp-cache plugin, as well as the file uploader because the wp-content folder wasn’t writable. One way to fix this is to change the permissions to 777 which means anyone can write to it. This is not the preferred method because it causes security problems – in that you become very vulnerable. What my host did to fix this was to install the suPHP module. This solved the problem. I won’t get into the details, but it has to do with file ownership.
- .htaccess For some reason the .htaccess file didn’t get included in the compressed file for the directory. So my permalinks went away and quite frankly wouldn’t work. I just copied over the .htaccess file separately.
- DNS lag During the DNS move, I found myself not knowing if I was on the old or new site and it seemed to change. A quick check is to open up a command line on your site and type in ping hostname.com The results that come back show the IP so you know if you’re accessing the old or new site.