The process of migrating WordPress from an SSH command line is relatively painless and only requires basic Linux Command Line knowledge to achieve. There are a few basic steps to follow:
The (detailed) process is:
- Package up your site’s WordPress 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.
- Reverse the 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.
Even though this appears to be a lot of steps, your new Web Hosting service should create the account, database and configure you with a New Account Name and Password combination as well as DB credentials. We will cover all steps and you can omit what is not necessary as needed.
Packaging up WordPress
Log into your web site via SSH and change to your wordpress root directory. My test WordPress site files are located in /var/www/vhosts/<domain-name>. Change using a command similar to:
The wordpress files are owned by the HTTPD Daemon (the web server) which in this installation is the popular “Apache Web Server”. All files are owned by the user and group “apache“. To package the wordpress site I use the Linux/UNIX utility “tar” to create an archive of my site ready to transfer. Although small, we will compress the archive to save some space.
tar -cvzf copy-test-conetix-com-au.tar .
Once the files are archived up, we need to dump our database tables to a file. We need the Database name, Database User Name and Password in order to access the Database. These settings are located in the file wp-config.php, the quick way to get them is is to extract all lines with “DB” in them:
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 usem in the command line for the mysqldump utility, the command looks like:
mysqldump -u wpuser -ppassword wpdatabase > copy-db-20150505.sql
We write the mysqldump output to the file copy-db-20150505.sql. Once we have this file we transfer both files to the new server.
In this example we used the password on the command line, you can omit it and 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).
There are several methods available on most systems to get the tar file and SQL data file to the new web server. I like to use the rsync command to move data. SSH into the new web server and use a similar command to that shown below (changing the host names as needed):
cd /var/www/vhost/new-directory rsync -avz firstname.lastname@example.org:/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 http://old-web-site.com/copy-db-20150429.sql wget http://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.
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. 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. Its good practice 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 email@example.com 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
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:\windows\system32\drivers 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.
To move you site into production use (go live), the DNS records for your site need to be changed to reflect the IP address of the new server. I usually create a single “A” record for “domain.com” and another “A” record for “www.domain.com”
It is not uncommon for there to be a propagation delay before your new site is visable. (Worst case time can be 24 hours or more depending on your DNS provider). Once the new site is live, shut down the old site (remove the HTTP configuration for the VirtualHost) and the site files including TAR copies) to avoid security exploits occurring.
Even if a web server has no DNS entries pointing to it, its still a functional web server that can be exploited.
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 (to be sure it applies) flush them so they apply:
[mysql]> FLUSH PRIVILEGES;
Then exit the mysql utility.
Redirecting to you preferred domain name
It is common to skip using the “www” part of a domain name and just use the “domain-name.com” as the advertised web server. To make sure people end up on the right site, I use a simple rewrite rule in my web server configuration, 1 file per site and located in /etc/httpd/vhosts.d
<VirtualHost *:80> ServerAdmin firstname.lastname@example.org ServerName www.domain-name.com RewriteEngine on RewriteRule (.*) http://sdomain-name.com/ [R=301,L] </VirtualHost>