Client Area

How to Migrate Your Website to a Hong Kong VPS: Zero-Downtime Transfer Guide (2026)

Migrating a live website to a new server is the task most website owners dread most — the risk of downtime, lost data, or a broken site that was working fine before. Done systematically, a website migration to a Hong Kong VPS is achievable with zero downtime and minimal risk.

This guide walks through the complete migration process: from initial VPS setup through file and database transfer, testing the migrated site, and executing a clean DNS cutover that your visitors never notice.

The Zero-Downtime Migration Strategy

The key insight that makes zero-downtime migration possible is this: your old and new servers can both serve your site simultaneously until you are ready to switch. DNS propagation takes up to 48 hours, during which some visitors hit the old server and some hit the new one — both serving identical content from their respective databases.

This requires keeping the two databases in sync during the cutover window. The procedure below handles this cleanly.

Step 1: Set Up and Verify Your New Hong Kong VPS

Before touching your existing server, provision and fully configure your new Hong Kong VPS:

  • Install your web stack (Nginx + PHP + MySQL, or your application’s stack)
  • Configure SSL certificate infrastructure
  • Verify all required PHP extensions and software versions match your current hosting
  • Set file permission structures

Completing setup before transferring data means your new server is verified before any content migration begins.

Step 2: Lower Your DNS TTL

DNS TTL (Time to Live) controls how long DNS resolvers cache your domain’s IP address. Before migration, reduce your TTL to 300 seconds (5 minutes) — this shortens the propagation window during cutover to approximately 5 minutes instead of 24–48 hours.

Make this change at least 24–48 hours before your planned cutover — you need to wait for existing cached TTL values to expire before the lower TTL takes effect.

# Check your current TTL
dig yourdomain.com +noall +answer

Log in to your DNS provider (Cloudflare, Namecheap, GoDaddy, etc.) and reduce the A record TTL for your domain to 300.

Step 3: Transfer Website Files

Transfer your website files from the old server to the new Hong Kong VPS using rsync — it handles large file sets efficiently with compression and resume capability:

# From your local machine, or from the new VPS pulling from old server
rsync -avz --progress \
  -e "ssh -p 22" \
  oldserver_user@OLD_SERVER_IP:/path/to/webroot/ \
  /www/wwwroot/yourdomain.com/

For cPanel/shared hosting where SSH may not be available, use SFTP:

# Using sftp command line
sftp oldserver_user@OLD_SERVER_IP
get -r /public_html/* /www/wwwroot/yourdomain.com/

Set correct ownership after transfer:

chown -R www:www /www/wwwroot/yourdomain.com/
find /www/wwwroot/yourdomain.com -type d -exec chmod 755 {} \;
find /www/wwwroot/yourdomain.com -type f -exec chmod 644 {} \;

Step 4: Export and Import the Database

On the old server — export the database:

mysqldump -u DB_USER -p DB_NAME \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  > /tmp/site_backup_$(date +%Y%m%d_%H%M).sql

Transfer the dump to your new VPS:

scp -P 2277 oldserver_user@OLD_SERVER_IP:/tmp/site_backup_*.sql \
  deploy@NEW_VPS_IP:/tmp/

On the new VPS — create database and import:

mysql -u root -p -e "CREATE DATABASE new_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "CREATE USER 'new_user'@'localhost' IDENTIFIED BY 'strong_password';"
mysql -u root -p -e "GRANT ALL PRIVILEGES ON new_db.* TO 'new_user'@'localhost';"
mysql -u root -p -e "FLUSH PRIVILEGES;"

mysql -u new_user -p new_db < /tmp/site_backup_*.sql

Step 5: Update Application Configuration

Update your application’s configuration file to point to the new database credentials:

WordPress (wp-config.php):

define('DB_NAME', 'new_db');
define('DB_USER', 'new_user');
define('DB_PASSWORD', 'strong_password');
define('DB_HOST', '127.0.0.1');

Laravel (.env):

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=new_db
DB_USERNAME=new_user
DB_PASSWORD=strong_password

Step 6: Test the Migrated Site Before DNS Cutover

This is the most important step. Test your site on the new server without changing DNS by modifying your local machine’s hosts file:

macOS / Linux:

sudo nano /etc/hosts

Add:

NEW_VPS_IP yourdomain.com www.yourdomain.com

Windows: Edit C:\Windows\System32\drivers\etc\hosts as administrator with the same line.

Now visiting https://yourdomain.com in your browser loads from the new VPS while the rest of the world still hits the old server. Test thoroughly:

  • All pages load correctly
  • Images and media display properly
  • Forms submit and process correctly
  • User login and session management work
  • E-commerce checkout processes completely
  • SSL certificate is valid and HTTPS works
  • No broken links or missing assets

Remove the hosts file entry when testing is complete.

Step 7: Final Database Sync Before Cutover

Your old server’s database has continued accepting new data (orders, user registrations, comments) since your initial export. Sync changes before DNS cutover:

# Export only changes since initial backup
mysqldump -u DB_USER -p DB_NAME \
  --single-transaction \
  > /tmp/final_sync.sql

scp -P 2277 oldserver_user@OLD_SERVER_IP:/tmp/final_sync.sql \
  deploy@NEW_VPS_IP:/tmp/

# On new VPS — import updates
mysql -u new_user -p new_db < /tmp/final_sync.sql

For sites with high write rates (frequent orders or user activity), consider scheduling a brief maintenance window (5–15 minutes) to prevent new writes during the final sync. Display a “back shortly” notice on the old site while syncing and cutting over DNS.

Step 8: DNS Cutover

With your TTL already reduced to 300 seconds and your new site verified:

  1. Log in to your DNS provider
  2. Update the A record for yourdomain.com and www.yourdomain.com to your new Hong Kong VPS IP
  3. Save changes

Propagation with a 300-second TTL takes approximately 5–10 minutes for most global resolvers. Monitor which server is receiving traffic:

# Check which IP your domain resolves to from different locations
dig yourdomain.com +short

# Monitor Nginx access logs on the new server
tail -f /var/log/nginx/access.log

Once you confirm traffic is consistently hitting the new VPS, your migration is complete.

Step 9: Post-Migration Cleanup

  • Remove your hosts file test entry if you forgot earlier
  • Increase DNS TTL back to 3600 seconds (1 hour) or higher after 48 hours
  • Keep the old server running for 72 hours as a fallback — revert DNS if any unexpected issues arise
  • Set up automated backups on the new VPS (see our security checklist)
  • Cancel the old hosting plan after confirming stability

Conclusion

Migrating to a Hong Kong VPS with this systematic approach is achievable with zero downtime and zero data loss. The process takes 2–6 hours for most sites depending on database size and file volume — the majority of that time is file transfer rather than active work.

The performance improvement after migration — CN2 GIA routing for Chinese visitors, NVMe SSD I/O, dedicated resources — is immediately measurable in page load times and TTFB from the moment DNS propagation completes.

Ready to migrate? Start with Server.HK’s Hong Kong VPS plans — provision your new server in minutes and begin the migration process today.

Frequently Asked Questions

How long does a website migration to a Hong Kong VPS take?

For a typical WordPress site (1–5 GB of files and a database under 500 MB), the active migration work takes 2–4 hours. Large sites with 10+ GB of media files or databases over 2 GB may require 6–12 hours for file transfer depending on connection speed between servers. DNS propagation adds 5–10 minutes with a reduced TTL.

Can I migrate a WooCommerce store to a Hong Kong VPS without losing orders?

Yes, using the process in Step 7 — a final database sync immediately before DNS cutover captures any orders placed after the initial export. For very high-volume stores, a brief 5–10 minute maintenance window during the final sync eliminates any risk of order data loss during the cutover moment.

What if something breaks after DNS cutover?

Keep your old server running for at least 72 hours after cutover. If a critical issue appears, revert the DNS A record to your old server IP — with a 300-second TTL, most visitors will be back on the old server within 5–10 minutes. Diagnose and fix the issue on the new server, then re-execute the cutover when ready.

Leave a Reply