A significant number of businesses are running web applications, intranets, or tools that were built years ago in PHP and have not been meaningfully updated since. The code works, the application does what it always did, and so it sits. What accumulates in the meantime is technical debt with real business consequences.
What legacy PHP actually means
Legacy PHP typically means code written in an older style, often without a framework, sometimes as a collection of files that grew organically over years, with logic that was added as needs arose rather than designed with any particular structure. PHP 5.x and PHP 7.x code written this way is common. The application works, but it is increasingly disconnected from the standards and security expectations of current PHP development.
The security exposure is real
PHP 5 reached end of life in December 2018. PHP 7 reached end of life in November 2022. Applications running on these versions are not receiving security patches. Beyond the PHP version itself, older PHP codebases frequently contain patterns that modern development practices specifically avoid: direct database queries constructed from user input, unvalidated form data, session handling that would not pass a basic security review. These are not theoretical concerns. They are the categories of vulnerability that are exploited in practice.
The developer who built it has usually moved on
In most cases, the developer or agency who wrote the original code is no longer available. The application works, but nobody currently employed by the business, and perhaps nobody still active in professional development, fully understands how it works. Modifications are made carefully and nervously, or not made at all, because the consequences of a change are unclear.
The cost of leaving it alone keeps growing
Each year a legacy PHP application is left unaddressed, the gap between its current state and the standard required to move it to current technology grows. Frameworks advance. Security requirements evolve. PHP itself changes. A migration that would have been a modest project in 2022 is a more substantial undertaking in 2026, and will be larger again in 2028. The asset is depreciating.
What to do about it
The starting point is documentation and assessment. Understanding what the application does, what data it handles, how it connects to other systems, and where it sits in your business operations. From that, you can make an informed decision about whether the application should be maintained in place, migrated to a modern framework such as Laravel, or replaced with a purpose-built alternative. What you should not do is continue to treat it as invisible infrastructure. The risk associated with ignoring it is not static. It grows.
If you are not sure how much legacy PHP debt your site is carrying, get in touch with Karl for an assessment.
Most business websites are built on content management systems. That makes sense for most situations. But there are cases where a CMS is the wrong tool, and the gap between what a CMS can do and what a business needs it to do creates ongoing friction, cost, and limitation. Knowing when a bespoke solution makes more sense is a useful thing to understand.
Custom web application development covers an enormous range of scope and complexity, which means the cost range is equally wide. If you have asked for quotes and received wildly different figures, that is not necessarily a sign that something is wrong. But understanding what drives the cost helps you evaluate what you are being offered.
Most business websites work in the sense that they function. Far fewer perform in the sense that they actively contribute to the business. Here is what the difference looks like in practice.
Most clients come to us when their site has started to feel like a risk rather than an asset. Whether the agency relationship has ended, an upgrade has been delayed, or the site has simply grown beyond what it can handle, a conversation costs nothing.