Migrating a production website to a new VPS without downtime is one of the most stressful operations in web development. A poorly executed migration can result in lost data, broken sessions, or hours of downtime during peak traffic. This playbook walks through a proven zero-downtime migration process for moving a website to a Russia VPS, covering DNS strategy, data synchronization, cutover procedures, and rollback planning.
1. Pre-Migration Planning
Before touching any infrastructure, document your current setup. Inventory all services your website depends on: web server (Nginx/Apache), application server (PHP-FPM, Node.js, Python), database (MySQL, PostgreSQL, MongoDB), cache (Redis, Memcached), search (Elasticsearch, Meilisearch), file storage (local disk, S3-compatible), email (SMTP relay), and any third-party APIs. Note the version of each service — the new VPS must run identical versions to avoid compatibility issues. Document your DNS configuration, SSL certificate provider, and any cron jobs or scheduled tasks. This inventory is your migration checklist.
2. Provisioning the New VPS
Provision a Russia VPS with sufficient resources to handle your current traffic plus 30% headroom. Use our 2026 provider comparison to select a provider that meets your latency, uptime, and budget requirements. Install the base operating system (Ubuntu 22.04 LTS is a safe default) and apply all security updates. Install the LEMP/LAMP stack or your application's runtime dependencies. Configure SSH key-only authentication, enable `ufw` firewall (allow only ports 22, 80, 443), and install `fail2ban` for brute-force protection. The goal is a production-ready server before any application code is deployed.
3. DNS Strategy: Low TTL Phase
The key to zero-downtime migration is DNS propagation timing. By default, DNS records have a TTL (Time To Live) of 3600 seconds (1 hour) or higher. If you cutover DNS at the last minute, some users will continue hitting the old server for up to the TTL duration, causing inconsistency. Solution: 24-48 hours before migration, lower the TTL on your DNS A record to 300 seconds (5 minutes). This way, when you cutover DNS, propagation completes within 5 minutes for most users. Most DNS providers (Cloudflare, Route 53, Namecheap) allow TTL customization. After migration, you can raise the TTL back to 3600 for better caching.
4. Code Deployment
Deploy your application code to the new VPS using the same deployment process you use for the current server. If you use Git, clone the repository and check out the same commit hash as the current production. If you use a deployment tool (Capistrano, Deployer, Ansible), run the same playbook. Verify the application boots correctly by running it on a non-standard port (e.g., port 8080) and accessing it via the VPS's IP address. Run your test suite against the new VPS to catch any environment-specific issues. Do not yet configure the production domain on the new VPS — leave Nginx/Apache listening on the IP only.
5. Database Migration: Initial Sync
Database migration is the most delicate part. The strategy is: replicate the database to the new VPS in advance, then perform a final incremental sync during the cutover window. For MySQL/MariaDB, set up master-slave replication from the old server (master) to the new server (slave). The slave will continuously apply updates from the master, keeping the data in sync. For PostgreSQL, set up streaming replication similarly. For MongoDB, configure replica set membership. The initial replication may take hours for large databases — start it 24-48 hours before the planned cutover. Verify replication lag is near-zero before proceeding.
6. File Storage Migration
File storage (user uploads, generated files, static assets) must also be synchronized. If you use S3-compatible storage, simply configure the new VPS to use the same S3 bucket — no migration needed. If files are on local disk, use `rsync` to copy them to the new VPS: `rsync -avz --progress /var/www/uploads/ root@new-vps:/var/www/uploads/`. Run this initial sync 24 hours before cutover to copy the bulk of files. During the cutover window, run a final incremental `rsync` to capture any files changed since the initial sync. The incremental sync should complete in seconds if the volume of new files is small.
7. SSL Certificate Transfer
If you use Let's Encrypt, simply issue new certificates on the new VPS using certbot — there is no need to transfer the existing certificates. Run `certbot --nginx -d yourdomain.com -d www.yourdomain.com` to issue and install new certificates. If you use a paid Certificate Authority (DigiCert, Sectigo), export the certificate and private key from the old server and install them on the new VPS. Verify HTTPS works on the new VPS by accessing it via IP with the Host header set (e.g., `curl --resolve yourdomain.com:443:NEW_VPS_IP https://yourdomain.com/`).
8. The Cutover Window
Choose a cutover window during your lowest-traffic period — typically Sunday 2-5 AM in your primary users' timezone. Notify your users in advance if your traffic is significant. During the cutover window: (1) put the old server in maintenance mode (return 503 with a friendly message), (2) perform the final database sync (for replication setups, promote the new server to master and stop replication), (3) perform the final `rsync` of files, (4) update DNS A record to point to the new VPS IP, (5) verify the site loads correctly via the new IP, (6) monitor for issues.
9. Verification
After DNS cutover, verify the new VPS is serving traffic correctly. Use `curl -I https://yourdomain.com/` to check the response headers — they should come from the new server (check the Server header if your web server identifies itself). Monitor application logs on the new VPS for errors. Run synthetic transactions (login, search, checkout) to verify functionality. Watch your error tracking service (Sentry, Bugsnag) for new errors. Monitor Google Analytics or your analytics platform to confirm traffic is flowing. Expect 5-15 minutes of mixed traffic during DNS propagation — some users will hit the old server, some the new.
10. Rollback Planning
Always have a rollback plan. If the new VPS has issues that cannot be fixed within 30 minutes, roll back to the old server. To roll back: (1) revert the DNS A record to the old server IP, (2) if you promoted the new database to master, set up reverse replication from new to old (or accept the data loss if you have a recent backup), (3) remove the maintenance mode from the old server. The rollback window is 60-90 minutes — after that, DNS propagation will be complete and rolling back becomes messier. Practice the rollback procedure in staging before the actual migration.
11. Post-Migration Cleanup
Once the new VPS is confirmed stable (typically 24-48 hours after cutover), clean up the old server. Take a final backup of the old server's data and store it safely for 30 days in case you discover missing data. Cancel the old VPS plan to stop paying for it. Update your documentation to reflect the new server's IP, location, and provider. Update your monitoring and alerting to track the new server. Raise the DNS TTL back to 3600 seconds for better caching. Review your SSL certificate renewal schedule — Let's Encrypt certificates expire in 90 days.
12. Common Pitfalls to Avoid
Several common mistakes cause migration failures. Hardcoded IPs: if your application has the old server IP hardcoded anywhere (config files, .env, database), update it before cutover. Time zone differences: if the new VPS is in a different timezone, ensure your application handles it correctly (always store UTC, render in user's timezone). Locale differences: install the same locale packages on the new VPS. PHP version mismatches: a 1-version difference can break applications — match exactly. Missing PHP extensions: compare `php -m` output between old and new servers. Missing system packages: install everything the application needs (ImageMagick, FFmpeg, etc.). File permissions: ensure ownership and permissions match (typically `www-data:www-data` for web files).
13. Testing in Staging First
For complex migrations, test the entire process in staging first. Provision a third VPS as a "staging" target, migrate a copy of production data to it, and run the full cutover procedure. This catches issues like missing dependencies, broken file paths, and configuration drift before they affect production. The staging test should be identical to the production migration in every way except the actual DNS cutover. If staging migration takes 4 hours, expect production to take 4-6 hours (with debugging).
14. Communication Plan
For migrations of customer-facing applications, communicate proactively. Post a status update 7 days before the migration announcing the maintenance window. Post a reminder 24 hours before. During the migration, post real-time status updates to your status page (statuspage.io, cachethq.io). After the migration, post a completion summary with any issues encountered and resolution time. Customers tolerate planned maintenance far better than unexplained outages — transparency builds trust.
Conclusion
Migrating a website to a Russia VPS without downtime is achievable with careful planning. Lower DNS TTL 24-48 hours in advance, set up database replication, sync files with rsync, choose a low-traffic cutover window, and always have a rollback plan. Test the migration in staging first, document every step, and communicate proactively with users. A well-executed migration is invisible to users — they never know it happened. A poorly executed migration can take a site down for hours and erode user trust. Invest the time to do it right.