The strangler pattern modernises a legacy system incrementally by routing selected capabilities to new components while the old system continues operating. It reduces cut-over risk, but only when boundaries, data ownership, routing, observability, and retirement are managed deliberately.
Decide Why to Modernise
Tie the programme to measurable outcomes: release frequency, lead time, reliability, security, operating cost, customer experience, or ability to change. “Old technology” alone does not prioritise work.
Baseline the existing system and map critical journeys, business rules, integrations, data, peak periods, incidents, and change bottlenecks.
Find a Useful Boundary
Choose a capability with clear business ownership, manageable dependencies, and measurable value. Good candidates often combine high change demand with a boundary that can be isolated.
Avoid extracting the easiest technical utility if it creates no business learning. Also avoid starting with the most entangled financial core merely because it is painful.
Introduce a Routing Seam
Use an API gateway, facade, event route, link, or application-layer adapter to direct selected traffic. Keep consumer contracts stable where possible.
Make routing reversible. Feature flags, tenant cohorts, percentage rollout, or operation-level switching allow gradual adoption and rollback.
Control Data Ownership
Define which system is authoritative for every entity and transition stage. Prefer one writer. If temporary dual writes are unavoidable, make them idempotent, observable, reconciled, and time-bounded.
Use change-data capture or events carefully. Preserve ordering, schema compatibility, replay behaviour, privacy, and deletion. A new service reading a shared legacy database may speed the first extraction while preserving deep coupling.
Protect Behaviour
Capture characterisation tests around important legacy behaviour before replacement. Add contract, integration, migration, performance, and security tests. Compare old and new outputs in shadow mode where risk warrants it.
Instrument journeys across both worlds with correlation IDs, business measures, errors, latency, and reconciliation.
Migrate in Controlled Slices
For each slice: define acceptance, build, backfill or transform data, run in shadow, release to a cohort, compare, expand, and retire the old path. Keep support and incident ownership explicit during overlap.
Do not let the temporary coexistence architecture become permanent by neglect.
Retire Deliberately
Remove old routes, code, jobs, databases, credentials, infrastructure, licences, monitoring, and support procedures after evidence and retention obligations permit it. Archive required records and update recovery plans.
Measure outcomes plus the shrinking legacy footprint. If new components grow but nothing is retired, complexity and cost increase.
DualByte's software development service can plan and deliver incremental modernisation with controlled data and cut-over risk.
Sources
Need help with implementation?
Get a free consultation with the DualByte team for your business technology needs.
