What Adobe Experience Manager Actually Costs (and When to Leave)

Adobe does not publish a price for Experience Manager. That is not an oversight. It is the first thing you should understand about what it costs, because a product priced by negotiation is a product priced by what the seller thinks you can pay.

We build on Drupal and WordPress, so read the rest with that in mind. But we have also spent enough time inside organisations running AEM to know that the licence is rarely the number that hurts, and that most of the people asking this question have already been quoted — they are trying to work out whether the quote is sane.

Why there is no price list

AEM is sold as part of Adobe Experience Cloud, through enterprise agreements negotiated per customer. What you pay depends on which modules you take (Sites, Assets, Forms), how many authors and environments you need, your traffic, your contract length, and how badly Adobe wants the logo.

Two consequences follow. First, any figure you read online — including ranges quoted confidently by agencies — is somebody else’s deal, not yours. Second, the negotiation is genuinely asymmetric: Adobe knows what comparable organisations pay and you do not.

So rather than invent a number, here is the structure of the cost. Price out these four lines against your own quote and you will know quickly whether it is reasonable.

The four costs, in ascending order of surprise

1. The licence. Annual, six figures for most organisations that end up on AEM, and the only number anyone mentions in the board meeting. It is also the number you have the least control over after year one, because renewal negotiations happen when switching is already expensive.

2. Implementation. Routinely larger than the first year’s licence, sometimes several times larger. AEM is not software you configure; it is a platform you build on. Components, templates, workflows and integrations are all custom development, and the specialist rate for AEM developers is high because the talent pool is small.

3. The team you have to keep. This is the one that gets underestimated, because it never appears as a line item. AEM needs people who know AEM — not Java developers, AEM developers. If they leave, replacing them is slow and expensive, and in the meantime nobody can safely change your website. Budget for this as a permanent operating cost, not a project cost.

4. The cost of the things you stop doing. The hardest to quantify and often the largest. When a content change requires a developer, a ticket and a release window, teams stop making content changes. The marketing site calcifies. That is a real cost, it just never shows up on an invoice.

If your quote covers line 1 and waves at line 2, it is not a quote. It is an opening position.

What you are actually buying

It is worth being fair about this, because the case against AEM is usually made by people selling the alternative.

AEM is a genuinely capable enterprise platform. The Java stack underneath it — a JCR content repository on Apache Oak, Sling for request handling, OSGi for modularity — is built for very large content estates with complicated governance. The authoring experience for structured, reusable content is strong. Content Fragments and Experience Fragments solve real problems for organisations publishing the same content across many channels and locales. The Dispatcher caching layer, configured properly, is fast.

And if you are already deep in Adobe Experience Cloud — Analytics, Target, Campaign — the integration is not marketing copy. It works, and rebuilding it elsewhere is a serious project.

None of that is in dispute. The question is whether you are using it.

The four situations where AEM earns its price

Genuine multi-brand, multi-locale scale. Not “we have a French site”. Dozens of brands or markets sharing a content model, where a change to a component has to propagate consistently everywhere. This is the problem AEM was built for and it solves it well.

Editorial governance at scale. Hundreds of authors, real approval chains, per-field permissions, full audit trails, and regulatory consequences if the wrong thing publishes. Drupal does workflow well; AEM does it at a scale and granularity that very large organisations sometimes need.

Deep Adobe Experience Cloud investment. If personalisation through Target and measurement through Analytics are load-bearing for your business — not aspirations in a slide deck — the integration cost of leaving is real and should be counted.

Digital asset management as the primary job. AEM Assets is a strong DAM. If your actual problem is managing hundreds of thousands of assets with metadata, renditions and rights management, and the website is secondary, that changes the calculation.

If you did not recognise your organisation in at least one of those, keep reading.

The renewal that funds software nobody uses

The pattern we see most often looks like this. AEM was bought three to five years ago, during a transformation programme, by people who have since moved on. The implementation partner delivered and left. The internal AEM specialists were gradually lost to other projects or other employers.

What remains is a platform that only two people understand, a marketing team that raises tickets instead of editing pages, a content model built for requirements that changed two reorganisations ago, and a renewal notice.

The honest test is not “is AEM good software”. It is: which of the four capabilities above are you actually exercising this quarter? Open your own instance and look. How many authors logged in last month? How many workflows have more than one step? How many Content Fragments are reused anywhere? If the answers are small numbers, you are paying enterprise licensing for a very expensive brochure site.

What leaving actually involves

If you conclude AEM is no longer earning its cost, be equally clear-eyed about the exit. Migrating off AEM is harder than migrating off WordPress or Joomla, and anyone who tells you otherwise has not done it.

The content moves, with effort. Content in the JCR repository is structured and exportable — as packages, or through the HTTP API, or by walking the node tree. This is more tractable than a database full of page-builder markup. Content Fragments in particular map cleanly onto Drupal entities with fields, because both are properly structured content rather than blobs of HTML.

The components do not move. Every AEM component is Java, HTL templates, Sling Models and dialog definitions. None of that has any meaning outside AEM. Each one is rebuilt — as a Drupal field group, paragraph type, or Layout Builder block. If you have two hundred components, you have two hundred small rebuild decisions, and the honest first question for most of them is whether anyone still uses it.

Workflows are re-expressed, not ported. AEM workflow models become Drupal Content Moderation states and transitions. The concepts map; the implementations do not.

The Dispatcher goes away and something replaces it. Drupal’s caching is different, not worse, but the performance architecture is rebuilt rather than translated. Plan for a proper caching design rather than assuming parity on day one.

The integrations are the real scope. Analytics, Target, Campaign, single sign-on, DAM, translation vendors, commerce. Inventory every one before scoping anything, because this list — not the content — is what determines whether the project is six months or eighteen.

What leaving costs

Less than the implementation you already paid for, and more than a website redesign. The shape is predictable: content migration is a minority of the effort, component rebuild is the bulk, and integrations are the variable that decides the timeline.

The saving is not only the licence. It is the specialist team you no longer have to retain, and the return of the ability to change your own website without a release.

The cost nobody quotes is the year you spend doing it. If your organisation cannot commit to that, staying on AEM and using it properly is a better outcome than a migration that stalls at sixty per cent — which is a genuinely bad place to be, paying for both platforms at once.

So should you leave?

Do the audit before the arithmetic. Count the authors, the workflows, the reused fragments, the locales. If AEM is doing the four things it is good at, keep it and get better at using it — most underused AEM instances are an adoption failure, not a software failure, and re-training is far cheaper than re-platforming.

If it is doing none of them, you are renewing out of inertia and switching costs. That is a real reason to delay, but it is not a reason to renew forever. The cost of leaving only goes up while you wait, because every year adds another layer of custom components nobody remembers commissioning.

And if you are still in the evaluation stage, reading this before you sign: ask the vendor to price lines two, three and four alongside the licence. The answer, or the reluctance to give one, will tell you most of what you need to know.

Gspikes builds and maintains Drupal platforms, and we have told organisations to keep AEM when the audit said they were using it. If you want an honest read on whether your instance is earning its renewal, send us the details and we will tell you what we find. More on how we approach this on our Drupal development page, and the same logic applied to smaller platforms in our WordPress to Drupal guide and Joomla migration guide.