Migrate a Website with Minimal Downtime
Because the global DNS system takes up to 48 hours to take to DNS changes, websites that allow users to make changes on a website must typically disable user input during a transfer. However, since Site Wrangler uses nginx, we can shorten the outage to only a few minutes. This guide assumes you are migrating from a non-nginx server. If you are migrating from an nginx server, this guide still works but it may be better to migrate the site and set up the old server as the proxy. If you are running a site where only admins can modify site data, you may be better off cloning the site to the new server, updating the DNS and then deleting the site from the old server 48 hours later, so long as your admins know not to modify the site during this time.
Step 0: (optional) Test site on the new Server
Before starting the real transfer, it is usually best to clone the site to the new server and make sure it will work before setting up the reverse proxy. You will need to edit the hosts file on your computer to point the domain to the new server on just your local machine. At the end of the transfer process you will need to re-migrate your site data so that any updated information is carried across.
Step 1: Setup nginx proxy
First, let’s set up nginx to point to your old server. You will need to know the IP address of your old server and enter it when prompted for PROXYIPP. When prompted for PROXYPORTT, enter 80 for a non-SSL site or 443 for an SSL-enabled site.
sw user add example_user sw nginx add example.com example_user
Your old server should now be accessible via the new server. You can test this by editing the hosts file on your local machine and testing the site in a browser.
Step 2: Update DNS
Now update your DNS settings to point your domain to the new server. This is generally best accomplished by updating your domain’s nameservers to the new Site Wrangler server. It is important to note that if you use a third party email provider such as Gsuite, you should update your DNS zone file on the Site Wrangler server before updating the nameservers. Alternatively, if you host your email on your web-server, make sure you set up all of your email accounts for the domain on the new Site Wrangler server before updating DNS.
Step 3: Wait
Since the global DNS system takes up to 48 hours to take to new values, we want to wait that long before migrating the site data. This is to make sure that the old server is no longer being accessed directly before the migration and that all new data modifications will only occur on the new server, following the transfer.
Email, however cannot be proxied by Site Wrangler’s default setup. Instead just re-sync the email messages every so often or if email is not too important to them, just once at the end of the migration process. Just be sure to fix file permissions following each sync. Let email users know that any messages that are deleted will show back up and any messages that are moved to a different folder will end up having a duplicate show up in the original location after each sync.
Step 4: Transfer Site Data
Now that all web traffic is going to the new server, we can move the site data across. The best way to do this is to first rsync the site files from the old server to the new. Then we need to disable the site, but since we will be using a different nginx template when we re-enable the site, let’s just delete it.
sw nginx add example.com example_user
When prompted for a template select maintainance-ssl
if your site is SSL-enabled or otherwise maintainance
.
Wile the site is down, we need to re-run the rsync but since we just ran one, there should be little to move if anything at all. Your rsync commands should look something like this:
rsync -ar root@192.168.0.1:/home/example_user /home/
Now that the data is moved, we need to make sure that files are owned by the correct user by running ls ~/public_html
. Otherwise this command will change all the files in the public folder to be owned by the site’s user:
chown example_user:example_group -r /home/example_user/public_html/
Now we need to move the SQL data if applicable:
ssh user@192.168.0.1 'mysqldump example_database -u example_user -p' | mysql example_database -u example_user -p
Lastly, we need to re-enable the site on the new server; this time using the template best suited for the site instead of the proxy template.
sw nginx add example.com example_user
This time select the template most appropriate for your live site. Now the site should be live. Make sure to test your transferred site thoroughly.
Don’t forget to remove any hosts file modifications you made during the transfer to avoid future confusion.