What typically takes place during the due diligence phase of an acquisition of a software company?

Question

What typically takes place during the due diligence phase of an acquisition of a software company?

I am in particular interested in how the value of the software assets is determined. What is the scope and nature of the technical documents that is reviewed? Is it common to examine the actual source code? the version control history (the comments or code history)?

If interviews are conducted, how far down the engineering organization do they typically proceed.

Obviously, a wide range of things could take place. I am wondering what Stackoverflow members have seen and what is viewed as common.

Answer 1

We recently considered an acquisition where I work and we went through several phases.

• Current financial review: we looked at sales, support contracts, investment funding, credit reports, outstanding credit, operating cost, pretty much everything you could imagine.
• Projected financial review: basically do we believe this product could make money (I mean, after all, if they're for sale then something must not be going well right?)
• Customer inquiry: who are the current customers, how many, can we support them, are there any conflicts of interest (do they sell to a major competitor.), etc.
• Business review: what were their goals, objective, intentions with the software? Do we plan on doing something different?

Our acquisition did not go beyond this point (we didn't feel like paying off their enormous debt, 8 VPs at a 31 person company) but we had planned:

• Code review: essentially a random sampling of the code to see what were getting ourselves into.
• Open work review: what are they working on right now, any promised features for customers, open bugs, etc.
• Employee review: interview key employees (especially those we were going to hire into our company to continue working on the product.)

In my experience both here and in other situations pretty much anything is on the table, especially as the purchase becomes more likely. If they are really desperate for a buy-out (ex. venture capital funded) you could have them running obstacle courses in the parking lot.

The only suggestion I have is - make sure some of the employees want to come work for you - especially the really good ones who will probably cost a lot of money. Ultimately, they will help you to succeed in getting the software to a better place.

Answer 2

This is a highly specialized field of study. Usually by this point the Cost Benefit Analysis is complete and the decision to aquire has been made. The due diligence phase focuses on the fact that the assets and company are in the state that was advertised. This step is similar to an audit. Claims have been made and documentation and proof of those claims should be provided. Each case is unique but some common analysis includes:

• Examination of Existing Contracts
• Review of Assets and Liabilities
• Legal Review of Liens
• Vitality Review of the Software Assets
• Verification of the Maturity of Company Processes

Software engineers will be most involved in the final two items. Auditors will be verifying the claims made during the earlier stages of aquisition. The auditors should provide a list of required documentation to management. The management should provide initial responses. Once this first round is completed the audiors should be allowed to verify the claims by asking management for a subject matter expert from each area.

Answer 3

I would have to say that it entirely depends on the purpose of the acquisition. Not every buy-out is for the same reasons.

• For example, you may want to buy out your competitor in order to reduce the competition and plan to EOL most of the products because they are redundant to yours. (Look at what Oracle is doing).

• Or, you may be interested in several key patents, copyrights, trademarks etc. and don't actually care about the code (or product) itself.

• Is the human resources the key factor behind the deal. Or will the company close shop and move the new business back to head quarters?

• Is it for immediate access to existing contracts, or maybe subsidies being received?

It can even be any or all of the above actually. Meaning that the actual documents (architectural/design) and code base 'may' have little to no value to a buyer.

Is it common to examine actual source code? the version control history (the comments or code history)?

Yes it is if the purpose of the acquisition has the objective (in part or in whole) of acquiring the code base. I have been through this process myself once. Some dude showed up at work and interviewed the CTO, architects, project managers and team leads. Then he got access to architectural documents for which he studied for a while and asked to see the code for various parts. This guy didn't care about the programmers at all (competence or expertize). For my modules, he ended up asking my boss instead (non technical), for which he got vague answers. I guess that suited him fine though.

So if your buying, make sure you know exactly what really matters to you. If your being bought, you will kind of get an idea what interests them from where they do the looking.

Answer 4

On this specific point:

If interviews are conducted, how far down the engineering organization do they typically proceed.

Any worthwhile due diligence of a software company would interview randomly chosen engineers.

Answer 5

I've been through this a few times, and talked to consultants like Construx, who help major technology firms with due diligence. Focusing on the code assets and the team (I am assuming you re the one being bought, not the buyer in this case):

• first, Intellectual Property risks need to be addressed. Who owns the IP, where did the ideas come from, who saw what with or without NDAs, what rights did the developers, contractors sign over? Is there anyone who could come back and say they contributed to the design or implementation? Skeletons in your closet? Have you done any patent reviews, or filed for patents? Same for trademarks. This will also include a review of third party software, open source licenses, etc. Be prepared to have all of this documented in detail.

• are they buying the software or the team? If they are more interested in getting their hands on the code, they are only going to care about interviewing and locking up the key designers, lead developers, the core senior team, for long enough to assimilate the technology, leverage the patents, whatever. If they want the team, random interviews as stated above would be a good idea, although whether the buyer has the time or resources to do this is another question.

• review of the architecture, and a walkthrough of key algorithms / design points, including some code - whatever the magic is that you are selling, make sure it is real.

• some basic code metrics at a minimum - code size, code complexity and code coverage (how scary is it going to be to maintain this stuff?)

• a review of your SDLC - assuming that they are buying the team and depending on you to continue doing what you are doing, then they want to know how you will do it. Otherwise they want to know how you got this far. If it's a big fish buying a startup, they won't expect too much from you, they will want to know just how much technical debt they might be inheriting, how much of a cultural change they/you may be facing.

Valuation is a whole other game: it's more about business value than the code itself.