A legacy code audit is a structured review of an existing codebase that tells you three things: what the software actually does, where it can hurt you (security, outages, cost), and what to fix first. It ends in a prioritized

report, not a pile of opinions. If your system still earns money but nobody wants to touch it, this is the cheapest way to turn fear into a plan.

We do these audits for founders, CTOs and IT leaders every week. Below is how a good one works, what it should hand you, and how to decide between fixing, refactoring and rebuilding.

TL;DR

  • A legacy code audit maps architecture, dependencies, tests, security and operations, then ranks the findings by business risk.
  • “Legacy” does not mean old. Code you inherited, can’t explain or can’t test safely qualifies.
  • Expect a written report with a risk-ranked findings list, a dependency and security picture, and a sequenced fix plan.
  • Cost scales with codebase size, how much documentation exists and whether you need security depth. Our published entry point is $449.
  • AI tools speed up the scan, but a senior engineer has to judge what the findings mean for your business.

Table of Contents

What “legacy code” actually means

Most people hear “legacy” and picture a mainframe. The working definition is broader. A UC Santa Barbara software course describes a legacy codebase as preexisting software that developers fix, extend or refactor, and treats it as the normal setting for professional work, since most developers modify existing systems rather than start fresh.

Berkeley’s software engineering course material makes the same point from the other side: legacy code still meets customer needs but is hard to work with because it was inherited, written long ago, poorly documented or lacks good tests. It isn’t necessarily unused or obsolete.

That matters for you in two ways:

  • A three-year-old app built by a contractor who left can be legacy today.
  • A prototype generated by an AI assistant and pushed to production can be legacy in six months, because nobody on your team can explain why it works.

A widely repeated shorthand, which Perforce attributes to Michael Feathers, is that legacy code is simply code without tests. Without tests, nobody can say which requirements the code satisfies or whether a change breaks something. We find that definition useful because it points at the fix.

What a legacy code audit examines

A code review looks at a change. An audit looks at the whole system. That is the core difference, and it changes the work.

Security guidance draws the same line. The OWASP secure code review cheat sheet separates baseline reviews, which examine the entire codebase and suit legacy system onboarding, compliance needs and post-incident analysis, from diff-based reviews that cover only pull requests and commits.

A legacy audit is a baseline review with business context added. Here is what we look at.

Architecture and structure

We map the system boundaries: what talks to what, where data lives, which parts are tangled together. We look for the load-bearing pieces, the ones where a small change causes a large failure. This is where “software archaeology” happens: reading code to recover intent nobody wrote down.

Dependencies and platform age

Outdated frameworks, unsupported language versions and abandoned libraries are the most common source of hidden risk. We inventory every dependency, check what is pinned and what is stale, and note what can’t be upgraded without a larger change. If you need a living inventory afterward, our guide to an SBOM for applications covers what to include.

Tests and code quality

We measure what is covered by tests, what is flaky and what has no safety net at all. We also look at complexity, duplication and dead code. For the metrics we recommend tracking afterward, see our code quality metrics and CI gates playbook.

Security

We check authentication, authorization, input handling, secrets in the repository, and known-vulnerable components. For a deeper look at the security side alone, read our application security assessment guide. NIST’s control for developer security testing describes verifying that controls work as intended using static analysis, dynamic analysis, binary analysis or source code reviews, and it lets contracts specify flaw-remediation processes and evidence. A good audit leaves that kind of evidence trail.

Build, deploy and operations

Can a new engineer build the app in an hour or in a week? Is there a deployment pipeline, or does one person run commands by hand? Is anything monitored? Code can be clean and still be dangerous if the release process lives in someone’s head. Our continuous integration assessment goes deep on this layer.

Bus factor and knowledge risk

We ask who understands each part. If the answer is “one person” or “nobody,” that goes in the report as a risk, because it is one.

Audit, code review, health check: how they differ

The searches around this topic use many names. In practice they overlap, with different emphasis.

Name Main question Typical scope
Code review Is this change safe to merge? A pull request or a feature
Legacy code audit What is in here and what should we do about it? Whole codebase plus operations
Technical debt audit Which shortcuts are costing us the most? Code, tests, architecture
Software quality audit / code quality check How maintainable is this? Metrics, standards, tests
Application security review Can someone break in? Security-relevant code and config
Software risk assessment What could go wrong for the business? Technical findings translated to business impact

A strong legacy audit covers the first four rows and produces the sixth as its summary. You rarely need to buy them separately.

What you should get at the end

If you pay for an audit, you should be able to hand the output to a board member, a new CTO or an engineering team and have each of them know what to do. Ask for these deliverables:

  1. An executive summary. One or two pages in plain language: overall condition, the top risks, and a recommended direction.
  2. A risk-ranked findings list. Each finding has severity, location, what it affects and how hard it is to fix. No unranked lists of 400 warnings.
  3. A dependency and security picture. Outdated or vulnerable components, exposed secrets, weak access control.
  4. A test and quality baseline. Current coverage, the riskiest untested areas, and the metrics to track going forward.
  5. An operations assessment. Build, deploy, logging, monitoring and backup gaps.
  6. A sequenced remediation plan. What to do in the first 30 days, the next quarter and the next year, with rough effort for each.
  7. A walkthrough. A live session where you can ask questions of the person who read your code.

If a vendor sends you only an automated scan export, you have bought a tool’s output, not an audit.

How to prioritize after the audit

A long findings list is not a plan. The sequence that works for us, and that matches widely taught practice, looks like this.

1. Fix what can hurt you this month. Exposed credentials, known-exploited dependencies, no backups, no way to roll back a release. These are cheap and urgent.

2. Build a safety net. Sonar’s guidance on managing legacy code recommends automated tests and software archaeology to understand the system first. Characterization tests, which record what the code does today, let you change things without guessing.

3. Refactor in small steps. The same guidance points to incremental refactoring and the strangler pattern, where new components gradually take over from old ones. You never need a risky big-bang cutover. Our walkthrough on how to refactor legacy code in one sprint with tests and safe AI shows the mechanics.

4. Decide on modernization with evidence. Some systems deserve a rewrite. Most deserve targeted replacement of the worst parts. The audit gives you the data to choose. For the bigger picture, see our legacy system modernization roadmap.

5. Keep it healthy. Audits decay. A software maintenance plan with scheduled dependency updates, monitoring and quarterly reviews keeps you from needing a rescue again in two years.

A simple way to rank any finding: multiply how likely it is to cause harm by how much it would cost if it did, then divide by the effort to fix. High score, low effort goes first.

How to prioritize after the audit

What a legacy code audit costs

Price depends on four things:

  • Size and language mix. More code and more stacks mean more reading time.
  • Documentation and access. Missing docs, no staging environment and no original developers all add effort.
  • Depth of security work. A general health check is lighter than a full security review with exploit testing.
  • Deliverables. A written report plus a walkthrough costs more than a verbal summary, and is worth more.

For a broader view of how prices break down and how to compare quotes, read our code audit pricing guide.

Our published pricing, last read on our site in September 2026, gives you concrete anchors:

Service Price
Senior Developer Review from $449 one-off
Vibe Check (AI-generated app review) $449 one-off
ShipDoctor scan $59 one-off
Infrastructure Assessment $2,750 one-off
Automated Monitoring / Logging / Alerts $2,750 one-off
Continuous Integration (CI) Assessment $4,500 one-off
Dockerizing Your Application $3,800 one-off
AI Assisted Engineering from $9,950 one-off

Most clients start with a focused review, then add an infrastructure or CI assessment where the audit points. The full price list shows what each includes.

Auditing AI-generated and vibe-coded software

A growing share of the “legacy” code we see is only months old. A founder prompts an AI tool, the prototype works in a demo, customers sign up, and then the cracks show: hard-coded keys, no tests, a database nobody can migrate. We call it the prototype trap, and it is the last mile that sinks these projects.

AI-assisted scanning is genuinely useful here. It reads fast, flags patterns and surfaces candidates for review. But it can’t tell you whether a flagged function matters to your business, and it can miss logic flaws that look syntactically fine. Treat tool output as a lead list for a human reviewer, not a verdict. We explain why in why every AI application needs a professional code audit, and how to change this kind of code safely in how to refactor AI apps without breaking them.

If you are a nontechnical founder holding an app you can’t evaluate, our Vibe Check is built for exactly this: a human-led review that tells you in plain language whether it is safe to launch, what to fix and what it will take.

Auditing AI-generated and vibe-coded software

When to commission an audit

Bring one in when any of these is true:

  • You are acquiring a company or inheriting a product and need to know what you are buying.
  • The only developer who understood the system has left.
  • Releases have become slow, scary or frequent sources of outages.
  • You have a compliance, customer security questionnaire or insurance review coming.
  • Cloud or token costs keep rising without a clear reason.
  • You are about to add AI features to a system you haven’t looked inside in years.

The common thread: you are about to make a decision that depends on the true state of the code.

Our perspective

Most legacy audits fail the same way: they hand over a long report and walk away. The client now knows 300 things are wrong and has no idea which five matter.

We built our approach around the opposite. Experienced engineers read the code, AI speeds up the mapping and the scan, and every finding gets tied to a business consequence and a next step. We favor simple fixes over clever ones, because simple is what your team can maintain after we leave.

We also stay. Launching a fix is not the finish line, so we offer ongoing support so the codebase doesn’t drift back to where it started. If you can’t tell whether your software is an asset or a liability, an audit is the fastest honest answer.

Chad

Start with a review

If you want a straight answer on your codebase, we can help. Start with a Senior Developer Review, from $449, to get a ranked view of the risks. If the code came out of an AI tool, the Vibe Check is the right door. Larger or more tangled systems get a scoped audit with infrastructure and CI assessments added where needed.

Bowtie

You can see everything we offer on our services page, or reach us from bowtie.co.

FAQ

What is a legacy code audit?

It is a whole-system review of existing software, covering architecture, dependencies, tests, security and operations. The output is a prioritized report that says what is risky, what it would cost to fix and in what order to act. It differs from a routine code review, which checks one change at a time.

How long does a legacy code audit take?

It depends on code size, the number of languages and how well the system is documented. A focused review of a small application can be quick, while a large multi-service platform takes longer because the reviewer must map it first. Ask for a timeline in the scoping call, tied to a defined scope.

Can an AI tool audit my legacy code on its own?

AI tools are good at fast scanning and pattern spotting, and they cut the time a human spends reading. They can’t judge business impact or catch every logic flaw, so use them as input to a human-led review. This is how we use them ourselves.

Do we have to rewrite everything after an audit?

Usually not. Incremental refactoring and replacing the worst components one at a time is typically safer and cheaper than a full rewrite. The audit gives you the evidence to decide which parts to keep, fix or replace.

Sources