The following assumes you're comfortable on the command line and with basic networking. Also, I haven't tried this recently so I'd strongly recommend you try this out on a test install before doing it on a production install.
Pre-reqs
- Verify your full machine backup and restore works.
- Verify you can whitelist traffic to Central only from your IP. An upstream firewall is great for this.
- Verify you have the same OS on the source (src) and destination (dest). If you don't, the folders noted below may not match. Adjust adjust accordingly.
- Verify you can set the TTL of the DNS record on the domain to something low (~300 secs) to reduce downtime.
- Verify you have an effective way to communicate a maintenance window with users.
Migration
- Take a full machine backup of src.
- Over ssh, rsync the key folders (
/var/lib/docker
,/root/central
) from src to dest. This might take some time. - Start the maintenance window.
- Block all incoming HTTP/S traffic to src.
- Shutdown Central on src with
docker-compose stop
; - Rsync the key folders from src to dest again to pick up the latest changes to data. This will be faster than the first rsync.
- Shutdown src and take another full machine backup.
- Only allow incoming HTTP/S traffic only from your IP to dest.
- Update the DNS record to point to the dest. This should happen quickly if your DNS TTL is low.
- Bring the dest server back up (
docker-compose build; docker-compose up -d
). - Verify you can login via the Central UI to dest, see records, preview forms, etc.
- Allow all incoming HTTP/S traffic to dest.
- Stop the maintenance window.
Notes
- If you value speed over safety, you can skip the backups. I don't recommend it.
- Running the first rsync outside the maintenance window should be safe, but if you want to be extra safe, you can run it after blocking all incoming traffic.