Server-to-Server Migrations

Moving a server to a new host is one of the most stressful events in infrastructure operations. You're managing live production data, coordinating with your team, watching the clock, and praying that the cutover goes smoothly.

RasnuCloud handles server migrations autonomously — with a detailed, reviewable plan, step-by-step execution, and a rollback path at every stage.

What RasnuCloud Migrates

RasnuCloud migrates your entire server — not just files. This includes:

Operating system configuration and installed software
All running services, their configurations, and their dependencies
All databases (MySQL, PostgreSQL, Redis, MongoDB) with data integrity verified
All Docker containers and Compose stacks
Web server configurations (Nginx, Apache, Caddy)
SSL certificates, scheduled jobs, and environment files
Your application code and compiled assets

The destination server starts from a clean state and ends in an exact working replica of your source — tuned for the destination's hardware.

Creating a Migration

Connect both your source and destination servers to RasnuCloud
Go to Dashboard → New Migration
Select source and destination
Click Generate Migration Plan

RasnuCloud reads the complete state of both servers and generates a customized, step-by-step migration plan within 30–60 seconds.

The Migration Plan

Before anything runs, you see the full plan:

Migration Plan: Production Server → Hetzner CX52

Phase 1  System Setup
  → Install matching OS packages on destination
  → Replicate system configuration and user accounts

Phase 2  Service Configuration
  → Configure Nginx with all existing virtual hosts
  → Install and configure PostgreSQL matching the source version
  → Configure Redis with persistence settings from source

Phase 3  Data Migration
  → Snapshot and transfer PostgreSQL databases (estimated 4.2 GB)
  → Verify data integrity — row counts and checksums must match
  → Sync Redis keyspace to destination

Phase 4  Application Setup
  → Sync application files from source
  → Install production dependencies
  → Copy and adapt environment configuration
  → Start and verify all application services

Phase 5  Live Cutover
  → Set up live database replication: source → destination
  → Wait for zero replication lag
  → Switch traffic to destination
  → Confirm destination is healthy
  → Decommission replication

Rollback available at every step.

Review the plan carefully. You can ask RasnuCloud to adjust it before approving:

Skip the Redis migration — I'll start fresh with an empty Redis on the destination

Run Phase 5 manually — I'll trigger the cutover myself once I've tested the destination

Execution Modes

Autonomous — RasnuCloud runs all phases without pausing. Best for migrations you've planned thoroughly and are confident in.

Step-by-step — RasnuCloud pauses after each step and waits for your approval. Best for high-risk migrations or first-time migrations of a server type you're unfamiliar with.

Pause and Resume

Migrations can be paused at any step. If you need to wait for a maintenance window, or something needs your attention before proceeding:

Pause after Phase 3 — I'll resume tonight during the maintenance window

The migration holds in place until you resume it. Your source server continues serving traffic normally.

Rollback

If anything goes wrong, RasnuCloud rolls back cleanly:

Something failed in Phase 4. Roll back to source immediately.

Because RasnuCloud never decommissions the source server until the final step, rollback is always available and always safe.

Server-to-Server Migrations ​

What RasnuCloud Migrates ​

Creating a Migration ​

The Migration Plan ​

Execution Modes ​

Pause and Resume ​

Rollback ​

Next Steps ​