I have now lived inside a strangler-fig migration long enough to stop recommending it like a slogan. The pattern is sound. You put a façade in front of the monolith, peel off a capability, route a slice of traffic, repeat. Three years in, the interesting work is not the first extract. It is the stretch where two systems agree most of the time.
That stretch is where you invent a third thing: the rules for disagreement. Who wins when the old table and the new service diverge? How long may they diverge? What does a replay look like? If you do not write that down, the monolith remains the real system and the new service is a cache with opinions.
Feature flags are not enough. You need an anti-corruption layer that is boring on purpose — explicit mappings, no “smart” inference across bounded contexts, ids that survive a cutover. You need traffic shaping that can go to 1%, 10%, 50%, and back, without a heroics channel. You need idempotent writes, because the first time you dual-write you will do it twice.
The other thing three years teaches you is that “zero downtime” is a claim about users, not about your feelings. There will be a weekend where a backfill is the product. There will be a week where you freeze the old schema so the new one can catch up. Say that out loud early or someone will schedule a launch in the middle of it.
I still use the pattern. I would use it again on a 15-year system I did not want to rewrite from a standing start. I would not start it without a definition of done that includes deleting the façade. A strangler that never finishes is just a distributed monolith with better diagrams.
The fig is a method. The work is deciding, in public, which system is allowed to be right.