Speaking Topic: Evolutionary Architecture Principles in Legacy M&A Targets
Most acquired legacy platforms do not need replacing, they need to be made revisable for the first time.
Acquirers evaluating a legacy target often default to one of two conclusions: the platform is fine as is, or it needs a full rewrite. I argue the more common reality sits between those: the platform was simply never designed to be revised, and that is the actual, fixable risk.
Applying evolutionary architecture principles to a legacy acquisition means assessing not whether the current system works, but whether its components can be replaced independently as the acquirer's roadmap inevitably changes it.
This reframes the integration plan from a binary rewrite decision into a staged, component-level revisability project, which is both cheaper and more honest about where the actual risk lives.
Key Takeaways
- 01A legacy target rarely needs a full rewrite; it usually needs to be made revisable for the first time.
- 02The real diligence question is whether components can be replaced independently, not whether the system currently works.
- 03Framing integration as staged revisability work is cheaper and more accurate than a binary rewrite decision.
Frequently Asked
How do you assess revisability in a legacy acquisition target?
By testing whether individual components can be replaced independently without a full-system deployment, which is the practical measure of whether the architecture can absorb change.
From the Q&A
“Isn't "the system was never designed to be revised" just another way of saying it needs a rewrite?”
No. A rewrite replaces everything at once. Revisability work replaces components independently over time, which is a materially different risk and cost profile.