Classic PHP starts fresh for every visit and forgets everything at the end. That's simple and robust, but it makes live dashboards, chat, notifications and long-running jobs slow, costly or fragile to build. Here's what that means for your business.
Your sales team wants a live dashboard. Your customers want to watch their delivery move on a map. Support wants chat on the website, and operations wants an alert the moment a payment fails. Each sounds like a small request. On an older PHP system, each one can run into the same obstacle: the way classic PHP runs code.
This isn't a security flaw. It's a design choice that has served the web well for decades, and that now makes some ordinary product requests slow, expensive or fragile to build. For a business, that turns into delayed features, rising costs and workarounds that can quietly put the whole website under strain.
Why older PHP systems struggle with live, always-on features
Classic PHP handles each visit to a website as a single, self-contained task. A request arrives, PHP runs the application from the start, builds the page, sends it back, and then forgets everything. The next request starts from scratch.
Think of a service counter where each assistant deals with one customer at a time, then wipes the slate clean before the next. It's simple and robust. A problem with one customer can't spill over to the next, and the set-up is easy. It's a big part of why PHP became the default language of the web.
The trouble starts when a feature needs one of three things:
- A connection that stays open, so the server can push updates to the browser as they happen, for live dashboards, chat or notifications.
- Work that takes a long time, such as generating a large report, importing a spreadsheet or waiting on a slow partner system.
- Something running on a schedule or in the background, whether or not anyone is visiting the site.
Each of these fits awkwardly into the "serve and forget" model:
- Every open connection ties up a worker. In the most common PHP set-up, there is a fixed number of workers, and each handles one request at a time. A worker holding a connection open for live updates can't serve anyone else. As an illustration, a site with 20 workers and 20 visitors each holding a live connection has nobody left to load a page for the next visitor.
- Tasks are expected to finish quickly. By default, the PHP manual says a script is stopped after 30 seconds, and there are often further time limits in front of it. A long import that works in testing can be cut off halfway on the live site.
- The work can stop when the visitor leaves. By default, PHP stops a task if the visitor disconnects. Older applications rarely handle that carefully, so partly finished work can be left behind.
- Scheduled jobs can depend on visitors. WordPress's built-in scheduler, for example, is "only triggered on page load". Its own documentation gives the example of a task due at 2:00 PM that doesn't run until the next visit, which might be 5:00 PM.
What could go wrong for your business
None of this stops a website working day to day. The cost shows up elsewhere:
- Features that stall. Requests for live updates, chat or notifications get labelled "hard" and pushed back, while customers increasingly expect them.
- Slowdowns under load. Common workarounds have a price. Having every browser ask "anything new?" every few seconds turns one live feature into a constant stream of extra requests. Holding connections open can use up the workers that serve ordinary pages.
- Unreliable background work. Reports, reminders and data imports that run late, run during busy periods or stop halfway can affect customers, finance and operations.
- Rising running costs. Bolting a separate real-time service onto an old application means two systems, two deployments and two sets of software to maintain and keep updated.
- Lost opportunities. When the system decides what the business can offer, competitors on more flexible platforms can move faster.
Could your website be next?
The risk here isn't an attacker. It's the next feature request, the next busy period or the next workaround that pushes an older system past what it was designed to do.
Problems tend to appear at the worst moment. A sale, a marketing push or a spike in customer activity is exactly when held-open connections, slow imports and late scheduled jobs collide. A system that copes on a quiet Tuesday can struggle under the load that matters most to the business.
A smooth track record isn't proof that it will keep coping, either. Many of these limits only show up once a live feature is added, or when traffic grows.
There is a security angle, though it's indirect. Each separate service added to work around these limits is more software that has to be kept patched. Attackers use automated tools to scan large numbers of websites for known flaws in outdated software, and a forgotten add-on service is as visible to them as the main site, whatever the size of the business.
None of this means every PHP website is about to fall over. It means that if your roadmap includes live or long-running features, the way your current system runs code deserves a closer look.
Why legacy PHP applications deserve attention
To be fair to PHP, the modern ecosystem has solved much of this. There are now PHP application servers that keep the application in memory between requests, such as Laravel Octane and FrankenPHP's worker mode. There are real-time servers written in PHP, such as Laravel Reverb, and separate background workers that take long jobs out of the web request. A current, well-maintained PHP application can use all of them.
Older PHP applications usually can't, for three reasons:
- They need current versions. These tools target supported PHP releases and recent framework versions. For example, Laravel 12 requires PHP 8.2 or newer. An application stuck on PHP 7, or on a framework version from 2016, has years of upgrades to complete first.
- They need code that's safe to keep running. Older code often assumes it gets a clean slate on every request. Laravel's own Octane documentation warns about memory leaks and stale data when code written for that model is kept in memory. Moving an old application to a persistent server means reviewing it carefully for exactly these patterns.
- They need control of the server. Real-time servers are long-running processes that need monitoring and server-level configuration, which typical shared hosting plans don't provide.
So for an older system, the realistic choice is rarely "just turn on live updates". It's a workaround, a third-party service, a separate system in another language, or modernising the application first.
What this means for your organisation
If several features on your roadmap have stalled for the same reason, that's a strategic issue, not a backlog issue. Questions worth asking now:
- Which requested features have been called "hard" or "not possible" on the current system, and why?
- How does background work run today, and what happens if it runs late or stops halfway?
- Which tasks already come close to the system's time limits?
- Is your application on a PHP and framework version that can use modern options, or would those need a major upgrade first?
The answers help you choose between staying put, upgrading and re-architecting, or moving gradually to a platform designed for long-lived connections.
Recommended next step
Before committing budget to more workarounds, find out what your current system can realistically support. Our free Legacy PHP assessment reviews your PHP version, framework, hosting and dependencies, so you can see whether live and long-running features are achievable where you are, and at what cost.
Then talk to our team about the options. If you're on current PHP and a modern framework, the PHP tools above may be enough. If not, Node.js can be a strong modernisation path for real-time features, because it's built around one long-running process handling many connections at once, with background work in the same codebase. It has its own trade-offs: the Node.js documentation warns that slow work can hold up every other visitor, in the worst case causing "complete denial of service", so it needs careful design too. Where it fits, a gradual migration can start with the real-time feature itself while the rest of your application keeps running.
Free Legacy PHP Risk Assessment
Not sure whether your current system can support the features on your roadmap? We'll review your PHP version, framework, hosting setup and dependencies, and tell you plainly what's possible where you are and what your options are, whether that's an upgrade, a re-architecture or a migration. Email us to request a free Legacy PHP Risk Assessment
