Getting started with legacy modernisation
The gap between knowing this and actually doing it is where most teams lose ground. A short on-ramp to legacy modernisation for teams who have not touched it before.
The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Doing this properly once is usually cheaper than doing it approximately three times.
What it costs to ignore
Strangle the old system gradually rather than replacing it at once. That sounds obvious written down. It is still the thing most often skipped. Doing this properly once is usually cheaper than doing it approximately three times.
Your first week
- Find out what is already in place
- Big-bang rewrites are the most reliable way to lose two years
- Change one thing and measure it
Every migration needs a way back. It is worth being explicit about, because assumptions differ quietly. Write the reasoning down alongside the decision, because the reasoning is what changes first.
In practice
Most systems fail at the seams rather than inside any one component. Three things worth confirming about legacy modernisation before you move on:
- Someone can say what the current setup is without going to look
- Big-bang rewrites are the most reliable way to lose two years — and you know whether that is true here
- There is a way to tell whether the last change to this helped
None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.