An organization operated a legacy web platform connected to core processes. Replacing it in one move would have concentrated too much technical and operational risk.
Situation #
The hard part was not drawing a target architecture. It was designing a transition in which old and new capabilities could coexist without losing data ownership, traceability or a route back.
My responsibility #
As principal architect and advisor, I designed the target direction and capability-based transition. I defined boundaries, contracts, write ownership, progressive routing, release criteria and observability requirements.
Key decisions #
- Apply a strangler pattern by business capability rather than technical layer.
- Keep a single writer for each domain during transition.
- Stabilize contracts before adding consumers.
- Move traffic with canary, abort criteria and rollback.
- Observe critical journeys across both sides of the architecture.
Defensible outcome #
A target architecture and phased transition route were defined with explicit ownership, contracts, release controls and reversibility.
Limits #
Implementation was partial and phased. No claim is made that the legacy system was retired, that full replacement was completed or that public outcome metrics exist.