"Tech stack aligned" is the most dangerous line in a diligence report.

It reads like a green light. It's a statement about the nouns: language, database, servers. It says nothing about the decisions underneath them, and the decisions are what you're actually buying. Miss them, and the deal thesis carries a debt nobody priced.

The deal on paper

The target was a retail planning software company with a long reputation for doing what bigger vendors wouldn't. Its customers were complex, heavily SKU'd retailers, and it built them deeply customized features. It forecast every store in dollars or units, then turned those forecasts into unit-level allocation plans.

The algorithms were sophisticated and they worked. They looked great on a whiteboard. The stack was C#, SQL Server, and Windows Server, the same stack the acquirer ran. The price was right. The customer base was ripe for the acquirer's other products.

Every box on the checklist was checked. It was an M&A dream on paper.

What I found under the stack

I came in after the acquisition, because the integration was taking far too long. My first job was figuring out what the delay was and how it happened. That's where I learned what the diligence had missed.

The software was built to do something genuinely hard. It created dynamic hierarchies and could roll numbers up, down, and across them on demand. For its on-prem customers, the heavy processing ran overnight, with exception handling and manual tweaking during the day.

It was also built around a specific operational setup: a small staff, a handful of implementers, and lots of custom code for fewer than 50 clients.

And it was written in C# by long-tenured COBOL programmers. They knew how to speak C#. They didn't use what the language could do. The core allocation module alone was 100,000 lines of code, with dozens of goto statements. That's not a knock on the people. It's what happens when decades of skill in one language get carried into another.

Then there was the architecture. It was designed when database storage was extremely expensive. Retailers track style, color, and multidimensional sizes, by store, by hour. The data explodes just recording the basics. So the team engineered the database down to a tight size and did everything else on the fly: caching, real-time roll-ups, calls into a calculation library because every customer had its own math. It was slow, because all that processing happened at runtime. That was the trade.

The acquirer did the opposite. It precalculated every number overnight and stored it in fixed hierarchies, so nothing had to be computed when a user asked.

The target's design was an elegant, vastly impressive solution to a problem that no longer existed. In the 15 years since it was written, storage prices had collapsed and SQL engines had gotten orders of magnitude faster at calculating, sorting, and organizing. Same stack. Different data architecture, meaning how the data was stored. Different information architecture, meaning how it was organized and rolled up. Different code architecture, meaning how the logic was built. None of the three was a close match.

Both sides were right, and it didn't matter

The integration is where it came apart.

The acquiring team never saw that gap. They saw a calculation engine with performance "issues" and never took the time to understand why those issues existed.

The acquired team was angry that nobody had done real due diligence. They were right. But instead of learning the acquirer's structure and finding a path to align, they dug in. Everything came to loggerheads.

What should have been a 12-to-18-month integration turned into years of lingering resentment. The product kept a small, devout following. There was never a simple or straightforward way to bring it into the acquiring stack.

The cost showed up fast. Zero new customers for the first 18 months. Existing customers were pushed to replatform instead of upgrade, and that cost us two key accounts.

That's thesis debt: the deal's plan depends on something diligence never checked, and the bill comes due after close. The deal model priced cross-sell into a customer base. The cross-sell depended on an integration. The integration depended on an architecture nobody had looked at. The diligence report was right about every fact on it, and the plan stalled anyway.

This was a strategic acquisition. Every PE add-on to a platform company makes the same bet: buy the product, cross-sell the base, integrate onto the platform. The cross-sell is in the model before anyone has opened the code.

Start Monday

If you have a software or platform acquisition in diligence, or one that closed in the last two years and still isn't integrated, start these before the next board meeting.

  1. Ask what was expensive when it was built. Storage, compute, bandwidth, headcount. Every architecture is a bet on a constraint. If that constraint is gone, the design is optimizing for a world that isn't there anymore. Your technical lead should be able to name it in one sentence, and if it's gone, it goes straight into step 5.
  2. Open the core module. Not the architecture diagram. The code that does the thing you're paying for. Make sure you know who wrote it and why they wrote it that way: have your tech diligence team ask the target's head of engineering directly who built the core, what were they building before this, and why did they structure it this way. Goto statements in C# would have been a red flag on day one.

    Some of you are saying you don't get the code during an M&A. In many cases, you'd be right. But diligence can still cover the core aspects of the code: a walkthrough of the core module, a code scan, or a sample under NDA. And the who, why, and how questions cost nothing to ask.
  3. Count the customers who have their own code. Under 50 clients with custom calculations per client is a services business shaped like a software product. Have your integration lead budget every custom client as its own migration, not a configuration step.
  4. Architect Death Match. Two architects enter. One architecture leaves. Put the acquirer's architect and the target's architect in a room before close under your clean-team rules, or in week one after close if the seller won't agree to a pre-close session or the deal has already closed. Each explains why their design works the way it does, and "why is it slow" gets answered before anyone calls it a problem. The integration lead makes the call. The architecture that survives is the one that fits where the business is going, not the one that belongs to the bigger company, and both sides hear why. You want that fight while it's still a line in the model, not years of resentment.
  5. Price the integration on architecture match, not stack match. If the data and code architecture don't line up, the deal lead puts it in the model now: a replatform budget or a longer timeline, written into the thesis. Before close, that's leverage on price or structure. After close, it's re-baselining the integration plan and the synergy timing with the board before the miss shows up on its own. A 12-month integration plan built on a stack match is a guess.

The stack is what the report shows you. The architecture is what you'll be living with.