Website migrations can be stressful, but it doesn’t have to be. I’ll walk you through four different ways to migrate your site based on your unique situation.
- Automated migration to a new server
- Manual migration to a new server
- Automated migration to live server
- Manual migration to live server
Moving to a new server
It’s much easier to launch your site on a new server than to launch it on the one hosting your live site. With a new server launch there’s no downtime for your website.
You can take your time to make sure everything is working, and only then update your domain’s DNS settings. Users will begin to see the new site as the DNS change propagates, with most seeing it within a few hours.
With a new server, you can take your time to make sure everything is working, and then update your domain’s DNS settings to seamlessly transition with no downtime.
Automated migration to a new server
Many webhosts have automated tools to help you migrate your site.
If you’d like to use WPEngine as your new host (I recommend it), you can use their automated migration plugin.
I use WPEngine as my development server and migrate all my client sites using this plugin before starting work on their redesign. It works great, even for very large sites.
- Purchase your new hosting plan
- Log into My WPEngine, and click SFTP in the left sidebar
- Add an SFTP User and write down the Username, Password, Server Name, and Port Address.
- On your live site, install the WPEngine Automated Migration plugin.
- Click “WPEngine Migration” at the bottom of the admin bar menu and you’ll see this screen.
- Type in your email address, WPEngine URL (yoursite.wpengine.com), and your SFTP details
- If your WPEngine install is password protected, click “My site is password protected” and type in the username/password. All transferrable installs are password protected, and this can be found in My WPEngine on the Overview page (screenshot).
- Click “Migrate” and wait for the migration to complete! You can close this window if you’d like. They will email you when the migration is finished.
For hosts that don’t have an automated tool, you can use Migrate Guru. The steps are similar to the WPEngine ones listed above. You can also try the Duplicator plugin – see this tutorial by WP Beginner.
Once the site is on your new hosting environment, it should be accessible from an internal URL like yoursite.wpengine.com. You should confirm that the site looks and works correctly.
You’ll need to update the URLs in the site to match your live site. Either ask your host’s support to help you, or use one of these tools:
- Better Search Replace plugin
- wp cli on the server. Type
wp search-replace clientsite.wpengine.com clientsite.comwith the first one being the temporary URL and the second one being your final URL. If you’re using WPEngine, you can click the “Advanced” tab to access wp cli (screenshot).
Finally, you should update your domain’s DNS settings with your domain registrar (ex: Godaddy) to point to your new host (more information).
Manual migration to a new server
A manual migration is pretty straightforward. Assuming WordPress is already installed on the server, you simply need to move all the site’s files (the wp-content directory) and the site’s database.
It’s easier to move one large file than lots of little ones. I like to package the wp-content directory into a tarball, then upload that to the server.
In my local copy of the site, I run tar pvczf wp-content.tar.gz wp-content. That compresses the entire wp-content directory into a single wp-content.tar.gz file. I then upload that directly to the server.
If I have SSH access, I’ll delete the existing wp-content directory, then run this to unpack the file: tar zxf wp-content.tar.gz. If I don’t have SSH access, I’ll ask the host’s support to unpack it for me. You might also need to ask them to update file permissions.
There’s a few ways you can migrate the database. You can log into phpMyAdmin on the server and manually upload it, but if it’s a large database it will time out before it’s fully uploaded.
If you have SSH access, you can upload the sql file to the server, then run mysql -p u username database_name < file.sql to import it. Tip: do the same tar compression shown above. SQL files compress super small.
Once uploaded, use Better Search Replace or wp cli to update the URL (see above).
I personally prefer using Migrate DB Pro to move databases. It works in all situations – I don’t need SSH access, and I don’t have to worry about the database size.
Install the plugin on your local copy and the new server’s WordPress install. Log into the new server, go to Tools > Migrate DB Pro > Settings and copy the Connection Info. On your local site, go to Tools > Migrate DB Pro, click “Push” and paste the connection. You can even tell it to update all the URLs before pushing to the server.
Once all the files and database are in place, test to make sure everything works, then update your domain’s DNS settings to point to the new server.
Migrating to your live server
This is more complicated. You need to have a solid plan in place – make a checklist so you don’t forget anything – and work fast. If you do it right, you can minimize the downtime.
Automated migration to live server
You could use the exact same tools shown above for the automated migration to a new server. But I’m personally afraid to let an automated tool start overwriting the database and files on my live server. If something goes wrong, there’s no “off” switch to stop those tools.
Any time I’m migrating a large site back to it’s original host, I speak with the host directly about setting up a staging environment. We then migrate to the staging environment, exactly like the new server approach above.
Once the site is setup (staging.clientsite.com), we ask the host to flip the switch. It usually takes about 30 seconds and they’ve swapped the files and databases for the two sites.
This depends upon having a high quality host who can provide this level of support. When working with lower tier hosts, I typically do a manual migration.
Manual migration to a live server
The goal here is to minimize downtime by getting all the pieces in place before making changes visible to users.
First, upload the wp-content directory to the server (same as the manual approach described above), but use a different name for the directory. I typically call it wp-content.new.
Determine how you’re going to migrate database: via phpMyAdmin (make sure the database is much smaller than the max upload size), SSH, or Migrate DB Pro. If SSH, upload it to the server so it’s ready for you.
Rename the current wp-content directory to wp.content.old, and wp-content.new to wp-content. There should be minimal disruption at this stage since all the themes, plugins, and uploads from the old wp-content directory should already be in the new one.
If possible, create a second database on the server and upload the new tables there. Toggling between old and new versions of the site is as simple as changing the database name in wp-config.php. If you can’t create a new database, make a backup of the live database so you can restore it if something goes wrong.
Change out the database and make sure everything looks good. If something looks broken, rename the wp-content directories again and quickly swap out the database so you’ve restored the “old” version, then figure out what went wrong.
Tim Osborn says
I’ve been doing so much of this lately, and am still settling on a solid workflow.. I’ve been trialling backupbuddy, (when its good its great, but have found i often have to go back nurse the process depending on (? server config ?)).
It often seems too much hassle to manage getting SSH access for random short-job clients, so my alternative is to use the cPanel file manager to zip the wp-content directory, ftp the single zip file, then use cpanel to unzip it at the destination..
I’m developing my themes (using Genesis, Bones4Genesis and Core-Functionality) on XAMPP, and doing this migration to staging servers pretty frequently, and am desperate for a brain-free method of cloning to a remote host (from XAMPP!)… I’m also trying ManageWP, but my apache-fu is not equal to granting access via ports other than 80, etc ..
Any suggestions for a scriptable process / feedback ?!
Bill Erickson says
The way I outlined is the easiest solution I have found. My only other recommendation is to only develop in one location. You can build the initial version locally, but once you migrate to a staging server for the client to review, continue building it there. It’s just too difficult to keep them all in sync, especially when the client might add content to one and then it disappears when you bring over a newer version.
You could probably use version control to fix some of this, but that won’t keep the databases in sync and it’s usually overkill for most of my projects.
Tim Osborn says
Thanks.. my workaround is similar to your first response – after the initial clone, I generally only change the theme and a plugin or so, so Transmit sync sorts me out.. then I fix the db when its ready for the client (not ideal!).
I’m just getting into Git, but my shared hosting absolutely won’t install it.. I’m getting closer to moving to a VPS, but its scary!
Thanks for your consideration 🙂
(PS – I don’t see a submit button under this form!)
Bill says
Thanks for this — How might the process be different if you’re migrating a multisite installation?
Bill Erickson says
I don’t work on multisite projects so I’m not much help here, but I would assume the process would be the same.
Andrea_R says
It is the same. 😉
Paul says
I used to use the searchreplacedb script, but I found an easier way. I now use the WP Migrate DB plugin.
http://wordpress.org/extend/plugins/wp-migrate-db/
it just requires you to enter the old and new domain names and path to root, and does the search/replace and exports the database automatically.
then you just have to import it to the new DB. Saves a few steps.
I think, if you have ssh access to both servers, you can transfer the files directly from server to server instead of downloading first
Bill Erickson says
Very cool. I usually only have SFTP access to my development server. If I have it on their server as well I can log in and wget the tarball.
Jon Brown says
Great walk through Bill! I really like your reasoning about having unique table prefixes. I’ve used unique prefixes for each site for security reasons, but never thought of using as a quick roll back option. It does bring up an issue I’ve thought a little about lately which is merging new and old content. For example on a recent site redesign I needed to keep all the old site’s blog posts and comments, but wanted to replace all the pages, custom posts, menus and widgets… I ended up doing most of that merge manually… probably a better way but hacking it together in MySQL seemed to risky… I don’t know well enough what where everything is that spans multiple tables.
The one thing about this procedure I do differently is to rename wp-content before I change wp-config… it’s unlikely but the possibility exists for someone to hit /wp-admin and for WordPress to helpfully deactivate the non-existent theme and plugins.
Jon Brown says
proof read… THEN hit the post comment button! I always seem to do that backwards. :/
Cathy TIbbles says
Love that you include the last line – make visible to search engines – I’ve forgotten that MORE than once. So embarrassing!
Thomas Bock says
Bill,
Great tutorial. One question….You state in item ‘0 or 10?’ to change back to the old prefix if you encounter a problem. So when you change the prefix as described, the old prefix is preserved in the database and then deleted once everything is up and running?
Thanks
Bill Erickson says
Before you start any work, the old site will be up and running with their old prefix. Migrate a copy of these database tables to your development server, then change the prefix on your dev database. Then build out your new site on the dev server.
When you’re ready to go live, you are able to upload your new database tables into the old database since they have different prefixes. At this time you’ll have both the original tables and your new site’s tables in the database, and in wp-config.php you’ll tell WordPress which to use. If there’s any issues, you can go back to using the old tables while you figure it out.
Once the site is up and running smoothly, you can remove the old database tables and the old wp-content directory (renamed to wp-content.old in the above steps).
Thomas Bock says
Oh, you import from your dev ser. It is always nice having a backup.
Thanks
Gwen says
Hi Bill!
I’m an aspiring WordPress/Genesis Designer, and I have been trying to wrap my head around this post…
When you say “Migrating your WordPress Website” are you referring to moving it from your local testing server to and online demo site or your clients temp url?
Thanks!
Gwen
Bill Erickson says
I typically develop directly on my development server, so the migration process is usually my development server => client’s production server. But if I do decide to develop locally (e.g., at an airport right now developing locally), the migration process is exactly the same going from local installation => my development server.
Alex says
Dude. That searchreplacedb2.php tool freaking rocks! gonna have to tell the author about that! Good share as usual! Thanks.
Srikanth says
hello, i am trying to export from a self hosted wordpress site, to wordpress.com and i find that if i use tools->export on one end and tools->import on other end, many posts are missing.
I am not sure how to resolve this issue. please help me.
Bill Erickson says
Since you’re going to WordPress.com the only tool you have available is Import/Export. Try exporting in smaller batches, like all the posts from a single year, or from a single category.
James Piper says
Ha! I wish I had your playbook a month earlier, before my back-and-forth attempt to successfully migrate.
I will definitely be referencing this to all others who are moving thru this “delightful” process 🙂
-James