Cloud Migration: Zero Downtime Strategy

“Zero downtime” cloud migration does not mean every byte moves with zero seconds of freeze. It means users see no outage—or only a short, controlled cutover—while production lands on new infrastructure. This guide covers blue-green, phased moves and DNS cutover aimed at EuroVDC cloud servers / KVM.

If the target is Sofia (EU), also read the Bulgaria KVM VPS guide. For plan sizing see the KVM rental guide. Here the focus is how you manage interruption risk.

What “zero downtime” really means

• Read-heavy sites: Old and new run in parallel; DNS or a load balancer shifts to the new side; writes sync with a short freeze window.
• Write-heavy apps: A short maintenance window (minutes) or a freeze to close replication lag is normal; “literally zero seconds” is often marketing.
• Metric: HTTP 5xx, failed checkouts and “site down” time—your SLA defines success.

Inventory before you move

1. App stack (PHP, Node, Docker…), web server, reverse proxy.
2. Database size, engine (MySQL/PostgreSQL), existing replication.
3. File storage (uploads, media); can it move to object storage?
4. Cron, queues, websockets, outbound email.
5. SSL certs, DNS TTL, dependent subdomains.
6. Secrets and API keys—ready on the target, not only in git.

Missing inventory creates cutover-day surprises. Stand up the same image on a staging VM first.

Strategy A: Blue-green (parallel environments)

Keep the old environment as “blue” and prepare EuroVDC cloud as “green”. Green runs the app plus a DB snapshot/replica; smoke tests pass; traffic flips to green. On failure, DNS/LB returns to blue.

1. Provision the target VM (Sofia), harden OS and firewall.
2. Deploy code; wire production secrets.
3. Bring the DB close via replica or dump + binlog/WAL.
4. Health-check green (login, cart, critical APIs).
5. Lower TTL early; at cutover change A/AAAA or LB backends.
6. Keep blue for ~48 hours (rollback).

Strategy B: Phased migration

Move static/CDN first, then read replicas, then the write master. Splits risk for ecommerce and large databases. Every phase needs a written rollback.

• Phase 1: Media/object storage or CDN origin update.
• Phase 2: Shift a share of read traffic to the new app servers.
• Phase 3: DB promote / final sync + short write freeze.
• Phase 4: Watch the old host, then decommission.

DNS, SSL and the cutover window

Lower TTL to 300 (or less) 24–48 hours before cutover. Validate SSL on the new IP with Let’s Encrypt or your existing cert beforehand. Schedule cutover in a low-traffic window; add payment-provider webhooks to the new IP allowlist.

If the domain is at EuroVDC, update A records in one panel via domain search / DNS; the same record logic applies at an external registrar.

Database sync: practical options

• Small DB (<5–10 GB): Dump/restore in a maintenance window with app freeze.
• Medium/large: Build replication, promote when lag ≈ 0; short freeze.
• File-heavy: rsync dry-run, then final delta at cutover.

After cutover check integrity: row counts, last order IDs, critical crons firing once.

Common migration mistakes

• Cutting over without lowering TTL—hours of split-brain.
• Flipping production DNS without a staging rehearsal.
• Crons running on both hosts (double charges / double email).
• Moving files but forgetting .env and queue workers.
• Deleting blue immediately with no rollback plan.
• Refusing any write freeze in the name of “zero downtime” and risking data loss.

Sample timeline (mid-size SaaS)

1. T-7 days: Inventory, target VM, staging rehearsal.
2. T-2 days: Lower TTL, prepare SSL, start replication.
3. T-0 (60–90 min window): Freeze writes → final sync → DNS/LB → smoke → unfreeze.
4. T+2 days: If metrics are stable, decide to retire blue.

Practical notes on EuroVDC

On Sofia KVM you install your own reverse proxy (Nginx/Caddy) with root; use the panel IP in DNS. Managing domain + SSL in the same account shortens the cutover checklist. On move day, record staging smoke (screenshot + curl) before opening tickets—it speeds diagnosis.

Add payment and email IP allowlists to the new server IP on T-1. Watch 5xx and queue depth for 24 hours after cutover; silent failures usually show up in cron and webhooks, not on the homepage.

Frequently asked questions

Is true zero downtime possible?

For read-heavy systems, user-visible outage can often be avoided. With heavy writes and a single master DB, a short planned freeze is safer; “literally zero seconds” claims are usually overstated.

What is the typical EuroVDC target?

A Sofia KVM cloud server with root, NVMe and EU location. Size the plan to the workload and rehearse on the same image in staging.

Blue-green or phased?

Blue-green is fast for small/medium apps. Phased migration splits risk for large DBs or many components. Combining both is common (prepare green, sync the DB in phases).

When should DNS TTL be lowered?

At least 24–48 hours before cutover. Otherwise resolvers cache the old IP and traffic splits across both hosts.

How does rollback work?

Keep the old (blue) environment up for at least 48 hours. Point DNS/LB back; have a written plan for syncing post-cutover writes back to blue if needed.

What about email and cron during migration?

Lock cron so it runs on only one side at cutover. Add SMTP/webhook IP allowlists on the new host to avoid silent delivery failures.

Plan the move

Compare Sofia plans: Cloud Server. For heavy single-tenant needs see dedicated servers; for location context see the Sofia VPS guide.