On the day a large software company is bought, everyone has a verdict. It was brilliant, it was reckless, it was overpriced, it was a steal. Five years later, the same people have usually moved on, and the deal is either quietly folded into the business or quietly regretted. Yet that later point is when you can actually judge a software acquisition, because the story has had time to play out. The trouble is that most people do it badly.
Here is a method I find useful. It does not need inside information, just patience and a few honest questions.
Start with what the buyer said it wanted
Every acquisition arrives with a rationale: enter a new market, add a product, gain talent, remove a competitor, cut costs, secure technology. Find the original announcement and write down the stated goals in plain words. This is your yardstick. To judge a software acquisition fairly, use its own purpose as the yardstick, not whatever happened to look impressive later.
Be careful to separate the goals from the justification of the price. Many deals are explained as strategic, yet only make sense if the price was low enough. Both questions matter, and they should be kept apart.
Check whether the product survived and grew
Software acquisitions often succeed or fail on the product. Ask a few simple things. Is the acquired product still sold? Has it kept its name, or been merged into something else? Is it still updated, or does it feel abandoned? Are there new features that suggest investment?
A product that thrives often shows up in the buyer’s own marketing, integrated into its main offerings. One that quietly vanishes from the website probably did not deliver what was hoped. You can judge a software acquisition like this from outside, using public pages, release notes and customer reviews. Our article on why AI infrastructure firms buy software companies shows what buyers usually hope to gain from such moves.
Follow the customers and the people
Customers are the real asset in most software deals. Look for any public signs of whether they stayed: statements about customer counts, large clients still named, or complaints about changed pricing and support. A wave of customers leaving for competitors after an acquisition is a loud signal.
People matter just as much. Did the founders stay, and for how long? Did key engineers remain, or did they leave after their retention periods ended? Professional networks and public announcements can reveal a lot. When leadership turns over in the buyer itself, outcomes become harder to read, a theme covered in what governance changes mean when leadership turns over.
Compare with a fair alternative
This is the step people skip. To judge a software acquisition fairly, ask what the buyer would have done with the money otherwise. It could have built the capability itself, partnered, bought a different company or simply returned cash to shareholders. A deal that looks mediocre may still have been better than the alternatives, and a deal that looks successful may have cost more than building would have.
It is also worth asking what would have happened to the target. If it was failing, a rescue may count as a decent outcome even if the numbers look modest.
Traps when you judge a software acquisition
- Survivorship bias. We remember the famous successes and forget the many quiet disappointments, which skews our sense of how often deals work.
- Hindsight. Knowing the outcome makes it seem obvious. Ask what a reasonable person could have known at the time.
- Accounting noise. Companies sometimes write down the value of an acquisition, which can signal trouble, but write-downs also depend on accounting rules and timing.
- Attribution. If the buyer grew after the deal, was it because of the acquisition or despite it? Rising markets lift many boats.
- Moving goalposts. Buyers sometimes redefine success afterward. Hold them to the original statement.
Put it together into a scorecard
To judge a software acquisition with discipline, a simple scorecard helps. Rate the deal on goals met, product health, customers retained, people retained and cost versus alternatives. Give each a plain label: clearly yes, mixed, clearly no, unknown. If most are unknown, say so, because honest uncertainty beats a confident story.
For example, a company that bought a tool to enter a new market should see that market in its revenue and customer base within a few years. If it does, even a high price may look fair. If it does not, no amount of optimistic language rescues the deal. Anyone trying to judge a software acquisition should be ready to accept a mixed verdict. Revenue claims after a deal deserve their own scrutiny, as discussed in what $100M in recurring revenue really means.
Why the long view matters
Headlines reward quick judgments, but integration takes years. Contracts have to be renewed, systems merged and teams reorganized. By the time you can judge a software acquisition honestly, the news cycle has moved on. That is the point. The people who revisit old deals learn more than those who only react to new ones.
If you want to read about the wider subject, the Wikipedia article on mergers and acquisitions covers the common structures and motives. Then pick one old deal in your industry and apply the method. You will likely find the truth sits somewhere between the original hype and the later gloom, and that is the best reason to judge a software acquisition slowly.
