Change without rewriting.
WHAT TO EXPECT
The architecture will need to change, and the original decisions were made with less information.
WHAT TO AVOID
Treating architecture as fixed Rewriting because it is imperfect
WHAT TO DO INSTEAD
Change it incrementally, in the direction needed.
WHAT MAKES THAT POSSIBLE
Clear boundaries Tests Small deployable changes
WHAT THE STRANGLER APPROACH IS
Building the new alongside the old, routing traffic progressively, and removing the old once nothing uses it.
WHY IT WORKS
Each step is small and reversible, and the system works throughout.
WHAT TO DO FIRST
Something self-contained and low risk.
WHAT TO ESTABLISH BEFORE ANY LARGE CHANGE
What is actually still used.
WHY
Substantial parts of most systems are not.
WHAT TO NEVER DO
Begin a rewrite with no plan for reaching parity.
WHY REWRITES FAIL
Feature parity takes far longer than expected, fixed defects return, and the business continues needing changes to the old system meanwhile.
WHAT TO MEASURE
Whether the change improved what it was meant to.
