PATTERN Cited by 1 source
Like-for-Like Migration Contract¶
Definition¶
A like-for-like migration contract mandates that a system replacement preserves absolute consistency across three dimensions: (1) user-facing interface, (2) output contract (schema, metadata), and (3) final data artifact. This transforms a potentially distributed multi-team migration into an internal platform implementation detail requiring zero code changes or validation from downstream consumers.
Canonical example¶
Netflix's Casspactor → Move Data migration (Source: sources/2026-06-19-netflix-the-evolution-of-cassandra-data-movement-at-netflix):
- Data movement parameters defined via Data Bridge remained unchanged.
- Schema, metadata, and data in destination Iceberg tables were identical to legacy output.
- Dozens of internal teams required zero code changes or re-validation.
When to apply¶
- Replacing a mission-critical system (batch pipelines, ETL connectors, storage engines) where downstream consumers are many and heterogeneous.
- The replacement improves internals (cost, reliability, performance) but the external contract is correct as-is.
Trade-offs¶
- Pro: Eliminates coordination cost; migration scope is bounded within the platform team.
- Con: Constrains the new system to reproduce legacy behavior exactly, even legacy quirks. Must be combined with rigorous shadow validation to prove equivalence.
Seen in¶
- sources/2026-06-19-netflix-the-evolution-of-cassandra-data-movement-at-netflix — cornerstone of Netflix's Platform Engineering migration philosophy.