A founder recently told me about the last stretch of his company's sale. Technical diligence had gone well. Good answers, no nasty surprises. Then someone from the buyer's integration team joined a call for the first time and asked: "If we sign next month, how do we bring your customers onto our platform?"
It took most of a day to answer, and the answer wasn't pretty. Logins ran on a homegrown system that wouldn't connect to the buyer's identity platform, so every enterprise account would have to be moved by hand. Usage data lived in a database shared with another product that wasn't part of the deal. Billing depended on an export only one engineer really understood. None of it was broken. It just couldn't be connected to anything else without a project nobody had planned. The integration estimate tripled, and the buyer lowered the price to cover it.
Two questions, not one
For 27 editions we've treated diligence as a risk question: what could go wrong, and what will it cost to fix? A buyer who plans to bring you into their systems quietly asks a second one: what will it cost to make you part of us?
You rarely see that estimate, but it ends up in the price, in money held back at closing, or in a longer transition period.
To be fair, not every exit looks like this. Many acquirers leave the company running mostly on its own. But when integration is the plan, it's the most demanding diligence there is, and preparing for it makes every other exit easier.
What helps, long before anyone asks
Most of this is ordinary hygiene. If your risk register (Edition 1) is a living document, you've already started.
Know who owns the code. A buyer pays for the code, so they want proof the company owns it. Employees are usually covered by their contracts and often by law. The gaps are freelancers, agencies, and code the founders wrote before the company existed. Without a signed contract transferring those rights, ownership is unclear. I'm not a lawyer, but this comes up more often than you'd think, and it's easier to fix while everyone is still reachable. Open source is the other half. Your SBOM (Edition 16) usually records each component's licence, and a buyer will check that none of them obliges you to publish your own code.
Try the hard parts once. Move a group of test users onto another identity provider, and export customer data at realistic volume and check the result (Edition 17). Every step you haven't tried means a longer dual-run after close.
Read your contracts. Some vendor and customer contracts change when the owner changes: a vendor may raise prices, a customer may leave. Better to know which ones before the buyer's lawyers point them out. Start with your vendor register (Edition 9).
Keep a one-page exit-readiness canvas. List the systems and data stores that would have to move or be separated. For each one, note who owns it today, who could step in if that person leaves (Edition 26), the main dependency, when it was last tested, and the next step. Update it when a key vendor, contract, or engineer changes. With it, an integration lead can turn each line into a task without starting from scratch.
How the stage changes things
Early on, nobody expects a canvas. Just avoid sharing what you may later have to separate: one (or actually three) cloud account per product, standard single sign-on, one owner per dataset. By growth stage, walk the canvas once a year with the people who would do the work, or ask an experienced adviser to play the buyer for a day, and fix what you find as normal work. Once talks start, name one person on your side who owns integration questions, so the buyer always knows whom to ask.
Signs it will take longer than you hope
- The data room is put together from scratch after an offer is on the table
- Core parts of the product were built by freelancers or an agency, and nobody can find the contract that transfers the rights
- Nobody has ever moved realistic data volumes or a test group of users out of the current setup
- Contracts haven't been checked for change-of-control terms
- Critical systems have one owner and no deputy
One of these is usually manageable. Several tend to mean a lower price, or part of the purchase price held back until the issues are fixed.
A few terms
- Dual-run: The period when old and new systems run side by side while users and data are migrated.
- Change-of-control clause: Contract terms that let the other party renegotiate or terminate when the company changes owner.
Your turn
Have you been through an exit or an acquisition? What surprised you most on the integration side? Share it, it helps the founders who haven't been there yet.
How ready are you, really? Each month I do a few free 30-minute calls where I play the buyer's integration lead and ask the questions they would ask. Founders and CTOs can bring their own company. Investors can bring a portfolio company that might be sold in the next few years. Either way, you'll leave knowing which answers are still missing. Book one.
Next in the Playbook
Edition 29 looks at R&D Efficiency and ROI: how to judge engineering productivity without falling for vanity metrics. Stay tuned!
Originally published on the Tech Due Diligence Playbook newsletter on LinkedIn.