Legacy PHP Modernization — Audit, Refactoring & PHP Upgrades

Legacy code is working code that cannot be changed safely: no tests, outdated dependencies, knowledge of the system living only in one person’s head. A system is not legacy because it is old — it becomes risky when it blocks growth: every change risks a regression, releases are done manually at night, and the framework and PHP version are long past end of life. Signals that it is time to modernize: PHP 7.x or older (no security patches), dependencies that can no longer be updated, growing release times and maintenance costs, and no way to hire new people for the project. Modernization is not the same as a rewrite — it is cleaning up the existing system step by step while keeping what works. You can read more about identifying and classifying the problem in the article “What is legacy code?”.

I run a comprehensive audit: architecture and dependency analysis, dead code and technical debt identification, security review (OWASP Top 10), performance and scalability analysis, and recommendations with a modernization roadmap. The audit answers three questions: what exactly blocks the system’s growth, which order of fixes minimizes business risk, and what each stage will cost. The result is a report with priorities, estimates and a module plan — you decide what to modernize first. An audit at 2,000 PLN net gives you an exact quote for the whole programme; the full scope is described in the article “Legacy code audit step by step”.

I do not rewrite everything from scratch — that is too risky and too expensive. I use the proven strangler fig pattern: new modules (e.g. in Laravel) run alongside the old application and take over successive areas of the system, and the old code is retired only once the new path is tested in production. I pick one module, protect it with characterization tests, refactor it, deploy to staging, monitor and promote to production. Only then do I move to the next module. The small-steps strategy minimizes risk, delivers value quickly and never leaves the company without a working system. How this looks in practice is described in the article about the strangler fig pattern.

Refactoring improves the structure of the code without changing its behaviour — and it is only safe when we first describe the system’s current behaviour with characterization tests. These tests are written from observed behaviour: they pin down what the system does today (including business-relevant bugs) so that refactoring changes nothing unexpectedly. In practice: I cover critical paths with tests (orders, billing, integrations), refactor module by module, remove dead code and dependencies, and deploy every change through staging with a rollback plan. Refactoring instead of a rewrite is usually 3–5× cheaper and far less risky. When to refactor and when to rewrite from scratch is covered in the article about legacy code refactoring.

PHP 7.x no longer receives security patches — every version below 8.1 is out of support, and PHP 8.1 loses it on 31 Dec 2026. A migration is not just a version bump: new PHP versions break some old constructs, so it needs to be done layer by layer: compatibility audit (PHPCompatibility, PHPStan), regression tests, automated refactoring with Rector (the tool automates PHP changes — it rewrites deprecated constructs into their modern equivalents), staging deployment and post-switch monitoring. A jump from PHP 5.6 requires an intermediate version. Upgrading from 8.2/8.3 to 8.4 usually takes 1–3 days of work; migrating from 7.4 to 8.x — 1–2 weeks for a small project. The full process, with a support-date table, is described in the PHP migration guide.

Technical debt is the cost a company pays for every change to the system: longer releases, more bugs, slower development and growing maintenance costs. Instead of describing it in generalities, I measure it with concrete indicators: test coverage of critical paths, number of known vulnerabilities in dependencies, time to release a change, number of production incidents per quarter, and time for a new person to make their first commit. These numbers show before and after modernization — so the programme has a measurable effect, not just “tidier code”. Example metrics from a real project are shown in the graphic below.

I implement CI/CD, automate deployments, set up monitoring (servers, databases, applications), backup and disaster recovery, and optimize servers and databases — including moving applications to cloud hosting with predictable costs. Releases stop being a manual ritual: every change goes through automated tests, static analysis (PHPStan/Larastan) and a one-command deployment with instant rollback. Monitoring with alerts (Sentry, Horizon, New Relic) catches problems before users notice them.

AI assistants shorten the most expensive stage of modernization: understanding what the old code actually does. In practice I use AI in three places: mapping dependencies in a module I am seeing for the first time; generating drafts of characterization tests, which I then verify by running them; and mass refactorings, where Rector performs the change and AI helps prepare the rules. The boundary is fixed: architecture decisions, risk assessment and code review stay human — no unreviewed code ever reaches production, and your code and data are never used to train public models. The result: a shorter time to understand the codebase and faster test coverage — without giving up control of the system.

Legacy is not only custom code. Outdated WordPress, WooCommerce and PrestaShop sites have exactly the same problems: PHP past end of life, unmaintained plugins and themes, growing security risk, slow performance and blocked development. I modernize them with the same methodology: inventory and backups, staged updates (never live on production), malware removal after an infection, PHP migration and performance optimization. WordPress sites and PrestaShop stores then continue under technical care — with updates, backups, monitoring and an SLA.

Typically: e-commerce applications and stores (PrestaShop, WooCommerce) integrated with ERP, marketplaces and carriers; B2B systems and internal company tools (orders, inventory, billing, a sales rep panel); SaaS applications and client portals; systems taken over from another vendor — with no documentation and nobody who knows them. The challenges are always similar: no tests, manual releases, technical debt blocking growth and a PHP version past end of support. The first step is always the same: an audit, a risk report and a modernization roadmap with cost estimates.