Database Migration Strategies

Moving a database between servers is the highest-stakes part of any migration. A wrong step can mean data loss, replication drift, or hours of unexpected downtime.

RasnuCloud selects the right strategy for your database based on its size, your acceptable downtime window, and the database engine — and executes it correctly.

---

Strategy 1: Snapshot and Restore

When to use: Databases under 10 GB. Acceptable downtime of 5–15 minutes.

RasnuCloud takes a consistent, full snapshot of your database, transfers it to the destination, restores it, and performs a final incremental sync during a brief maintenance window.

Migrate the PostgreSQL database to the destination server.
The database is about 3 GB. We can have up to 10 minutes of downtime.

This is the simplest and most reliable strategy. For most teams with smaller databases, it's the right choice.

---

Strategy 2: Live Replication → Cutover

When to use: Databases over 10 GB. Target downtime under 5 minutes.

RasnuCloud sets up live replication between source and destination. Data flows continuously from source to destination. When replication lag reaches zero, RasnuCloud executes the cutover — a window of 30–120 seconds where writes are briefly paused, the final sync runs, and traffic is switched.

Migrate the MySQL database using live replication.
We need to keep downtime under 5 minutes. The database is 40 GB.

This is the strategy RasnuCloud uses by default for large databases in production migrations.

---

Strategy 3: Online Migration (No Locking)

When to use: Large tables that can't be locked during the migration, or when you need to change schema while migrating.

For tables with millions of rows where a standard migration would lock writes for too long, RasnuCloud uses online migration tooling that replicates data in the background without any locks.

Add an index to the orders table (80M rows) without taking a lock or causing any
downtime for the application

Migrate the users table to the new schema while the application keeps running

---

Data Integrity Verification

After every database migration — regardless of strategy — RasnuCloud runs a full integrity verification:

• Row counts verified between source and destination for every table
• Checksums on critical tables to confirm data is bit-for-bit identical
• Index validity confirmed on the destination
• Foreign key integrity checked — no orphaned records

RasnuCloud will not consider a database migration complete until verification passes. If any check fails, it reports exactly which tables have discrepancies before you cut over.

The migration completed but I want to verify everything before I switch traffic.
Run the full integrity check.

---

Redis

Migrate all Redis data to the destination server. I need no data loss.

RasnuCloud sets up live Redis replication, waits for the destination to fully synchronize, then promotes it to standalone during a sub-second cutover window.

---

MongoDB

Migrate my MongoDB replica set to the new servers.
The dataset is 15 GB — minimize downtime.

RasnuCloud handles adding the new servers to the replica set, letting them sync, stepping down the primary, and reconfiguring the set — all without data loss.

---

Don't migrate databases during peak traffic

Even with live replication, database migrations have risks. Plan your cutover during low-traffic periods. RasnuCloud supports pausing and resuming a migration — start the data sync during the day and execute the final cutover at night.