Technology due diligence and integration after an acquisition

The situation

An acquisition comes with a technology stack nobody on the buyer's side has seen. The people who built it may have left, the documentation is thin or missing, and the systems carry costs, dependencies and risks that don't show up in the financials. The acquirer needs to know what it actually bought, what it costs to run, and how to fold it into its own architecture without breaking the business it paid for.

What I do

• Reverse-engineer the inherited systems. Read the code, the infrastructure and the data, and work out how the platform really works, including the parts nobody remembers building.
• Document it. The architecture, the functionality, the dependencies (internal and external) and the running costs, written for both the executives and the engineers.
• Assess the risk. Security and data protection: how customer data is stored, who can reach it, the vulnerabilities and leaked secrets in the code, and what a breach would trigger under privacy law. Compliance and regulation: the obligations the systems carry in the target's industry, and whether they're met. Research where the answer isn't in the code: vendors, contracts, the market the product sits in.
• Check what you actually own. The intellectual property and its licences: who wrote the code and under what terms, the open-source licences it depends on, and the vendor contracts, lock-ins and renewals that come with it.
• Find the single points of failure. The people only one engineer understands, the system with no backups or disaster recovery, the monitoring nobody watches. Key-person risk is often the largest technology risk in a small acquisition.
• Recommend a path. What to modernise, what to consolidate with the acquirer's own systems, what to retire, and in what order, with the costs and risks of each step.
• Integrate. Align the inherited technology with the acquirer's architecture, reduce its complexity and find the savings.

The first engagement is complete. The second, a full assessment and integration of another acquired business, is under way.

Why I'm good at this

This is where every part of my career meets: the enterprise systems of my early career, the rescue of a stalled platform, the legacy modernisations and the cost reductions. I've spent years understanding systems I didn't write, quickly. AI agents now make the reverse-engineering itself much faster: they read a codebase end to end in hours, and I verify what they find.

Why it matters to you

If you're buying a company, or have just bought one, you need someone who can tell the board in plain language what the technology is worth, what it costs and what it will take to integrate, and who can then do the integration. That's one person, not a hand-off between a consultancy and an engineering team.