Hollinford describes a software architecture audit in plain terms: it shows how a business system is put together, where it is likely to break, and what it will cost to change. That is the work behind the fixed-price Legacy Health Check, and this guide explains how to buy it well from any provider. If a search for ‘software audit’ brought you to licence compliance pages, that is a separate service, compared in the table below.
Directors running a system nobody fully understands any more will find the guide useful, as will IT leads who need board approval to spend on it. If you are assessing a deal, start with the due diligence section.
By the end, you should be able to brief an audit and budget for it without guesswork. Choosing who does the work is harder, which is what the scorecard further down is for.
What Is a Software Architecture Audit?
A software architecture audit is a structured review of the decisions that shape a business system: where data is held, how the parts connect, where the system runs, and how it is secured. In Hollinford’s audits, findings are ranked by business impact, risk, and effort, so directors can see what to fix first.
Architecture means the choices that are expensive to change later: the data model (how information is structured and stored), integration points with other systems, service boundaries, hosting, and security design. Shortcuts in these choices build up as technical debt, the extra cost carried by every later change.
The Software Engineering Institute (SEI) at Carnegie Mellon University treats architecture analysis as a core practice wherever software is a key business asset. There are five situations that commonly prompt a review:
- A key developer has left, or only one person understands the system.
- The system fails or slows down at busy times.
- The business is buying or selling a company, or raising investment.
- The board wants an independent view before approving spend.
- A legacy system modernisation programme needs a clear starting point.
For illustration: a UK distributor’s orders run through a system built in-house years ago. The developer who wrote it has left, nobody else dares to change it, and staff now re-key orders into a spreadsheet to work around its gaps. An audit would show which parts can be changed safely and what has to be fixed before the next peak season.
What an Architecture Audit Covers
An architecture audit examines the decisions that are hardest to change and judges them against the goals of the business. In Hollinford’s view, a complete scope covers the eight areas below, whether the brief is called an audit, an assessment, or an application architecture review.
Coupling describes how tightly the parts of a system depend on each other. In a tightly coupled system, orders, billing, and reporting might all write to one table, so a small change to billing breaks the order screens. Resilience matters when something goes wrong: it is the system’s ability to keep running, or recover quickly, after a failure.
| Area | The question it answers | What the auditor examines |
|---|---|---|
| Structure and coupling | Whether one part can change without breaking others | Modules, dependencies, shared databases |
| Data and integration points | Where data lives and who changes it | Data model, interfaces, manual exports |
| Security by design | Whether protection is built into the design | Authentication, access rights, storage of secrets, supported versions |
| Resilience and operations | What happens when something fails | Monitoring, backups, recovery |
| Performance and scalability | Whether the system copes as users and data grow | Bottlenecks, load, queues |
| Cost of change | What it costs to add a feature | Tests, deployment, code complexity |
| Hosting and cost of ownership | What the business pays for | Infrastructure, licences, support |
| Knowledge and documentation | What only one person knows | Documents, system owners, key-person dependency |
Auditors often grade findings against published reference models. ISO/IEC 25010:2023 defines a product quality model of nine characteristics, each split into subcharacteristics. The AWS Well-Architected Framework groups cloud good practice into six pillars, and the Microsoft Azure Well-Architected Framework into five.
The SEI’s Architecture Tradeoff Analysis Method (ATAM) is a formal, scenario-based evaluation run as workshops with stakeholders. These models are reference points: an SME rarely needs a full ATAM, and a lighter review that borrows its scenario thinking is usually enough.
An architecture audit can find security weaknesses in the design, such as shared admin accounts or unsupported software versions. Testing whether the live system can be broken into is a separate job: the penetration test described below. Where personal data is involved, the review can flag design choices that make the UK GDPR security principle or Cyber Essentials controls harder to meet, so any later compliance work starts from known gaps.
What You Should Receive from the Audit
A good audit ends with documents that a board can use to make decisions, with every finding tied to evidence and business impact. Hollinford’s independent technology audit produces three: a prioritised modernisation roadmap, a risk register, and an executive summary, followed by a one-hour walkthrough of the findings.
The table below shows the fuller set worth asking any provider about, and who each document serves.
| Document | What it contains | Who reads it |
|---|---|---|
| Current architecture map | Systems, integrations and data flows | Technical lead, a new supplier |
| Risk register | Each risk with its severity, business impact and evidence | Managing director, finance director |
| Prioritised remediation roadmap | What to fix and in what order, ranked by impact, risk and effort | Board, IT team |
| Executive summary | A short, board-ready summary of risks and priorities | Board, investors |
| Findings walkthrough | A live session to go through the report and challenge it | All stakeholders |
Every entry in a risk register should make sense to a finance director. Take an ageing customer database: a good entry states that the vendor no longer patches that version, so customer records are exposed. It rates the risk as high and cites the server inventory as evidence.
Before you sign, ask to see a sample report with client details removed. If you can follow it without ever having seen that client’s system, a new supplier should be able to work from your report too.
Architecture Audit vs Code Review, Penetration Test, Licence Audit, and Due Diligence
An architecture audit answers whether a system can support growth and change at a sensible cost. The neighbouring checks in the table answer narrower questions.
| Check | The question it answers | What it examines | Output | When to choose it |
|---|---|---|---|---|
| Architecture audit | Whether the system can support growth and change | Structure, data, integrations, resilience | Risk register, remediation roadmap | Before modernisation, a deal, or hiring a team |
| Code review or code audit | Whether the code is well written | Readability, defects, duplication | Comments on the code | When code quality is the main concern |
| Penetration test | Whether the live system can be broken into | The running system, tested from outside | List of vulnerabilities | When defences need testing under real conditions |
| Software licence audit | Whether licence terms are being met | Licences, usage, contracts | Compliance report | After a vendor request, or as part of software asset management (SAM) |
| IT audit | Whether controls work as intended | Processes, access rights, policies | Controls report | For financial audit and regulators |
| Technical due diligence (also called software due diligence) | Whether the technology supports the deal | Technology, team, processes, risks | Report for the investor | Before a deal |
Technical due diligence usually includes an architecture audit as one component, alongside reviews of the team, delivery process, and security. For tech due diligence on a live deal, Hollinford argues that the architecture work should show what the target’s technology will cost to bring up to standard. Pre-deal work is covered on the page about technical due diligence for private equity.
A search for ‘software audit’ mostly returns pages on licence compliance and software asset management, where a vendor checks that a business has paid for what it uses. Some providers also sell a narrower application audit focused on a single product. Both have a different purpose and output, set out in the guide to software licence audit vs architecture audit.
How Much an Architecture Audit Costs in the UK, and How Long It Takes
There is no single UK price for an architecture audit, because the cost follows the scope of the review. Hollinford’s Legacy Health Check service is fixed at £5,000 plus VAT and takes two weeks from agreed access. Larger or more complex environments are scoped and priced on the free discovery call.
What Drives the Cost
- The number of systems in scope.
- The size of the codebase.
- The number of integrations.
- The quality of existing documentation.
- The depth of the report.
- Whether the system holds regulated data, such as personal or payment data.
Pricing Models
- Fixed price: the cost is known in advance, and work outside the written scope is charged on top.
- Day or hourly rate: suits an unclear scope, but the total stays open until the work ends.
- Phased work: a short first phase sets the scope for the next, which adds a decision point and some time.
How Long It Takes
A focused review of one system can take two weeks. Softjourn puts a comprehensive architecture assessment at one month for simpler systems and up to six months for complex systems with limited documentation.
Netguru publishes indicative ranges for software audits that include architecture work: $8,000 to $20,000 for a rapid audit of one to two weeks, and $25,000 to $65,000 for a full audit of four to six weeks. Both sources are outside the UK, and neither quotes UK prices, so treat these figures as rough reference points only.
What a Proposal Should Include
- Scope: the systems, environments, and questions the audit will cover.
- Deliverables: the documents you will receive, ideally with a sample.
- Timeline: the start condition, such as agreed access, and the delivery date.
- Exclusions: what the price does not cover, such as penetration testing or remediation work.
See Legacy Health Check pricing →
How to Choose an Audit Provider
Choose an audit provider on three things: independence, a clearly written scope, and findings that another supplier could use. The size of a provider’s brand says little about any of them.
Types of Architecture Assessment Providers
Firms selling software audit services or technical due diligence services can all deliver a software architecture audit, and most fall into five groups:
- Independent specialists and boutiques: deep expertise, limited capacity.
- Software consultancies that also build: they know delivery well, with a possible conflict of interest.
- Large consulting and audit firms: broad coverage and a recognised name, at a higher price and further from the code.
- Cyber security specialists: strong on defence, lighter on architecture and the cost of change.
- Cloud vendor partners: strong on their own platform, with a natural bias towards it.
Hollinford is both an auditor and a modernisation supplier, so the same conflict of interest applies. With any provider, check that another supplier could act on the report and that the contract carries no obligation to buy follow-on work. The Legacy Health Check is sold with no lock-in.
A Buyer’s Scorecard for Comparing Providers
Score each provider from 0 to 2 on every criterion, multiply by the weight, and add up the results. The maximum is 40. Compare totals side by side, and raise every warning sign with the provider before signing.
| Criterion | What good looks like | Warning sign | Weight | Your score (0 to 2) |
|---|---|---|---|---|
| Independence | Discloses conflicts; findings can go to another supplier | The report is unusable without follow-on work from the same firm | 3 | — |
| Clarity of scope | Written scope, criteria and exclusions | A vague description of the work | 3 | — |
| Method | Names the models or approach used | General statements only | 2 | — |
| Outputs | Shares a sample report | Will not show a report | 3 | — |
| Who does the work | Names the roles and their experience | A partner sells the work, and juniors deliver it | 2 | — |
| Data security | NDA, secure access, code stays with the client | Asks to copy code to its own systems without agreement | 3 | — |
| Use of AI | Explains what the tools do and who checks the output | No answer, or a claim that AI replaces human review | 2 | — |
| Price transparency | Fixed price or clear limits | Price set only after the work | 2 | — |
When an Architecture Audit Is the Wrong Next Step
Hollinford uses the Discovery Call to check whether an audit is the right starting point. In four situations, something else should come first:
- If you already know what to modernise, move straight to scoping the delivery work.
- If the application is small and due for replacement soon, put the budget into the replacement.
- If you need to test the defences of a live system, commission penetration testing.
- If the question is about licences, ask for a software licence audit.
For a lighter first step, businesses can start with the legacy system self-assessment.
How a Hollinford Legacy Health Check Works
Hollinford’s Legacy Health Check is an independent technology audit that runs in four steps:
- Hollinford holds a free 30-minute discovery call to understand the systems involved, the goals behind the work, and whether a Health Check is the right starting point.
- Both sides sign an NDA and set up secure access, usually read-only, to the code and documentation. Code stays in the client’s infrastructure unless otherwise agreed.
- At Hollinford, senior engineers review the technology stack and use AI-assisted tools where appropriate, with human review at every stage.
- The client receives a prioritised modernisation roadmap, a risk register and an executive summary, then a one-hour session to question and challenge the findings.
The Legacy Health Check is a fixed-price assessment: £5,000 plus VAT, delivered two weeks from agreed access.
To keep to that timeline, name one person who knows the system and gather whatever documentation exists before access starts. A short list of the decisions ahead, such as a contract renewal or a planned acquisition, lets the report address them directly.
Clients can use the findings internally, ask the same team to deliver the roadmap, or pass the report to another provider, with no lock-in either way.
Frequently Asked Questions
How much does a software architecture audit cost in the UK?
There is no standard UK price, since cost follows the number of systems, the integrations, and the depth of the report. Hollinford’s Legacy Health Check is a fixed £5,000 plus VAT. Quotes for larger estates may use day rates or phases, so compare them only against a written scope.
How long does an architecture audit take?
A focused review of one system can take two weeks once access is in place. According to Softjourn, a comprehensive assessment runs from one month for simpler systems to six months for complex ones. While access is being arranged, the legacy self-check is a useful first step.
Is an architecture audit the same as a code review?
No: a code review service checks the quality of the code itself, such as readability, defects, and duplication. An architecture audit looks at how the whole system is built, how data moves, and where it will fail or become expensive to change. Many audits sample the code along the way.
Will an auditor need access to our source code?
Usually yes: most audits need read-only access to code, configuration, and documentation under an NDA. Hollinford keeps code in the client’s infrastructure by default, with secure access arranged before analysis starts. Ask any provider to state in writing what access it needs and how that access ends.
Can I use the findings with another supplier?
Yes, if the report is complete enough for a new team to work from. Hollinford writes its reports so that a client can use them internally, brief another supplier, or commission the roadmap from the same team. A sample report shows whether any provider’s findings pass that test.