Follows a review · Runtimes, platforms, dependencies
Systems Modernisation
Runtimes fall out of support. Frameworks stop getting security patches. The one dependency nobody wants to touch pins three more in place, and the upgrade gets deferred another quarter. Modernisation is moving that forward in the order the evidence supports, on an estate that has to keep serving traffic while it happens.
Scoped by what the two-day Architecture Review found, and never quoted before it.
Which estates this is for
A system still doing real work and still being changed: enough traffic that measurement means something, a team that has to keep shipping while this happens, and a version gap wide enough that the next upgrade is genuinely risky rather than routine.
It fits badly where there is nothing yet to measure — something still being written, or a job that runs twice a day. And if the pressure is load you have not reached yet rather than versions you cannot stay on, Scaling Systems is the branch to read instead.
What gets modernised
Weighted by what the review found load-bearing. An estate a version behind on something still supported is a different job from one running what the vendor stopped patching years ago.
01
Versions brought back into support
The language runtime, the framework, and the libraries that have to move with them. Out-of-support versions go first, because those are the ones no longer getting security patches — a risk with a date on it rather than a preference.
02
The dependency holding the rest hostage
There is usually one: a pinned library, an old driver, a component nobody owns, blocking every upgrade queued behind it. Finding which one it is, and what moving it actually costs, changes the shape of the whole plan.
03
Less estate to carry forward
Code paths the review found dark, features with no users left, a service still deployed for a single caller. Retiring something is cheaper than upgrading it, and it is the only part of this work that makes the next round smaller.
04
Enough instrumentation to prove nothing broke
An upgrade is only safe if you can see what changed. The paths the review found load-bearing get measured before anything moves, so the answer to did that break it is a graph rather than an argument.
Most of it lands incrementally, behind a system that stays up. Where a cutover genuinely needs a window, it is named in the plan before the work starts — the promise is that you are never surprised by one, not that one never happens.
Code does get replaced along the way — this is not a rewrite, and it is not a promise never to rewrite anything. The earned portion is simply smaller than the proposed one, and by the time anything is replaced there is a measurement behind the decision. The scope comes out of the review in writing, and then it ends.
What you are left holding
Supported versions, fewer things pinning each other in place, less estate than you started with, and the instrumentation that proved each step was safe — in your repositories, on your infrastructure, maintained by the people who were in the room while it was done. None of it stops working when we leave.
That is the part worth paying for. The next upgrade is a smaller job than this one was, and the one after that is smaller again, because the estate stopped growing the debt faster than anyone could pay it down.
Which part moves first
The review says which versions are load-bearing, which dependency is blocking the others, and what can be retired instead of upgraded. That order is the difference between modernisation that finishes and modernisation that stalls halfway. The person who scopes it is the person who does it.