If your website or application was built several years ago, there is a good chance it runs on PHP, and a fair chance the version of PHP it uses is one the PHP project no longer supports. The same is true of old Python, .NET Framework and Django releases. This post explains what "end of life" means in practice, in plain language, and how a sensible upgrade is planned.
What end of life means
Every programming language runtime has a published support schedule. For a period each release gets fixes and updates. After that, it reaches end of life: the maintainers stop releasing updates for it. The software does not stop working on that date. A page does not go blank. What changes is the support around it.
In practice, that has three consequences.
- No more fixes from the maintainers. If a problem is found in that version, it will not be corrected there.
- The ecosystem moves on. Libraries and plugins your application relies on drop support for the old runtime. Updating one of them can then require updating the runtime.
- Hosts retire it. Hosting providers eventually stop offering old runtimes, often with a deadline and a notice email that gets missed.
The third one is where most businesses meet the problem. The first sign is not a technical report. It is an email from the host with a date.
Why it is not just a developer's concern
An unsupported runtime becomes a business matter when:
- Your host announces it will retire the version, and your site will stop on the date.
- A customer, an insurer or a partner asks which versions you run, and "an old one" is not a satisfying answer.
- You need a change made, and developers are unwilling to work on the old version or charge more to do it.
- The application slows or misbehaves after a host-side change nobody told you about.
Each of these is, at root, a continuity question: can this software keep running and can someone change it when you need that?
How an upgrade is planned
A good runtime upgrade is boring. That is the goal. The steps look like this.
Read before touching
Before any change, someone reads the code and the deployment. They identify what depends on the old version: the framework, the libraries, the server configuration, any scripts. They note what is already broken, which is common in older applications.
Make a copy that behaves like production
The upgrade is rehearsed in a separate environment that mirrors the live one. This is where problems surface in a controlled way. Old applications frequently use functions that were removed or changed in later versions, and finding that in a test environment costs hours. Finding it in production costs more.
Update in stages
The runtime moves one supported step at a time where that makes sense. Dependencies are updated along the way. Each stage is tested against the same set of checks: logging in, the main workflows, the reports people actually use.
Roll out with a way back
The final cutover is scheduled for a quiet time, with a written rollback plan. If something goes wrong, the rollback plan returns the application to its previous state. We test that plan beforehand so it is not a surprise.
Write it down
The most valuable output is often the documentation: how the application is built, how it is deployed and what was changed. The next upgrade then starts with a map.
What it costs
Cost depends on the size and condition of the code, so we price from a look at it. Our runtime upgrade packs run between $8,000 and $30,000, set using a simple formula: twice our estimated hours at our fixed rate. We show you the estimate and the formula before you commit. The fix work that comes out of an assessment is priced per item, and the details are on our fixes and upgrades page.
When not to upgrade
Sometimes the right call is to leave the runtime alone for now. If the application will be replaced within a few months, or if the cost of upgrading is close to the cost of rebuilding, an upgrade may not be worth it. We will say so. In some cases a short-term hosting arrangement buys time for a planned replacement. Either path is reasonable if it is chosen deliberately.
What you can do this week
- Find out which runtime version your application uses. Your host's control panel often shows it.
- Check the support schedule for that version on the project's official site.
- Read recent emails from your host for any retirement notice.
- Write down the date and tell whoever will be helping you.
You do not need to act on all of it today. You do need to know the date.
Keep it from happening again
The cheapest way to handle end of life is to treat it as routine. On a Keep-Alive retainer we watch the support dates for what you run, apply updates in small steps and tell you in the monthly note what is coming, so a notice from your host is never a surprise.
If you have a date from your host or just a feeling that your application is old, tell us about your software. We will reply with what we would check first and what an upgrade might involve. We do not offer security assessments or security testing, and our work is AI-assisted and human-reviewed, which we disclose from the first call.
