[vc_row][vc_column][vc_column_text]Here is my step-by-step process for migrating a WordPress web site from a working or development server (sandbox) to its permanent server. This process does not make use of plugins and avoids the need to edit the database.
Before I moved a WordPress web site for the very first time, I prepared for the move by doing a lot research, culling information from the WordPress Codex and elsewhere. From that research I developed a which resulted in a successful, glitch-free migration. I hope it saves you time and questions. I’ve included links to my key resources at the end of the article.
First, some definitions:
- Working server: this is where you developed the web site (the sandbox).
- Target server: the server you’re moving the web site to (its permanent home).
- FTP client: the application you use to access the back door of a web site on your server. I use Fetch. Several of my colleagues use CyberDuck or FileZilla.
Turn off custom permalinks. In the WP dashboard on the working server, go to Settings>Permalinks and select the default button. Save.
Once in the new location, you will return permalinks to their original settings (Step 10).
Create a back-up of the working site’s content folder. Use an FTP client and download the wp-content folder to your computer.
Make a copy of the wp-content folder you just downloaded. This is a safeguard.
Create a backup of the working site’s database. On your working server, go to the phpMyAdmin (MySQL), locate the database used by the working WordPress web site, make a back-up file of it, and download the backup to your computer.
Make a copy of the database file you just downloaded. This is another safeguard.
On the target server, install WordPress if it is not already installed. This can be done from the admin area on the target server (this requires the files be zipped), or by uploading the unzipped files with your FTP client. The install process should include setting up a username and password. You’ll need these for Step 10 and subsequent site management.
Using your FTP client, upload the wp-content folder (from your desktop per Step 2) to the target server. Put it into the same directory where WordPress exists. It will overwrite the wp-content folder that was part of the install.
Upload the database file (from your desktop per Step 5) to the target server. On the target server, go to phpMyAdmin and upload the database from your computer. This is done via the “Import” tab. Note: you will not edit this database.
Using your FTP client, go to the functions.php file in your theme folder (inside the wp-content folder) on the target server, click on Edit and add this line of code at the bottom. Replace new-site-address.com with the new domain:
The database must be edited with the URLs of the target server and domain in order for the site to function correctly in its new home. You can edit the database directly (not recommended), use a search-and-replace software, or use this update_option code.
Using the update_option function means that you don’t need to edit the database directly to fit the new server or URL. It updates the URL settings in the database all by itself.
Test. Log in to the WordPress dashboard on the target server and change the permalinks back to their original settings. Remember to save. Load your new site in your browser and test everything. NOTE: You may need to clear your browser cache or refresh the browser window in order to see the migrated site. Check and verify all of the links.
Delete the update_option lines of code that you added in Step 9. Once your site has loaded for the first time and you’ve checked and verified all the links, return to the functions.php file in the theme folder and delete the lines you added. They are no longer necessary, and keeping them may affect load and refresh times.
Take care of back-end details: SEO, Akismet, site map, payment gateways, etc. I hold off on installing certain plug-ins until the web site is happily ensconced on its permanent server. Again, check and re-check all links, plugins and functions before pronouncing it good to go. Once it’s running smoothly, you can delete the original site from your development server.