Modernisation

Age on its own is no reason. Ugly code that rarely changes and does its job can stay. The reasons are different: a change the business wants cannot be made without breaking something else, a dependency no longer gets security updates, or one person alone understands the part everything else hangs on. Then it is not the age that costs.

What needs to change, and what can stay?

Before anything is rebuilt, every part needs one of four answers: keep, repair in place, replace or retire. Neither we nor the code can give that answer. It means asking the people who use the system which behaviours still matter. The temptation is to turn everything old into requirements for the new system. Then you rebuild what should have gone too, and carry the cost with you.

We would rather make the change one bounded part at a time, with the rest running alongside, than as a rewrite that has to be finished before anyone can use it. How that works is under legacy systems, and if the history has to come along it starts with a trial run.

Where we start

Sometimes with a code review, when you need an independent picture of what the system costs to own and where the risks are. But a review does not automatically lead to a rewrite, and not every modernisation needs to start with one. If you already know which change is stuck, we start there.

Bring that change: what you wanted to do and why it could not be done. Bring what you know about the dependencies: which systems read from the same database, which jobs run at night. And give us access to the people who use the system. The goal of a first conversation is one prioritised first decision: what changes first, what can wait and what can go. Not a plan to replace everything. Get in touch and we will take it from there.