Open Data Infrastructure
The Strangler-Fig Pattern for Data Platform Migration
An incremental migration approach that displaces platform dependencies safely, without a high-risk big-bang cutover.
The safest migrations do not “move everything.” They change the default path until the old system becomes irrelevant, and you can turn it off without a ceremony.
What the pattern is
The strangler-fig pattern is an incremental migration strategy. Instead of a full cutover, you build the new capability alongside the old one and route more and more traffic to the new path until the old path can be retired.
In data platform terms, this usually means building an ODI-aligned contract layer and then migrating consumers to it in a deliberate sequence.
Core idea: the migration succeeds when the default path changes.
Why it works for data platforms
Data platforms have many consumers, long tail dependencies, and a lot of implicit behavior. A big-bang cutover forces you to discover every dependency under deadline pressure.
The strangler approach gives you space to learn. It also lets you measure the real work: schema edge cases, governance parity, performance differences, and operational ownership gaps.
A practical sequence
- Define the new contract layer: open table formats, catalog boundary, and governance enforcement points.
- Pick one domain: migrate a domain with clear value and manageable risk.
- Run in parallel: keep old and new paths available while you validate semantics and performance.
- Migrate readers first: dashboards and ad hoc analytics are often safer first moves than writers.
- Move writers with reversibility: use dual-write windows if you need rollback confidence.
- Decommission intentionally: retire old jobs and exports only after governance and audit needs are satisfied.
The pattern is not glamorous. It is operational discipline.
Risks and how to manage them
- Split brain: parallel systems drift. Use explicit synchronization and validation, not informal checks.
- Hidden consumers: inventory aggressively, including ad hoc users and scripts.
- Policy gaps: ensure permissions and auditability match before you move sensitive workloads.
- Maintenance neglect: assign ownership for compaction, retention, and table health on the new platform early.
A strangler migration is slower than a big-bang plan on paper. It is faster in the real world because it avoids catastrophic rework.
Sources to start with
This pattern is an architecture and operating model choice. For ODI-specific migrations, ground the contract layer in table and catalog specs.