In this guide 6 sections
Auditing an undocumented codebase means getting authorised access, running a copy in isolation, mapping its stack and entry points, tracing data and deployment, and rating risk and test coverage. The deliverable is a readable system map plus a ranked backlog, which gives the owner a plan instead of a list of complaints.
Confirm authorisation and set up an isolated environment
Confirm who may authorise the review. Then get the code running in an environment that cannot touch production, because reading alone misses swallowed exceptions, dead menus and features that quietly fail. Dummy data is enough.
Consider a manufacturer with a shop-floor scheduling tool written in PHP against a MySQL database by an engineer who has since retired, and nobody left has opened its source. Copy it first. Use a separate machine. Load an anonymised snapshot of real orders so the auditors see realistic behaviour while the live schedule the shop floor depends on stays untouched.
Document the setup as you go. Note every missing package, hand-edited configuration file and manual step needed to start the copy, since those notes become the first draft of the deployment section.
Map the frameworks, dependencies and entry points
Next, record the stack. That means the language and framework versions, every third-party library, and each entry point where execution begins, including web routes, scheduled jobs and background workers. Old systems collect forgotten entry points. A nightly cron job that still emails a payroll CSV to someone who left years ago is a typical find, and it can fail or leak data unnoticed.
No special tooling is needed. Dependency manifests, lock files, a directory listing and the server’s crontab will surface most of the skeleton quickly, and the rest of the audit hangs from it. Judging quality comes later.
Group what you find into three piles. Sort them into current components, old but harmless ones, and old components exposed to the internet, such as a login form on an unmaintained framework.
Reconstruct how data, builds and deployment work
Data flow is usually the least documented part of an inherited system, and every report, invoice and export depends on where a value enters, changes and lands. Trace one order end to end. Follow the code, or switch on the database query log and watch which tables an order touches, which is slower than a diagram but often the only honest option.
Then reconstruct the build and deploy path. Find the commands that turn source into a running application, and check whether the release steps are written anywhere or live only in someone’s memory. Skipping deployment leaves the riskiest gap unexamined.
Ask the people who still use it. A dispatcher or bookkeeper can name the exports they run by hand and the files they email around, and each answer points to a data path the code hides.
Assess risk, test coverage and maintainability
Once the shape is clear, assess risk. Look for known vulnerabilities in outdated dependencies, SQL built by string concatenation, credentials hardcoded in config files, and any component whose vendor no longer supports it. Test coverage is a separate signal. A codebase with no automated tests is not necessarily broken, but every future change to it carries more risk, because nothing exists to catch a mistake before customers do.
Maintainability is the last check. Look at how consistent the naming is, how tangled the links between modules are, and how much a new developer must learn before making one safe change. Score each area high, medium or low. A rough rating is enough to decide what happens next, and false precision only slows the conversation with the owner who must approve the budget.
Finish with a one-page risk summary. List the five findings most likely to hurt the business first, each with the component affected, the reason it matters and who approves the fix.
Produce a system map and a remediation backlog
The real output is a system map. It holds the framework list, entry points, data flows and deployment steps, written in one place so a developer who did not write the original can work from it. A findings list is not enough.
Pair the map with a ranked backlog. Rank each item by risk and business impact, so the owner can see that an expired TLS certificate outranks a folder of unused migration scripts. Decisions about repair, modernisation or rebuild then rest on evidence, in a sequence you can defend, instead of on whatever the last person to touch the system remembered.
Store them in a company account. Review the map whenever a major change ships, because a map that drifts from the running system becomes the next undocumented legacy the following owner has to decode.
Recovered architecture and dependency map
A template for the framework and dependency versions, entry points and scheduled jobs, data flow from input to storage to output, and deployment steps of an inherited system. Every audit should leave it behind.
Open a blank worksheet to printQuestions owners ask
Can code be reviewed without running it?
Only in part, because reading shows structure, style and obvious risks while running a copy shows silent failures and dead paths that look functional but no user ever reaches. Do both where possible.
What should the audit deliver?
A readable system map covering frameworks, dependencies, entry points, data flow and deployment, plus a ranked backlog of risks and remediation work that the owner can price and schedule. A narrative of complaints falls short.
Who should receive the finished map?
The owner, the next maintainer and one internal contact should each hold a copy, stored in an account the company controls, so knowledge never sits with one person. Update it after each release.