How to Migrate VPS from Another Provider to Hostini with Zero Downtime

Migrating a VPS between providers looks risky when you have a production application running, but the operation is deterministic when it follows a runbook. The real risk is not in the commands — it’s in skipping validations or underestimating DNS TTL. This tutorial covers the full process to move your VPS from Vultr, DigitalOcean, Contabo, or similar providers to Hostini, with a downtime window measured in seconds.

The approach uses incremental rsync to synchronize files while the old application keeps serving traffic, reduces DNS TTL to speed up cutover propagation, and validates everything via local /etc/hosts before making the change public. Target persona: you run a Linux VPS (Ubuntu/Debian/Rocky) with a web application, database, and possibly a stack like Nginx + PHP-FPM, Node.js, or Docker.

Estimated time: 2-4 hours, with 30-45 minutes of active execution and the rest waiting for rsync and DNS propagation. The downtime perceived by end users typically stays under 2 minutes.

Prerequisites

Before touching any server, document the current state. Run systemctl list-units --type=service --state=running on the source and save the output. Note down versions: nginx -v, php -v, mysql --version, node -v. List cron jobs with crontab -l and ls /etc/cron.d/. This inventory is what you will replicate.

Provision the destination VPS on Hostini

The new VPS should mirror the source operating system on the same major version. If the source runs Ubuntu 22.04, pick Ubuntu 22.04 — jumping OS versions in the middle of a migration adds incompatibility variables (libraries, config paths) you don’t need to carry.

ssh root@NEW_HOSTINI_IP

sudo apt update
sudo apt install -y nginx mysql-server php8.3-fpm php8.3-cli redis-server

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Reduce the DNS TTL

This step must be done 24 hours before the cutover. The current TTL of your A record determines how long DNS resolvers around the world will cache the old IP after you point to the new one. A default TTL of 3600s (1 hour) or 86400s (1 day) means downtime measured in hours for some visitors.

Sync data with rsync

rsync with the application running is safe for static files (web root, uploads, configs), but requires care with databases — sync database files via mysqldump/pg_dump, not via direct copy of the table files.

rsync -avz --progress \
  /var/www/ \
  root@NEW_HOSTINI_IP:/var/www/

rsync -avz --progress \
  /etc/nginx/ \
  root@NEW_HOSTINI_IP:/etc/nginx/

mysqldump --single-transaction --routines --triggers \
  --all-databases > /tmp/backup.sql

rsync -avz /tmp/backup.sql root@NEW_HOSTINI_IP:/tmp/

ssh root@NEW_HOSTINI_IP
mysql < /tmp/backup.sql

rsync -avz --progress \
  /etc/letsencrypt/ \
  root@NEW_HOSTINI_IP:/etc/letsencrypt/

sudo systemctl enable --now nginx php8.3-fpm mysql
sudo systemctl status nginx

Validate before the cutover

This is the step that separates a smooth migration from a chaotic one. You will test the new VPS as if it were already production, without touching the public DNS — only your local /etc/hosts.

sudo nano /etc/hosts

NEW_HOSTINI_IP  yourdomain.com www.yourdomain.com

Cutover: point DNS to the new IP

This is the transition moment. Before the switch, run a final rsync to capture any changes since the last sync. Ideally, put the application in maintenance mode for 30-60 seconds during this final rsync to guarantee consistency.

rsync -avz --delete --progress \
  /var/www/ \
  root@NEW_HOSTINI_IP:/var/www/

mysqldump --single-transaction --routines --triggers \
  --all-databases > /tmp/final.sql

rsync -avz /tmp/final.sql root@NEW_HOSTINI_IP:/tmp/
ssh root@NEW_HOSTINI_IP "mysql < /tmp/final.sql"

dig +short yourdomain.com @8.8.8.8
dig +short yourdomain.com @1.1.1.1

Post-cutover verification

Confirm everything is responding on the new infrastructure and nothing still depends on the old server.

curl -I https://yourdomain.com

The response should include Server: nginx (or whatever you configured), and the TCP socket IP should be the Hostini one. Verify with curl -v to inspect the TLS handshake and confirm the certificate is correct.

Monitor logs for a few hours:

sudo tail -f /var/log/nginx/access.log

Incoming traffic = cutover worked. If logs stay empty after 30 minutes, DNS propagation may be slow — some ISPs ignore TTL.

Troubleshooting

TLS certificate error after migration

Check that the certificate path in nginx still points to /etc/letsencrypt/live/yourdomain.com/. If you renamed directories during the migration, adjust ssl_certificate and ssl_certificate_key in the config. Test with sudo nginx -t before reloading.

Application can’t connect to the database

Confirm the database user exists on the new VPS with the same passwords. mysqldump exports data but doesn’t import mysql.user records by default — add --all-databases (already included in the commands above) or do a separate dump of mysql.user. Check /etc/mysql/my.cnf to make sure bind-address is correct.

Traffic keeps hitting the old VPS

Resolvers that ignore TTL can cache for hours. Keep the old VPS online for 48-72 hours after cutover as a safety net. Configure it to issue a 301 redirect to the new IP via Nginx — that way even visitors stuck on old cache end up where they should be.

Next steps

With the migration complete, focus on consolidating operations on the new infrastructure:

• Configure automatic backups on the new VPS — scheduled snapshots protect against operational errors
• Update monitoring (UptimeRobot, Better Stack) to point to the new endpoints
• Document the runbook you executed for the next migration — it evolves with each run
• After 7 stable days on Hostini, cancel the old VPS and remove the safety redirects
• Restore DNS TTL to a standard value (3600s or 86400s) — keeping it at 60s permanently puts extra load on resolvers

If you are putting production load on a VPS, a Hostini VPS offers NVMe SSD, native IPv6, and a network with volumetric attack protection — worth running comparative benchmarks during the parallel window between both servers to confirm a real performance gain.