PHP still runs most of the web, but developer surveys show its users skew towards more experienced developers, while newer developers lean towards JavaScript and TypeScript. For an older system, that's a staffing risk worth understanding now.
Most older PHP systems have a name attached to them. It might be the freelancer who built the site in 2014, the one in-house developer who "knows how it works", or the agency that still has the server password. The system runs because that person is there.
This is about what happens when they aren't. It's not a security flaw or a performance problem. It's a staffing risk, and it tends to surface at the worst possible moment: during an incident, an audit or an urgent change. For business owners and IT managers, it's one of the easiest risks to overlook, because it costs nothing until the day it costs a great deal.
Finding people to look after an ageing system
PHP is not a dying language, and that's worth saying clearly. According to W3Techs, as of 23 October 2026, PHP is used by 69.3% of websites whose server-side language it can identify. There is a large, active community of professional PHP developers, and current PHP with a modern framework is a perfectly reasonable thing to hire for.
The risk for a business running an older PHP system is narrower. You don't just need "a PHP developer". You need someone willing and able to work on your version of PHP, your framework or lack of one, and code written by someone who left years ago, often without automated tests or documentation. That pool is much smaller than the headline numbers suggest, and developer surveys suggest it leans towards more experienced people.
The most widely cited source on what developers use is Stack Overflow's annual Developer Survey. Its 2026 edition is based on 30,903 valid responses from 169 countries. Its respondents chose to take part, so treat it as a strong signal rather than a census. It found:
- Across all respondents, 18% had done extensive work in PHP in the past year, compared with 62% in JavaScript and 44% in TypeScript.
- Among developers with 1 to 5 years' experience, 15.3% used PHP. Among those with 16 years or more, 19.6% did.
- At every experience level, JavaScript and TypeScript were used by far more developers than PHP.
- Looking ahead, 8% of respondents said they wanted to work with PHP, compared with 28% for TypeScript.
The 2025 survey reported a similar share of respondents using PHP, so this isn't a sudden change. The broad picture is stable: roughly one in five developers uses PHP, and around three in five use JavaScript.
What could go wrong for your business
None of these figures mean you can't hire PHP developers. They point to practical risks for a business that depends on an older system:
- Slow response in a crisis. If your one developer is unavailable during an outage or a security incident, finding someone who can safely work on the system may take days or weeks.
- Higher costs. Experienced developers willing to take on old code often charge a premium, and some will decline the work altogether.
- Lost knowledge. Older systems accumulate undocumented decisions: a scheduled job only one person knows about, a modified library, a server setting changed during an incident. When that person leaves, the knowledge leaves with them.
- Changes that stop happening. The harder a system is to staff, the less often it gets changed, and the further it drifts from current versions, which makes it harder still to staff.
- Awkward audit questions. "One person understands it" is a difficult answer when a customer, insurer or auditor asks who supports your software.
Could your website be next?
Staffing risk doesn't announce itself. A system can run for years without trouble while the one person who understands it is around, and that smooth history can make the risk look smaller than it is. The real test comes when something goes wrong and that person isn't available.
That moment can be forced from outside your business. Attackers commonly use automated tools to scan large numbers of websites for known flaws in outdated software, regardless of how big or well known the business behind them is. When a widely exploited flaw lands in older software, every business running it needs help in the same week. W3Techs reports that, among websites using PHP, 26.9% run PHP 7 and 7.7% still run PHP 5, as of 23 October 2026. Both are long past the end of security support. That's a very large installed base of old code, all drawing on the same limited pool of people willing to work on it.
That doesn't mean an incident is inevitable, or that every older system is a target. It means your ability to respond depends on having someone ready who understands the system, and that's worth checking before you need it.
Why legacy PHP applications deserve attention
The staffing risk is closely tied to the age of the system. The PHP project itself only supports PHP 8.2 and newer as of 23 October 2026, and PHP 8.2 loses security support on 31 December 2026. Asking a strong developer to maintain code on a version the PHP project no longer supports is asking them to do work that won't help their career. Some will take it on at a premium. Many will decline.
The lean towards experience matters too. The developers most likely to know PHP are the ones with the most years behind them. That's good for quality, but over a five-year horizon some of them will move into management, change specialism or retire. If newer developers are less likely to pick up PHP, there are fewer people at the junior and mid-level, where most day-to-day maintenance happens.
Modernising changes the picture, but it isn't a magic fix. A system rebuilt carelessly, without tests, documentation or a routine for keeping its software up to date, becomes tomorrow's legacy system, whatever language it's written in. A broader hiring pool helps only if the code is something developers are willing to work on.
What this means for your organisation
A few simple questions show how exposed you are:
- Who could fix your system today if it went down? And who could do it if that person were unavailable?
- Is there written documentation of where the code lives, how it's deployed, which PHP version runs and what runs on a schedule?
- Does the system have automated tests that would let a new developer change it safely?
- If you had to hire a replacement next month, what would the job description say, and how many people would realistically apply?
If the answer to "who else could fix it?" is "nobody", that's your first finding. Understanding the real state of your system is the starting point for deciding whether to invest in keeping it on current, supported PHP, or to plan a gradual move to a platform that's easier to staff. Both are reasonable choices. Drifting is not.
Recommended next step
Don't wait for a resignation or an incident to find out how much depends on one person. Our free Legacy PHP assessment looks at your PHP version, framework, hosting, dependencies and how much of the system is documented and tested, so you can see where the staffing and maintenance risks lie.
Then talk to our team about the options. For some businesses, the right answer is bringing the system onto current PHP with proper support. For others, a gradual move to a modern Node.js stack with TypeScript may make sense, opening up a much larger pool of developers, depending on what the system does and where the business is heading. Whatever the platform, the goal is the same: a system that a developer you haven't hired yet can understand and change safely.
Free Legacy PHP Risk Assessment
Not sure how exposed you are if your PHP developer moves on? We'll review your PHP version, framework, hosting setup, dependencies and how much of the system is documented and tested, and tell you plainly where the risks are and what your options are, whether that's an upgrade, a support arrangement or a migration. Email us to request a free Legacy PHP Risk Assessment
