Auditing an existing application before a takeover

Auditing an application before you take it over means checking six things: the code, its dependencies, security, data, hosting and documentation. The goal is not to grade the previous vendor's work but to answer a business question: can this application be changed safely, at what cost, or is it better to rebuild it? A good audit ends with a written, reasoned recommendation, not a score.

This guide covers what to examine, what the deliverable should contain, and how to choose between taking over and rebuilding.

When an audit is worth doing

Four situations come up again and again:

• your vendor is winding down or has stopped responding, and another team must step in;
• your in-house developer is leaving, and nobody else knows the application;
• you are acquiring a company or a product, and the software is part of what you are paying for, which makes the audit part of technical due diligence;
• the application is getting slower, less stable or more expensive to change, and nobody can say why.

In each case, the temptation is to ask straight away for a quote on new features. That is premature: a vendor who prices work without reading the code is pricing an assumption. The audit turns that assumption into evidence.

The six areas to examine

Code

The auditor does not read every line. The question is whether another team can understand and change the code without breaking it. The ISO/IEC 25010 standard, whose 2023 revision describes nine product quality characteristics, groups modularity, reusability, analysability, modifiability and testability under maintainability. It is a sound checklist: is the code split into independent parts, are business rules readable, and are there automated tests that catch a regression before your users do?

The language and framework matter too. An application built on mainstream, well-documented tools easily finds a team to take it over. An abandoned framework or a home-grown layer ties it to the people who wrote it.

Dependencies

A modern application assembles dozens, often hundreds, of external libraries. Any of them can carry a known vulnerability or be abandoned by its maintainers. OWASP, the reference foundation for application security, ranks software supply chain failures third in its Top 10 2025.

Software composition analysis (SCA) tools such as OWASP Dependency-Check list dependencies and flag those with publicly disclosed vulnerabilities. The output can take the form of a software bill of materials (SBOM), which the US Cybersecurity and Infrastructure Security Agency describes as a list of the ingredients that make up software components. If you are acquiring a product, asking for an SBOM is a reasonable request.

The platform versions need checking as well. The Node.js project, for example, states that production applications should only run on releases that are still supported; an application stuck on an end-of-life version no longer receives security fixes. Finally, the audit records the licences of open source components, some of which carry obligations if you distribute the software.

Security

A takeover audit is not a full penetration test, but it must cover the issues that prove expensive: access control (can one user see another user's data?), password storage, secrets committed in plain text, data exposed by the API, and logging. The OWASP Application Security Verification Standard, whose version 5.0 was released in May 2025, provides a list of testable requirements to work from. We cover the priorities in business application security: the essentials.

Data

The data is often worth more than the code. The audit checks the data model (do the tables make sense, are duplicates common?), the backups, and above all the restore: a backup that has never been restored is a hope, not a plan. If the application processes personal data of people in Europe, this is also the moment to confirm that retention periods and access rights match your GDPR obligations.

Hosting

Who holds the accounts? It is the simplest question and the one most often left unresolved. Hosting provider, domain name, email delivery, payments, file storage: every account held in the previous vendor's name is a potential blocker. The audit lists these accounts, their monthly costs, the monitoring in place and the deployment procedure. Our guide to avoiding vendor lock-in lists what you need to be able to recover.

Documentation

The test is practical: can an outsider install the application on a laptop and deploy it using only the documents provided? If not, the takeover starts with a discovery phase, and that phase needs a budget.

The deliverable: what you should receive

A useful audit is neither a single score nor a list of hundreds of warnings exported from a tool. The report should include:

1. a one-page executive summary: overall condition, the top three risks, the recommendation;
2. a review of each area, with findings and evidence (file, version, screenshot);
3. risks ranked by severity, separating what is urgent (an exploitable flaw, missing backups) from what can wait;
4. an action plan: what must be fixed before any new work, and in which order;
5. a reasoned recommendation among the options below.

Not every problem is a mistake. Many findings are technical debt: shortcuts taken at some point to move faster, which are repaid with interest. We explain the idea without jargon in technical debt explained for business owners.

Take over, remediate or rebuild

A rebuild is not a failure. When the underlying platform is no longer maintained, rebuilding can cost less over three years than remediation that never ends. But it should not be decided on a hunch. The old application remains valuable: it shows what people actually use and becomes an excellent specification for the new one. If the choice of technology is open, our guide to choosing a tech stack for business software explains which criteria keep the next version easy to hand over.

Two rules prevent bad decisions. Secure the data first: whatever the option, it must be exportable and understandable. Separate the audit from the sale: if the auditing team is also the one bidding for the takeover, ask for a written report in which every recommendation rests on a verifiable fact, and have it reviewed if the stakes justify it.

Preparing the audit so it moves fast

Much of an audit's time is often lost waiting for access. Before it starts, gather:

• read access to the full code repository, including its history;
• access to hosting, the domain name and third-party services;
• an anonymised copy of, or read access to, the database;
• the contracts signed with the previous vendor, to know what rights you hold (see who owns the source code of custom software);
• someone who knows how the application is really used, and what frustrates its users.

Where to start

If you need to take over an application, start by checking what you can actually obtain: the code, the accounts and the data. At LPR Studio, we start from what exists rather than judging it on its reputation, then turn the decision into concrete screens. If a rebuild is the right call, the visual prototype of the new version is free and presented in a video call within 5 working days, before any commitment. The three ways to fund what comes next are on our offers page.