How to Audit a Legacy Web Application

Define the evidence needed before making a legacy decision

An audit of a legacy web application is a structured investigation into what the system actually does, how it operates, what it depends on and where the risks lie. It is not a code review. The purpose is to build an accurate picture of the system from the outside in, so that a business can make informed decisions about modernisation, takeover, replacement or continued operation.

Most legacy audits are triggered by one of four situations: a supplier relationship is ending or deteriorating; the business needs to understand compliance exposure; the system is showing signs of strain under current demand; or a modernisation project is being planned and the starting point is unclear. In each case, the audit needs to answer a different primary question, but the underlying process is largely the same.

What the audit must cover

A thorough audit addresses six areas, regardless of the trigger:

• Ownership and access. Who legally owns the source code, the database schema, the design assets and the domain names? Who currently has credentials to servers, databases, third-party services and DNS management?
• Architecture and dependencies. What servers, databases, caching layers, message queues and third-party APIs does the system rely on? Which of these are still supported by their vendors?
• Data landscape. What data does the system hold, where does it sit, how is it structured and what regulatory obligations apply to it?
• Integrations. Which other systems send data to or receive data from this application? How are those connections maintained, and who controls them?
• Operations. How is the system deployed, monitored, backed up and recovered after failure? Are these processes documented or held entirely in someone's head?
• Known problems. What issues are the current users or support team already aware of, and how are they being managed or worked around?

The audit does not require reading every line of code. It requires asking the right questions, verifying the answers against observable evidence and recording the findings in a form that non-technical stakeholders can use for decision-making.

Who should conduct the audit

The audit needs both business and technical input. A business owner or operations manager can answer questions about process, user behaviour and commercial purpose. A technically competent person — either an internal developer, a contracted engineer or a specialist consultancy — is needed to verify infrastructure claims, check dependency versions and assess integration architectures. If the current supplier is still cooperative, they can provide documentation and access, but their answers should be independently verified where possible. A supplier with a commercial interest in retaining the account may understate risks or overstate the system's capabilities.

Gaining access

Access is frequently the first obstacle. Before any technical assessment can begin, the business needs control of or visibility into: the server hosting environment and its management console; the database and its credentials; the source-code repository; the domain registrar account; any CDN, email or authentication service accounts; and the DNS configuration. If the current supplier is uncooperative, the business may need to invoke contractual rights to access, which is why ownership clauses should be reviewed before the audit starts rather than after access is refused.

Mapping integrations

Legacy systems often accumulate integrations over years, and the people who set them up may have left the business. A practical approach is to start from the known systems — the accounting package, the email platform, the CRM — and ask each vendor or internal team whether they send or receive data from the legacy application. Cross-reference this with any API keys, webhook URLs or scheduled export jobs visible in the application's configuration. Undocumented integrations are a significant risk because they may break silently if the legacy system changes or is replaced.

Assessing data obligations

The audit should identify what personal data the system holds, where it originated, how long it has been stored and whether it is still needed. This is not a substitute for a formal data-protection review, which requires current specialist legal input, but the audit can flag where such a review is necessary. Look for data that was imported from older systems, data belonging to former customers or employees, and data that is duplicated across multiple tables or exports. These are often the areas where retention policy gaps cause the most exposure.

Evaluating operational resilience

Ask for evidence of the last successful backup restoration, not just confirmation that backups exist. A backup that has never been tested is an assumption, not a safeguard. Check whether monitoring is in place and who receives alerts. Determine what happens when the system goes down: is there a documented runbook, or does recovery depend on a specific individual remembering what they did last time? If the system handles real-time operations — order processing, booking management, customer-facing portals — the resilience assessment carries more weight than for a purely internal reporting tool.

Use case: pre-acquisition due diligence

When a business is being acquired, the buyer's team will want to understand the legacy systems that support critical processes. The audit in this context focuses on risk transfer: what breaks if the current team leaves, what compliance liabilities exist and what the realistic cost of replacement would be. The findings feed directly into valuation and negotiation.

Use case: supplier exit planning

If the business has decided to move away from the current supplier, the audit serves as a handover baseline. It establishes exactly what exists, what the business is entitled to and what gaps need to be filled before another supplier can take over. This is distinct from the codebase-level assessment that happens afterwards and is covered in the next article in this series.

Where the work usually goes wrong

• Starting with the code instead of the business process. Understanding what the system is supposed to achieve for the business should come before examining how it achieves it technically. Otherwise the audit produces a technical inventory without commercial context.
• Trusting documentation without verification. Legacy documentation is often outdated. A diagram labelled "current architecture" may describe a version of the system that was replaced three years ago. Always cross-reference documents against what is actually running.
• Skipping the integration map. It is relatively easy to catalogue servers and databases. It is harder and more important to identify every system that silently depends on the legacy application, because those are the connections that cause unexpected breakage during change.
• Assuming the current supplier will cooperate fully. Even with contractual rights, gaining access can take time and may require legal involvement. Build this into the audit timeline rather than treating it as a given.
• Treating the audit as a one-time event. If the decision after the audit is to continue running the system, the audit findings should be converted into a living risk register, not filed away.

What this work cannot prove on its own

An audit has boundaries. It identifies risks and gaps; it does not fix them. It can confirm whether a backup exists and when it was last tested, but it cannot guarantee that restoration will succeed under all conditions. It can flag that a dependency is approaching end-of-life, but it cannot predict the exact point at which it becomes unsupported. It can highlight where personal data is stored, but it cannot replace a formal data-protection impact assessment conducted by a qualified professional.

The audit is also limited by the access available. If the business cannot gain entry to the hosting environment or the source-code repository, the audit has to work from observable behaviour — what the system does from the user's perspective, what external services it communicates with and what the current support team reports. This is less precise than a full infrastructure-level review, but it still produces actionable findings.

Key checks to carry out

• Confirm source-code ownership by reviewing the original contract, any subsequent amendments and the repository access controls.
• Verify that the business controls the domain registration and DNS, not the supplier.
• List every third-party service the system connects to and check whether each service is still actively maintained.
• Identify all user roles and confirm who currently holds administrative access.
• Request evidence of a recent backup restoration test.
• Ask for a list of known bugs, workarounds and deferred fixes.
• Determine whether the system has any hard-coded values — IP addresses, file paths, API keys — that would break if the hosting environment changed.
• Check whether there is a documented deployment process or whether changes are applied ad hoc.
• Confirm that SSL certificates are auto-renewing and not at risk of lapsing.
• Review whether logging is sufficient to investigate security incidents or data breaches.

Turn the assessment into a controlled next step

The output of the audit should be a written report that a non-technical decision-maker can read and act on. It should state clearly what was checked, what could not be checked and why, what risks were found and what the recommended next steps are. That report then becomes the foundation for whatever comes next — whether that is a codebase review, a modernisation plan, a supplier negotiation or a decision to replace the system entirely.