In this tutorial, I am going to show you how you can move your WordPress powered website to a new location.
Moving WordPress to a different location is a daunting task to many people. I have spoke to many bloggers who were so unsure about the process that they were reluctant to ever move their website. These fears are unfounded. The process of moving WordPress to a new location is very straightforward. All you have to do is follow the steps outlined in this tutorial.
I am sure you are aware that it is possible to import posts to a WordPress website using the WordPress Importer. This is not an ideal solution as it is restricted by the PHP memory limit of your host, which means that only small websites can be transferred. Those of you with VPS or dedicated hosting can increase this memory limit yourself if necessary. A quick look at the support forum for the plugin on WordPress.org highlights this, as there are many threads from WordPress users complaining about the plugin causing errors.
Due to these issues, the WordPress importer is not a good solution for moving a WordPress website. The best method of transferring a WordPress website is to transfer your database manually. There are many different MySQL administration tools available such as Adminer. By far the most popular MySQL tool on the internet is phpMyAdmin, therefore that is the tool I have used in this tutorial. The steps detailed in this tutorial are, of course, applicable to any MySQL administration tool.
Moving WordPress to a New Location
Transferring a database driven website to another location is not as difficult as you would imagine. You simply need to move two things: Your files and your database. After you have successfully done that, all you have to do is ensure that everything is configured correctly such as references to your website URL, your .htaccess file and file permissions.
Thankfully, with WordPress, you do not have to do many modifications after you have transferred over your database and files.
One problem that you may face is uploading your database to its new location. This is a major stumbling block for many WordPress users during the migration process, which is why I have devoted a large part of this tutorial to it.
Below you will find the main steps that are involved in transferring a WordPress website to a new location:
- Step 1: Backup Your Old Database
- Step 2: Backup Your Files
- Step 3: Create a Database On Your New Server
- Step 4: Edit Your WP-Config.php File With Your New Database Information
- Step 5: Upload Your Files to Your New Server
- Step 6: Upload Your Database
- Step 7: Replace References To your Old URL (this step is necessary if the URL of your website is changing)
- Step 8: Login and Save Your Permalink Structure
This tutorial is long as it covers every part of the migration process in great detail. I still recommend reading the full article if you have experience with transferring a WordPress website. Then you can use the steps noted above as a quick guide so that you do not forget any of the steps.
You will find a link to your database administration area in your hosting panel. phpMyAdmin is normally located next to other MySQL options.
Once phpMyAdmin has loaded up, you simply need to choose the database you want to back up. If there are many databases listed, it is prudent to double check you have selected the right one by checking the database that is linked in your wp-config.php file.
The tab that phpMyAdmin loads up primarily is the structure tab. This loads all the tables in your database. You do not need to do anything within this area, however you may find the information at the bottom of the table list useful. It states the number of tables in your database and its overall size in MB.
The tab you want to go to is Export. All you have to do is ensure that the format you save your database in is SQL.
Make sure you save your database in a safe location. The size of your database depends on many factors such as the number of posts and pages you have, and the plugins you are using.
When you are transferring a WordPress website to a new location, the most important folder to copy over is wp-content. That folder contains all of your themes, plugins and uploads. It is also worth backing up your .htaccess file for reference too. This file be found at the root of your WordPress installation.
You can transfer files to their new location using a file transfer protocol client such as FileZilla.
There are two ways you handle file transfer. The most straightforward is to backup all files from their existing location and simply upload them to their new location. This is what I recommend WordPress beginner’s do.
Alternatively, you can upload a new version of WordPress to the new location and then upload the wp-content folder that you backed up previously. This is what I usually do if a new version of WordPress has just came out and I have yet to update. For example, the latest version of WordPress is 3.6. If my existing website is on WordPress 3.5.2, I may upload version 3.6 and simply upload the wp-content folder. This will save me from having to upload WordPress twice. That is, upload 3.5.2 files and then overwrite them afterwards with 3.6 files.
You should always try and ensure that your WordPress websites use the latest version, however you may be faced with transferring an older version of WordPress. If the website being transferred is using a much older version of WordPress (e.g. more than six months); I suggest simply copying over all files. The reason being is that when you update an older version of WordPress, you may face problems with older plugins clashing with the latest version of WordPress.
So if you are transferring a website that is powered by an old version of WordPress, simply transfer all existing files. Your first priority is to ensure the website is transferred correctly first. You can then ensure a safe upgrade later by setting up a test installation.
The next thing you need to do is create a database at your new location (e.g. your new hosting account). The process is almost identical through every hosting panel, though I will be walking you through the steps required in cPanel.
First you need to click on the link entitled “MySQL Databases”.
Next you need to name your database. You can use a random series of characters if you like, however I always try and use something that is self-explanatory such as WordPress or blog.
You will also notice in cPanel that your account username is prefixed to your database name. This also occurs with your username.
cPanel then confirms that your database has been created. You should take a note of your database name and write it down somewhere. In this example, the database name is mrb_wordpress.
Go back to the main MySQL Databases screen and scroll down to the “Add New User” section. All you need to do is enter your chosen username and password. I recommend using the provided password generator to ensure a strong password is used.
You will then be advised that the requested user has been created. Take a note of the username and password as you will need it later.
One step you must not forget to complete is to add your created user to the database you set up. If you do not, the user will not have permissions to administrate the database.
Make sure that the database user is given all database privileges.
Finally, you will get confirmation that your user has successfully been added to the database.
That is all there is to it!
Now that you have set up your new database, you can now enter these details in your wp-config.php file. You will find this in your backup or in your download of the latest version of WordPress.
The wp-config.php file is very simple to complete. You only need to enter four pieces of information: Your database name, database username, database password and your MySQL hostname. Your hostname will always be localhost unless you are connecting to a database on another service.
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
/** MySQL database username */
/** MySQL database password */
/** MySQL hostname */
Here is what the main part of my wp-config.php file would look like using the example database I set up before.
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
/** MySQL database username */
/** MySQL database password */
define('DB_PASSWORD', '[email protected]}!#N');
/** MySQL hostname */
The wp-config.php file is how WordPress files connect to your database, therefore it is important the details in this file are connect. If they are not, your website will not load. Do not worry too much if your website does not load because the information in your wp-config.php is wrong. It only takes a minute to correct this information and upload the file again.
Your files will now include a wp-config.php configuration file that details how your new server can connect to the new database you set up. All you need to do is upload all of your files via file transfer protocol.
Do not upload your backed up .htaccess file. It is useful to keep a version of your old .htaccess file for reference, however it does not have to be uploaded. Later on we will be generating a new .htaccess file through WordPress.
Once all files have been uploaded (except from .htaccess), you need to ensure that your uploads folder is writeable. To do this, all you need to do is go to the wp-content directory and change the permissions of the uploads folder to 777. You can also do this through the file manager located in your hosting administration area.
Importing your database to its new location can be done easily through phpMyAdmin. All you have to do is select your database and then click on the import tab. You can then import your database file.
If you have a small website with few pages and posts, your database should have uploaded correctly. What makes the process of uploading your database difficult is that most web hosting companies place a restriction on the size of the database that can be uploaded. The default limit is normally 50MB; though hosts can change this.
Most WordPress databases are larger than this. For example, my blog’s database is currently 167 MB.
To complicate matters even more, many hosting companies have runtime limits. This means that even if your database size is small, your upload may fail because it times out. There are scripts available such as MySQLDumper that adress this issue. You may also want to speak to your host about your runtime limit; however many hosts will not change this setting.
Uploading a database that is larger than the maximum upload size is the biggest problem you will face. I have therefore detailed the most common methods below.
Compress Your Exported Database
PhpMyAdmin allows you to export and import databases using compression. I have exported databases using gzip on many occasions, however I normally just export databases without compression as it allows me to open up the .sql file in a text editor without having to unzip anything. I would rather download a slightly larger file onto my computer than having to unzip another file later (YES…I am that lazy!!!).
In order to test how well compression works, I exported the database of a test WordPress installation I use frequently to test plugins and themes. The unzipped SQL file was 22,167 KB in size (around 22 MB). Here are the sizes of the databases using the three compression options available to me:
- Zipped – 22,167 KB
- Gzipped – 3,465 KB
- Bzipped – 2,799 KB
The results for Gzip and Bzip compression really surprised me. They surprised me so much that I kind of doubted whether the Gzip and Bzip backups would work. I therefore imported the Gzip backup into a test database. All tables were transferred successfully. I repeated the process with the Bzip backup and saw the same result.
I should not be surprised that the zipped files successfully imported all tables correctly. After all, that is what compression was designed for and the functionality would not be used on millions of websites if it did not work.
I demonstrated that the compression worked perfectly on a small WordPress installation. Still, the results of the Gzip and Bzip compressed backups surprised me enough to do another test. I then proceeded to download a Gzip and Bzip backup of my personal blog. As mentioned previously, that currently has a database size of 167 MB. I also tried to download a regular zipped backup of the database, though phpMyAdmin timed out every time I tried to do so (this was likely a temporary issue).
The results were:
- Gzipped – 19,433 KB
- Bzipped – 12,384 KB
With my first test, Gzip reduced the size of the database to 15.63% of its original size and Bzip reduced it to only 12.63%. The database for my second test was around 7.5 times larger. In this instance, Gzip reduced the size of the database to 11.64% of its original size and Bzip reduced it to only 7.42%.
This highlights how important compression is when moving a database to a new location. By utilising compression, you can upload a database that would be around ten times its size uncompressed. This means that even with a 50 MB upload limit, you can upload a uncompressed database of around 500 MB in size directly through phpMyAdmin.
Increase the phpMyAdmin File Import Size Limit
Many hosts decrease the maximum file upload size of phpMyAdmin. It is not uncommon for many shared hosting companies to decrease the maximum file upload size to a paltry 2 MB (though a limit of 8 MB seems to be more common). This effectively removes your ability to upload any file as the limit is impractically low.
If you have a basic hosting package and find yourself in this situation, I advise you to contact your host and ask them to increase the file upload limit. Some hosting companies (annoyingly) point blank refuse to do this. I recommend leaving any hosting company that does this. Others will only increase your upload limit temporarily; reducing the limit back down to the default size after you have confirmed your database has been imported.
VPS and dedicated hosting plans normally give you more freedom over how your account is configured. Therefore, if you wish, you can attempt to increase the file upload limit yourself. This can be done by editing the php.ini configuration file.
The location of php.ini file is different on each server. The easiest way to find out where it is located is to create a file entitled phpinfo.php and add this to the file:
Then upload the phpinfo.php to the root of your WordPress installation and access it via your browser (e.g. at www.yourwebsite.com/phpinfo.php). You will then see then see where your php.ini file is located. In the example below, you can see it is located at /usr/local/lib/php.ini.
Then open up the php.ini file using the vi editor using:
Once you are in editor, you should look for the following lines (values below are examples):
Enter i in order to edit the file and then change the definitions above to your desired values. Note that post_max_size must always be the same size or larger than upload_max_filesize.
Next, press escape and type :wq to save and quit the file. Lastly, you need to restart your server for these changes to take effect. Once you have done this, you should see that your maximum file upload size has increased in phpMyAdmin.
If you have never connected to your server through Secure Shell (SSH) before, I do not recommend editing the php.ini file. You can easily mess up your hosting set up by deleting or modifying a line of code that you should not have modified.
Another way you can increase your file upload limit is through the .htaccess file. The .htaccess file is stored in the root of your WordPress installation and, amongst other things, controls how your permalinks are set up. As a rule, you should always backup your current .htaccess file before making any modifications to it (though at this stage of the migration process, you will probably not have any .htaccess file saved on your website).
You can change your file upload limit by adding this to your .htaccess file:
#Change file upload limits
php_value memory_limit 64M
php_value post_max_size 64M
php_value upload_max_filesize 64M
php_value max_execution_time 300
php_value max_input_time 300
Again, I remind you that post_max_size must always be the same size or larger than upload_max_filesize.
The .htaccess file is one of the most temperamental files in Web Development. Even the smallest of mistakes can bring your whole down website. Thankfully, resolving this issue is easy: Simply re-upload your backup .htaccess file. If for any reason your backup file has been deleted or lost, upload a blank .htaccess file over the problematic .htaccess file. Then go back into your WordPress admin area and re-save your permalink structure.
If all of these suggestions about modifying your php.ini and .htaccess file seem too technical; I strongly encourage you to ask your host to increase your maximum file upload limit for you. A good host should perform this request for you quickly as it is a common request.
Import via SSH
Large databases can be imported using Secure Shell (SSH) commands. You need to have permission to use SSH in order to use it. Most hosting companies will not grant SSH access to people on shared hosting packages so it will probably not be an option for you if you have a basic hosting plan. Those of you with VPS and dedicated hosting packages should be able to use SSH.
I have used SSH commands in the past to do other things such as edit the php.ini file, but it is not something I have much experience with. The only times I have used it, I have simply copied commands given to me by my hosting company or via a tutorial.
The most common command that people recommend for importing a database into phpMyAdmin is:
mysql -u myuser -p mydatabase < myfile.sql
Unfortunately, I have never tested this myself to see how this works in practice. So whilst I would love to walk you all through the process of importing a database via SSH, I know that I am not the right person to do so. I would simply be copying someone else’s advice and passing it on as my own. And when it comes to something like this, that can be dangerous.
A quick search on Google brings up many tutorials that explain you how to import and/or transfer a MySQL database using SSH. I hope you find them useful:
- Import A MySQL Database
- Transferring a MySQL database via SSH
- Moving a MySQL database between servers using a single SSH command
- Copy MySQL Database From One Server To Another Remote Server
Please note, I would advise against importing a database using SSH unless you have previous experience with it. The other techniques detailed in this tutorial are much simpler to action.
Stagger the Import Using a Dump Script
Another way to handle big database file uploads is to stagger the import process. BigDump is a popular script for doing this and it is free to download. I have used it many times in the past to migrate large databases.
The script works by staggering the process of importing the database. It does not modify your importing database in any way to achieve this. It simply processes a certain number of lines from your backed up database file in stages. This gets around the file upload limit that phpMyAdmin enforces.
You will be glad to know that it is straightforward to use and does not require any knowledge of coding. All you need are the database connection details.
Once you have downloaded the bigdump.php file, you need to add your database details to the file. This is the same information you added to your wp-config.php file previously. Your backed up database may have the DROP TABLE command line within it so that any tables are deleted before uploading. As the database you are importing to has never been used, it should have no tables on it.
After configuring the bigdump.php file, you need to create a directory at the root of your website. For example, www.yourwebsite.com/dump/. Your backed up database and bigdump.php file should be uploaded here. Then simply run the script at the place you uploaded it e.g. www.yourwebsite.com/dump/bigdump.php.
If you define the $filename parameter in the bigdump.php file, you will remove the option to upload a file from your computer.
You may be faced by an error stating that you are trying to import too many dump lines. This is a common problem that is caused by trying to upload a database that has too many extended inserts (i.e. long INSERT Lines).
One way to resolve this is to download your old database again without any extended inserts. In older versions of phpMyAdmin, there is an option in the export tab to include or exclude extended inserts. In newer versions of phpMyAdmin, you need to ensure that “include column names in every INSERT statement” is checked.
Downloading your database again without extended inserts is not the quickest option. A quicker solution is to simply change the $max_query_lines value in your bigdump.php file to something higher. It is set to be 300 by default.
$max_query_lines = 300;
When testing the script again for this article, I changed the value to 3,000. Once I did that, the error disappeared.
Be aware that if the script stops mid way due to an error, your database will be populated with tables. As mentioned previously, your database has to be empty unless the database you are importing has the DROP TABLE command in it. Therefore, you need to drop the tables before starting again.
This can be done easily through phpMyAdmin. From the structure tab, select all tables and then click on the drop option.
Then confirm that you want to delete the tables you selected.
You can then return to the BigDump script and start the import process again. With the $max_query_lines set at a higher value, you should now be able to import your database correctly.
In my experience, BigDump is the most practical way of importing a database into phpMyAdmin. You do not have to be familiar with MySQL or any programming language in order to use it. All you have to do is follow the instructions outlined on the BigDump usage page and refer to the BigDump Frequently Asked Questions if you encounter any errors.
Split Your Database Up
Large MySQL databases can be split up into smaller parts and uploaded separately. This is a simple technique that gets round the file upload limit of phpMyAdmin.
Before finding BigDump, I used to split databases into small chunks in order to upload them. All you have to do is copy and paste parts of the sql file into another. This proved to be time consuming for large databases, however the method was effective. If you have experience with MySQL, you will be familiar with how this is done.
Splitting a database up manually is tiring and time-consuming. Thankfully, the days of copying and pasting MySQL code into another database file is over. You can now do this by automatically by installing SQL Dump Splitter.
SQL Dump Splitter is a free application for Windows that will divide your database into parts. All you need to do is choose the database file, define how big you want each part to be, and then select the directory you want each part to be saved to.
I believe BigDump is a more practical way of uploading a large database, however should you have any problems with that script, you may want to look into splitting your database up into smaller parts. You can then upload each part separately.
Ask Your Host to Upload the File
You pay your hosting company month for quality support…so why not use it. If you are not a technical person, my advice to you is to ask your hosting company to upload your database for you. To help them do this, all you need to do is upload your database to your server using file transfer protocol.
Even if you do know how to import large databases, you can still ask your hosting company to help. At the end of June I moved my three discussion forums to a new forum hosting company called Nimbus Hosting. As I was living in South America at the time, my internet connection was very poor. So downloading and uploading a large database file would have taken me several hours (if not longer). They resolved the issue for me quickly by transferring my database for me. It reduced the downtime of my forum from hours to minutes.
The moral of the story is: Take advantage of the support your hosting company offers. They are there to assist you. If your hosting company will not help you, I would give serious consideration to changing your hosting provider. Why stick with a company that offers terrible support?
A Quick Overview About Importing Databases
I have devoted a large part of this tutorial to uploading an imported database because it is the step where most WordPress users face problems.
As I have shown, Gzip and Bzip compression can decrease your database size to around 10% of its original size. It should therefore be the first method you should attempt when importing your database.
The default file upload limit for phpMyAdmin is 50 MB. Some shared host companies frustratingly drop this limit to as low as 2 MB. This makes uploading a database impossible. If the hosting company refuses to increase the limit, I would look at moving host. I realise this can be a hassle in the short term, however in the long term, you will save yourself a lot of time dealing with a company that does not want to help you. Those of you on VPS and dedicated hosting plans should be able to increase this limit yourself; but it may be quicker to just ask your host to do this for you.
If your maximum file upload limit is set at a reasonable limit and your database is still too big, you need to review your options for importing. I believe the staggered importer script BigDump is the best solution. You may also want to try splitting your database up into multiple databases which are smaller. SSH is also an option for advanced users.
The easiest solution by far is to ask your host for help. They will normally transfer a database for you if you give them the login details of your old host. It is also common for hosting companies to ask you to upload your backed up database to your server using file transfer protocol. Once you do that, they can easily import the database.
Without doubt, importing the database is the step where most WordPress users face problems. If you follow the methods detailed in this tutorial, I am confident that you will not face anything you cannot tackle.
This step is only necessary if the URL of the website is changing. If you are moving host and the website location will remain the same, the URLs in your database will already be correct.
There are two situations in which you would need to move WordPress to a new location. The most common situation is when you change hosting company. When you are simply changing where a website is hosted, you do not have to change any information within the database because all references to the website’s URL remain the same.
Occasionally, you will be faced with transferring a WordPress website that is being restored on a different URL. For example: Let’s say that you have decided that moving to a different hosting company is the perfect opportunity to move your blog from www.yourwebsite.com/blog/ to the more brandable www.yourwebsite.com. Or perhaps you believe that the new WordPress website you purchased on Flippa would be easier to promote if it was located at www.domainone.com rather than www.domaintwo.com.
Step 7 is for anyone who needs to change the URL of a WordPress website. You can skip to step 8 if you are simply changing your hosting company.
Your database will contain lots of references to its existing location. If the website URL is changing, these URLs need to be changed. In the past, I used to recommend this was done using the find and replace functionality within a text editor such as TextPad or Text Wrangler. This was what I always did when moving a WordPress website, however I have since learned that problems can arise from using this technique.
According to Interconnect, it can be problematic “because the length of the string changes but the indexes for the serialized strings does not. Consequently settings are lost and widgets disappear. Not good.”.
Their WordPress Search & Replace Tool addresses this issue. The tool is a simple PHP file entitled searchreplacedb2.php, however Interconnect recommend renaming it. All you have to do to install it is upload it to the root of your WordPress installation (i.e. where your wp-config.php file is located).
The script is very simple to use. You can automatically pre-populate your database details yourself or enter details manually.
Even if you choose to pre-populate your database login details, you can overwrite them with different login details. This is useful if you ever want to modify a different database remotely.
You then need to choose what tables you want to scan.
You can then search for all references of your existing URL and replace it with your new URL. Pay close attention to the replacement URL if your WordPress installation is in a sub-directory (e.g. www.yournewwebsite.com/wordpress/).
After a while, the script will advise that the search and replace has been completed. I found the script occasionally stalled at this step, therefore you may need to refresh your page in order to see the “Completed” message.
Your website should now have the correct URLs defined and your website should now be live at your new location.
Your home page should now be displaying everything correctly. With no .htaccess file uploaded, clicking on your posts and pages will show an internal server error unless your old website used the default permalink structure (i.e. www.yourwebsite.com/?p=123). If the website you are transferring used a search engine friendly permalink structure, you will need to create a new .htaccess file.
All you need to do is choose your permalink structure and then save changes. When you do this, a new .htaccess file will be created and your posts and pages will be displayed correctly.
Sometimes a new .htaccess file will not be created because of the way your hosting account is configured. If this happens, what you need to do is:
- Create a blank .htaccess file and upload it to your root folder.
- Make the .htaccess file writable by changing permissions to 777.
- Save your permalink structure.
- Change the permissions of the .htaccess file to 644.
The last step above is very important. Changing the file permissions of your .htaccess file will stop hackers from doing something malicious to your website. Therefore, it is imperative that you do not skip this step.
The .htaccess file is frequently used for other tasks such as redirecting links and pages, and restricting access to directories. Once you have saved your website permalink structure, download the file and add the additional rules that were in your .htaccess file previously. Be sure to change file permissions back to 644 after you do this. If your website stops working at any time during this part, simply delete the .htaccess file and start again.
Congratulations. You have successfully transferred your WordPress website.
Transferring a Live Website
More often than not, the website you will be transferring will be a live website. This can cause a little bit of a headache as domain name servers can take up to 48 hours to update. Internet service providers update their domain name server information at different times. This means that for a short period of time, some places around the world will be directed to your new hosting account and some will be directed towards your old hosting account.
This can be a big problem as it means that the old database will continue to be updated after you have transferred it to its new location.
When migrating to a new hosting company, do not ever close down your old account until the new website has been transferred successfully. Once your website has been transferred, you can then point your domain to your new hosting company. You do this by changing the DNS (Domain Name Server) of your domain. DNS details will be provided by your new hosting company in your welcome email or on their frequently asked questions page. If not, contact them and ask what DNS information you should use.
The DNS links will normally start with ns or dns. For example, HostGator use ns1.hostgator.com and ns2.hostgator.com.
This is probably not the first article you have read about migrating a database driven website. You have probably found that when it comes to DNS issues, most tutorials skip the problems associated with two databases being updated at the same time. They simply advise waiting for the DNS to propagate around the world.
Simply waiting for the DNS to switch over is fine if you have a small static website that is not updated every day; however, doing nothing can cause headaches later if you have a popular WordPress website that is updated every day with new comments, posts and pages. In addition to comments being submitted to both your old and new hosting accounts, there is a high chance that your authors will be working on the old hosting account. This could cause an article they worked on for several hours to be lost.
Anytime someone interacts with your WordPress website, the database that powers it is updated. When you are transferring your website to a new hosting company, your aim should be to limit or completely stop the number of updates that occur on the old database. Things like page views and stats are irrelevant during the migration process, however posts, pages and comments are not.
Therefore, as soon as you backup the database from its old location, you do not want that database to be updated. Having transferred hundreds of database driven websites over the last thirteen years, I have learned a few things about reducing problems during migration.
The key to minimising these problems is preparation. You should be taking steps to avoid two databases being updated before you even back it up.
Posts, Pages & Other Content
If you are the only person who updates the WordPress website that is being transferred, all you have to do is ensure that you do not add content to the old location. You can continue to work by logging in at the temporary location before the DNS propagates.
Popular WordPress websites normally have many contributors. It is therefore important that you advise all staff that the website is being moved to a different location. In my experience, even when you email authors and request that they do not submit any articles during the migration, some will disregard this and submit content anyway. Therefore, I feel that it is necessary to take steps to stop them from doing this.
All you have to do is:
- Login to your website at the old location after backing up your website.
- Download all authors and contributors to subscriber level.
Doing this stops authors from being to access the post editor and ensures that no authors can work on the old database after you have backed it up. As these actions have been performed on the old database, you do not need to modify the capability level of your writers again, as their account will be correctly configured on your new hosting account.
If you do not want to restrict authors from working for a day or so, you can advise them the temporary URL of your new hosting setup. This will allow them them to continue to submit new articles.
Another thing you should do before backing up is schedule articles in advance for the days the DNS is propagating. These articles will publish on the old and new database. This means that no matter what status your DNS is in a country (i.e. the old DNS or the new DNS), the articles will publish.
Comments are something which many WordPress owners do not give any consideration to when migrating their website. On the grand scale of things, you may feel that losing a few comments during the migration is not a big problem. I believe this is the wrong mindset to have.
I recently left a long comment spanning several hundred words on a website and it was marked as spam and deleted without review. As you can imagine, I was disappointed at someone automatically deleting a comment that took me thirty minutes to write. If you experienced this before yourself, I am sure you can relate to how frustrating it is.
Deleting legitimate comments from your website can discourage people from leaving a comment again. They may even unsubscribe from your website because of it. As a blogger, I do not ever want to lose one subscriber. So I believe disregarding comments during the migration process is dangerous as you could be losing dozens of loyal subscribers.
I have found that the easiest way to resolve this situation is to disable comments on your old database. It is also worthwhile editing your comments.php template and adding a message that advises visitors why comments have been disabled. A simple apology and explanation about moving host should be sufficient. Comments will automatically be enabled again when the domain name servers are updated as your new database still has comments enabled.
It is perhaps not the best way to handle the problem. Another possible solution is to enable an external commenting solution such as LiveFyre, DISQUS or IntenseDebate. External commenting services store comments on their server and then sync the data back to your WordPress website.
If you receive a high number of comments every day, switching to an external commenting system (at least temporarily) will allow you to continue to receive comments without worrying about any syncing issues. No comments will be lost as visitors who view your website stored on your old hosting setup and your new hosting setup, will see the exact same comment form.
When your DNS propagation is complete, all outstanding comments will be synced to your WordPress database. You can then switch back to the default WordPress commenting system if you wish.
A Quick Review of Transferring a Live Website
The key to transferring a live website successfully is to do your utmost to ensure that the old database (that is, the database stored on your old hosting company), is not updated after you have backed it up. This is a bigger concern for websites that are updated everyday and for websites that receive a lot of comments.
As I have shown, if you prepare in advance, you can ensure that authors do not add content to your old database. Likewise, disabling comments or switching to an external commenting system will mean that comments that your readers submit are not lost.
Moving WordPress to a new location is a relatively simple task to complete; however there are problems that can arise. The vast majority of these problems can be avoided if you take your time, backup everything, and follow the steps detailed in this article.
Remember, do not be afraid to ask your new hosting company for support at any point during the migration process. That is what you are paying them for.
I hope you have found this tutorial on migrating a WordPress website useful. If there is any part of this tutorial that you are unsure of, please let me know and I will clarify it for you.
For further information on moving a WordPress website, I recommend checking out the Moving WordPress tutorial at WordPress.org. I also encourage you to subscribe to WP Hub. We have publishing some fantastic tutorials over the next few weeks that you do not want to miss.