Replication & Final Cutover

The most technically demanding part of any migration is the final cutover — the moment when you stop serving traffic from the old server and start serving it from the new one. Done poorly, this results in data loss or extended downtime. Done with RasnuOS, it is a sub-second operation.

Migrating Stateful Data

Migrating stateless application code is straightforward — you pull the latest Git commit onto the new server. Migrating stateful data (databases, user-uploaded files, persistent queues) requires careful orchestration to avoid data loss during the transfer window.

The Double-Sync Pattern

For file-based stateful data (e.g., an uploads directory at /var/www/uploads or a media storage volume), RasnuOS uses a double-sync pattern executed over the encrypted peer-to-peer tunnel between the two Agents.

1. Phase 1 — Bulk Sync (Background): While the source server remains fully live and accepting traffic, RasnuOS begins transferring the entire dataset to the target in the background. For large datasets (hundreds of gigabytes), this can take time. Your application is completely unaffected.
2. Phase 2 — Delta Cutover: Once the bulk transfer completes, RasnuOS briefly suspends the source application — for a few seconds at most. It executes a second, lightning-fast incremental sync that transfers only the files that were created or modified during the Phase 1 window. The target is now perfectly current.

Database Replication

For live databases (PostgreSQL, MySQL, MariaDB), RasnuOS takes a different approach. Instead of a simple file copy, it establishes native database streaming replication:

1. The source database continues accepting writes while the target database receives a consistent snapshot.
2. All subsequent writes are streamed to the target replica in real-time, keeping it fully synchronized with zero lag.
3. Before the cutover, the replica is confirmed to be fully caught up.

Only then does the cutover execute — promoting the replica to primary and switching the DNS in a single atomic operation.

Automated DNS Cutover

The exact second the target server is confirmed ready, RasnuOS fires an API call to your connected DNS provider (Cloudflare, DigitalOcean, Route53, or others). The A and AAAA records for your domain are updated instantly.

Providers like Cloudflare proxy traffic dynamically, meaning the global traffic shift takes effect in milliseconds — not the 24–48 hours of traditional DNS propagation.

The Grace Period

After the DNS cutover completes, the original source server is not immediately decommissioned. The Migration Engine holds it in a Grace Period — keeping it live alongside the new server while any residual traffic from slower DNS caches drains naturally. Once you are fully satisfied that the new server is operating correctly, you can destroy the original with a single click from the dashboard.