Draft for founder review. Not yet approved for publication.
When an old application becomes a problem, the instinct is to replace it. Sometimes that is right. Often it throws away years of business rules that nobody remembers writing down. The decision deserves evidence.
Five things to find out first
- Can the code be read? Is the source complete, and can an engineer follow it?
- Are there tests? Without them, every change is a gamble, and so is every comparison with a new system.
- Do the business rules still fit? If the application still does what the business needs, the rules inside it are an asset.
- Is the platform still supported? An unsupported platform is a security and continuity risk whatever the code looks like.
- Who knows it? If one person holds all the knowledge, capturing it comes before anything else.
When modernising makes sense
Modernise when the business rules are still right and the problems are structural: an old platform, tangled code, no tests, slow releases. You keep what works and repair what does not.
When a rebuild makes sense
Rebuild when the business has changed so much that the old rules are wrong, or when the platform cannot be moved forward at any reasonable cost. Even then, the old application is the best specification you have.
Why the answer is often “in stages”
A single big switch-over puts all the risk on one day. Moving one part at a time, with the old and new running side by side, spreads that risk and lets the business keep working. It also lets you stop if priorities change.
A sensible first step
Before deciding, spend a short, fixed amount of time on the five questions above. A written answer to each one usually makes the decision obvious, and gives you something to show the people who must fund it.