Diligence support
Before you close, you need to know what actually runs the business. Not what the seller says runs it. Not what the architecture diagram claims. What software sits where, who holds the keys, how the data flows, what licences are missing, and how much it will cost to separate from the seller after close. We provide the engineering analysis that lets your deal team and licensed advisors form their own conclusions.
When a private equity operating partner looks at a target, the technology stack is often the least understood part of the asset. Financials and legal documents get thorough review because the frameworks for reviewing them are established. Technology does not get the same treatment. The seller provides a spreadsheet of software subscriptions and a network diagram drawn two years ago. The buyer's deal team, rightly cautious, wants more but does not always know what to ask for.
We approach technical diligence as an engineering investigation, not a checklist exercise. We map the real estate: every application the business depends on, every database, every integration point, every domain registration and DNS record, every administrative account and API key, every third party dependency with a renewal date or a usage cap. We identify where the business is exposed to a single employee who holds knowledge no one else has. We trace how customer data moves from entry to archive and where it sits at rest. The output is a written findings memo, a comprehensive inventory, and a remediation and transfer plan that gives your team a clear picture of what it will take to own and operate the technology independently.
This work is data and systems analysis performed to support the client's own accountants and counsel. We do not hold professional licensure and we issue no professional opinions. The conclusions drawn from our findings belong to the client's own licensed advisors, who use our technical inventory and analysis as one input among others in forming their own judgements about the transaction.
Sellers rarely maintain a living inventory of their technical assets. What they hand over during diligence is often incomplete, out of date, or structured in a way that hides dependencies rather than reveals them. We produce an inventory that covers the ground sellers miss.
The inventory begins with software: every application used by the business, whether it runs on a desktop, a server, or a third party cloud. For each application we record the vendor, the version, the licence model, the renewal date, the number of seats or instances, the cost per period, and whether the licence is transferable to a new owner. We flag applications that are end of life, unsupported, or running on infrastructure the seller intends to retain.
We then map the data. Where does customer information live? In which databases, which file stores, which third party platforms? How is it backed up? Who can access it? What encryption is applied in transit and at rest? We document every integration point between systems, noting whether the integration is maintained by an employee, a contractor, or a vendor, and whether it would survive a change of ownership without renegotiation. We catalogue domains, SSL certificates, mail delivery infrastructure, and the administrative accounts that control them.
In many small and mid market businesses, a single person holds the knowledge that keeps the technology running. That person may be the founder, a developer hired years ago, or an IT manager who built everything from scratch. When the business changes hands, that dependency becomes a risk the buyer must price and plan for.
We look for key person risk in several places. First, the codebase itself: who wrote it, who maintains it, and whether anyone else understands it well enough to make changes or fix problems. We examine commit histories, documentation, and deployment practices. Second, the infrastructure: who has the root credentials, who configured the network, who set up the email system. Third, the vendor relationships: who holds the account manager relationship, who negotiates renewals, who knows the escalation path when something breaks.
We do not simply flag the dependency. We estimate the effort required to transfer that knowledge to a new team or to replace the function with a documented process or a third party service. That estimate becomes part of the remediation plan, giving you a basis for negotiating the purchase price or structuring the transition period.
Software licences and technology contracts often contain change of control provisions that trigger on acquisition. A licence that costs a few hundred dollars a month under the seller's ownership may reset to list price under yours. A contract that the seller signed five years ago may not permit assignment to a new entity. Open source components buried in the codebase may carry obligations the business has never met.
We review the licence position of every significant software asset. For commercial software, we read the licence terms, note any change of control clauses, and estimate the cost of renewal or renegotiation under new ownership. For open source components, we identify the licences in use, check for copyleft obligations that might require the business to release proprietary code, and flag any components with known security vulnerabilities that have not been patched.
We also examine the contracts for hosting, infrastructure, and third party services. We note auto renewal terms, notice periods, termination fees, and data extraction provisions. The goal is to give your legal counsel a complete picture of the contractual landscape so they can advise on what needs to be renegotiated before close or addressed in the purchase agreement.
Businesses that have grown through acquisition or that have operated for many years under a single owner often accumulate integration debt. Systems are connected with scripts that one person wrote and no one documented. Data flows through spreadsheets that are emailed between departments. The CRM talks to the accounting system through a middleware layer that has not been updated since it was built.
Integration debt matters in diligence because the buyer will eventually need to separate the target from the seller's shared infrastructure. That separation may require rewriting integrations, migrating data, or replacing systems that cannot be transferred. We map every integration, assess its fragility, and estimate the work required to decouple the target from the seller.
We also look at the operating cost of the technology once it stands alone. The seller may provide shared servers, shared IT staff, shared software licences, and shared internet connections. After close, the buyer must replace those shared resources. We estimate what that will cost, both in one time separation work and in ongoing operating expense, so the deal model reflects reality.
We deliver three documents. The findings memo is a narrative report that describes what we found, what it means for the transaction, and what risks and costs the buyer should factor into their model. It is written to be read by an operating partner who needs to make a decision, not by an engineer who wants to debate architecture. The language is plain and the recommendations are specific.
The inventory is a structured catalogue of every asset we examined. It is delivered as a spreadsheet and as a set of records that can be imported into the buyer's own systems. The inventory is designed to be a living document that the buyer's team can update as the business evolves. It covers software, data, domains, accounts, integrations, and contracts.
The remediation and transfer plan is a phased work programme that describes what must happen between signing and close, what must happen in the first thirty days after close, and what can wait until the first ninety days. It assigns each task to a responsible party, estimates the effort, and identifies dependencies between tasks. The plan is built to be handed to an integration team or to us for execution, as the buyer prefers.
Before we can produce the inventory and the findings memo, we need access to the target's systems and the seller's data room. We work with the deal team to define the scope of access, request the necessary credentials and documents, and conduct the review without disrupting the seller's operations. Our systems and data room review process is covered in more detail on a separate page.
The review typically takes between two and three weeks, depending on the complexity of the target and the responsiveness of the seller. We begin with a document request list tailored to the business. We then conduct technical interviews with the seller's key technical staff. Finally, we examine the systems directly, inspecting configurations, code repositories, and infrastructure. We report progress to the deal team throughout the process so that findings that might affect the negotiation are surfaced early.
We understand that sellers are often reluctant to grant deep technical access before close. We design our review to be minimally invasive. We do not install agents on production systems. We do not run penetration tests or load tests. We read configurations, we do not change them. The goal is to gather the facts without creating risk for either party.
Financial due diligence answers whether the numbers are correct. Our forensic analysis answers whether the systems that produce those numbers are reliable. We examine the accounting platform, the billing system, the inventory management tools, and any other system that feeds the general ledger. We look for gaps between what the system records and what the financial statements report.
We trace transactions from source to ledger, checking for manual adjustments, deleted records, and batch processes that run without oversight. We examine user permissions to see who can create, modify, or delete financial data. We review the integration between the operating systems and the accounting platform to confirm that data flows without manual rekeying. This analysis supports the work of the client's own accountants, who use our technical findings to inform their own procedures and conclusions. A separate page covers our forensic accounting analysis work in more depth.
This is not a substitute for financial due diligence. It is a complement. The client's licensed advisors remain responsible for forming their own opinions about the accuracy and completeness of the financial information. Our role is to provide the technical evidence that helps them do that work with greater confidence.
The work does not end at close. The technology must be transferred from the seller's environment to the buyer's, and it must continue to operate throughout the transition. We plan and execute technology transfers that minimise disruption to the business. Our post close technology transfer work is described on a separate page.
The transfer plan we produce during diligence becomes the blueprint for execution after close. We handle domain transfers, email migration, server provisioning, software licence transfers, and data migration. We coordinate with the seller's IT staff and the buyer's team to ensure that every system is handed over cleanly and that no data is lost. We also train the buyer's team on the systems they are inheriting, so they can operate them independently.
The transfer is typically completed within the first ninety days after close, though complex environments may take longer. We provide status reports throughout the process and escalate issues that threaten the timeline. The goal is a clean separation that leaves the buyer in full control of their new technology assets.
Lawless LLM is not a CPA firm, not an audit firm and not a law firm. We do not issue audit opinions and we do not provide legal, accounting, tax or investment advice. This work is data and systems analysis carried out to support your own licensed advisors, who remain responsible for the professional conclusions drawn from it.
Questions
Most reviews take between two and three weeks from the point we receive access to the target's systems and data room. The timeline depends on the complexity of the technology environment and the responsiveness of the seller's technical staff. We can accelerate the review for time sensitive deals by adding more engineers to the engagement, but there is a lower bound of roughly one week for even the simplest targets because we need time to conduct interviews, inspect systems, and write the findings memo.
Cost depends on the scope and complexity of the target. A small business with a handful of applications and a single server might require a week of work from one engineer. A larger target with multiple business units, custom software, and complex integrations might require a team of three or four engineers working for several weeks. We provide a fixed price quote after an initial scoping conversation. We do not charge by the hour and we do not bill for discovery work that does not produce useful findings.
Most private equity firms do not employ engineers who spend their days reading code, inspecting server configurations, and mapping integrations. Even firms with internal IT staff typically use them for portfolio company support, not for pre acquisition technical investigation. Our team does this work repeatedly across many deals, which means we know what to look for and how to find it quickly. We also bring the perspective of having seen what goes wrong after close when technical diligence was not done thoroughly.
It happens. Some sellers are reluctant to grant technical access before close, particularly in competitive processes. We can still do useful work with the information available in the data room and through interviews with the seller's technical staff. The findings memo will note where access was limited and what risks could not be assessed as a result. The buyer can then decide whether to make access a condition of closing or to price the residual risk into the deal.
No. We provide technical findings, not investment opinions. Our job is to give you and your licensed advisors the facts about the technology: what exists, what it costs, what risks it carries, and what it will take to separate it from the seller. The decision about whether to proceed with the transaction, and at what price, belongs to you and your investment committee. We do not hold professional licensure and we issue no professional opinions of any kind.
Related
Next step
Technical due diligence is not a box to tick. It is the process of understanding what you are buying before you own it and are responsible for it. A business that looks strong on paper can be hollowed out by technology problems that were invisible during diligence: a licence that cannot be transferred, a database that no one knows how to back up, an integration that breaks the moment the seller's IT staff stop maintaining it. Our job is to find those problems before they become yours, document them clearly, and give you a plan for fixing them. When the deal closes, you should know exactly what you own and what it will take to run it. Contact zach@lawlessllm.com to discuss a specific transaction or to understand how we scope a diligence engagement.
Start a conversation