Choose the right change strategy without blowing up delivery
Every system evolves. The decision isn’t whether to change, but how.
Best when:
Wrap the old system and replace pieces gradually. Best when:
Rarely the best choice. Use only when:
If customers depend on the system, prefer strategies that keep delivery moving. Big‑bang rewrites often fail because reality changes mid‑project.
Use automated checks that enforce architectural goals:
This keeps evolution aligned with intent.
Q: Why do big‑bang rewrites often fail?
<details> <summary>💡 Reveal Answer</summary>They take too long, requirements change mid‑build, and the old system continues to evolve. By the time the rewrite ships, it’s already behind and missing real‑world edge cases.
</details>Pick one legacy component and plan an evolution strategy:
Full access
Unlock all 12 lessons, templates, and resources for Software Architecture & Decision Patterns. Free.
Scenario: Your monolith is slow to change, but it still works. A competitor just released a major feature.
How do you respond?
Start with a strangler slice: build the new feature as a separate module/service and route only that feature’s traffic through it. This lets you ship fast without a full rewrite and creates a path to gradual modernization.
| Idea | Remember This |
|---|---|
| Change strategies | Refactor, strangle, rewrite |
| Rewrite risk | High, slow, often outdated |
| Fitness functions | Automated guardrails for evolution |
| Ship while changing | Keep delivery moving |
Next: Decision Governance & Your Architecture Framework