There are lots of reasons to move your WordPress site, better high speed hosting, better support and security monitoring, moving to a High Availability model and need a second copy of it running or just plain cost. The process itself is relatively painless when done via the command line and only requires a few basic steps to achieve a successful migration but some level of skill is needed to achieve success.
The basic process is:
- Package up your site's files using a tool such as “tar”.
- Dump the database image to a file which also include the commands needed to recreate the database tables.
- Transfer the files to the new host using either rsync, ftp or wget.
- On the new host, reverse the "tar" package back to files in the correct location.
- Create the new database and Import the database dump file.
- Change the WordPress config for the new database user name and password if needed.
- Configure the web server to host the site.
- Change DNS to point to the new server.
- Cleanup the old server and files.
While this might seem like a lot of steps, your new hosting provider will most likely create the web server entires, create an empty database and give you the login details for your account so that's a few steps less to worry about but we will cover it anyway.
Packaging up your site
First log into your web site via an SSH application and navigate to your web server root directory. My server stores web site files in /var/www/vhosts/<domain-name> so for this article I am going to use:
cd /var/www/vhosts/test.conetix.com.au/
In this directory are all the WordPress files, owned by the web server which is an Apache Web Server, the files are owned by the user and group "apache". To package my files I will use the unix utility "tar" to create an archive of my site ready to transfer. Normally I would not worry about compressing the archive as it's not large but I have also shown the separate command to gzip the file if you wish to:
tar -cvf copy-test-conetix-com-au.tar . gzip copy-test-conetix-com-au.tar
You can also use the "z" option in tar, so the line has the options "-cvzf".
Next we need to dump our database tables, to do this we need the Database name, Database User Name and Password. These settings are located in the file wp-config.php, the quick way to get them is:
cat wp-config.php | grep DB
You should get output similar to:
define('DB_NAME', 'wpdatabase');
define('DB_USER', 'wpuser');
define('DB_PASSWORD', 'password');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');
Once we have these parameters, we can use them in the command line for the mysqldump utility, the command looks like:
mysqldump -u wpuser -ppassword wpdatabase > copy-db-20150429.sql
Where copy-db-20150429.sql is the file that contains our WordPress site in raw SQL statements, we need this file along with our tar file on the new server. Also note that if you do not specify the password, you will be prompted for it (more secure also as the command line can be seen by others using the "ps" and "top" utilities to name just a few).
Migration
There are many ways to get the tar file and SQL data file to the new server, you can use the rsync command from the new server by SSHing into it and using a similar command to that shown below (changing the host names as needed):
cd /var/www/vhost/new-directory rsync -avz :/var/www/vhost/<my-domain-name>/copy-* .
You could also use "scp" to securely copy your files, the syntax looks like:
scp copy-test-conetix-com-au.tar your_new_username@new_host.com:/var/www/vhost/your_new_domain.com
Failing this you could try a “wget” to get each file:
cd /var/www/vhost/new-directory wget https://old-web-site.com/copy-db-20150429.sql wget https://old-web-site.com/copy-test-conetix-com-au.tar
Or use FTP to transfer the files to the new server.
NOTE! – if the files are visible on your web server others may try to take copies so remove them immediately after you copy them to the new host.
Installation
Once the files have arrived on the new server, you need to extract the tar file into the new directory:
cd /var/www/vhosts/<new-directory> tar -xvf copy-test-conetix-com-au.tar
One thing to ensure is that the files have the right ownership, since you are on a new server, chances are your login account is different so the owner and group permissions may be different from your old site. If you run the command “ls -la“ while you are in your web server directory you will see the permissions and ownership. They should be the same as the parent directory shown as ".", the first line of output from the "ls" command.
If the ownership of the extracted files is different from YOUR web server directory, you need to change them to match using the "chown" command, with the -R option to make it recursive (be sure you are in the right directory when doing things recursively!). So if /var/www/vhosts/my-new-site.com is the directory I'm currently in and the account is wu3200 group webusers then all files will need to be set to this pair. In a private hosted environment, you will most likely find the files being owned by the “apache” user with a group also set to “apache”. Contact your hosting provider if you have issues prior to making any file permission changes as you could lock yourself out of your hosting account!
After you have the WordPress files installed, you need to first verify access to the Database, then you need to dump the database SQL file using the “cat” utility and pipe it into the mysql cli utility which will import it into the nominated database, the commands are:
mysql -u new-user-name -p new-db-name Password: <exit back to a shell prompt if successful> cat copy-db-20150429.sql | mysql -u new-user-name -p new-db-name
It is most likely you will be given a new database name, user name and password on the new server. As a result in the change in credentials, you will need to edit the wp-config.php file to reflect the new account details. It is good practise and common sense to make a backup of the old config file, then make the change. You can also just comment out the old lines in the file after you copy it and then edit the file accordingly.
If you have not yet created the database see below in the Appendix for specific instructions, but the above process assumes your hosting provider has done this, if you are moving back to in-house servers then you will need to create a database and user account.
Web Server configuration
The web server will require a configuration file for the new site, this file will define the Document Root directory, the URL via the ServerName line and any specific details you might want, its often best to take a copy of an existing config file and then change the ServerName and DocumentRoot parameters to reflect the new wordpress web site. My web site configuration files are located in /etc/httpd/vhosts.d each site has a config file and looks something like this:
<VirtualHost *:80>
ServerAdmin
ServerName my-new-site.com
DocumentRoot /var/www/vhosts/my-new-site.com
<Directory /var/www/vhosts/my-new-site.com>
AllowOverRide All
</Directory>
</VirtualHost>
Once you have added the new site, the web server will need to be restarted, if you are in a managed host environment, your web host should already have done this for you and the configuration is ready to go live when the DNS records for your site are changed to point to the new server.
Restarting the web server:
#service httpd restart
in Centos 7 it will be:
#systemctl restart httpd
Testing
Prior to go live, you can test locally, this is done by editing your /etc/hosts file on your workstation and then firing up your web browser and pointing to your web site. On Microsoft Windows desk tops the hosts file is located under the c:windowssystem32drivers directory.
Once a local DNS entry is present in our local hosts file, fire up a web browser and enter your new site in the address bar. If all has been configured correctly it should fire up and present your WordPress site. If it doesn't, verify the server's httpd logs and check the file permissions and paths to make sure everything is owned by your login account and accessible to the web server.
Going live
To go live, the DNS records for your site need to be changed to reflect the IP address of the new server. There will be a propagation delay time which can be upwards of 24 hours or more depending on your DNS provider. Once live, shut down the old site to avoid security exploits occurring as its still a functional web server even if no DNS entries are pointing to it.
Appendix
Creating the database
These steps are usually only needed if you are hosting back on your own hardware or into a private VPS that is unmanaged.
Create the database using the following command, using the site name as the database name makes it logic with the site but it is not mandatory.
$mysqladmin -u root -p create <mysitecom> Password:
Next create the user account, log into mysql and then execute the create user DDL command:
mysql -u root -p mysql Password: [mysql]>CREATE USER '<user_name_here>'@'localhost' IDENTIFIED BY '<NEW_DB_PWD>';
next grant permissions:
[mysql]>GRANT ALL PRIVILEGES ON wpdatabase.* TO '<user_name_here>'@'localhost';
Finally flush them so they apply:
[mysql]> FLUSH PRIVILEGES;
Then exit the mysql utility.
-oOo-
