Although this guide is targeted towards being used with an Ubuntu server, it should be easy to adapt it to other distributions assuming the same basic components are in place (a server running Apache, Mysql and PHP), and if the reader understands any difference in file locations on their distribution from Ubuntu server. This guide assumes that the user already has a server prepared to run Drupal and that they are running a copy of Drupal downloaded and installed manually rather than installed from a package manager. This guide was informed by my recent experiences setting up a server as a backup host and testing platform but will serve for permanent migration as well, although some of the steps will likely be unnecessary for a permanent transfer.

Two computers will be referenced consistently as examples through out the length of this article, one is Server_A - the server from which the instance of Drupal is being migrated from - and the other is Server_B - onto which Drupal is being moved. The Drupal site directory will be referred to as drupal (all in lower case) and the Drupal database will be referred to as DRUPAL (all caps). The database user for drupal will be referred to as USER, and the IP of Server_B will be 192.168.0.x

To keep site down time to a minimum, start by preparing the mysql database on Server_B. Notice that all mysql commands end in a semi-colon (;). Open up the mysql shell as root with the command mysql -u root and enter the root password. If the DRUPAL database has previously been on Server_B you must remove it before you can import a new one, but make sure you run this command on the out-dated database on Server_B, not on the current database on Server_A, or you will loose all you data since your last backup To remove the old database, run DROP DATABASE DRUPAL;. Now, before being able to import the DRUPAL database from Server_A, you have to create the database (unfortunately no command seems to exist to simply clear a database) by running CREATE DATABASE DRUPAL; in the mysql shell. Now the mysql user for drupal must be duplicated on Server_B’s mysql installation. Run CREATE USER 'USER' IDENTIFIED BY 'password'; with “password” being replaced by the password of USER on Server_A’s mysql database. Grant USER all privileges for the DRUPAL database with the command GRANT ALL PRIVILEGES ON DRUPAL.* TO 'USER' WITH GRANT OPTION;. Finally, flush the privileges of mysql (to actually make the changes in permissions take effect) by running the command FLUSH PRIVILEGES;. Log out of mysql shell with quit; and then (if necessary) remove the current drupal install with rm -r /var/www/drupal. Server_B is now ready to receive both the database and the site, so we move onto packaging those components on Server_A.

First, log in to your site on Server_A as administrator and put the site into Off-line mode by going to Administer > Site configuration > Site maintenance and selecting the appropriate option. Now, switching to command line on server A, we will pack the site into a tarball that will preserve the file permissions by running tar -pczf /tmp/drupal.tar.gz /var/www/drupal (alternatively you can migrate everything on the website by packaging up the whole www directory). Next dump the DRUPAL database by running mysqldump -u root -p DRUPAL > /tmp/DRUPAL.bak

At this point you need to transfer both files onto Server_B - which can be done in many ways, but I will only cover using scp. Run the command scp /tmp/drupal.tar.gz Server_B:/tmp and then scp /tmp/DRUPAL.bak Server_B:/tmp, then log in on command line to Server_B.

Extract drupal.tar.gz to its proper location by running tar xvf /tmp/drupal.tar.gz -C /var/www/. Now load the DRUPAL.bak file into the database as USER with mysql -u USER -p DRUPAL < /tmp/DRUPAL.bak. At this point, you should be able to navigate to your site on Server_B by going to 192.168.0.x, but you will not be able to log in. To log in, go to http://192.168.0.x/?q=user and log in as administrator. At this point the site should be fully functional, but to ensure that no problems occurred, go to the Drupal Status report page (Administer > Reports > Status report) and fix any problems reported there. At this point, you should be able to change Server_B’s copy of the site to online, and point your domain at it, leaving Server_A to under go maintenance or be taken offline permanently. To return the site to Server_A, simply reverse the direction of the steps.

In the future, I fully intend to investigate some of the modules related to backing up and migrating, but at the time I needed to migrate my site over in a timely fashion, and so had no desire to deal with the learning curve for a special module.