A system that works and nobody wants to touch
The system was built on something that made sense at the time: classic ASP, an old version of PHP, AngularJS, Visual Basic, a Delphi desktop app, an early Rails version. It still runs the business. Orders flow through it, reports come out of it, staff know its quirks.
The developer who knew it retired or moved on. Job ads for the old stack get no responses, or candidates ask whether there is a plan to move off it. The few contractors who know it are expensive and hard to book.
Why the pool keeps shrinking
Developers follow the work they want to do and the skills that will keep them employed. An unsupported framework offers neither. Each year fewer people learn it and more of those who know it move on. Meanwhile the platform itself stops getting security fixes, hosting providers phase out the old runtime, and libraries it relies on disappear.
The system does not get worse on its own. The world around it moves, and the gap widens.
What staying put costs
| Risk | What it means for you |
|---|---|
| No security updates | Known vulnerabilities stay open |
| Hosting constraints | Old runtimes need old servers, which carry their own risk |
| Slow changes | Every change needs scarce expertise and careful testing |
| Integration limits | Modern services and APIs are hard to connect |
| Key-person dependence | One contractor may be the only person who can help |
Doing nothing still has a cost. It is just spread out, until something forces a rushed decision.
The rushed decision is the expensive one. It usually arrives as a hosting provider's end-of-life notice, a failed security review from a customer, or the one contractor giving notice. At that point there is no time to plan a gradual move, and the business ends up paying for an emergency rewrite under pressure, which is the riskiest way to do it.
How we keep it running and move it on
- Assess honestly. We look at the stack, the codebase, the hosting and the business processes it supports, and say whether we have developers experienced in that technology. If we do not, we tell you.
- Stabilise first. Get the code into a repository you own, set up a staging copy, add monitoring and back up everything properly. This makes the system safer whatever happens next.
- Contain the risk. Where the platform cannot be patched, we isolate it: restrict network access, put it behind a modern proxy, and reduce what it is exposed to.
- Plan a gradual move. Rather than a full rewrite, we move one area at a time to a stack you can hire for, often by putting new modules alongside the old system and routing work to them as they are ready (sometimes called the strangler approach).
- Keep data in sync during the transition, so staff are not re-entering things in two places.
- Retire the old parts as the new ones take over, documenting everything along the way.
Sometimes modernising is not worth it. If a system is stable, isolated and rarely changes, careful upkeep may be the sensible choice. We will say so when that is our view.
How it looks on the other side
Your system is safer now, and there is a plan with visible steps for moving it forward. Each new part is built with technology that developers want to work on, so hiring gets easier as you go. Staff keep working throughout, without a big switchover weekend. And you are no longer dependent on one scarce contractor.
Sound familiar?
- Your core system runs on a framework or language that is no longer supported.
- Job ads for developers in that stack get few or no responses.
- One contractor is the only person who can make changes.
- Your hosting provider has warned about retiring the runtime your system needs.
- You are worried a full rewrite would be too risky.