How to get legacy modernisation right
Every audit we run turns up some version of this. The short answer to legacy modernisation is that it is mostly a sequence of small decisions, not one big one.
The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Write the reasoning down alongside the decision, because the reasoning is what changes first.
The reason this keeps coming up
Strangle the old system gradually rather than replacing it at once. It is worth being explicit about, because assumptions differ quietly. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The steps
- Establish what you have today before changing anything
- Big-bang rewrites are the most reliable way to lose two years
- Every migration needs a way back
- Write down the decision so the next person does not re-litigate it
Every migration needs a way back. This is the sort of thing that compounds, quietly, in both directions. It is the sort of thing that looks like polish right up until it costs you an enquiry.
Turning this into a decision
What this looks like day to day
Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Three things worth confirming about legacy modernisation before you move on:
- Someone can say what the current setup is without going to look
- Strangle the old system gradually rather than replacing it at once — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you want a second opinion on how yours is set up, ask.