Site migrations can be a daunting task, and for good reason. Only a foolish business owner or SEO would take a domain migration or site re-design lightly. Done incorrectly, it will complete ruin your organic traffic. Done correctly, it might still hurt your organic traffic, but at least all the content will be in the right place. In this guide we will walk you through the most common scenarios for SMBs or blogs needing to migrate their site to a new domain, a new server, or migrate a re-design from a staging server. To that point, let’s take a look at these various situations.
Reasons for Needing a Site Migration
#1 – Moving to a New Server
Migrating to a new server is very common, especially for growing businesses or blogs. Often a site will outgrow it’s old bandwidth, or the owner will have a new focus on site speed or security and need to go with a new hosting provider.
Thankfully this process is usually the most straightforward, because the actual website is not changing at all, it’s just being hosted on a different server. In fact, many hosting providers provide free migration services when you sign up, so they can do the heavy lifting and deal with technical glitches that may come up.
However, if you need to, or choose to, do it yourself, the same principles apply to this scenario as the “Site Redesign/Staging Server” scenario.
#2 – Site Re-Design/Staging Server
This scenario is also very common. When a site is undergoing a large re-design (i.e. changes that can’t be done to the live site), its common that a “staging server” is set up to host the re-designed version of the site. When the site is ready to go, the re-designed site is migrated to the main server, i.e. it “goes live”.
This situation comes with some more risk to SEO. Re-designs that aren’t done with SEO in mind can have serious implications. Broken URLs, dropped meta data, content changes, all can have adverse impacts on a sites organic performance.
We will cover exactly what you need to do to minimize the chances of negative effects below.
#3 – Full Scale Domain Migration
This is a situation where a company decides to switch domain names entirely. This can happen for a number of reasons, including some very stupid ones. There may be legal circumstances (i.e. trademark issues), strategic re-branding (smart, data-driven), non-strategic re-branding (stupid, faith-based), or recovering from search engine penalties.
The first thing that needs to be said in this situation is that you must manage expectations around the effect of the migration on your sites organic traffic. There are numerous horror stories of sites that lose 20, 30, even 70 percent of their traffic after a re-design. As the CEO of HomeAdvisor (formerly ServiceMagic) said after taking a 50% hit post-migration, “we believe those costs [to traffic] are largely unavoidable“.
Let me repeat, even if you do everything right, spend a year planning and preparing, hiring multiple consultants and make no mistakes, you can still lose traffic if you change your domain name. It’s unavoidable.
Ok, enough warnings, let’s get down to the nitty gritty.
What all these Situations have in Common
All these situations share the same common factors, understanding these will make it much easier to understand what is happening when a site is migrated and how to handle your specific circumstances. So here’s the deal:
WordPress Websites (and most all websites, to be fair), after fairly simple creatures. They are comprised of:
- Code files (WordPress is run on PHP code),
- Iimage and media files
- A database (WordPress uses MySQL).
So as a simplification of what any site migration is, there are 3 key steps:
- Copying PHP Files and Media Files to new server
- (A big ol’ copy/paste can work fine here, just make sure it’s the same folder structure).
- Copying the Database
- This isn’t as simple as CTRL+C + CTRL+V, but it’s not very complicated either. You have to use a database utility to export and import the DB to your MySQL instance.
- Find and Replace on Old Domain Name/URL
- This is necessary everywhere except when simply moving to new hosting. With staging servers and new domain names, the URLs will be different (i.e. newDomain.com or staging.example.com), so need to be swapped out.
Make sense? Good, because with any luck we won’t have to personally do any of that junk. Why? Plugins!
Plugins to the Rescue!
WordPress has really spoiled the hell out of web entrepreneurs. Not only do we get a great CMS for free, but we have thousands of developers working tirelessly to make any conceivable issue solvable via a plugin. It’s kind of crazy.
Migrating your site is no exception, there are several plugins that claim to be able to migrate your site easily. Some do, some don’t. In my experience there is 1 clear winner, with another backup if necessary, and they are:
#1 – All-in-One WP Migration
This plugin is amazing. After using several plugins that ended up with random unexplained errors, or just simply didn’t do what they claim to do, this one was all it claimed to be and more. Made by the same people that brought the ubiquitous All-in-One SEO Plugin (which I still like better than Yoast, IMHO), they really take development seriously and you can tell by the professionalism of this plugin.
It is free, with some paid upgrades. Feel free to use the paid upgrades if you feel necessary, or to donate a few bucks to the plugin author, but in interest of the cheapskates like myself who don’t want to pay for anything, this guide will use the strictly free versions.
NOTE: There is a limit of 512MB. You can unlock this limit by paying a one-time fee of $69. For many small-ish websites this is going to be plenty of room.
#2 – WP Clone by WP Academy
This plugin was the first one I used, and it does a solid job. The one big caveat I have is that it does not work at all when I’m using cloud servers (like Digital Ocean, etc). It can also error out on large site migrations (an issue which does not occur with the All-in-One plugin, perhaps because they use chunked loading).
Nonetheless, it’s free. It also does have some modicum of support (i.e. you can leave a question and the developers will get back to you, eventually). However all-in-all I wouldn’t count on having your issue solved.
Moral of the story, If you are having issues with another plugin, give this one a try and see if it works.
Step-by-Step Migration Guide
Ok, enough build-up. Let’s do the actual migration. Make sure you have your Mise en place, i.e.:
- WordPress AND your favorite plugin installed on BOTH the source and destination servers.
- A handy FTP utillize like FileZilla, along with your FTP login info for your destination server.
- This step isn’t necessarily required but makes things MUCH easier with larger sites that could freeze your wordpress upload utility.
- Access to your HOSTS file (required for proper QC of migrations to new servers).
Step 1 – Export Your Site
The first step to export the site you wish to migration. The plugin makes this super easy, i.e.:
- Find and Replace – You might think you will need to add in your domain name here, but I’ve actually found this part unnecessary in many cases. It’s important in case you want to change Brand Names or swap out any other text content within the database, but it seems to do the URL part on its own. Don’t worry, we will make sure everything is working fine before anything goes live.
- Advanced Options – IMPORTANT TO NOTE: if you are not changing your domain name or your e-mail addresses, you should check “Do not replace email domain”. This shields you from an annoying bug once you’ve migrated the site.
- Export To – Here you have the option of exporting to a file (Free option), as well as many different cloud providers. All the cloud providers are paid extras so we will opt for File export.
After clicking Export to -> File, we get this screen:
Here you need to download the export of your site (it’s a single file in .wpress format). This could take a while if your site is very large. Make sure you get this file downloaded fully, as its the most important part of this process.
With very large downloads this can error out on you. The .wpress file has been generated, but actually downloading it via your web browser can be iffy. For this we will utilize an FTP Client like FileZilla.
Step 1A – Exporting Site via FTP
Login via FTP
To do this you need to login via FTP to your site. This is fairly straightforward, I use FileZilla.
The login credentials are usually the IP of your site, and the same username/password as your cPanel.
If this doesn’t work, or you don’t know where to start, try contacting your Hosting provider for some guidance. Every hosting situation is similar, but different, so I can’t provide exactly guidelines here.
Download the File
Once you login via FTP, it’s as easy as tracking down the .wpress file and downloading it.
Where is it? Well, if you hover over the download link in the previous image, you will see exactly where on your server the .wpress file is hosted, for me it’s in this path:
/wp-content/ai1wm-backups/www.darbyhayesconsulting.com-XXXXXX-XXX-XXX.wpress
Clicking through on my FileZilla I can see it like this:
And your done!
For very large files this is likely preferred to trying to do it via your web browser.
Downloading large files via FTP (the File Transfer Protocol), is much stabler then using HTTP, since FTP it was built for this sort of thing.
Ok, we have got the .wpress site in hand. Let’s get it to the new server and get this over with…
Step 2: Upload to Destination Server
Here we have to switch over to our destination server. Remember you should have WordPress AND the All-in-One Migration Plugin installed on this server already.
Easy as pie, simply select “Import” from the All-in-One WP Migration menu on the left hand side, and you will be presented with this:
Again you are presented with a variety of cloud options to upload, but if you are choosing the free “File” method, simply choose the file you downloaded in Step 1 and upload it here.
As before, for very large sites this can error out on your, if that’s the case, see the FTP method below.
Step 2A: Importing Site via FTP
Following the same steps as Importing Site via FTP, you need to login via FTP to your destination server.
Once there, you need to track down where to put the .wpress file so that the plugin can access it.
NOTE: YOU CAN’T PUT THE .wpress FILE JUST ANYWHERE. IT’S ONLY ACCESSIBLE FROM THE DESIGNATED PATH.
Where is the designated path? Just as before, it should be here:
/wp-content/ai1wm-backups/
If that folder isn’t created yet, go ahead and create it.
Upload the .wpress file to that directory.
Once that is done, you should see it populate in the “Backups” section of the All-in-One Migration Plugin:
Clicking that big button “RESTORE” is the last thing you need to do to import the the site.
Back to regular scheduled migrating…
Once uploaded (or “restore”, depending on which upload method you took) you will get this scary message:
It’s scary for good measure, you are about to wipe out this WordPress instance and replace it with your new data.
If this isn’t a brand new WP instance, make sure to backup everything thoroughly.
AGAIN: MAKE SURE TO BACK UP ANYTHING YOU CARE ABUT ON THIS WORDPRESS INSTANCE.
Sorry for yelling. Now that we are good with pressing that big button, let’s do just that:
Follow those few steps, and you are all done, right?
Yes and no. A few things to clear up:
Some Housekeeping
- E-Mail Addresses
One thing I’ve noticed on many migrations with this method is that Email Addresses within the content will get prefixed with “www”. I.e.: [email protected] will become [email protected]
You will likely need to go in and manually fix these.
As mention above, in the Advanced Export settings you can set it to “Do not replace email domain (sql)”. But even after that I suggest you do some quick manual checks to make sure everything is correct.