There are numerous ways to move a WordPress site from a development environment to the live, production environment, but there’s one method I’ve found that makes things quick and easy for me. I thought I would share the process so others can have a little less pain when attempting this. I realize that this is a technical post that may not be useful to all of our site visitors, but there is a percentage of our user-base that may need this information at least once, so we’ve included it here.
Development vs. Production?
First, lets describe what I mean when I talk about a development vs. production environment. Let’s take a typical scenario in the work I routinely do.
Jane contacts me and asks if I would convert her static HTML site to WordPress. She tells me the URL of her site (let’s say it’s http://www.janesawesomesite.com) and where the site is hosted.
Once we agree to begin the project, I create a new subdomain on one of my own domains that I use mostly for this purpose. Most likely, my hosting company is not the same as Jane’s, by the way.
Let’s say I own mytestdomain.com (I don’t, but let’s pretend for this example that I do). The first thing I will do is go to the domain’s cPanel, click on Subdomains in the Domains section, and then fill out the short form to Create a Subdomain. Sticking with our example, I might create a subdomain called “jane”, so the resulting URL for my test development environment would be http://jane.mytestdomain.com.
Next, I would create a new database for the jane project, download the latest version of WordPress from wordpress.org, place the information for the new database in the wp-config.php file, upload the files to the server, and install WordPress.
With WordPress up and running on http://jane.mytestdomain.com, I begin the process of converting Jane’s content and design. Once http://jane.mytestdomain.com is running Jane’s site the way she wants, it’s time to move it over to her real, production server.
Sorry it took so long to get to the meat of this tutorial, but I felt it was necessary to make sure everyone started with a basic understanding of the process that takes place before it’s time to move the site.
Steps to move the newly developed WordPress site from development to production server
So how do I quickly and easily move the site from jane.mytestdomain.com to www.janesawesomesite.com? I follow this process exactly, and usually have the site up and running on the production server in a matter of a few minutes.
1. Backup the current live site (www.janesawesomesite.com) just in case everything goes wrong and you need to restore the current site.
TIME THIS TAKES: Varies depending upon how large the current site is. Usually a few minutes.
2. Compress the files. On the development server (jane.mytestdomain.com in this example), go to the cPanel File Manager, select all the files for jane.mytestdomain.com, and click the Compress icon in the top navigation to create a zip file. Download this zip file to your computer.
TIME THIS TAKES: Approximately 1 minute.
3. Create a new database. On the production server (www.janesawesomesite.com), go to cPanel and create a new database. Make note of the database’s name, username and password. (You may also need special instructions from the hosting company if the database host is anything other than “localhost”, but the majority of the time, “localhost” is the appropriate host).
TIME THIS TAKES: Approximately 2 minutes.
4. Unzip and edit. On your computer, unzip the files you downloaded from the development server, and edit wp-config.php to put in new database info. Once wp-config.php is edited, select all the files and rezip them using your favorite zip managing tool. I like 7-Zip, personally.
TIME THIS TAKES: Approximately 1 minute.
5. Delete old site files and upload new site files. Since you’ve already backed up all the current files in step 1 above, you can feel comfortable in deleting all the current files and folders from the production server. Simply select them and click the Delete icon in the top navigation. Now, you need to upload the new files. Upload the newly zipped files to the production server, using the cPanel File Manager. Once the zip file is uploaded, select the zip file and click the Extract icon in the top navigation to unzip all the files to the production server.
TIME THIS TAKES: Anywhere from 2 minutes to 45 minutes or longer, depending upon your upload speed and size of the zip file.
6. Export the WordPress database. Now it’s time to export the WordPress database on the development server. You could simply use phpMyAdmin, or WordPress’s own export tool (which doesn’t export everything), but there are problems with both of these solutions. I won’t go into major details, but essentially, WordPress serializes some data, which doesn’t get converted properly via some methods of export. Because the development URL (jane.mytestdomain.com) is different than the production URL (www.janesawesomesite.com), AND the subdomain jane is a different length than the subdomain www), it’s best to export with a tool that handles serialized data properly. You don’t really need to understand the technical details, but I mention it in case you decide you want to research it further.
All you need to know is that there is a great little WordPress plugin that exports the database properly and replaces the development URL with the production URL as needed.
a) Install the WP-Migrate-DB plugin on the development server.
b) Go to Tools > Wp Migrate DB. You’ll need to fill in two pieces of information.
The first is the New address (URL), which is the production URL – in our example, http://www.janesawesomesite.com.
The second is the New file path. This is a little trickier because most people don’t have this information at hand. You can usually figure it out using the Account Information section of cPanel. It will list the Home Directory in the form “/home/username”. The full file path would often be “/home/username/public_html” (where username in our example case might be janedoe). If necessary, contact the hosting company to find out what the production server’s file path – also known as server path – is. For now, we’ll assume “/home/janedoe/public_html”.
Once you’ve filled out those two short pieces of information, you can leave the rest of the checkboxes as they default (Replace GUIDs checked and Save as file to your computer checked).
Click the Export Database button which will download the exported database to your computer. (Pay attention to where it downloads so you can find it later).
TIME THIS TAKES: If you know the new file path, approximately 2-3 minutes (longer if the database is very large).
7. Import the new database. Login to the production server’s cPanel and click on phpMyAdmin in the Databases section. Look in the left sidebar and find the new database you set up in step 3 above. At this point, this database should have no tables in it yet. Now click on the Import tab at the top. Click the Choose File button to find and open the exported database you downloaded in the previous step (Step 6). You can ignore the rest of the Import settings, leaving the defaults chosen, and just click the Go button.
TIME THIS TAKES: Approximately 2 minutes, although a very large database may take a good bit longer.
8. That’s it! You should be able to now go to the production URL (www.janesawesomesite.com) and see the new WordPress site up and running.
Final Once over
Now, it’s possible there are some glitches. If you hard-coded the development URL anywhere in the posts or pages, then you’ll need to manually change those to the new URLs or use a search and replace plugin, such as this one. If you hard-coded the development URL in the theme templates, then you’ll need to manually change those as well.
I always double-check all of my settings as well. Especially important for SEO purposes – be sure that Settings > Reading doesn’t have the Search Engine Visibility box checked or you’ll be blocking the site from search engines.
Finally, you may need to edit .htaccess if any changes need to be made, such as adding 301 redirects from the old URLs (like www.janesawesomesite.com/about-us.html) to new ones (like www.janesawesomesite.com/about-us/). This is also very important for SEO purposes. If you do need to do this, you should have prepared this list in advance. This goes beyond the scope of this tutorial, but if you use a tool such as Screaming Frog SEO Spider, you’re able to create a list of the current site’s URLs, which you can then use to map 301 redirects to the new WordPress URLs.
It seems a little more daunting while reading this than it actually is. Within about 15 minutes (for a site that isn’t too large), you should be able to successfully move a WordPress site from a development environment to a production environment without working up too much of a sweat.
i have done a good tutorial check it out on this link http://calvignac.com/production-ready-wordpress-install-under-linux/
Cheers Donna Fontenot for your self discovery and wonderful tips. You are really a talented writer, Great content and the article was very informative. I couldn’t but love your for writing techniques, distinctive quality and step-by-step tips. Thanks.
Thank you for the hints, keep up the good work! :°)
Many thanks for this guide. It seems to work a treat 🙂
Hey Donna, there is a much simpler way to do this, thanks to an ithemes.com utility called BackupBuddy. Of course you would want to make sure that you have backed up “janes’s” original site, but other than that BackupBuddy makes moving from development to production super easy.
For a developer , the price is $150, for personal it’s $75. IMHO, every developer should have this in their toolbox. For a non developer, pay the $75 and save yourself some headaches. It’s easy for things to go wrong, when doing this manually.
Regarding the 301 redirects, you will still have to handle that separately of course, but for the WordPress stuff, BackupBuddy handles it beautifully.
BackupBuddy is the simplest, fastest, most foolproof way to go. Transfers from XAMPP, WAMP, MAMP, Production Servers, Development Servers like magic. TOTALLY worth the investment for any professional WordPress developer.
Thank you very much for this post Donna, just what I needed. I haven’t done this myself yet but will likely need to very soon and this all looks very clear.
Hope it helps, Robert, when the time comes. Best of luck!
Thanks, Donna! I have done WP switchovers many times – I just expect there to be a few glitches that need fixing. I will have to try the plugin you mention.
Andrew is right about the new site using the test site images – this happens often, as well. I find I have to hunt for those to fix them (sometimes in widgets, for example, there are whole urls to test site images).
Leora, this particular process has given me the fewest glitches and headaches than any of the others I’ve tried, so hopefully it will be useful to a few out there. Re: the test site images, those hard-coded URLs, if any, are usually the culprit, and the search and replace plugin I mentioned in the final once-over does a good job of catching them. But yes, I’ve seen it happen and that’s definitely a part of the last-minute process to make sure little things like that aren’t overlooked.
Oh! And one other thing I’ve seen crop up…if the test site used a base href tag in the header.php file, then that should be changed to the new base href as well. Once again, a hard-coded url issue, which is generally the biggest culprit of gotchas.
It really seems so simple but I know it’s not as simple. Once I tried to upload same WordPress files to another domain using WordPress import option. But it never worked correctly, it all messed up and I finally I give up the idea. I was doing it to improving my technical understanding of WordPress and realized I’m not good with WordPress. 🙂
Right, Pankaj, and that’s probably because the WordPress import option isn’t a very good option. I don’t understand really, why it’s still as imperfect as it is, but that’s why I don’t use it, and prefer the method I outlined. Still, I do understand what you mean. Sometimes, no matter how hard I try, there are things that just aren’t in my skillset. Thanks for giving your thoughts.
It’s always a good idea to disable the test site once you have finished with it. Not only are they hazardous if left laying around development servers but a lot of times you will find images and links on the production site that point to the test site that you will never notice until the test site is offline.
That’s absolutely true, Andrew! I didn’t think to include that in the steps above, but that is a very good point. Thanks for mentioning it.