Legacy modernisation: the questions we get asked most

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. The questions about legacy modernisation that come up most often on our calls.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. If two people in the business would answer this differently, that gap is the actual problem.

Do we need to care about this?

Strangle the old system gradually rather than replacing it at once. The reasoning matters more than the rule, because the rule has exceptions. It rarely shows up as a line item, which is exactly why it slips.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The teams that handle this well are rarely the ones with the biggest budgets.

How do we know it is working?

Every migration needs a way back. It is worth being explicit about, because assumptions differ quietly. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

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
• 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

If any of that sounds like a description of your current setup, it is fixable.