Well my friends, the time has come for us to upgrade to a larger server to accommodate all of our content and traffic. Oh… happy day. As excited and grateful as I am, we’re now faced with the unpleasant task of server migration. If YOU are faced with this task, I suggest hiring someone else to do it – but if you don’t have that option, here are the steps I took to get this done as effortlessly as possible.
*Disclaimer: this involves effort no matter how you do it.
Here are the specifics of our move.
- The server is a Linux VPS setup. Your setup may vary, but the main principals shown here should help you keep things straight at the very least.
- There are several email accounts associated with this domain.
- The blog is installed locally and since it is WordPress it runs off a database. The website should be an easy move – the blog will be a little more complicated. My goal is to show how to migrate without copy & pasting EVERY post, re-uploading EVERY image… and so on.
- WordPress offers extensive documentation on this subject, I am simply providing a condensed version to help you avoid the mistakes I made my first time through.
1. First off, let’s do this… update to the latest version of WordPress and BACK UP EVERYTHING ON THE OLD SERVER. Save it locally, and keep this in mind – YOU DO NOT NEED TO DELETE ANYTHING FROM THE OLD SERVER. You will be able to see if the new server / site combination is working without removing the old site files.
*If you need the space, then by all means delete the old files after you are 100% certain the new setup is functioning correctly.*
2. Be safe and back up everything again.
3. Prepare the new server for the website by creating the new domain directory. This creates a new “virtual host” with the setup we have, placed automatically within the “www” directory. You may also wish to recreate any email addresses that are associated with this domain at this time.
4. Place your “old” website files – not the WordPress files – within the new directory. Move everything except the folder(s) titled “WordPress-3.1″ or something similar.
5. Test the new website files by adjusting your local DNS settings. This is a good trick to know in general, and can be done as follows on a windows machine.
- Navigate to “C:\WINDOWS\system32\drivers\etc\hosts”
- Make a copy / backup of this file.
- Open the original file with a text editor like Notepad++.
- Enter a new line after “127.0.0.1 localhost”.
- Type the new server IP address and domain you want to associate it with. In our example we want to test the same domain name but look to the files on the new server:
- Save the file (in some cases you may need to save as a .txt file, then drop the .txt extension off the new file you created).
- Open your browser and navigate to the domain. Remember “mysite.com” and “WWW.mysite.com” are different.
- After testing, open the “hosts” file and delete the line you created. Save.
*During this process, I adjusted the hosts file multiple times to test as I went. You will probably find yourself doing the same as you progress.
6. If you use PHP like I do (index.php instead of index.html) when you test your site you will only see text. This means that you may have to install PHP on the new server to view your site.
So, install PHP on the server now – in my case this involves the command line and accessing the server root with a small program called putty.exe
Once PHP is installed, reboot your server and head back to your “new” website IP address (you may need to re-adjust your local hosts file) to confirm that the changes took place.
Looks like it’s supposed to? Good, now go back and remove the changes you made to the local hosts file and save. If you don’t undo your changes each time you test something you might forget you changed it in the first place and get all mixed up. I did a few times while writing this.
7. Now let’s move on to WordPress. In our case we want to install a new version of WordPress on the new server since we do NOT want to use the old database location. We also want to keep all of our content and posts and use the same logins and page style and so on.
If you want to skip the hard stuff at this point, you can always browse the list of plug-ins WordPress users provide – but I prefer doing it step by step to make sure everything is correct as I go along…
The vast majority of the content is stored on the server, and we already have that backed up locally (as per steps 1 and 2). But this is where it gets a little tricky: PHPMyAdmin and the MySQL database that the blog run on are on server 1. We want all this stuff running off of server 2. But what if we mess something up? Well, this is why we are not going to delete the first blog until we know this transfer completes correctly – remember we can test by periodically adjusting the local hosts file. Let’s begin.
8. Back up the WordPress database currently on Server 1 – I used PHPMyAdmin – detailed instructions can be found here, along with other methods. Remember – you have NOT backed up the files and folders – such as images in the Media Library – but all your posts, users and comments are now safe. Also, since users are stored within this database it means that existing contributors don’t need to change anything (like passwords) after the transfer. Sweet.
SO – note that at this point ALL of our images, themes, posts, comments – everything – is backed up in one way or another AND still located on server 1 just in case.
9. Install a new WordPress site or blog on server 2 – in my case this again involves the command line and an assisted install (vinstall). Your install method may be different, and detailed instructions can be found here. Conveniently, in my case the vinstall noticed that MySQL wasn’t on the server yet – so it initiated, created my WordPress database, and asked me for a MySQL root password. Then it confirmed that PHP was installed, and asked what directory to place the new WordPress site in, as shown.
BEFORE YOU LEAVE, do a quick check to make sure that PHPMyAdmin is installed – usually you log in to it to manage your databases with “root” as the user and your MySQL password. Then exit, change your local hosts file if need be, and see if the new blog exists.
10. Log in to the new WordPress database and import your content / backup. This way we can make sure that you have all your users, posts and comments before moving on to fixing the style and missing images and plug-ins. Detailed instructions can be seen here. In my case I used PHPMyAdmin, so it’s a quick log in, select the database, click import, browse to the old backup and click “Go”… well… it’s quick if your settings are correct. Mine weren’t.
11. Fix your PHPMyAdmin / database upload settings if need be.
I was unable to import my database initially.
Here are the steps I took to make things work.
Make sure that both servers are using the most recent version of PHPMyAdmin. Server 1 had an older version installed. I updated PHPMyAdmin on server 1, exported my data again, and retried the import on server 2.
My import STILL didn’t work yet because the default setting for file uploads was a measly 2MB. My database was 3.3MB, so this caused an error. To prevent this you need to edit the php.ini file on your server (detailed instructions here).
If you want to find it quickly you can do a command line search. Open another PuTTY session and type “find / -name php.ini”. This will let you know where this file (or files, if for some reason there are multiple with this name) is located. Mine was located at “usr/local/php5/lib/php.ini”. You may have to use your servers file management tool to get at this file – I couldn’t retrieve it via FTP. Open the file after backing it up and navigate to “upload_max_filesize”.
*Be careful you don’t type “6MB” instead of “6M” – unless in your php.ini file the initial value is listed that way.
So there was my problem – my database was larger than 2MB. While editing the php.ini file double check to make sure that that “post_max_size” and “memory_limit” values are larger than “upload_max_filesize”. Save changes, reboot the server, and go back in to PHPMyAdmin to import your old database into the new one – you should notice your changes on the import screen.
12. Now try to import your database again. Make sure to do a complete wipe and import, meaning DROP all the tables from the server 2 database, and then import all the tables from the server 1 database.
13. Why is my blog blank?? Well, it’s not really, but after these steps the first time you load up the blog on server 2 you might see a blank screen – don’t freak out. Your imported database kept track of the latest theme you had selected, so if that theme is not on server 2 yet, you will only see a blank white screen. Just log into your new blog real quick and change the theme to default (whatever that is).
*Again, note that all of this “log into the new blog”, and “log into the old blog” stuff requires you to edit your local hosts file as mentioned above.
14. After logging in you should be prompted to “update your database”. This is good – do this now.
15. Now you can select one of the default WordPress themes after your database has updated. Then head back out to look at the blog. You should now see all your posts and comments, as well as some kind of messy layout.
See your posts and comments now?
They probably look like crap right?
Especially if you were using a custom WordPress theme, so let’s fix that.
16. Head to your dashboard and update to the latest version of WordPress. Make sure to USE YOUR NEW IP ADDRESS AS THE HOST NAME.
Now, remember way back in the beginning when you updated WordPress on server 1 to the latest version before you backed everything up? It was to make sure your folders matched up for this next step…
17. Upload all of your backed up files to the new server (this would be the folder titled “WordPress-3.1″ or something similar). Put the whole enchilada up there – EXCEPT FOR THE “wp-config.php” FILE – if you overwrite that nothing will work. Overwrite everything else… then hurry up and wait.
Now check out your blog again. You should notice that several of your plug-ins and images from the Media Gallery have started to work.
Log back in and select your preferred theme (which should now be available to you), update all of your plug-ins (which should now be working) then check out your blog (which should now be displaying properly).
Are we done?
No, we have 2 more major steps.
Your blog should allow you to write new posts at this point, assuming you were able to do that on the old blog. In my case I had added a few .htaccess files which allowed me to “write” and create custom permalinks (see details here). They were copied over with our move and I was able to create new posts immediately since my local hosts file was pointing at the new IP.
The next crucial step was a DNS update.
18. In order to direct the general public to our new blog we need to update out DNS Zone File for this domain (since the DOMAIN has not changed, just the SERVER) – we need to adjust the A Record and plug in our new IP Address. This change will show our “new” blog to the world, but it can take as long as 72 hours to take effect. Change your A Record now, and come back to finish up when the change takes place at your service provider.
*You can check the nameserver status by opening a command line and “pinging” your domain. It will return your IP address – when you see the returned IP matches the new IP, you are good to go on your LOCAL machine after you clear your browser cache. Other people in other locations might still be seeing the old site.
After this change if you can log in and add posts, users, and images – good for you, you’re done.
19. If you can’t add images you may need to adjust the folder permissions on your new server. Detailed instructions can be found here, but let me break it down for you. In this example we are using Filezilla as our FTP client.
FTP in to your server and navigate to your “wp-content” directory – in my case the location is “/home/adminname/www/hauserdesigngroup.com/wordpress-3.1/wp-content/”.
You should see several folders: “languages”, “plugins”, “themes”, “upgrade” & “uploads”
This is where WordPress should be attempting to upload images, and probably with no luck at this point. You can check this by logging in to WordPress as the admin and going to Settings > Media. The field “Store uploads in this folder” should be blank or say default “wp-content/uploads”. When you try to upload you might see something similar to: “Unable to create directory. Is its parent directory writable by the server?”
In my case I did NOT get an error, the file appeared to upload and I could see the file name and any alt text I added – but no thumbnail was created and no image file was uploaded to the server.
Click back over to Filezilla. Do you see how each folder has a number to the right of it? This represents the permissions granted to users for each folder. In our case every one is set to 755. We want to set this to 775 to give broader write permissions to the uploads folder. However, when I did this folder-by-folder manually it did not fix the problem. What did fix the problem was right-clicking the uploads folder (in Filezilla) typing in 775 and checking “Recurse into subdirectories” and radio button “apply to directories only”.
777 will also work, but it allows public permissions too, so avoid this if at all possible. Also, if you try to upload an image to a post that was created before you made these permission changes, it still won’t work – but if you “save draft” and try again it should.
Now for me at this point everything works properly, I can read, write, comment, log in, edit and so on just as I could before – and the best part is that I have moved all of my old content. My DNS has also propagated, so I can test the email accounts I added way back at the beginning, and test the website – forms etc. – extensively.
20. Since my testing checks out, it looks like we’re done.
So as I said if you have the option – hire someone who has done this before. If you don’t, just read this carefully and go slow. Back up often and you’ll be fine. There is a plethora of online documentation out there, and the information I’ve gathered here came from my own experience and all over the web. Hopefully it helps you save some time… because this truly can be a pain in the arse.
Happy blogging… & good friggin’ luck!
About AJ Hauser
AJ Hauser owns and operates the Hauser Design Group. He has worked with several small and medium sized businesses as a marketing consultant, and is a passionate disciple of design, branding, SEO, social media marketing, web standards and development. His portfolio features work from both local and national brands, and he can't wait to hear from you.