It just occurred to me that my recent quotes on Fierce Content Management make me sound like the Statler and Waldorf of the content management industry. I really don’t mean to sound so negative but, from where I sit, software company acquisitions are nearly always bad news. My clients are software customers and my job is to help them be better software customers by making better technology decisions. Mainstream software analysts, who are mainly speaking to the vendors, spin acquisitions in terms of what it means to competitors. They talk about how the acquisition changes the landscape and competitive dynamics. Mainstream analysts get pretty excited by mergers and acquisitions. It means that there is movement that needs to be understood and explained. It means that they get to re-answer the question that their software vendor and investor customers always ask “who is the best company in the market and why.”
The software customer has a different question: “which one of these products is the best for me right now and in the foreseeable future.” Market dominance plays a role but customers should be more concerned about their requirements and that the vendor will stick around and continue to focus on what matters to the customer. Customers should care less about who acquired who (today and yesterday) and about more who is at risk of getting acquired tomorrow. Acquisition adds uncertainty and risk that a customer would do best to avoid.
The dirty little secret about software company acquisitions is that, in most cases, they have nothing to do with technology. When one software company buys another, it is usually buying customers. Implicit in the transaction is the understanding that the customers are worth something and the acquiring company can more effectively make a profit from them.
An acquired CMS customer is valuable because switching costs are really high. To switch to another product, a customer would need to rebuild its web site, migrate its content, and retrain its people. Unless the product is totally doomed, the customer will probably stick around and pay support and maintenance for a for a while. The acquiring company can increase profitability by cutting down on product development, support, and sales. Most of these cut-backs directly affect the customer. The vision for the product will get cloudy. Enhancements will come out slower. Technical support and professional services will be less knowledgeable. Market-share will gradually decline. In some cases, the product will be totally retired in favor of an alternative offering by the same company. If there is an option of terminating support and maintenance, it is probably a good idea to exercise that option because the value of the service is likely to decline steadily.
The sad thing is that this dynamic is practically built into the traditional software company business model. A typical software company burns through investments to first build a product and then build a customer base. At a certain point, the growth trajectory will flatten (or decline) and investors will want to move their money into another growth opportunity. Some companies will be satisfied by having achieved a sustainable business. Others will cash out by being acquired. Others will look to grow by acquiring steady (but declining) revenue streams. The scariest companies to deal with are the acquiring companies — what I call “portfolio companies” that buy up products for their customers and then decide what to do with the technology. When you are a customer of one of these companies the future of the software you bought is vulnerable to the shifting attention of the vendor. If the vendor decides to keep the product around, it means they can successfully drain revenue from you. If the vendor gives you a “migration plan,” it means that they have another product that is in an earlier stage of the same destiny. Neither case is good.
Related posts:
- Woah! Intertonomy! While I was heads down working yesterday Autonomy announced...
- Vendor risk Back in 2004 (I still can’t believe that I...
- How to make the most out of a vendor demo After you watch a couple of vendor demos, it...
- The Importance of Vendor Neutrality I was just reading CMS Watch Commentary today and noticed...
- Vendor Demos Continued Following in the vein of Tony Byrne’s 10 Steps...


Fantastic article, Seth. Thank you for articulating this so clearly.
I’m sure you’d agree that there are other shades of grey: acquisitions where it’s more about acquiring complementary technology with the (sometimes misplaced) promise of tighter integration, or because the product lines had some correlation in the first place. However, I think you’re absolutely right that this is seldom the only or even main driver for acquisitions, which after all are usually about maximising shareholder value, not altruism towards the customers of either the acquirer or the acquisition.
Martin
Hear, hear.
This is why you should never use a CMS solution that is maintained and developed by a single vendor.
Good post, Seth. While I think that software acquisitions in our space are less about technology today, it wasn’t always so. Just a few short years ago, companies tried to round out their dossier of products. So for instance, Vignette had VCM yet acquired Epicentric for a portal play (became VAP). So too, Interwoven acquired MediaBin to round ou its DAM play. EMC/Documentum acquired a number of different technologies, including Bulldog, to also present at least a veneer of enterprise content management.
However, in varying degrees, most of these acquisitions failed and the original application had to be scrapped and rewritten (ex. Bulldog was totally scrapped and DCTM’s DAM was rebuilt by the EMC staff up in Toronto). Worse still, a few companies kept the products and just built these elaborate integrations with the legacy products.
In some cases, the companies didn’t even attempt to integrate the solutions. When OpenText acquired Artesia, for instance, they kept that group as a standalone unit – I don’t know that there was ever any attempt to integrate that product into the larger OT stack. You can be sure that OT did push their premium products downstream to the Artesia group though.
I don’t necessarily agree that a single vendor couldn’t manage an enterprise content management solution. However, I wholeheartedly DO agree that trying to integrate completely different code bases and different company resources and cultures is a recipe for a disaster. I’m not sure anyone has ever been successful doing it in our marketplace.
Good post. -JB
Great points Joe. Mergers 5+ years ago seemed to be more about building complementary suites of products. If this was the intention, it is now pretty clear that these deals were not put together by technical people who had any architectural vision. I doubt that the decision makers understood the technology of the products that they were acquiring or had a realistic plan to integrate them. Whether they earnestly tried or not, these companies were unsuccessful at assembling the solution that they claimed to be aiming at.
I think the strategy of the day was probably about keeping up with a changing marketplace and acquiring product categories that seemed hot. Vignette and Interwoven both felt that web publishing was running out of growth potential. They wanted to get into enterprise content management because selling a 100,000 seats for an intranet is a more lucrative deal that selling 40 seats to an internet publishing group. The customers paid the price because these acquisitions shifted these companies away from their core competency and the web publishing products stagnated. This is why Vignette and Interwoven both entirely missed web 2.0 and felt like an anchor to their customers who were competing against agile start-ups with more nimble technology.
recently @Christian_Burne tweeted that Open Text is where CMS go to die. I thought it was pretty funny. But it does raise some questions about what happens when CMS are acquired or when a company like Open Text has RedDot and acquires Vignette. Travis Cole had some interesting thoughts on an an Open Text Acquisition Roadmap.
Customers should demand portability in a vendor’s solution – how easy is it to export and import data? Do the tools already exist within the product that make the data and metadata portable?
One aspect of this is ensuring that media that is exported can contain as much metadata the customer wants from the host system. Either embedded in the native format, with XMP, or as an associate stream. At least this allows some of the context to carry with the media itself. So that it can reestablish itself in a new home.
This metadata rich approach allows for the data to be point of integration and interoperability rather than the aging system.
Thanks for the comment, Gunar. My experience is that content migration tends to be more complicated in document management systems because DMSs do not always have a way to export metadata. WCM migrations tend to be easier because the content is structured and the presentation tier can be used to produce XML representations of the content for import into another system.
In the WCMS world, the big migration cost is in developing presentation templates. Most WCMS have a built in presentation tier with its own tag library or syntax. When migrating, developers need to re-build the presentation on the new platform from the ground up. This, in itself is a lot of work. Even worse is when the business takes the opportunity to lob in a bunch of “while your in there” template changes. Before you know it, you have stumbled into an un-managed web redesign project that you didn’t sign up for. Without some serious product management discipline, things begin to unravel very quickly after that.
Great article, I saw the different stages for RedDot in so many places here. As well as Obtree and Gauss.
I have summarised the effects of the double buyout through the last 5 years of RedDot from a customer and partner point of view here: http://www.reddotcmsblog.com/why-the-acquisition-by-open-text-was-bad-for-reddot-cms
I would appreciate your thoughts on this article.
Regards,
Markus