Why a strangler-fig Sprint beats a big-bang rewrite
Legacy monolith modernization projects fail for a predictable, well-documented reason: teams plan them as a single multi-year rewrite with no shippable increment until the very end, which means the business gets zero value and zero feedback for years while risk compounds silently. This module argues the fix is not a different rewrite plan, it is refusing the rewrite framing altogether in favour of the strangler-fig pattern, sliced into ordinary Sprint-sized increments that each ship independently and each reduce risk on their own, with the legacy system still running throughout.
The module works through backlog slicing for modernization specifically: pick a single capability, extract or rebuild it behind a routing layer that lets old and new systems coexist, and ship that slice as a genuine Increment with its own Sprint Review, rather than treating the whole migration as one undifferentiated block of work with no visible progress for months. A key scenario covers a stakeholder asking why the team is not simply rewriting the whole thing faster, and gives concrete language for explaining why a slice-by-slice migration with continuous delivery beats a big-bang cutover that carries all the risk in a single, high-stakes event.
Later lessons address the specific coordination problems that come with a coexistence period: keeping old and new systems in sync during migration, defining a Definition of Done that includes a working rollback to the legacy path if a slice underperforms, and managing a backlog that mixes new feature requests against a business that has not stopped needing the legacy system to work in the meantime. The module treats the migration itself as a first-class Product Goal with its own Sprint Reviews, not an invisible background project competing for capacity against every other request.
Mistakes teams make with this material
Scoping the whole migration as a single deliverable with nothing shippable until the very end, which means years pass with no real feedback, no reduced risk, and no way to tell whether the plan is actually working.
Switching all traffic to the new system at once instead of routing a single capability at a time behind a strangler layer, which concentrates all the migration's risk into one high-stakes event instead of spreading it across many smaller, reversible ones.
Assuming the old system will not need bug fixes or urgent changes while the rewrite is underway, which is rarely true and creates a synchronization problem between two systems the team did not plan for.
Shipping a migrated capability without a tested way to fall back to the legacy path if it underperforms, which turns an ordinary Sprint-sized risk into a production incident with no safety net.
Questions people ask
Why does a strangler-fig approach beat a full rewrite for modernizing a monolith?
Because it ships value continuously, one capability at a time, behind a routing layer that lets old and new coexist, instead of asking the business to wait years for a single all-or-nothing cutover with no interim feedback.
How do you slice a modernization backlog into Sprint-sized work?
Pick a single capability, extract or rebuild it behind a strangler routing layer, and ship it as a complete Increment with its own Sprint Review, rather than treating the whole migration as one undifferentiated multi-year block.
What should Definition of Done include for a migrated slice?
A tested rollback path to the legacy system in case the new implementation underperforms, alongside the normal functional acceptance criteria, so a bad migration is a reversible Sprint-level event rather than a production incident.
How do you handle new feature requests for the legacy system during a migration?
Treat the migration as its own Product Goal with a real backlog and its own Sprint Reviews, and negotiate legacy feature requests against that goal explicitly, rather than letting the migration silently starve for capacity every time the legacy system needs urgent work.
A question from this module's assessment
One sample question with the reasoning, so you can judge the level before you start. The rest of the assessment stays inside the module.
Which is the strongest modernization approach in a Scrum context?
- Freeze features, build a parallel rewrite, cut over in eighteen months
- Strangler-fig one bounded context at a time, with vertical slices shipped every Sprint
- Rewrite the UI first, then logic, then data
- Do it all after the next major release
Big-bang rewrites die in the graveyard. Strangler-fig with vertical slices is the pattern that actually ships.