A legacy code audit is the starting point of every modernization — a technical review of the system that answers what works, what is a risk, and where to begin. A good audit does not end with a report on a shelf; it ends with a prioritized roadmap. This article breaks the audit into parts: what it covers, how it runs, how long it takes, what it costs and how to read the results.
Key takeaway: A legacy code audit covers five areas — architecture and dependencies, security, performance, tests and technical debt. The outcome is a report with priorities and a modernization roadmap. An audit without "what next" recommendations is a cost, not an investment.
When to commission a legacy code audit
An audit makes sense in several specific situations
- you are taking over a project from a previous vendor and want to know what you are getting,
- the system works, but every change takes weeks and you are afraid of deployments,
- you received a "we will rewrite it from scratch" quote and want a second opinion before deciding,
- you are planning product growth and need to know whether the current code can carry it,
- you are buying or selling a company and need technical due diligence.
The common denominator is always the same: you are about to commit serious money and want to base the decision on facts, not opinions. That is exactly what an audit is for.
What the audit covers — five areas
A comprehensive legacy code audit looks at the system from five angles. Each answers a different business risk.
Architecture and dependencies. How the system is built, where module boundaries are, how traffic and data flow between them. A dependency map shows which modules can be modernized independently and which are so intertwined that any change risks an outage. This area also reveals whether the architecture can be saved or whether individual fragments must be carved out and rewritten. The wider context of this stage is described in Legacy Code Modernization — Step by Step.
Security. Outdated libraries with known vulnerabilities, an unsupported PHP or framework version, input-handling flaws, access and secret management. The reference point is the OWASP Top 10 — the list of the most common web application vulnerability classes. In old PHP systems I typically find two categories of problems: libraries nobody has updated for years, and code written before the framework era without injection and XSS in mind. If the system runs on Laravel, I break the details down in Laravel Application Security — OWASP Top 10.
Performance. Where the system spends its time, which database queries are the most expensive, which code fragments slow users down. A performance audit also answers whether the problem is in the code or in the infrastructure — two different fixes and two different budgets.
Tests and quality. Do any tests exist, what do they cover, what does the deployment process look like. In old projects the answer is usually "no tests, and deployments are done manually over FTP." That is not a verdict — it is a starting point from which we plan characterization tests and CI/CD.
Technical debt. The scale and distribution of debt — what it costs to maintain the current state and what happens if nothing is done. How to measure it and how to think about repaying it is covered in the article on technical debt management.
How the audit runs in practice
A legacy code audit is not a one-off file read. It is a multi-day process in several steps
- Business conversation — which features generate revenue, what you plan to build, where it hurts most today. A technical audit without business context evaluates code, not risk.
- Inventory — project structure, dependencies, PHP and library versions, change history, environment state (servers, backups, monitoring).
- Static analysis — PHPStan, Psalm and tools for detecting dead code and duplication. Machines find in hours what would take a human weeks.
- Security analysis — mapping libraries against vulnerability databases, reviewing code against the OWASP Top 10, reviewing access management.
- Performance analysis — profiling the most important paths, slow queries, bottlenecks.
- Report and roadmap — a list of findings with risk ratings, recommendations and an ordered plan with estimates.
Step six is the key one. A report without a roadmap is a list of problems that paralyzes instead of helping. A good audit ends with an answer like: "this quarter we secure payments and patch libraries, next quarter we refactor the billing module, and we consciously postpone rewriting the reporting module." The decision about what we do not do is as important as the list of what we do.
How long it takes and what it costs
A technical audit of a small or medium system usually takes 3 to 10 working days, depending on code size and documentation availability. For larger systems the process is split into stages — a coarse review first, then deeper dives into the highest-risk areas.
An audit is money that pays back in several ways: it lets you avoid rewriting a system that does not need rewriting, it orders the sequence of work (and therefore the spending), and in the case of an acquisition it can save you from buying a problem worth tens of thousands.
How to read the audit report
A good audit report has three layers, read in this order
- critical risks — things that can cost the most and need immediate decisions: security holes, missing backups, single points of failure,
- modernization priorities — modules to refactor in order of risk-to-cost ratio,
- strategic recommendations — the answer to "refactor, rewrite or leave it alone," with justification and cost ranges.
A red flag when receiving a report: a document that lists only problems and concludes "everything must be rewritten." An honest audit also shows what is healthy in the system and worth keeping — in old systems there is usually more of that than it seems at first glance.
What happens after the audit
The audit closes the discovery stage and opens the action plan. The most common sequence after an audit: patch critical security holes, cover the most important paths with tests, refactor modules according to priorities and set up CI/CD. The whole process — step by step — is described in the guide to legacy code modernization.
If you need support auditing your system, take a look at the code maintenance and modernization service and get in touch through the contact form.
Frequently asked questions
What exactly do I get in an audit report?
A report with a list of findings across five areas (architecture, security, performance, tests, technical debt), a risk rating for each finding, a modernization roadmap with sequence and estimates, and a strategic recommendation — refactor, rewrite or leave unchanged.
Does the audit require access to production?
Not to production data. An audit needs access to the code repository, environment configuration (without production secrets) and — optionally — the ability to run the system on a copy. Customer data is not needed to assess code quality.
Will the audit be done by a competitor, since I am sharing my code?
An audit is a service of trust, and it makes sense to commission it from a vendor you might want to work with further — not a requirement, but a natural fit. If you are worried about the code, cover it with an NDA and a defined scope of access (repository without secrets, test environment). It is also standard to state that the report and knowledge of the code may not be used outside the audit.
Can an audit end with a "do nothing" recommendation?
Yes, and it happens more often than you might think. If the system is stable, reasonably secure and rarely changes, the honest recommendation is: leave it, keep security updates going and revisit the topic when a real business need appears. An audit that always ends with a big project is not an audit.