I recently wrote a guest post for a popular German M&A blog. You can see the post here:

http://blog.fredelia.com/2012/12/27/it-due-diligence-researching-the-target-company-prior-to-the-onsite-visit/

My last post was Why Investors Ignore IT Due Diligence, so I thought I would follow it up with some real-world examples of issues that a thorough IT due diligence effort can identify. I’ve personally encountered the issues below over the course of many transactions.

As usual, the acquiring or investing company is identified as AcquiringCo and the target company as TargetCo.

Software Licensing / Ownership Issues

• TargetCo had unlicensed business software that required a six-figure investment to correct
• TargetCo software had been developed by outside consultants with no work-for-hire agreement in place, putting the ownership of the source code into question
• An important TargetCo software product had no available source code (it had been lost during a network upgrade and there was no viable backup)
• TargetCo did not own its software. It was in fact owned by a competitor. The competitor had originally developed the software on a contract basis, and then gotten into the same business after seeing the success TargetCo had and realizing it still owned the software based on a poorly-written contract
• TargetCo had obtained the source code on which the company’s products were based through questionable means
• A licensor of software critical to TargetCo would not indicate approval of the transfer of the license to AcquiringCo until TargetCo was acquired. AcquiringCo didn’t want to acquire TargetCo if it couldn’t get the license

Staff Issues

• The architect of TargetCo’s software was on medical leave with no hope of returning
• TargetCo had no non-compete agreements in place with key employees
• A TargetCo employee with a terminal disease was kept on the payroll to provide medical benefits and TargetCo expected that employee to be transferred to AcquiringCo

Flat Out Lies

• TargetCo’s registered users and website traffic statistics were completely manufactured
• A senior TargetCo software developer had a resume full of inaccurate employment history and college degrees
• TargetCo’s sales PowerPoint presentation listed 25 customers as users of a newly-launched product. In reality, there were fewer than 5

General Deficiencies

• TargetCo had a complete lack of business / domain knowledge. The company received all product ideas from large customers
• Many cases of poorly written software that required a significant investment to address
• Company culture issues. Often, a small technology acquisition would prefer that AcquiringCo send an armored car with their money, have a bunch of software developers hop out of the back, carry the money inside and start working, and then be left alone by AcquiringCo. Spending some quality time in person at TargetCo can help to understand the personalities and expectations at TargetCo

Security / IT Infrastructure

• Data storage and access strategies were inappropriate for the relevant regulatory requirements for TargetCo’s industry. Worse yet, the TargetCo developers had never even heard of the regulations
• TargetCo’s data center was located in a building that had recently been subjected to a flood that reached 5 feet up the walls on the floor below
• A data center with a tarp over the server racks because of a persistent roof leak
• The owner of TargetCo personally owned a large amount of the computer hardware used in the data center, and leased it back to TargetCo at a significant profit

Not all of these identified issues led to the transaction being abandoned, but some did. In certain cases, the deal value or terms were changed. In every case where the transaction continued, the fact that IT due diligence had been performed allowed the investors to move forward with their eyes open to the challenges and potential costs they were facing.

A very thorough recent survey by Ernst & Young of C-level and private equity executives found that separate IT due diligence was performed in M&A transactions only about half the time. IT issues discovered in due diligence played into transaction negotiations less than 20% of the time.

Many of the survey respondents realized after the fact that more thorough (or any) IT due diligence could have helped to protect the value of the transaction.

So why do some investors ignore IT due diligence? In my experience there are several reasons.

Sometimes the deal is done before ANY due diligence starts. If there is a very strong CEO or a single shareholder in a private company, they want what they want. Even when legal and financial due diligence is performed, it’s not unusual that IT is brought in at the very end with the instruction of “don’t ruin this deal.” This situation has the highest potential to turn into a financial or integration disaster.

At other times, an investor or management team may be looking at an IT acquisition for the first time. Even if they have extensive experience as operators of non-tech companies, they may not understand the specific issues involved in technology M&A. Without the required expertise on staff, IT due diligence doesn’t even come into play. A related problem is that IT due diligence can have many subjective aspects, unlike accounting where things can be much more black and white. Unless they get lucky, this type of investor’s first deal is often a learning experience, and you can be sure that IT becomes part of the standard due diligence process going forward.

Some deals are simply done so quickly that no substantial IT due diligence can be performed. Think of recent “arranged marriages” among banks in the US. In many cases, a failing bank is shuttered on Friday night and opens for business under new ownership on Monday morning. In these cases, regulators can rely on laws and best practices to have at least a reasonable understanding of financial condition, but there is absolutely no IT due diligence of any kind performed. This happened to my personal bank over four years ago, and the IT systems are only now being slowly integrated. Who knows what the CIO of the acquiring bank found on that Monday morning.

In still other cases, some investors forego IT due diligence with their eyes open, or discount the findings even if IT due diligence is performed. As Dan Sweet said so well in a recent Quora discussion, “many are willing to forgo [technical robustness and platform stability] if the value creation and growth story is strong enough.” This can be very risky, but some experienced IT investors can make it work.

If a company is planning a merger of a competitor, there may be cultural issues at play that prevent IT from having a seat at the transaction table. IT may not be respected in an organization dominated by sales or finance. In other cases, the acquiring company may simply assume that their product is better, and that the target company’s customers can be easily converted to the acquiring company’s technology. In either situation, even if IT gets involved prior to the transaction closing, they may not be privy to the overall business goals of the transaction, and not have these in mind as they review the target company’s IT resources. Any of these examples can lead to high unforeseen costs, slow or no integration and buyer’s remorse.

Regardless of the reasons, IT due diligence is being ignored in many deals, usually to the detriment of the investor. Acquiring companies owe it to themselves to understand the benefits of IT due diligence, and to include it in their M&A transactions.

A due diligence review of a software company should include a source code review – it’s as simple as that. This article will explain why it’s important and will provide some resources to assist in locating an appropriate expert.

In this article, AcquiringCo is the company contemplating an acquisition of or investment in the target company, which we’ll call TargetCo.

What is Source Code?

Just to be sure we’re on the same page, source code is the set of computer programming language statements and commands that a software developer creates and that eventually becomes the program that a user, website or other system runs. How it gets from source code to the program differs by language, and is well beyond the scope of this article.

What is a Source Code Review?

A source code review involves retaining the services of an expert in the particular programming language in which TargetCo’s programs are written. The expert will typically meet with the TargetCo software developers and receive an overview of how the company’s programs work, what they are meant to do, etc. Then the reviewer is provided access to the source code for the programs as well as any infrastructure that may be required to run the programs.

The reviewer will then read through the source code to assess consistency of style, efficiency, etc. Afterwards the reviewer will typically provide a report with an opinion as to the quality and effectiveness of the source code.

If you are a VC or private equity firm, it’s unlikely that you have someone on staff with the level of expertise in a particular programming language required to perform an effective source code review. If you are a software company acquiring another, you may find that you do have someone on staff who is an expert, but you’ll need to decide if that person can provide a reliable and objective opinion, and keep it confidential while the transaction is underway. You may determine that even in this case, it’s more appropriate to engage a third party.

Why is a Source Code Review Critical?

Even though you see a program or website running, this doesn’t mean that the source code exists or is in the possession of TargetCo. The only copy of the source code may have walked out the door with a key developer that is no longer with the company. If TargetCo contracted for the program to be written, it’s possible that the source code wasn’t included or provided.

More than once on a due diligence project, I’ve come across programs or utilities with no source code available. In the 1990s, I experienced a large company still running a program written in 1969! Needless to say, that source code was long gone, along with any tools or systems needed to replicate it.

A program without the source code may very well continue to run, but the problem is that no changes can easily be made to the program. This isn’t a good situation to discover after the transaction has been completed.

Assuming the source code exists, the reviewer will spend a lot of time looking at several important issues. Possibly the most important is security. An expert in a particular programming language will understand the vulnerabilities that are possible in that language and how to identify them.

In addition, the reviewer will provide an assessment of the overall quality and consistency of the source code. Quality companies will have standards that all of their programmers are to follow when it comes to programming style and conventions. Programming often allows for a great deal of personal style and variety in approach. Having standards in place makes it easier for new employees to understand source code and for any programmer to pick up where another left off.

Understanding source code written by many people without standards in place can be like reading a book where the writing style changes on every page. It’s much harder than it needs to be and takes more time than it should. If your plan is to acquire TargetCo and integrate their products with your own, this work can be much more difficult with inconsistent source code or code written by amateur programmers.

The reviewer will also focus on the scalability of the source code. TargetCo’s products may work well on a single web server but require a significant rewrite to be run across ten servers in a web farm. The database may be “good enough” when there are ten users on a website but provide unacceptable performance when the there are one thousand.

The source code review will be able to determine if there are any third-party libraries or components required to create TargetCo’s programs. This should be covered separately in the IT due diligence process, but it’s a good second opinion on an important issue.

You’ll also get the reviewer’s opinion as to the quality of the software documentation. This includes both internal documents describing the software and systems and comments within the source code. Comments are notes coders make within the program to themselves and for the benefit of those who may be reading the source code in the future. Comments often explain how parts of a program work, and why certain coding choices were made. They can be very helpful when a programmer other than the original developer needs to modify the source code. Good programmers provide abundant comments. Uncommented source code is one sign of inexperienced software developers and/or products that were rushed to market.

Ideally, the source code review should include building the company’s software product from the source code and deploying it to a test environment to verify that all required functionality really exists in the source code. If this is attempted and not possible, you have a serious concern about how much of the software or technology that you saw in those PowerPoint slides actually exists.

Where to Find Source Code Reviewers

There are numerous software consulting companies that specialize in source code reviews for particular programming languages. You can find them via Google (I have no interest in or relationship with any of them). Try this link:

If AcquiringCo has a software development staff, they moght be helpful in identifying an expert to perform the source code review.

Finally, the due diligence legal team may have access to technology expert witnesses that could be utilized for the source code review.

Whichever solution you choose to identify the expert, it’s important to be certain that the reviewer is an expert on the particular programming language utilized by TargetCo and is not simply a general IT pro.

Conclusion

A source code review is a vital step to take during an IT due diligence effort. It’s the only way to really understand what you’re getting when you’re investing in or acquiring a software company.

Cloud computing is one of the most prevalent buzzwords in the IT industry right now. In fact, with the interest that the term is drawing, you’ll find many companies claiming to be using cloud computing when all they’re really doing is utilizing the same hosted / ASP / SaaS model that has been prevalent for well over a decade.

True cloud computing, at least in my book, is the use of providers such as Amazon Web Services. Microsoft, Citrix and Rackspace are also big players, and there are certainly many others. These services provide extremely scalable and elastic server and network resources and largely hide the actual infrastructure from their own customers.

For example, if a customer of a cloud service provider is planning a promotion on their website for the next week, they can log into an administrative console, spin up several more web servers, and add them to their web server farm to handle the additional load. They don’t need to have their hosting company provision another server, purchase new hardware, or even talk to anyone at the cloud provider. When the online promotion ends and the traffic returns to normal levels, the servers can be decommissioned at the command of the customer and billing for those servers stops.

True cloud computing adds a number of complexities to the IT due diligence process. While many of the same concerns that would exist if the cloud provider was a traditional hosting provider are still present, cloud computing presents some new challenges that will be explored.

This post is the first in a series of three. Part one will discuss the IT due diligence issues involved when an acquisition target (we’ll call it TargetCo) is a customer of a cloud computing provider, and offers their own services via a cloud platform. Part two will consider issues involved in due diligence related to TargetCo’s use of third party services, such as CRM or productivity applications, hosted by cloud providers. Finally, part three will address concerns when TargetCo is itself a cloud computing provider.

Introduction

The main IT due diligence goals when TargetCo offers its services via the cloud are to determine if the cloud is the appropriate means of delivery and if so, to verify that the current cloud provider and contract are adequate.

The pooled resources of a cloud computing provider are a source of many of the concerns around a company’s use of the cloud. The fact that as a customer you have little control of the details can introduce a number of potential problems.

Data Storage and Backup

One of the most important things to understand is, “how is the data stored?” Even though you spin up a database server and load it normally, you really have no way of knowing what the disk structure is. If your data requires a certain level of confidentiality, a cloud-based solution may not allow you to know exactly how it’s stored. Is the data comingled with that of other customers on the same disk? If a potential customer wants to know security details around data storage, how would TargetCo answer?

On a related note, if the TargetCo application requires security and encryption, how is this maintained? Does TargetCo have enough control over its virtual servers to properly configure SSL and data storage encryption?

As with traditional hosting providers, backups can be a big issue, and you’ll need to ask questions appropriate to TargetCo’s business and security needs. If your data can be comingled in live storage, what is the backup situation like? Is your data combined with other customers’? Are backups stored offsite? Do they occur automatically? If so, are all data types and locations backed up?

How are onsite and offsite backups protected? Does the answer meet your security needs? If you need a backup restored, what is the process to make that happen? If you terminate your contract with the cloud computing provider, can the provider certify that all copies of your data, including on backups, are destroyed? This can be a big concern with financial and healthcare data.

Security

You’ll want to know if there have there been any security breaches at the provider. If one occurs, will TargetCo be notified, even if the breach only affected other customers? You want to know about it if at all possible. In certain industries, you have to know in order to meet your own notification obligations. Breaches with major providers sometimes make the news, but no matter who TargetCo is with, it’s desirable to have such notifications specified in the contract.

A cloud provider will most likely be happy to explain physical security, at least at a high level of detail, but if at all possible it’s a good idea to see the vendor’s data center with your own eyes. This will never happen with larger providers, but if TargetCo is a large customer or the provider is a small / niche one, it might be possible and advisable.

You may find that TargetCo’s cloud vendor distributes its load and TargetCo’s data across the world in multiple data centers. Would TargetCo’s customers like their data to be stored on servers in a country with less stringent privacy rules? It’s important that you understand the geography of the cloud vendor’s servers.

Billing and Other Business Issues

Cloud provider billing can be handled in various ways. Some are time/processor-based, some are based on data transfer. Often, you can also prepay for a set amount of server resource at a lower per unit cost. In all cases, it’s important to have a system to track provisioned and running resources. In cloud computing, if you forget that you added a server to your web farm, you may keep paying for it until you remove it. Does the cloud provider offer a system to allow track your servers and other resources? If not, tools are generally available from third parties. Does TargetCo have one in place?

Depending on state laws, use of a cloud computing vendor may create nexus (an effective business presence in a state) and its related tax liabilities. TargetCo’s data may end up on servers in different states without its knowledge or desire. You should have legal, accounting and tax reviews performed as part of due diligence to determine the impact of the use of a specific cloud vendor.
Does TargetCo’s insurance policy cover cloud breaches / data loss? This is a new area of technology. Liability insurance tends to lag new IT practices, so it’s important that the coverage maintained by TargetCo be reviewed to see if the company is covered in the case of a negative event.

Uptime

Will the provider detail its uptime history? Microsoft’s Azure cloud computing platform had a significant outage in late February, 2012. Microsoft provided a very detailed and transparent explanation in this blog post.

While they’re to be lauded for the amount of information they provided about the outage, the discussion shines a light on how complicated cloud computing infrastructure can be. While even top providers can’t guarantee 100% uptime, you should expect a successful due diligence effort to justify the fact that TargetCo is receiving value for its cloud computing dollars, and that the resulting solution is more secure and stable than what TargetCo could have put together on its own for the same expense.

Contract Issues

In addition to the items already discussed, consider the following when reviewing TargetCo’s contact with the cloud vendor.
You’ll want to determine the level of client support offered by the cloud computing company. Is TagetCo’s business a 24/7 operation? Can someone on the IT staff pick up the phone and call a cloud vendor technical support rep at 3AM?

It should go without saying that the cloud computing provider should have no ownership in anything stored on their servers by TargetCo, and that the cloud vendor can’t resell TargetCo’s data, even in aggregate. Check the contract anyway – due diligence is all about verifying things that should go without saying.

If TargetCo is storing healthcare data with identifiable patient information, will the cloud computing provider sign a HIPAA Business Associates Agreement? If TargetCo processes credit card data, is the cloud provider PCI-compliant at the appropriate level for TargetCo? Consider the specific needs of TargetCo’s industry and be sure those needs are addressed in the contract.

Is there scheduled down time for maintenance? Do the TargetCo services need to be available 24/7? If so, you’ll need to determine if an appropriate level of redundancy within the existing cloud provider or across providers is possible and/or necessary. How much advance notice of scheduled maintenance will TargetCo receive? Is the notification direct or is it posted in a customer forum? Be sure TargetCo is guaranteed in the contract the notice its business requires.

Due Diligence Process

If TargetCo is utilizing the services of a small or local cloud computing provider, there are several common sense steps that should be taken. This should be done independently of input from TargetCo’s IT staff, as they most likely selected the vendor and may not be completely objective.

First, simply contact the provider as if you were a prospective customer. Do you get a good level of comfort in talking to them? Does the cloud vendor provide redundant sites? How many customers do they have? What is their disaster recovery plan? Have they passed any security or operational audits, such as SAS 70 or obtained industry-specific certifications? If so, request copies of the relevant audits and certification reports.

Next, get some references and check them. Find out what the cloud computing provider’s customers have to say. Finally, if you are left with serious concerns, review the contract with the cloud vendor to determine if you have any opportunity to cancel or modify the agreement in the event of an acquisition of TargetCo. You may also want to consider this as a cost saving measure if you’re rolling TargetCo into an organization that already utilizes the services of a different cloud computing company.

Conclusion

The bottom line of IT due diligence when TargetCo offers its services via cloud computing is to determine if the company is better off overall for its use of the cloud. Using the services of a cloud computing vendor involves a number of tradeoffs, and your IT due diligence effort must be focused on evaluating those tradeoffs.