Moving to a different webhost can be a challenge if you don't know how or where to start. This post will take you through the whole process, step by step. I will also highlight other things than just Worpress, as a complete move needs to consider email, domains, and published content.
Beginning the journey
This post will be perfect for you if you have already figured out where to move your site. The list below will focus on WordPress, but I will also add things other than WordPress in the different stages. Doing things in the right order can be crucial for some of the things in the list.
You have signed up at a new webhosting company, and are about to move one or more wordpress sites to the new host. After everything is done, you will discontinue the webhosting plan at the old host.
1. Export WordPress database
Almost all PhpMyAdmin webinterfaces look the same. Log in to your old host account and go to PhpMyAdmin. At the left side you see all your databases. WordPress uses only one database per installation so click the right database, and you'll see that it consists of many tables. Dont worry, exporting one database will keep all tables intact. So dont click further on the table links on the left, or you will only export one table.
After clicking the proper database on the left, you will have several links at the top row. Choose "Export". Depending on PhpMyAdmin versions, the view presented may vary. It's all pretty safe and you will not destroy anything just by exporting the databse. But do remember that any posts, comments or whatever done after the export, will not be in the exported database!
If any choices are presented, choose to export in "SQL" format. When clicking export, you will either start a download of a databasename.sql file, or you will be presented with a form column showing some weird SQL code. If the latter, just copy that text into a textfile and name it to whatever.sql and save to your harddrive. Remember: The name of the .sql file doesn't matter, MySQL will get it right.
You should probably also delete anything that says "Create database" in the exported .sql file, as we will create the new database at the new host, and then perform the import. In my case, only one out of four exports had these lines in the .sql file.
2. Create the new database
Log in to the controlpanel at your new host. In my case (at Hostgator) I needed to scroll down a bit to find the Database section. The interface may vary from one host to another, but I clicked the "MySQL Databases" icon
cPanel screenshot from Hostgator
From there you need to create a new database with the same name as the one you previously exported. You will also need to create a new database user with the same name and same password as the one for the exported database. Then you (most certainly in the same area) assign the new user to the newly created database. Set full privileges.
3. Import database
Now that we have finished two important steps (1) exporting the old WordPress database, and (2) setup the new database environment at the newhost, it is time to import the old database.
Go to "PhpMyAdmin" in cPanel (or whatever webinterface your host provides). Click the new database name in the left column. Click "Import". Thats it, you're done. You can do a simple test by clicking the table names and look at the database content. If you get any errors here, it could be a permission error, and in worst cases you may need the webhost support to resolve it.
In which order?
Some states that you should first create a new database, and then import the old database into it (as mentioned in this post). Others may say that you should import the entire database, and have it created in the same process. I believe the first method gives more control, but do mind that you may need to edit the *.sql file before import and make sure there is no lines saying "Create database..". So, what we really do here is setting up the database manually, and we only import the tables from the old database.
4. WordPress – not only a database
Of course, it's not only the database that needs to be moved to the new host. WordPress consists of a lot of files in the root, and the three folders wp-admin, wp-content. and wp-includes. You may also have other folders and files there, which you may want to save before discountinuing your old webhosting plan. You can do all this in two different ways:
Log into your webhost account and download all folders and files. This is time consuming. Things may break in transfer, and you may also find that you get errors and transfer stops all of a sudden. There is also a security issue with FTP. If someone is listening to the network traffic, your FTP username and password can be viewed in clear text. May not be a risk at home, but if you are at a cybercafé or at work, it could be a risk.
Webhost filetransfer interface (recommended)
Most webhosts have a "Filetransfer" functionality, often just one click away after logging in to your account. This could also be named "FTP", as the protocol is the same. You do have other functionality here that makes this option a better choice over a simple standalone FTP client.
Here's a lifesaver tip. In most filetransfer webinterfaces you have the two buttons (or links) named "Compress" and "Extract". Simply select (or check the checkboxes) the files and folders you want to download, and click compress. If everything works as intended here, you should be prompted with a file download. Usually you get to download it all in a file named whatever-name-or-date.tar.gz. It doesnt matter if you cannot open this on a Windows machine, as your new web server knows what to do with it.
Uploading to the new webhost is just the same process in reverse. Upload the *.tar.gz file using the filetransfer interface. Select it, and click "Extract". You may get a question where you want to extract the archive, so please see further down this post regarding the creation of your new domain folder.
Wait! The wp-config.php file!!
After doing the filetransfer, your WordPress may still not be working. The config file contains vital information on how to interact with the database, and if it's not in order your WordPress site will not be able to fetch content from the database. In the root of your webhost account you can find the wp-config.php file. Using the same database user and password as in the old environment saves us some trouble, but most certainly you may need to edit the lines that say:
/** MySQL hostname */
The colored part is the path/name used by your webhost, to ensure that WordPress can find the actual database in the webhosting environment. Localhost means that it doesnt need to look elsewhere for it – it is on the same server. You could also see a name like customer-db-server-whatever. Your new webhost can tell you the location of the database, and most often you can see it clearly when logging in and going to PhpMyAdmin. If both your new and old webhost uses localhost, this file dont need edititing. Otherwise, it does.
Editing can be done in a simple texteditor. Download the file locally, edit, and then upload it.
If you plan to entirely end your relationship with your old webhost, make sure to download any email laying around in webmail accounts. If you download all email locally with an email client such as Outlook, Thunderbird or whatever, this may not be an issue. And once again, if you have other webcontent than just wordpress you need to backup that too. And you may need to backup subdomain content as well. Hell, backup everything and think twice before publishing it again. Better safe than sorry.
5. Move the domain
Chapters 1 to 4 have only adressed the moving of files and databases. Doing these steps will end up having two identical environments on each webhost. Our goal is to steer the visitors to the "new" website, and end the relationship with the old one. This requires a domain move as well. There are several ways of maiking a domain land softly at a new webhost.
- Startup an entirely new domain, and the webhost will setup everything.
- End your old webhost plan and dont mind it being offline. Startup a new plan with a new webhost later on.
- Move the website and let the new webhost take care of moving webcontent and domain move. They will charge you for moving files (we live in an automated world, manual labour will cost extra), and that may not include helping out with databses..
- Setup the environment at your new wehost before ending the relationship with the old one. This will in most cases be a transparent move (your visitors will not notice any offline period). This is what this post is about.
Setup the new environment
Now, lets say that you go with number 4 and have access to your new webhost. You need to setup the environment for your domain to be moved. Of course I use Hostgator as an example, but any webhost using cPanel could look almost the same.
Go to the domains section and add the new domain.
Clicking the Addon Domains link will let you enter the details for your domain to be moved. Keep passwords safe, but do remember that there is no dependency between this domain password and your WorcPanel screenshotdpress installation.
Now, what we have done is setting up the environment for the domain about to be moved. Of course, a lot of stuff have been going on in the background. The next step is the actual move of the domain to the new webhost.
DNS (Domain name System) is basically an Internet phonebook. Entering a domain name or web adress in your web browser requires DNS to (behind the scenes) steer your browser to the right webserver (which uses an IP adress such as 81.01.10.11). Making changes in this "DNS phonebook" can be done in different ways depending on the situation. Examples give here:
- An entirely new domain. The new webhost will take care of everything.
- Moving a domain from an old webhost, and continue relationship with the old webhost. The old webhost will take care of DNS stuff.
- Moving a domain from an old webhost, and discontinue relationship with the old webhost. A domain transfer needs to be done from the old webhost to the new one.
- Moving a domain not supported by the new webhost. This is no rocket science, but you need to be involved in taking care of domain registration parts.
Lets go through the steps, except the first one…it's pretty obvious. Pick the one that fits your situation.
#2 In this case you simply need to change the nameservers at your old webhost, so that they point to your new webhost. Usually this needs to be done by the support, and security wise I believe thats a good setup. You need to ask your new webhost what namservers are to be used, and ask your old webhost to point your domain to these nameservers. Usually, there are more than one because it's a redundant (failsafe) infrastructure. Your new webhost may throw a couple of names at you, such as ns1234.newhost.com and ns1235.newhost.com. Hand them over to your old webhost along with the domain to be directed. In this setup your old wehost will remain registrar of the domain, but nothing more. Your visitors will end up at your website hosted at your new webhost, but an extraction of a WHOIS lookup will show something like this
dnssec: unsigned delegation
In this case you will get webhosting bills from your new webhost, and domain renewal bills from your old webhost.
#3 This is a pretty common situation. You will need to follow instructions give by your new webhost. Most certainly your new webhost will ask you to fill out a domain transfer form, usually involving a minor fee (about $15). After completion of this form and fee payment, your new webhost will arrange the domain transfer and tie it to your website. One important note before starting this process: You need to get an authorization code for the domain from your old webhost, which needs to be entered in the domain transfer form. This will ensure both parties that there is no false intentions in the domain move. In some cases, depending on how your old webhost works, the domain can be "locked" for a certain period of time. Then you need to deal with your old webhost in order to get it unlocked.
When everything is set, you will get your domain renewal bills from your new webhost as they are now the new registrar. If you have no other services at your old webhost, you may discontinue your relationship with them.
#4 This scenario usually occurs when moving a domain that have a country specific top domain, such as arbi.se. The .se domain is the national top domain of Sweden, so in my case I needed to make myself as the registrar at IIS, the national department for .se domains. Similar to #3, I needed to get an authorization code from my old webhost, the nameservers from my new webhost, and enter the details myself at my IIS portal account. Unfortunately, I cannot answer on how other country specific top domains work. Hopefully they are just as easy as in Sweden. And if not, you can just go with #3, which is pretty much the same…except that you still have a relationship with your old webhost. If you are extremely unsatisified with your old webhost, you could probably move the domain to another webhost capable of registering your top domain, and do #3 through them.
In this setup you will get your webhosting bills from your new webhost, and domain renewal bills from your registrar (national top domain authority or national webhost/domain registrar, depending on how things are run in your country).
Yep, thats pretty much it. Dont forget to setup your new mailboxes, and reconfigure email clients so that you can get emails without to much interruption. Hope you found this post useful. if you had success or encountered certain problems or issues that may be good to know, please post a comment.
A small troubleshooting list
Q. My wordpress site is up, but dont show any posts. Seems like #404 errors everywhere!
A. Have you checked and changed your wp-config.php file? "MySQL hostname" may be completely different at your new webhost.
Q. Some stuff still aint working in my wordpress installation. Seems like I cannot add plugins and stuff.
A. Some older WordPress installations use a /tmp folder in the root. Just create a folder named "tmp" in the same directory as all your other WordPress folders and files.
Q: Seems like my domaintransfer is'nt kicking in. How long should I wait?
A. A DNS change usually takes 24-48 hours to populate through all the DNS servers around the globe. If it takes longer, please consult your new webhost.
Q. Seems like a lot of stuff to be taken care of. Is it worth moving to another webhost?
A. Yes! If you just think through it all, and follow all steps, the risk is very low and not very complicated. The more we move, the more do we put pressure on webhosts to delivery good service. Always strive for a better service and/or lower costs!
2 thoughts on “How to move a WordPress site”
Hi my Fridn thank you for this good good explanation 🙂 Please can you read my situation 🙂
i have the ~#2 situation :Moving a domain from an old webhost, and continue relationship with the old webhost. The old webhost will take care of DNS stuff.
My old host is bluehost and the new one is a dedicated server that I will buy, i know how to install configure every things to setup the dedicated server.
My problem is that i have a News website with 20 000 visitor per day and i don't want a downtime when moving,
My question is: i will take the news dns name and i will ask bluehost to change my dns.
Of Corse i have everything ready on the new hosting.
My problem start from here
Should i stop working on the site i have many blogger writing article so they will stop working right? Because everything they will insert will not be on the new host right?
Another thing when bluehost will change the dns my old site will be directly offline or it will continue working?
ahhhhh 🙂 i just remembered something very important i will answer my last question just for other people.
The new version of phpmyadmin have a "Synchronize" tools so i will synchronize both database in one click so anything i will insert will be inserted in the new database on the new hosting 🙂
Ok but my old website will be offline just at the same time bluehost change the new dns? Or it will take 241hours? So my visitor will continue having access to my old website>>> some of them will not (dns changed for them) etc… ?
If you have the new site up and running (I guess accesible by IP), then I see no risk of downtime. Its just the dns that will change, and users will land on the website on the new host. Im not aware of sql sync, but if you got this covered then I guess its entirely transparent with no data loss.