Products
Live Migration Lifecycle
Live migrations are staged so operators can observe, validate, migrate, roll back, and commit with explicit decision points. This page explains the product lifecycle at a higher level than the Redis API runbook.
Lifecycle Diagram
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.