Five mistakes teams make with legacy modernisation

We end up explaining this on discovery calls often enough that it deserved writing down. These are the ones we run into repeatedly when we audit legacy modernisation.

Most systems fail at the seams rather than inside any one component. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The mistakes we see most

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Strangle the old system gradually rather than replacing it at once
• Big-bang rewrites are the most reliable way to lose two years
• Never checking whether the fix actually worked

Every migration needs a way back. In practice this is a scheduling problem more than a technical one. It rarely shows up as a line item, which is exactly why it slips.

Making it stick

The short version

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

Worth checking on your own setup before it becomes someone else's problem to fix.