Zero-Downtime Cutover

Downtime during a migration is a visible failure. Even 5 minutes of a 503 page damages user trust and, depending on your business, can have direct financial consequences.

RasnuCloud is designed to cut over without your users noticing. Here's how it works.

---

The Core Principle

Zero-downtime cutover relies on one fundamental rule: the destination must be fully ready and accepting traffic before the source stops.

This means:

1. Your destination has a live, up-to-date copy of your data via replication
2. Traffic is shifted to the destination gradually or atomically — not in a hard cutover
3. The source stays alive and serving traffic until the destination is confirmed healthy

RasnuCloud enforces all three of these steps automatically.

---

The Cutover Sequence

When you've approved the migration plan and the data sync is complete, RasnuCloud executes cutover like this:

Cutover sequence initiated

  ✓ Destination database replication lag: 0 seconds
  ✓ All destination health checks: passing
  ✓ Application responding on destination: HTTP 200

  → Adding destination to load balancer (source remains active)
  → Monitoring error rate across both servers...
  → Error rate on destination: 0.0% over 2 minutes ✓
  → Removing source from load balancer
  → 100% of traffic now on destination

  ✓ External health check: api.mycompany.com → Hetzner IP ✓
  ✓ Database writes confirmed on destination ✓
  ✓ 0 errors in the last 5 minutes ✓

  Cutover complete. No downtime detected.

Your users experienced nothing.

---

When You Have a Load Balancer

If you have a load balancer (HAProxy, Nginx upstream, AWS ALB, Cloudflare), RasnuCloud works with it to shift traffic gradually:

I have an Nginx load balancer. Add Hetzner as an upstream with 10% of traffic
while source gets 90%. Monitor for 5 minutes, then move to 50/50, then 100% Hetzner.

This is a canary-style cutover. If anything breaks during the 10% phase, you're at 10% impact — and you flip back instantly.

---

DNS Cutover

If you're switching the DNS record for your domain rather than using a load balancer:

1. Lower your TTL 24 hours before migration. Set it to 60 seconds. This ensures that after you change the DNS record, the change propagates globally within 2 minutes instead of hours.
2. Let RasnuCloud handle the timing: when replication lag is zero and the destination is verified healthy, RasnuCloud prompts you to make the DNS change.
3. After the TTL expires and traffic is flowing to the destination, RasnuCloud confirms with an external check.

DNS is Not Instant — Even with Low TTL

Some DNS resolvers ignore TTL and cache for longer. Keep your source server running and reachable for at least 24 hours after DNS cutover to handle any stragglers.

---

When Things Go Wrong

Rollback during cutover is fast because the source server has never been touched:

Something's wrong on the destination — errors are spiking. Roll back immediately.

RasnuCloud re-routes 100% of traffic to the source within seconds. Your source database was never decommissioned, so there is no data loss. You investigate, fix the issue, and schedule the cutover for another time.

This safety property is why RasnuCloud never decommissions the source server automatically — only you initiate that step, after you're completely satisfied.

---

After Cutover

Once you've confirmed the destination is healthy:

1. Monitor for 24–48 hours before removing the source
2. Remove from load balancer (if applicable)
3. Decommission the source — RasnuCloud walks you through this step to confirm nothing was missed
4. Update any hardcoded IPs in firewalls, applications, or monitoring systems

I've been running on the new server for 48 hours with no issues.
Walk me through decommissioning the old server safely.