The beautiful tip of the iceberg
Most of what we build you'll never see. This is the part you can.
- Below the surfaceSaaS platforms, cloud systems and the engineering businesses run on.
- Above itA small glimpse of our UI/UX craft — ten real product interfaces.
Software Audits & Technical Due Diligence: know what you own before you commit.
Independent software assessments for acquisitions, modernisation, operational resilience and technology investment. We help organisations understand what they own, what risks exist, what it will take to maintain or improve their software, and whether the technology can support their future business objectives.
Synthetic example. Every audit is scoped to your question.
What is a software audit?
A software audit is an independent, evidence-based assessment of an application and everything it depends on: its architecture, source code, technical debt, security controls, infrastructure, deployment processes and the knowledge needed to run it. Technical due diligence is the same assessment carried out to support a specific decision, such as buying a business, investing in one, or changing software supplier.
The output is not a score for its own sake. It is a clear account of the risks that matter to your business, the evidence behind each one, and a prioritised view of what to do next, written so that owners, boards and engineers can all act on it.
Who commissions an audit
- CTOs & IT Directors
- Business owners
- Private equity & investors
- Procurement teams
- Acquirers of software businesses
- Organisations replacing a supplier
- Teams inheriting a system
Assemblysoft brings practical experience of designing, modernising, integrating, troubleshooting and supporting custom .NET and Microsoft Azure applications. Our recommendations are grounded in delivery realities rather than theoretical architecture alone.
Taking over software you did not build
When a business changes software supplier, buys a company or loses its original developer, two questions decide almost everything that follows.
Can we take over software developed by another company without rebuilding it?
In many cases, yes. Software does not need to be rewritten simply because the original development company is no longer involved. An independent assessment establishes whether another engineering team can maintain, improve or modernise the existing application, and what a structured handover would involve.
Where a replacement is justified, we help identify why, and evaluate the options before substantial expenditure is committed.
Read the full answer → Supplier transition assessment →Do we actually own and control the software and its source code?
Ownership and practical control are separate matters. A business can have a working application without controlling its source code, hosting, deployment pipeline or third-party accounts. We establish exactly which repositories, accounts, databases and deployment assets you can access, and which dependencies would complicate a supplier change.
Confirming legal ownership and IP rights requires your legal advisors; our findings tell them which questions to ask.
Read the full answer → Read the article →Nine areas, each tied to business impact
Scope is agreed with you first. A focused health check may cover three areas; a full due diligence assessment covers all nine.
Architecture & design
Structure, coupling and whether the design can support where the business is going. See the .NET code & architecture audit.
Code quality & technical debt
Material debt separated from acceptable compromise, and prioritised by business impact, urgency and remediation complexity.
Security design & controls
Authentication, authorisation, secrets, dependencies and logging, framed against OWASP ASVS. Not a substitute for penetration testing.
Azure infrastructure & cost
Reliability, security, cost, operations and performance across the Well-Architected pillars. See the Azure assessment.
DevOps & delivery
Build reproducibility, pipelines, test gates, environments and release safety. Can someone else ship a change tomorrow?
Operational resilience
Monitoring, incident response, backup, restore and disaster recovery compared with your expectations. See the resilience review.
Dependencies & support lifecycle
Frameworks, libraries and platforms mapped to vendor support dates. .NET 8 and .NET 9 both leave support on 10 November 2026.
Ownership & control of assets
Repositories, tenants, subscriptions, domains, certificates and service accounts: who holds the keys today.
Documentation & knowledge risk
What is written down, what lives with individuals or suppliers, and the onboarding effort for a new team.
Choose the depth that matches the decision
Every engagement is scoped and priced once we understand the systems involved, so you never pay for depth the decision does not need. Our day rates are published on the rate card.
Focused Technical Health Check
A rapid, targeted view of one application or one concern, when you need direction rather than a full audit.
- Best for
- A specific worry: rising costs, slow delivery, an approaching support deadline
- Typical duration
- Several working days
- Up to three agreed assessment areas
- Read-only code and configuration review
- Short report with prioritised actions
- Walkthrough call
Comprehensive Software Audit
A full assessment of an application and its estate across all nine areas, for planning the next stage of its life.
- Best for
- Modernisation planning, budgeting, board reporting, keep-or-replace decisions
- Typical duration
- Several weeks for interconnected business-critical systems
- All nine areas, scoped to your estate
- Build and deployment validation where authorised
- Executive assessment, risk register and roadmap
- Stakeholder workshop
Acquisition or Transition Due Diligence
Technical due diligence shaped around a transaction or a supplier change, with findings delivered to your timetable.
- Best for
- Buyers, investors and organisations changing software supplier
- Typical duration
- Aligned to the deal or notice period
- Document, interview and data-room review first
- Deeper code and infrastructure review as access allows
- Verified findings separated from uncertainty
- Briefing for your advisors and board
Six specialist reviews under one method
Commission one on its own, or combine them into a comprehensive audit. Each page explains what is assessed, what you receive and where the boundaries are.
From first conversation to an agreed next step
Most of the work uses read-only access, documentation, interviews and existing engineering evidence, so day-to-day operations are not disrupted.
Scope, access & NDA
We agree the decision the audit must support, the systems in scope, access arrangements and timescales, under NDA where needed.
Review & interviews
Code, configuration, pipelines, cloud estate and documentation, plus short interviews with the people who run the system.
Verify & prioritise
Each finding is checked against evidence, rated for impact and urgency, and marked as verified or uncertain.
Report & workshop
Executive assessment, technical report and roadmap, presented to business and technical stakeholders together.
A report you can put in front of a board
Written for decision-makers first and engineers second. Every material finding carries its evidence, its likely impact, a recommended action and any limitation in what could be verified, so nothing reads as more certain than it is.
View the anonymised sample report- Executive assessment: principal risks and their implications for continuity, investment and future development
- Technical report: findings, supporting evidence, impact, recommended action and assessment limitations
- Risk register & severity matrix: every finding rated by likelihood and impact
- Prioritised roadmap: immediate concerns, planned improvements and areas for further investigation
- Options appraisal where the question is keep, modernise or replace
- Stakeholder workshop to agree next steps
Aligned with recognised guidance, honest about its limits
Our audit method draws on established technical and regulatory guidance, so findings use a vocabulary your advisors, insurers and engineers already recognise.
| Area | Supporting authority | How it shapes the audit |
|---|---|---|
| Secure development practices and software acquisition | Secure Software Development Framework (SSDF), NIST SP 800-218US National Institute of Standards and Technology | Gives a vendor-neutral vocabulary for judging whether software was produced with secure development practices, and explicitly supports using those practices when acquiring software. |
| Application security review and verification | Application Security Verification Standard (ASVS)OWASP Foundation | Frames application security findings as verifiable requirements across authentication, access control, input handling and data protection, rather than a superficial vulnerability scan. |
| Cloud reliability, security, cost and operational maturity | Azure Well-Architected FrameworkMicrosoft | Structures Azure workload assessment around its five pillars: reliability, security, cost optimisation, operational excellence and performance efficiency. |
| Data protection during mergers and acquisitions | Data sharing code of practice: due diligence following mergers and acquisitionsUK Information Commissioner's Office | Identifies where personal data, its lawful basis and its security arrangements need attention when systems change hands. Legal conclusions remain with your advisors. |
These references support the audit methodology and its boundaries. They describe what a properly scoped audit can assess; they are not a claim that any particular client's systems have already been verified, and alignment with a framework is not a certification.
What a software audit is not
- It is not a financial valuation of a business.
- It is not legal advice on ownership, IP or contracts; that needs qualified legal advisors.
- It is not a substitute for specialist penetration testing.
- It cannot guarantee defect-free software or find every vulnerability.
- It does not produce a fixed price for every future requirement.
What it does give you
- Evidence about the technical condition of the software, not opinion.
- Risks ranked by business impact, urgency and remediation complexity.
- Indicative effort ranges where the evidence supports them.
- A clear line between verified findings and open questions.
- Technical evidence your advisors can use in negotiations and contracts.
Assessors who also build, migrate and support
Grounded in delivery
We design, modernise, integrate, troubleshoot and support custom .NET and Azure applications every day, including systems we did not build, such as the business-critical legacy applications we supported and migrated for LV=. Our recommendations reflect what change really costs.
No stake in the answer
The findings are yours to use with your own team or any supplier. There is no obligation to appoint Assemblysoft for remediation, and a recommendation to keep what you have is a perfectly good outcome.
AI-assisted, engineer-verified
AI tooling helps us map unfamiliar codebases and trace dependencies quickly. Every material finding is verified by a senior engineer before it reaches your report.
UK-based and accountable
A permanent UK team based in Bournemouth, a Microsoft Partner with Cyber Essentials Plus, and policies published openly in our Trust Centre.
After the audit
If you want help acting on the findings, the same team can turn recommendations into a structured programme: legacy .NET upgrade and migration, Azure modernisation, DevOps and CI/CD and managed application support, including a structured development partner transition. Any implementation work is scoped and agreed separately.
Your code, credentials and data, handled with care
An audit means trusting an outside team with source code, infrastructure and sometimes personal data. Here is how access and evidence are controlled. Certification describes how we run our own business; it does not, on its own, guarantee the security of a client's application.
NDA before detail
We sign your NDA or provide ours before receiving anything confidential, including the identity of an acquisition target.
Due-diligence questionsRead-only by default
Repository and cloud access at the least privilege needed, time-limited and revoked at the end. Anything that could affect a live system is agreed separately.
Information securityEvidence handled deliberately
Working copies are held only as long as the engagement needs, production data is avoided wherever possible, and evidence is returned or deleted on completion.
Data residencyCyber Essentials Plus
Assemblysoft holds Cyber Essentials Plus, independently audited. Our policies, insurance and certificates are published in the Trust Centre.
Visit the Trust CentreWhere personal data is in scope, a UK GDPR Article 28 Data Processing Agreement applies. Reports are confidential to you and shared only with the people you name, such as your advisors or board.
Explore the audit family
One evidence-based method, applied to the decision in front of you. Each specialist assessment can run on its own or as part of a comprehensive audit.
Software Audits & Technical Due Diligence
The overview: independent software audits and technical due diligence for acquisitions, supplier changes and investment decisions.
Software audits and technical due diligence, answered
Twenty questions business owners, investors and IT leaders ask before taking on or deciding the future of a software system. Each answer has its own link.
Buying or taking ownership of software
For buyers, investors and organisations inheriting a system from a supplier or developer who is moving on.
Can we take over software developed by another company without rebuilding it?
Key question
In many cases, yes.
Software does not necessarily need to be rewritten simply because the original development company is no longer involved.
An independent technical assessment can establish whether the existing application can be maintained, improved or modernised by another engineering team.
Assemblysoft evaluates the codebase, architecture, dependencies, deployment processes and available documentation to identify potential transition challenges.
The outcome may be a recommendation to retain the existing application, address specific weaknesses and establish a structured handover.
Where a replacement is justified, we can help identify the reasons and evaluate the available options before substantial expenditure is committed. See our software supplier transition assessment.
Link to this answerHow do we know whether we actually own the software and its source code?
Key question
Ownership and practical control are related but separate matters.
A business may have access to a functioning application without having complete control over its source code, hosting environment, deployment processes or third-party dependencies.
As part of a technical audit, Assemblysoft can establish which repositories, infrastructure accounts, databases, services and deployment assets are accessible to the organisation.
We can also identify technical dependencies that may complicate a supplier transition.
However, confirming legal ownership, intellectual property rights and contractual entitlements requires a review of the relevant agreements by qualified legal advisors.
Our technical findings can help identify which assets and contractual questions need further investigation.
Link to this answerWe're buying a business that owns custom software. How do we know whether the software is worth what we're paying?
An independent software audit helps establish whether the technology can support the business objectives behind an acquisition.
Assemblysoft can assess the software's architecture, code quality, technical debt, infrastructure, scalability and operational dependencies. We also identify potential engineering work that may be required after acquisition.
The resulting technical due diligence report helps you understand whether the software is maintainable, what risks could affect future investment and where additional expenditure may be necessary.
Although a software audit does not determine the financial valuation of a business, its findings can provide valuable evidence for commercial negotiations, investment decisions and post-acquisition planning. See acquisition and investment technical due diligence.
Link to this answerCan a software audit help us negotiate a business acquisition or supplier agreement?
Yes. Technical due diligence can provide evidence that informs commercial discussions.
For example, an audit may identify unsupported technologies, missing documentation, supplier dependencies, operational weaknesses or significant engineering work that will be necessary after acquisition.
These findings can help buyers and their advisors evaluate future investment requirements, transition obligations and appropriate contractual protections.
Assemblysoft provides the technical evidence and explains its likely operational implications.
Commercial negotiations, transaction valuation and legal terms remain matters for the relevant business and professional advisors.
Link to this answerCan you audit software before we have completed the purchase?
Yes. Pre-acquisition technical due diligence is a common and valuable use of a software audit.
The review can be conducted during the acquisition process, subject to the seller's agreement and appropriate confidentiality and access arrangements.
Assemblysoft can begin with available architecture documentation, technical discussions and supporting evidence, followed by deeper code and infrastructure assessment where access is permitted.
We identify material risks, outstanding questions and technical assumptions that may affect the buyer's decision.
Where access is restricted, our report distinguishes verified findings from areas that remain uncertain.
Link to this answerHow do we know whether another development team can maintain the software?
A maintainable application should be understandable, buildable, testable and deployable by suitably qualified engineers without unreasonable dependence on its original authors.
Assemblysoft evaluates the code structure, development tooling, documentation, automated tests, dependencies and deployment processes.
We also consider how easily a new team could establish a development environment, reproduce existing builds and understand important business workflows.
Where appropriate and authorised, practical build or deployment validation can provide stronger evidence than documentation alone.
The findings help organisations understand the likely onboarding effort and any barriers to transferring technical responsibility.
Link to this answerSoftware quality, security and operational risks
What a code audit and architecture review can, and cannot, tell you about the technical condition of a system.
How can we tell whether the software has been developed properly?
Software can function correctly for users while still containing significant technical weaknesses.
A software code audit examines the quality of the underlying implementation, including its architecture, coding practices, dependencies, error handling, testing and maintainability.
Assemblysoft looks for evidence of established engineering practices and identifies areas where changes may be unusually expensive, risky or difficult.
The assessment helps distinguish between software that simply works today and software that is reasonably structured to support future development.
No review can guarantee defect-free software, but an evidence-based assessment can substantially improve your understanding of its technical condition. See our .NET code and architecture audit.
Link to this answerHow can we identify whether the software has security vulnerabilities?
A technical audit can identify security weaknesses within application architecture, source code, authentication, authorisation, dependencies and infrastructure configuration.
Assemblysoft can examine relevant security controls and assess whether engineering practices support secure development and operation.
Depending on the agreed scope, this may include reviewing access controls, secrets management, dependency vulnerabilities, data protection arrangements and security-related logging.
Findings are documented according to their potential impact and the evidence available.
A general software audit does not guarantee that every vulnerability will be discovered and is not a substitute for specialist penetration testing.
Where deeper security assurance is required, we can recommend additional assessment.
Link to this answerHow do we know whether the software can support our future growth?
An application that performs adequately today may encounter difficulties as customer numbers, transaction volumes, data storage or integration requirements increase.
Assemblysoft can assess the architecture, database design, infrastructure configuration and known performance constraints to identify potential scalability concerns.
We consider whether the system is appropriately structured for anticipated business growth and whether its infrastructure can be adapted efficiently.
Where historical performance data, monitoring information or test environments are available, these can provide additional evidence.
A technical review can identify scalability risks and recommend further testing, but reliable capacity predictions may require representative load testing and defined growth assumptions.
Link to this answerWhat happens if the software fails or suffers a major outage?
Business-critical applications should have appropriate arrangements for monitoring, incident response, backup, restoration and disaster recovery.
Assemblysoft can assess whether these arrangements exist, how they are configured and whether the available evidence supports the organisation's recovery expectations.
We review operational dependencies, monitoring, deployment processes, recovery documentation and potential single points of failure.
Where agreed, we can also evaluate evidence from previous recovery tests or recommend controlled restoration exercises.
The assessment helps organisations understand how prepared they are for disruption and which improvements should be prioritised. See our operational resilience and DevOps review.
Link to this answerWhat if the software uses old technologies or unsupported frameworks?
Older technology does not automatically mean that an application must be replaced.
However, unsupported frameworks, outdated libraries and ageing infrastructure can introduce security, compatibility, maintenance and recruitment challenges.
Assemblysoft can assess the technologies in use, identify relevant support constraints and evaluate the implications for ongoing operation.
For Microsoft-based applications, this may include reviewing .NET Framework, modern .NET, ASP.NET, SQL Server and Azure-related dependencies.
We can then recommend whether to maintain, upgrade, refactor, migrate or replace particular components.
The objective is to establish a proportionate modernisation strategy rather than assume that a complete rewrite is necessary. See our legacy software modernisation review.
Link to this answerCosts, timescales and future investment
How an audit informs budgets, how long it takes, and what it means for the decision in front of you.
Can a software audit tell us how much it will cost to maintain or modernise the application?
A software audit can provide a stronger technical basis for estimating future development, maintenance and modernisation expenditure.
By examining the architecture, codebase, infrastructure and dependencies, Assemblysoft can identify areas likely to require corrective work or additional investment.
Where sufficient evidence exists, we can provide indicative effort ranges, technical dependencies and implementation priorities.
However, a code review alone cannot establish a reliable fixed price for every future requirement.
Detailed estimates may require additional discovery, business requirements analysis, prototyping or investigation of particularly complex components.
Our objective is to reduce uncertainty and make future budgeting more informed.
Link to this answerCan an audit identify whether we're paying too much for cloud hosting?
A cloud infrastructure assessment can identify opportunities to improve cost efficiency.
For Microsoft Azure environments, Assemblysoft can review resource configuration, utilisation, hosting architecture, monitoring and relevant expenditure data.
We look for potentially unnecessary resources, inappropriate service tiers, inefficient architecture and opportunities to simplify infrastructure.
Recommendations consider reliability, performance, security and operational requirements alongside cost.
Actual savings depend on usage patterns, contractual arrangements and the changes ultimately implemented. See our Azure infrastructure assessment.
Link to this answerHow long does a software audit take, and will it disrupt our business?
The duration depends on the complexity of the application, the number of systems involved, the depth of assessment and the availability of technical information.
A focused technical health check may take several working days, while a comprehensive review of interconnected business-critical systems may require several weeks.
Most initial review activities can be conducted using read-only access, documentation, interviews and existing engineering evidence.
Where testing or configuration changes could affect a live environment, these should be separately agreed and appropriately controlled.
Assemblysoft establishes the assessment scope, access arrangements and expected timescales before work begins.
Link to this answerWill you tell us whether we should keep, modernise or replace the software?
Yes. Where this is the agreed objective, the assessment can provide a reasoned recommendation based on the available technical evidence and business requirements.
Assemblysoft considers the application's condition, technical debt, architecture, dependencies, operational risks and suitability for future development.
Possible recommendations include retaining the existing system, targeted remediation, phased modernisation, platform migration or replacement.
We explain the advantages, disadvantages, dependencies and uncertainties associated with the principal options.
The aim is to support a proportionate business decision rather than recommend redevelopment unnecessarily.
Link to this answerAudit deliverables and next steps
What you receive, what happens if information is missing, and what comes after the report.
Can you audit software if we don't have complete documentation?
Yes. Incomplete documentation is a common reason for commissioning a software audit.
Where source code, infrastructure access and relevant technical stakeholders are available, it may be possible to reconstruct a useful understanding of the application's architecture and operating requirements.
Assemblysoft can examine code repositories, configuration, databases, integrations, deployment pipelines and other technical evidence.
We identify missing documentation and areas where knowledge appears concentrated within individuals or suppliers.
Any conclusions that cannot be adequately verified are clearly identified in the report.
Link to this answerWhat exactly will we receive at the end of the software audit?
The agreed deliverables typically include an executive assessment, detailed technical findings and prioritised recommendations.
The executive assessment explains the principal risks and their potential implications for business continuity, investment and future development.
The technical report documents material findings, supporting evidence, potential impact, recommended action and any limitations in the assessment.
A prioritised roadmap identifies immediate concerns, planned improvements and areas requiring additional investigation.
Assemblysoft can also present the findings in a stakeholder workshop, allowing business owners and technical teams to discuss the results and agree appropriate next steps. See an anonymised sample report built from synthetic findings.
Link to this answerWhat happens after the audit? Can Assemblysoft help us fix the problems?
Yes. Assemblysoft can provide further technical consultancy, remediation, modernisation, development and application support services where required.
Following the audit, we can help turn the recommendations into a structured programme of work, including technical priorities, dependencies, implementation phases and delivery estimates.
This may involve improving code quality, modernising .NET applications, optimising Azure infrastructure, strengthening DevOps processes or preparing software for transition to a new support provider through managed application support.
Any subsequent implementation engagement is separately scoped and agreed.
The audit findings remain available for your own engineering team or another supplier to use. There is no obligation to appoint Assemblysoft to perform the recommended work.
Link to this answerFrom the Assemblysoft blog
Still unsure about the condition of your software?
Whether you're acquiring a software business, replacing a development supplier or planning the future of an existing application, Assemblysoft can help you understand the technical risks before making a significant commitment.
Discuss Your Software Audit Requirements See a Sample ReportCyber Essentials Plus certified · NDA as standard · UK-based team · Microsoft Partner · No obligation to appoint us for remediation
Start a meaningful conversation with us today.
Assemblysoft are Your Safe Pair of Hands
Azure
Azure DevOps
