Why customers are choosing to migrate from AEM to Magnolia
Aug. 7, 2024
--
Blog_AEMMIgration

Why customers are choosing to migrate from AEM to Magnolia

Starten Sie mit Magnolia

Unser Expertenteam zeigt Ihnen gerne, was Magnolia kann.

Jetzt Demo buchen

In this article, Priocept, a Magnolia Platinum Partner, takes an honest look at why some customers are choosing to migrate from Adobe Experience Manager (AEM) to Magnolia.

At Priocept, we’ve been helping clients navigate the evolving landscape of Content Management Systems (CMS) and Digital Experience Platforms (DXP) since 2004. Our first experience with AEM was when it was still in the hands of its founding Swiss company, Day Software, and was known as Day CQ. At the time, the product resonated with us due to its rich feature set and its sophisticated architecture, most notably its use of the Java Content Repository (JCR) for content storage, security, and versioning. In this respect, AEM is very similar to Magnolia, which partly explains why, over time, we came to embrace Magnolia over AEM. But this transition was also largely driven by the demands of our customers.

In this article, we explain the reasons why customers are moving away from AEM to alternatives and argue the case for Magnolia as a viable and more cost-effective replacement.

Reasons

We have seen enterprise organisations migrating from AEM to alternatives for various reasons. The most common of these are:

1. Cost

AEM is expensive.

AEM’s pricing model is very much tailored to the needs of the enterprise customer, and it therefore does not publish a set of standardized pricing information. Past customers have reported paying annual AEM and Adobe Marketing Cloud licensing fees that are well into high six-figure sums and sometimes even approach seven-figures.

With many other enterprise-grade CMS vendors offering license packages at circa £100,000 or less, it’s easy to see why a business case can easily be made to shift away from the prohibitive ongoing licensing costs of AEM, particularly for those businesses that are operating at the upper end of Adobe’s pricing.

It is arguable that to match the rich feature set of AEM, alternative competitive products will require significant customisation, integration, and development, but often once the numbers have been crunched, this approach still ends up being significantly more cost-effective.

Those customers who want to use on-premise licensing to run AEM on their own infrastructure seem to be most harshly penalised by AEM’s licensing model, which is calculated by taking into consideration both the number of users and the hosting infrastructure. In an auto-scaling, cloud-hosted environment for a big e-commerce store, for example, the costs can escalate quickly.

2. Complexity

Operating a multi-site, multi-region, multi-language digital presence at scale creates complexity and any CMS solution that can handle this complexity is also likely to be a complex system.

AEM can therefore be challenging to deploy and operate due to its excessive complexity in various areas:

  • Infrastructure - AEM combines several infrastructure-level and application-level functions into a single integrated package. This includes a web application server (if deployed in standalone mode), a web application framework, and a content repository. Managing and operating these components, while adhering to DevOps best practices, including automation of deployment pipelines and defining infrastructure and configuration as code, can be a challenging task.

  • Deployment - In AEM terminology, an “instance” is a copy of AEM running on a server. AEM installations usually involve at least two instances, typically running on separate servers: Author and Publish. Ensuring the synchronisation of content between these environments creates additional complexity, particularly in auto-scaling environments.

  • Customisation - AEM provides infrastructure and application-level building blocks to allow the creation of customized solutions. While this customization is a strength of AEM, it can also add complexity as organisations need to build and maintain their own applications. Customization can also break when upgrades are installed, requiring remediation work to ensure continuity of service.

  • Updates - Keeping an AEM system up-to-date can be challenging. For on-premise versions, upgrades are not always easily available and can incur additional licensing costs and take time to apply (and more cost if you are relying on an agency to make the updates). In other words, AEM deployed using the on-premise licensing model is great business for an agency as they are required to spend a significant amount of time upgrading and maintaining the system, but it can be bad for end users of the system who must contend with missing features, downtime while upgrades are applied, and spiralling maintenance costs.

It is worth noting that AEM as a Cloud Service can significantly reduce the complexity of managing and maintaining AEM. However, for organizations that require greater control over their infrastructure, careful planning and the right technical expertise will be essential.

3. Composability

Composability is the ability to assemble a DXP from a series of best-of-breed solutions. These solutions work together via APIs to deliver content and digital experiences to customers in a more agile and flexible way than a single, integrated, and essentially monolithic platform.

Composability allows enterprises to consolidate their entire marketing stack, including content management, marketing automation, e-commerce, personalization, and analytics. Rather than having to think of all of these tools as separate entities, they can be viewed as a group of DXP partners.

In some cases, the selection of AEM versus an alternative can come down to a decision on composability. AEM offers a suite of proprietary solutions for personalisation, marketing, analytics, asset management, and more. In isolation, none of these features is the market leader in any of their categories, but collectively, the overall solution offers a powerful and compelling platform that is seamlessly integrated.

However, for enterprises that already have a varied set of technologies in use across their organization and are looking to build a solution comprised of best-in-class software, an alternative CMS or DXP product may lend itself more readily to the demands of the existing ecosystem.

Migrate from Adobe Experience Manager (AEM) to Magnolia

Make the move from your legacy AEM suite to the more flexible, composable Magnolia digital experience platform (DXP).

Why Magnolia

Priocept is one of the longest-serving Magnolia partners in the UK, having delivered our first Magnolia implementation in 2011. Since then, we’ve worked with some of Magnolia’s biggest customers in Europe and the US, including those who decided to migrate from AEM to Magnolia.

As mentioned in the introduction, Magnolia has various similarities to AEM – it is developed using enterprise Java, uses JCR for persisting content, and has a similar set of features aimed at helping enterprise organizations to consolidate their digital estates on a central platform. But it differentiates itself distinctly from AEM on the principle of being a composable DXP. Magnolia’s core guiding design principle is to be part of a wider, multi-vendor ecosystem made up of best-of-breed software solutions. In contrast, AEM operates on the principle of being a unified solution that meets all the digital marketing needs of the enterprise. As with other monolithic platforms, this approach means that AEM has certain limitations. Users are subject to the constraints of the platform and may feel stuck using a one-size-fits-all solution.

In addition to the flexibility and capabilities that can be unlocked by following a composable approach, Magnolia also offers much lower licensing costs without compromising on features. In our experience, this is why so many enterprises have started to consider Magnolia as a savvy alternative to AEM.

Summary

The purpose of this article is not to bash AEM, which is a powerful tool for consolidating and managing an organisation’s digital estate. However, it is important to know that alternatives exist and why they might be considered as viable alternatives to the Gartner market leader.

Magnolia is architecturally similar to AEM, has a similar set of enterprise features, is significantly cheaper, and therefore, in our opinion, can be considered a safe and sensible alternative to AEM.

As with many things in life, the decision may come down to cost, and AEM can be prohibitive for all but the largest of enterprises, which are unashamedly AEM’s target market. For savvy firms looking to invest in the development of bespoke features that differentiate their business versus over-paying on software licensing costs, other solutions are available that have a comparable feature set to AEM but at a price point that can deliver far superior ROI.

Über den autor

Abhay Kumar

Head of Delivery, Priocept

Abhay is responsible for ensuring the effective delivery of all Priocept client projects. He works with clients to gain a deep understanding of their business domain and the technology landscape that supports it. He ensures consistent delivery by applying industry best practice to the project delivery process, whilst drawing on his technical background to shape and direct projects to a successful outcome. Before joining Priocept, Abhay worked for Accenture as a senior IT consultant and was assigned to work with a number of global organisations. He started his career as a software engineer working for the hedge fund Liberty Ermitage, followed by private equity firm Apax Partners, and later developed real-time trading systems at FidessaLatentZero.