Products
Live Migration Lifecycle
Migration walkthrough
How Eden controls a zero-downtime migration
One connection for your application. A controlled path from source to target.
Keep the application connection unchanged
The application continues sending its normal requests through Eden while the live source remains authoritative.
API reference · illustrative request
Attach an existing interlay
/api/v1/migrations/{migration_id}/interlay/{interlay_id}Create the migration, source listener, and target endpoint first. Attach an approved interlay; this request does not configure your application's connection address.
POST /api/v1/migrations/{migration_id}/interlay/{interlay_id}
Authorization: Bearer {token}
Content-Type: application/json
{
"id": "{migration_id}",
"endpoint": "{target_endpoint_uuid}"
}Read GET /api/v1/migrations/{migration_id} to inspect the migration and attached interlays before execution.
Live migrations are staged so operators can observe, validate, migrate, roll back, and commit with explicit decision points. The interactive workflow above connects each stage to its API reference, an illustrative request, and the status or evidence to inspect next.
These are selected raw API operations, not a complete executable runbook. Create the migration and endpoints first, follow the API stage map, and resolve the applicable analysis, compatibility, planning, and readiness gates. Requests require an authorized bearer token; replace every placeholder before use. The walkthrough never sends requests.
Phase Summary
| Phase | Application path | Live Migrations behavior | Decision point |
|---|---|---|---|
| Pre-test | Apps still talk directly to source. | A traffic copy feeds Live Migrations, telemetry, and optional test systems. | Can Live Migrations observe representative traffic safely? |
| Analyze | Apps connect to Live Migrations; Live Migrations forwards to source. | Workload, compatibility, throughput, and target requirements are measured. | Is the target and migration strategy acceptable? |
| Compare | Source remains authoritative. | Safe requests can be mirrored or compared against target. | Are divergence and compatibility findings resolved? |
| Test | Live Migrations uses the observed workload model. | Smoke tests, validation checks, and rollback rehearsal run. | Is execution approved? |
| Migrate | Apps continue through Live Migrations. | Historical data movement and live write coordination run together. | Is progress healthy enough to continue? |
| Rollback | Apps continue through Live Migrations. | Traffic returns to source. | Should the run be repaired and retried or abandoned? |
| Commit | Target becomes authoritative. | Migration completes and source can be retired later. | Is the business ready to decommission source? |
Phase Details
Pre-test
Pre-test is intentionally non-invasive. Applications continue to use the source system directly while a copy of traffic is used for Live Migrations analysis and validation.
Pre-test should prove:
- traffic copy works,
- request parsing works,
- observability receives events,
- the target can be exercised safely,
- and no production path has changed.
Analyze
In analyze, applications cut over to Live Migrations, but source remains authoritative. Live Migrations forwards to source while it learns production traffic.
Analyze should produce:
- command or query mix,
- throughput and latency profile,
- compatibility warnings,
- target sizing inputs,
- provider-specific risks,
- and migration strategy recommendations.
Compare
Compare lets operators test the target without serving target responses to production users. It is where mirrored operations, sampled comparison, and divergence tracking become useful.
Compare should answer:
- does the target accept the same operations,
- are responses equivalent where comparison is meaningful,
- are writes converging,
- and which keys, rows, documents, or operations need remediation?
Test
Test is the approval gate before migration execution. It should include rollback rehearsal, target validation, smoke tests, and business-specific checks.
Migrate
Migrate coordinates historical data movement and live traffic handling. The exact behavior depends on endpoint family and migration strategy.
Operators should watch:
- data movement progress,
- queue depth,
- write latency,
- retry volume,
- compatibility issues,
- and source or target health.
Rollback
Rollback sends traffic back to source while preserving enough state for investigation. Rollback should be rehearsed before production execution.
Commit
Commit makes the target authoritative. Source should not be decommissioned until operators and business owners confirm the migration is complete and rollback is no longer required.