Decomposing a Legacy Monolith (Strangler Fig Pattern)

How It Works

A rewrite was never on the table: the platform served live clinical traffic, and any migration plan had to keep the legacy system authoritative until each capability was proven in production. The Strangler Fig pattern fits exactly this constraint — a routing facade sits in front of the monolith, and traffic for a capability is switched to its new microservice only once that service has demonstrated parity. If anything goes wrong, the switch flips back. Deployment risk becomes a per-capability decision instead of a single all-or-nothing event.

The Anti-Corruption Layer was the discipline that made the new services worth building. Legacy data models and implicit business rules were translated at the boundary rather than imported wholesale, so each extracted service got a clean domain model instead of inheriting a decade of accumulated shortcuts. Without an ACL, a strangler migration quietly reproduces the old monolith as a distributed one.

Data was the hardest part. During the transition, the same information lives in both the legacy SQL store and the new services, and clinical data cannot tolerate divergence. Change Data Capture streamed committed changes out of the legacy database so new services stayed consistent without dual-write logic in application code — dual writes being the classic way these migrations corrupt data. Cutover for each capability followed the same sequence: sync via CDC, verify, route reads, route writes, retire the legacy path.

The end state is an event-driven microservice architecture on Azure where individual services scale independently and teams release without coordinating a monolithic deployment train.