How to protect your interests when your software vendor is acquired

In today`s volatile ICT environment, it is only a question of time before the software vendor involved with any organisation is embroiled in some form of merger and/or acquisition.

According to Grant Thornton LLP, an advisory firm headquartered in Chicago, merger and acquisition activity in the software industry has risen steadily since 2003, and in 2005, software company mergers represented 16% of the total number of deals that were closed that year in the US.

Activity is especially strong in the ERP software market, which has shrunk from over 400 players 10 years ago to approximately 20 full-suite vendors today, according to the firm, and there are no signs that this trend is abating.

Grant Thornton claims that there is $63 billion in cash available for acquisitions on the combined balance sheets of Cisco, EMC, IBM, Microsoft and Oracle alone, and that there seem to be plenty of companies to choose from, as software companies with revenues less than $100 million turnover find it increasingly difficult to stay profitable.

"However, there are some ways to help prepare for the inevitable, and some additional resources available to extend your understanding," commented Riaan Jacobs, MD of South African Escrow Services. "Escrow code, for example, should be seriously considered.

"If your vendor is acquired, there`s a possibility that the software you depend on will be retired, along with its maintenance and support. However, you can protect yourself if, at contract time, you negotiate a source code escrow agreement. Many people argue that only 5% or fewer of companies have the ability or resources to actually make use of escrow code, but it really depends on how complicated the system is. If you`re dealing with a Web content management vendor or a utility add-on, for instance, I`ve encouraged people to look into putting the code into escrow as protection," continued Jacobs. "After all, end-users that have been relying on an acquired or merged vendor`s products for critical business functions and are now often left with unanswered questions such as:

* Will the new owner continue to move the product along the same path, providing support and upgrades?
* Will the product be discontinued in favour of the acquiring company`s technology?
* Will customers be forced to move to a new platform or database?
* Will the product be allowed to survive, but limp along in an IT purgatory, with only a minimum of support and attention from the provider?
* What will be the fallout in product pricing and maintenance costs?
* How will the morale of vendor representatives affect service levels?

No relationship with a vendor - no matter how large, well regarded, and financially stable - is without such risks, IT executives point out.

"There are two risks that you take when you purchase any new technology," continued Jacobs. "The first risk is whether you will face a lot of rework if the vendor is bought out by a company you don`t do business with - or if the vendor goes under. The second risk is if the vendor is bought out by a company that takes it in a different direction than why you bought the product in the first place."

While changes in vendor ownership are difficult to predict, IT executives need not be caught off guard. The most effective way to survive and thrive through a software vendor change of ownership is being prepared beforehand, and asking the right questions in the wake of a merger or acquisition announcement, according to sources.

This requires an informed grasp of existing contracts with current vendors, and doing homework on the financial situations and technology roadmaps of potential or renewing vendors. In addition, close communications is the best tool - before, during, and after an ownership change.

Safeguards need to be embedded in contracts up front, in the form of change of control provisions that are intended to ensure a continuation of product support if ownership changes, as well as provide an opportunity for the carrier to renegotiate for assurance from the acquiring party that they won`t stop supporting the product.

Industry executives point to two vital safeguards to assure the ability to maintain a software product through any merger or acquisition scenario: access to source code and adherence to standards.

In many contracts, the product`s source code is placed in escrow, usually to ensure the customer will be able to maintain the software if the vendor goes out of business. But many experts say this practice can also safeguard IT investments against a major shift in business, such as a merger or acquisition.

While it`s not common practice to escrow source code for this purpose, it would enable the customer to take advantage of third-party services for software maintenance, a company can support itself if it has source code, and thus, it`s not at the mercy of a product change or a strategy change in the event of an acquisition.

"Although the situations highlighted above are more prevalent overseas," concluded Jacobs, "the current acquisition of Business Connexion by Telkom SA could well create some of the scenarios mentioned above."

For further information, please contact Riaan Jacobs at telephone +27 12 654 0610; fax +27 12 654 0590; e-mail info@saes.co.za.