Negotiating the Purchase of SaaS Company Assets: Key Problems to Anticipate in any Deal

In light of the popularity of the SaaS model of doing business, it is not uncommon to come across deals in which one software company is buying a third party company’s SaaS assets.  While there are many reasons to be wary of these types of deals, regardless of what side of the transaction you are on,  it has been my experience that the parties tend to be in a hurry to close the deal and rarely take the time necessary to contemplate the issues that should be considered in connection with the acquisition.

So, what are some of the issues that an acquiring software company should be concerned about in a SaaS company asset acquisition?

First and foremost, if the acquiring software company seeks to acquire the code comprising the SaaS product, then the company needs to verify that the target SaaS company actually owns the code comprising the software product.  It has been my experience that entrepreneurs and companies of all sizes frequently overlook this issue and make significant investments in software development without first obtaining the appropriate rights in the products to be developed.  I receive at least a few calls each month from C-level executives whose companies have developed a software product using outside developers without the appropriate contracts in place and call me after a dispute arises over ownership of the code in the product.  If a problem is identified with the code to be acquired, it should be addressed before the acquisition talks are ever commenced, since once a negotiation begins, it will be much more difficult to procure the necessary rights in the code.

Second of all, if the acquiring software company seeks to acquire the SaaS company’s customers as part of the deal, then the acquiring company needs to verify that the customers are actually bound by subscription agreements that are automatically assignable in the event of an acquisition.  Where the customers to be assigned are enterprise-level relationships, the acquiring software company also needs to verify the quality of the contracts in place.  In general, SaaS company customer contracts are very poorly drafted and do not include the key terms of the business relationship, which will be of particular concern in cases where the transfer of a particular customer relationship or group of relationships is essential to the deal.  Again, if the customer contracts are deemed to be insufficient, then this is a problem that should be resolved in advance of the commencement of acquisition talks.

Third, if the acquiring software company seeks to acquire the hosted software platform as part of the deal and not just the code comprising the software, then the acquiring company needs to verify the terms of the relationship in place with the target company’s host, assuming the target company is relying on a third party host as is typical in the industry.  What kind of contract is in place with the host and is it automatically assignable to an acquiring company?  Are the terms of the service level agreement governing the relationship sufficient to operate the software platform without service failures and without breaches of the customer contracts in effect?  If the host is handling personal health information for the SaaS company, is there an appropriate business associate agreement in place that complies with HIPAA?  It has been my experience that most SaaS companies do rely on a third party host for the software platform, and that a significant portion of those companies do not have an appropriate contract in place with the host to provide the expected hosting services that could be assigned to the acquiring company as part of a deal.  If a the contract with the host is identified as inadequate, then this is a problem that should again be resolved in advance of the commencement of any acquisition talks with the target.

Fourth, since SaaS products are by their very nature “service” offerings rather than simply code, an acquiring software company may very well seek to acquire the SaaS company workers necessary to provide the services.  In any such case, the acquiring company needs to verify that these worker relationships are in fact employment relationships that can be transferred to a successor company as opposed to contractor relationships that may not be transferable to the acquiring company and/or that may pose worker misclassification problems for the acquiring company.  Where a problem exists, the acquiring company may want the SaaS company to address the issues in advance of the commencement of negotiations.  In general, it has been my experience that SaaS companies are relying largely on independent contractors to provide services for their SaaS platforms, so encountering issues with any acquisition of a SaaS company workforce is to be expected.

The bottom line is that many of the SaaS company assets that an acquiring software company will seek to acquire as part of a SaaS company asset purchase will be accompanied by a certain amount of problems–problems that the acquiring software company may prefer to resolve in advance of any deal discussions rather than as part of the usual, time-sensitive, deal discussions.  Anticipating the problems that are likely to be present with a target company’s assets before commencing negotiations can help to ensure a smoother negotiation as well as a smoother transition once the deal is closed.

Print Friendly, PDF & Email