migration-patterns
Installation
SKILL.md
Migration Patterns
Overview
Migrating a monolith to services, or moving a legacy database to a new schema, is one of the highest-risk engineering activities. Done wrong it causes data loss, extended downtime, and introduces coupling that is worse than the monolith it replaced. The patterns here provide incremental, reversible migration paths — each one shifts traffic or data gradually, allowing rollback at any step.
When to use: Planning service extraction from a monolith; replacing a legacy component; migrating databases without downtime; reviewing a migration PR for hidden risks.
Quick Reference
| Pattern | Core Idea | When to Use |
|---|---|---|
| Strangler Fig | Proxy routes traffic; new service replaces old routes incrementally | Extracting services from a running monolith |
| Anti-Corruption Layer | Adapter translates between old and new domain models | Integrating two bounded contexts with conflicting models |
| Branch by Abstraction | Abstract interface first, swap implementation behind it | Replacing an internal library or module in-place |
| Expand-Contract | Widen schema before migrating data, narrow after | Database column renames, type changes, normalisation |
| Dual-Write | Write to both old and new stores in parallel | Migrating a live database with zero downtime |
| CDC Bridge | Capture database change events and replay to new store | Backfilling a new service's datastore from a legacy DB |
| Change Data Capture | Stream row-level changes via Debezium or AWS DMS | Event-driven migration, read-model population |