If your business software still works but nobody wants to touch it, you are probably looking at one of five things: a platform past its end-of-life date, no automated tests, one person who is the only human who understands it, small changes that now cost weeks, or a replacement project that got started and quietly buried.
All five are diagnosable in about twenty minutes, and most of them point toward fixing what you have instead of replacing it.
Here is the annoying part: working software will never hand you a reason to act. No outage. No lost order. No Tuesday morning where the decision makes itself. Meanwhile the repair bill grows on a schedule nobody asked your permission about.
Why does software that still works turn into a problem?
Because it ages against other people’s deadlines, not against visible wear. The platforms underneath it hit end of life on published schedules, security patches stop, and your application behaves exactly as it did the day before, cheerfully, like nothing happened. It is a bit like a building code. The building is fine. The rules underneath it moved.
It also compounds. One version behind is an oil change. Five versions behind is a project, because you cannot leap the gap, you walk through every version in between, and each one changed something on the way. The pool of people willing to touch your system shrinks every year too, and the ones who will take it on price that adventure accordingly.
What are the 5 signs, and how do you check them?
Five questions. Three you can answer yourself. They are ordered by urgency, so start at the top and note where it fails, because the first failure is usually your priority.
| # | Check | Who answers it | What a failure means |
|---|---|---|---|
| 1 | What versions does it run, and are they supported? | Your developer, then endoflife.date | Security exposure on someone else's clock |
| 2 | Is there a test suite that runs on every change? | Your developer | No safety net under any future work |
| 3 | Could anyone else take this over tomorrow? | You | Continuity risk, fix this first regardless |
| 4 | Does the same size request cost more than it did two years ago? | Your invoices | The architecture is the bottleneck now |
| 5 | Has a rebuild been started and abandoned? | You | Strong signal against trying again |
Three or four failing at once is normal. It is not a verdict on you, or on whoever built the thing. Twenty minutes of this replaces several years of vague dread with facts, which is a much better thing to own.
Is your software still getting security updates?
This is the urgent one, because it runs on someone else’s clock. Every other problem here gets worse at your pace. This one gets worse on a schedule published years ago by people who have never heard of your company.
After a version passes end of life, security fixes stop. Not slow down. Stop. Your app does not change that day, but its risk profile does, and if you handle customer records, payments, or anything a regulator cares about, that is a position you would rather not defend out loud.
Check it today, without a developer. Ask what versions your system runs, then look them up on endoflife.date, or the PHP supported versions page. Five minutes, and it is the single most useful fact you can hold about your own software.
Does anything catch mistakes before your customers do?
Ask your developer one question: does the software test itself, automatically, on every change? Not “do you test it.” Does it test itself.
The answer is usually no. Without tests, every change is verified by a human clicking through screens and hoping they remembered to check the thing that broke. Which works beautifully, right up until it doesn’t, and the thing nobody thought to check is the thing your customer finds.
It also explains those quotes that come back high with caveats attached. When a developer says a small change might affect other things, they are not padding the estimate. They genuinely cannot promise you otherwise, and you have been paying for that uncertainty on every request for years.
A test suite is the least satisfying thing you will ever buy: real money out, no new features in, and all you get back is the ability to stop guessing. It is also what makes everything else affordable. Building something new instead of rescuing something old? The 18-step web app launch checklist puts that safety net in while it still costs almost nothing.
What if your one developer vanishes?
If the person who maintains your application became unreachable tomorrow, whether they retired, moved on, got sick, or discovered woodworking, what actually happens? For a lot of businesses the honest answer is several genuinely bad months, which makes this a key-person problem, not a technology one. The tell is documentation: if nobody can describe what your system does screen by screen, the only complete specification of your business rules is the running application itself. Which is fine. Until it isn’t.
Sign four is the same story from the invoice side. On a healthy system the price of a change tracks the size of the change. Past a certain point that snaps, and a two-hour request comes back as three weeks. Watch the trend, not the number.
Should you try another rebuild if one already stalled?
A rebuild that got started and quietly shelved is the strongest argument against starting another one. It almost always gets filed under bad luck. It is not bad luck.
The real specification lives in the running application, not in any document. This field is required, except for that one customer type. This report rounds this way, for a reason. This role sees the screen but not the export. Nobody wrote any of it down, and a decent chunk was settled in a phone call in 2014 by somebody who now works somewhere else entirely.
A rebuild asks a team to reconstruct all of that from memory, on a deadline, while the old system keeps running and changing underneath them. Projects get ninety percent of the way there, feel great about it, then hit the long tail of undocumented behavior, which turns out to be where the actual business lives. That last stretch is not a stretch, it is the building. I took the other path on a West Texas safety company’s compliance system carrying seventeen years of inspection records. The phase-by-phase breakdown is here.
Rebuild or modernize in place?
Owners assume rebuild almost every time, and it is the right answer less often than the industry likes to admit. Here is the honest split.
| Situation | Rebuild | Modernize in place |
|---|---|---|
| Software still does what the business needs | No | Yes - foundation problem, not a fit problem |
| Business changed what it sells or how | Yes | No - you need different capabilities, not newer ones |
| Records carry legal or compliance weight | Rarely - migration is the risk | Yes - the database never has to move |
| A previous rebuild already stalled | No | Yes - the depth that stalled it is still there |
| The app is small, or the data is disposable | Often yes | Optional |
| No automated tests exist today | Either way, build them first | Either way, build them first |
The deciding question is fit, not age. If the software still does the job and only its foundation has aged, that is a maintenance problem wearing a rebuild costume. Rebuilds are exciting. Maintenance is not. That asymmetry has sold a lot of rebuilds nobody needed.
Genuine rebuild cases look different. A telecom client needed one, not because their tool was old, but because they wanted to hand the system to their customers and the original design could never support that. That project is written up here. If your complaint is about what the software does rather than what it runs on, what has to change before you can hand an internal tool to customers is the more useful read.
And if your records are the proof of something, “we moved everything and only lost a little” is not a sentence you can say to an auditor and then keep talking. Modernizing in place means the database never moves, including the columns misspelled by somebody in 2009. Those stay misspelled on purpose, because tidying them up is the well-intentioned change that takes production down on a Tuesday.
What does modernizing actually involve?
Four things, in this order, none of them exotic:
- Write down what it does now. Every screen, every rule. That becomes the definition of “unchanged,” and without it nobody can tell you at the end whether something broke.
- Build the safety net before touching the platform. This is the phase where you pay and see nothing, which is why everyone skips it and everyone regrets skipping it.
- Move one step at a time, with a gate at each one. Not a heroic upgrade weekend. If step seven goes sideways you go back to step six, which is known good.
- Leave the database alone. Treat the schema as immovable and enforce it with checks that scream if anyone gets creative.
Next step: find out what you are actually running
The five checks are free, and the answer is more often “modernize” than the dread suggests. Waiting for a crisis to decide for you is the one option with no upside, because working software will not schedule one at a convenient time.
If the checks pointed at an unsupported platform, no tests, or a rebuild that already stalled, that is exactly the work we do. Our web app development service covers both paths, and we will tell you which one you are looking at, including when the answer is that you do not need us yet. Here is how the process works, other projects we have taken on, and more on how we got here.
Run the five questions first. Whatever they turn up, you will know what you are sitting on, and that is the hard part done.