If you're an IT practitioner today, there's one club you're nearly certain to become a member of: The "my software vendor has been acquired" club. It's not a question of if but when a piece of software in your company will play a starring role in some merger or acquisition.
According to Grant Thornton LLP, an advisory firm headquartered in Chicago, M&A activity in the software industry has risen steadily since 2003, and in 2005, software company mergers represented 16% of the total number of deals closed in the U.S. that year. (For the full study, click here.) Activity is especially strong in the Enterprise Resource Planning software market, which has shrunk from 400 players 10 years ago to approximately 20 full-suite vendors today, according to the firm.
And the trend shows no sign of abating. Grant Thornton claims that there's $63 billion in cash available for acquisitions on the combined balance sheets of Microsoft, Cisco, IBM, EMC, and Oracle. And there seem to be plenty of companies to choose from, as software companies with revenues less than $100 million find it increasingly difficult to make money, according to the firm.
Here are some tips, then, to prepare for the inevitable, and some additional resources to extend your understanding.
Consider Escrow Code
If your vendor is acquired, there's a possibility that the software you depend on will be retired, along with maintenance and support. But 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, I've encouraged people to look into putting the code into escrow as protection," says John Lakey, manager of the Acquity Group, a business and technology consultancy headquartered in Chicago.
Build Protections Into the Contract
There are other things you can do at contract time to protect yourself post-acquisition, says William Snyder, research vice president at Gartner, Inc. (For other tips on what to ask before you buy to mitigate your acquisition risk, click here.) Although the acquiring vendor must honor the terms of the existing contract, it can usually find plenty of room for interpretation and thus plenty of opportunity to turn things to its advantage.
For instance, contracts containing the terms "then-current pricing" or "then-current policy" are "a scourge to the customer base" when a merger occurs, Snyder says, because they effectively allow the acquiring vendor to change pricing and maintenance terms at its discretion. If you want to buy more copies of the software, for instance, "they can say, 'No problem, the price was $100 then, but now it's 10 times that,'" he says. To avoid that scenario, ask to hard-code the price into the contract or at least to base any price increases on an inflationary adjustment of the price list that existed at the time of the purchase.
The same goes for maintenance policies. Make sure you document in the contract all the maintenance entitlements and protection you've agreed to and specify that these will apply to all new versions of the software, Snyder says. Otherwise, you may end up having to abide by whatever new maintenance policies the vendor comes up with. (For more on the scourge of "then-current" phrasing, click here.)
Familiarize Yourself With Your Existing Contract
It's important to become well-versed in your contract exposures and strengths as soon as the acquisition occurs, Snyder says. One reason: All too often, customers who are ignorant of their current contract terms can end up over-paying when their vendor is acquired. For instance, the new vendor might automatically begin charging you its new 18% maintenance fee, even though your contract clearly states 15%. If you stuffed the contract in a closet and never looked at it again, the new percentage could easily be overlooked on the invoice.
Familiarity also prepares you for possible battle when you and the acquiring vendor disagree over contract terms, Snyder says. At that point, it's important to have your facts down cold, as victory tends to go to the party who can point to the most convincing contract clause. "There are very few things that are airtight in software licensing, but whoever has the most compelling business case that they're right on the terms and conditions is generally the one that prevails," he says.
Evaluate the Merger Type
Getting a handle on the future of your software application depends heavily on understanding why the vendor was bought in the first place. There are three basic reasons software vendors make acquisitions, according to Lou Mazzucchelli, a fellow at Cutter Consortium in Arlington, Mass., and each has different implications for customers. One is for the acquirer to gain access to new technology, which often results in increased investment in the application.
The second is to gain maintenance revenues from an older application with a large installed base, which means the software will stay alive but will probably not enjoy future investment in new bells and whistles.
The last reason is the most problematic for users, which is when the vendor is seeking to grow its customer base by buying a competitor. If your software is the one being acquired, don't expect it to be around for long. "There's no reason why the two applications would continue to coexist," Mazzucchelli says. Even if the acquirer keeps the application alive for a period of time, "that doesn't mean it will teach it new tricks," he explains.
Most likely, he says, the vendor will encourage you to transition to its own platform or to a new system that merges the best of both applications, along the lines of what Microsoft and Oracle are doing with many of their recent acquisitions. Either way, the migration or upgrade will likely be expensive and disruptive. (Click here for more on Oracle's strategy, here for more on Microsoft's approach.)
To keep the upper hand in these instances, it's best to be prepared to walk away, Mazzucchelli says, which is a problem for organizations that haven't considered how they'd function without that particular piece of software.
Clarify the Acquired Software's Importance
Before getting too anxious about the post-acquisition future of the application, you should evaluate how critical the software is to your organization, Lakey notes. For instance, which features of the application do you really use? How much value does it bring to your operations? How long have you licensed it? How much do you spend on maintenance and licensing? How well does it integrate with your other applications? How much would it cost to replace?
"It's good to have answers to these basic questions with an engagement plan laid out so you're not approaching the decision haphazardly," Lakey points out. For instance, if the application is already five years old when the acquisition occurs, you may automatically begin looking for a replacement instead of worrying too much about its future. Or if the application only weakly integrates with the rest of your systems, it may become important to look into the vendor's own integration plans.
"Their roadmap may represent future points of integration between tools you already have in your environment or that you'd like to incorporate," Lakey says.
Obtain a Product Road Map
If the application is still a critical part of your operations, you need to find out as much as you can about the acquiring vendor's plans for how long it expects to support the purchased application and whether it intends to subsume it or hollow it out as part of its own roadmap for the future.
To do this, Lakey suggests working with the application's user group or other companies you network with because it's not easy getting an audience with senior executives at the acquiring vendor. "Ask the vendor for a list of people using the software and attempt to congeal support for continuing to support the current application or for understanding the roadmap and future policies," Lakey says.
There's a high likelihood that this roadmap will hold future pain for companies that have grown to depend on the acquired software, Snyder says. "The vendor may make a complete architecture change, which might require the customer to rewrite integrations with other products," he says. "If that happens, the customer will have to understand how to make that conversion at some point in time."
It's not easy to face, but the longer lead time you have, the better off you'll be, Snyder says. "If the vendor doesn't come out with its plans, the analyst firms or Wall Street might be able to help shed light on things."
Don't Believe Everything You Hear
When talking with the vendor, it's important to realize that between the acquisition's announcement and its finalization, there's a period of limbo where the vendor really can't divulge its plans. "You have to take what they say with a very large grain of salt," Snyder says.
It's a time to gather as much information as you can, from as many sources as you can, and try to connect the dots, Mazzucchelli says. Sources might include your own investments division if you have one, other companies that use the vendors' products, research and analyst firms, user groups, news articles, and the sales forces and high-level executives at the companies involved in the merger. Important questions to ask include how likely it is that the merger will succeed, the benefits and losses to both companies, and what is likely to happen to product lines.