Legacy modernisation: what to get right first

This is one of those topics that looks small until it costs you something. If you only fix one thing about legacy modernisation this quarter, make it the first item below.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Start here

Strangle the old system gradually rather than replacing it at once. The teams that handle this well are rarely the ones with the biggest budgets. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Then this

Big-bang rewrites are the most reliable way to lose two years. In practice this is a scheduling problem more than a technical one. Assume whoever inherits this will have half your context and none of your patience.

Eventually

Every migration needs a way back. Small and consistent beats large and occasional here. If two people in the business would answer this differently, that gap is the actual problem.

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

Most of the value here comes from doing the first two things, not all of them.