Big-bang rewrites fail for predictable reasons: the old system keeps changing, the new one never catches up, and the cut-over becomes a single moment of enormous risk. The strangler-fig pattern avoids this by growing new services around the legacy system until it can be switched off.
The first step is a routing layer — usually an API gateway or reverse proxy — that lets you send specific requests to new services while everything else still reaches the monolith. Choose a first capability that is valuable but loosely coupled, so you learn the migration mechanics without betting the business.
The most common mistake is sharing a database between old and new. It feels efficient, but it couples the two systems permanently. Instead, give each new service its own data store and synchronise with change-data-capture or events until the legacy path is retired.
Finally, measure progress by traffic, not by code. A dashboard showing what percentage of requests each system handles keeps everyone honest and makes the eventual shutdown of the monolith an uneventful Tuesday.