Setting the Record Straight on the Total Cost of Adobe AEM vs Drupal
by Tom Wentworth
As Drupal begins to compete more often with Adobe Experience Manager (AEM) in enterprise web content management selections, I'm coming across a set of common objections coming from prospects after they speak with Adobe. We’ve been told by multiple customers that Adobe had an “unbiased partner” create a total-cost-of-ownership (TCO) document to compare Adobe AEM vs. Drupal.
The TCO document claims a typical Drupal project costs nearly 70% more than Adobe AEM, with example 3 years costs of approximately $2.4m for Adobe AEM and $4m for Drupal. I’ve read the document, and the total cost of ownership calculation makes hugely incorrect assumptions about Drupal in the areas of hardware cost and infrastructure, implementation cost, and support.
For TL;DR people, here’s my takeaway:
Adobe’s sales team is feeling the impact of Drupal more than ever, and is resorting to desperate and reckless tactics which undermine the credibility of everything they tell prospects about Drupal and Acquia.
If you'd like to learn more, read on!
This section of the Adobe TCO document lists out the hardware components needed to run Drupal and Adobe sites e.g. front-end servers and databases. The main argument is that Drupal requires additional database servers, software licenses, and support, while Adobe does not.
Adobe AEM is built on the CRX repository, a standards-based Java Content Repository which came to Adobe via its Day Software acquisition. The CRX repository comes with the AEM application, and does not require a separate license. It's a slick architecture, and it’s one of the reasons that Adobe does well against legacy proprietary web content management companies like Oracle and SDL Tridion who require expensive database licenses and hardware.
But Adobe seems to think the same is true of Drupal. That is, that Drupal requires over $100,000 of database software licenses and support to achieve what Adobe provides for free with CRX. But Drupal runs on the LAMP stack, which like CRX, is also free. And when companies work with Acquia, we provide support for all application components, including the database, so there is no need for separate database support.
Not surprisingly, the TCO document completely ignores the cloud, because this is an obvious weakness for Adobe. Ironic, given Adobe AEM lives under the “Marketing Cloud” Adobe brand. While Adobe AEM can certainly be deployed in the cloud in places like Rackspace and Amazon, and Adobe does offer some management tools for deploying sites, they don’t support the site itself. For example, what happens when your AEM site breaks because of a bad code deploy? Acquia provides total application assurance in the form of supporting the entire digital lifecycle of the project - from development through testing through production.
When you consider the total cost to provide complete assurance of your Adobe AEM site, the costs skyrocket compared to what you get with an Acquia Cloud subscription and Drupal.
This section of the TCO document compares the total implementation cost of AEM vs. Drupal, across different implementation roles including project management, development, and QA. According to the TCO document, building a “typical” Drupal site costs more than 2x as much as Adobe AEM. Of course, there’s no such thing as a typical implementation of Drupal, Adobe AEM, or any web content management product. The scope of each project varies wildly based on the complexity of the requirements.
The additional costs of a Drupal implementation supposedly come from Drupal’s lack of base product features which require lots of custom development, including multi-site management, mobile support, personalization, and dynamic content. Check the links for case studies which hit on each of those supposed limitations in Drupal. And of course there is no mention of the over 20,000 Drupal modules and distributions freely available from the Drupal community, which greatly help companies speed time-to-web and lower custom development costs.
Generally, I think Adobe AEM projects tend to be significantly more expensive, as Adobe targets the largest companies with the biggest budgets. In fact, according to this video from Adobe’s partner day (which I found on their YouTube page, but has since been taken down), the average implementation cost for AEM is 3 times the size of the license, which means the total cost for an AEM implementation usually approaches over $2,000,000 as their average license cost is around $450,000.
While it’s dangerous to make broad statements about “average implementations,” because no such thing exists and every project is unique, certainly the total implementation cost for most Drupal sites is far less than AEM. Why? Customers who evaluate Drupal vs. Adobe AEM head-to-head quickly see that Adobe’s complex page-based architecture drives complexity, which is poorly-suited to the needs of modern, content-centric sites. With Adobe, every feature must be implemented from scratch. Adobe AEM is a complex Java stack, including JCR, Apache Sling, Felix, Maven and the AEM framework itself.
There’s just no way Adobe can make a broad statement about the so-called “typical” implementation costs of AEM vs. Drupal. Every web project is unique, and I suspect in most cases Drupal costs far less to implement due to the availability of over 20,000 Drupal modules and Drupal distributions, the availability and cost of Drupal developers, and the relative simplicity of the Drupal architecture vs. AEM. But really, the only way to know for sure is to work with the vendor, or your implementation partner, on a specific statement-of-work for your project.
In the TCO document, Adobe claims that Drupal support costs are high, mainly due to upgrades, product quality, and resources required to support the Drupal once the site goes live. In fairness to Adobe, this was the section where Drupal costs were only ~10% higher. The primary difference in support costs comes from upgradability.
Upgrades in any content management system can be easy, or hard, depending upon the amount of customization and underlying changes to the platform. This is not a problem unique to Drupal. In fact, Day Software had this same challenge moving customers from Day Communique 4 to CQ5 not so long ago…
But to be fair, the upgrade process for Drupal between major releases always involves work: APIs change, platform architecture advances, features move from contrib to Drupal core. Drupal will never break your content, but its commitment to a modern architecture means that Drupal is willing to break some components to ensure the platform is modern and relevant, and eliminate unnecessary bloatware associated with rote adherence to backwards compatibility. But upgrades are about to get a whole lot easier in Drupal 8, which now includes a migration path from both Drupal 6 and 7 to Drupal 8, due to release later in the year. This is a huge milestone for Drupal, and will smooth the upgrade process for customers going forward. Thanks to my Acquia colleagues + others in the Drupal community who contributed to this improvement in Drupal 8.
Adobe seems unwilling to do the hard work it takes to articulate their competitive advantages over Drupal, instead taking the lazy approach of letting a partner produce a wildly inaccurate TCO comparison based on the perception that it was unbiased, when it was clearly engineered by Adobe to tell a story that simply isn’t true.
Truthfully, both Drupal and Adobe AEM are great products, but each has strengths and weaknesses which require proper consideration before making a selection. You’ll live with your new web content management system for many years, so selecting the wrong one for the wrong reasons could setback your digital strategy for many years. I’d hate for companies to eliminate Drupal because of the wild inaccuracies found in this TCO document. Our approach when competing against Adobe AEM, is to encourage customers to directly evaluate each product against their use cases.
If you’d like to take a closer look at what Acquia and Drupal can do for you, I’d suggest starting with a product demonstration.