Already weighing a move off Magnolia?
This page helps you decide whether to stay, decouple the front end, or replatform. If you want a senior team to plan and run the move — content, URLs, and SEO handled deliberately — see website migration services.
What Magnolia is — and why you’re probably here
Magnolia is a Java digital experience platform from a Swiss vendor, Magnolia International, and it has spent two decades in the same procurement processes as Adobe and Sitecore without ever being as large as either. Content lives in a Java Content Repository — the Jackrabbit implementation of the JCR standard. Templates render through FreeMarker. Configuration sits in YAML “light modules” that front-end developers can edit without a Java toolchain, while anything structural — integrations, custom logic, workflow — is Java and Maven.
The current 6.x line is hybrid rather than headless: editors work in a visual page editor over the repository, and the same content reaches external front ends through a REST delivery API and GraphQL. In 2026 the vendor’s framing has moved to an “agentic” DXP — governed AI agents running against the model you choose — layered over that same foundation.
Most visitors to a page like this already run Magnolia, and the question is whether it’s still the right home for the estate, or whether the delivery APIs are the way out.
Where Magnolia still fits
Java is the house language. If your platform team already runs JVM infrastructure and can staff Java work, Magnolia’s deep-integration story is real: it sits inside your existing services rather than beside them.
Data residency is a written requirement. DX Core is genuinely self-hosted, and the managed DX Cloud can be deployed to AWS, Azure, GCP, or a Swiss provider. With ISO 27001 and SOC 2 certification, SSO, and granular roles alongside it, that covers the requirements European procurement and regulated industries actually check — without the negotiation weight of the largest suites.
You genuinely need both a page editor and an API. Where marketers assemble campaign pages visually and product surfaces consume structured content over GraphQL, one system doing both is a legitimate answer rather than a fudge.
Behind all three sits a practical point: at this tier Magnolia is smaller, cheaper, and less ceremonial than AEM. Teams who priced the heaviest DXPs and flinched often landed here for good reasons.
Why teams migrate away
- The specialist pool is small — and it’s two pools. Light modules let front-end developers work, but everything structural needs a Java developer who also knows Magnolia. That combination is scarcer than Java alone.
- The repository is a page tree with structured content added later. Content apps and GraphQL model reusable content well enough, but the JCR heritage shows: multi-brand, multi-channel modeling works against the grain, and getting content back out at the end is a project of its own.
- Upgrades are projects, not patches. Major-version moves have to be coordinated across custom modules and integrations, and each one competes with roadmap work.
- Headless here is a delivery layer, not a change of model. Pointing a modern framework at REST or GraphQL genuinely improves the front end, but the authoring model, the license, and the Java dependence all stay — and that’s where the cost lives.
- The license floor is real for a website-only need. Starting prices are $3,500 a month for DX Core and $5,000 for DX Cloud, before implementation and operations. If Magnolia runs a marketing estate and nothing else, that’s a lot of platform for the job.
Stay or go — the short version
| Stay on Magnolia when | Move when |
|---|---|
 Your platform team runs Java and can staff Magnolia work without a partner on retainer |  Every structural change waits on a Java developer who also knows Magnolia |
| Self-hosting or a specific cloud region is a requirement you have to evidence | Residency is satisfied by a headless CMS with EU hosting and the right processing terms |
| Editors depend on the page editor and product surfaces consume the same content over the API | The page editor is the only part in real use — the delivery APIs were never adopted |
| Your install is on a current version and upgrades land without drama | You're facing a rebuild-scale upgrade anyway, so the destination is an open question |
| The license is proportionate to the brands, markets, and channels Magnolia runs | Magnolia runs the marketing website and little else |
The realistic paths off Magnolia
Keep Magnolia, decouple the front end
Adopt the delivery APIs properly, rebuild the front end on a modern framework, and leave authoring where it is. Editors keep their tooling, procurement keeps its vendor and its residency answer, and the delivery-speed win arrives quickly — while the license, the Java dependence, and the upgrade cycle all stay. It’s the right call when the Java estate or the residency rule is genuinely load-bearing, and it can buy several years.
Replatform to composable
Move the estate onto a headless CMS and a modern framework, and keep whatever Magnolia was integrating as standalone services. Going headless is what removes the license floor and the specialist bottleneck at the same time, and it consolidates brands and markets onto one shared platform editors can publish to without developers. The work is in the export: JCR content has to be mapped to a new model, assets moved, and every URL redirected. Content extraction from the repository takes longer than teams expect, and the SEO outcome depends on the redirect map being complete and tested before launch, not after.
Pricing, in plain terms
Magnolia is unusual among DXPs in publishing a starting price at all: DX Core (self-hosted) from $3,500 a month, DX Cloud (managed, on AWS, Azure, GCP, or a Swiss provider) from $5,000, with the real figure quoted against traffic, uptime commitments, multisite scope, and support tier. There is also a free Community Edition under GPLv3, but it’s deliberately limited — a single publishing receiver, no commercial support — so it’s an evaluation path rather than what a large estate runs.
Two costs sit outside that list price and usually dwarf it: the implementation, and the standing Java capacity to operate and upgrade the platform. Against a composable stack the honest comparison isn’t license to license — it’s the Magnolia license plus Java operations against a headless CMS subscription plus modern hosting, and most of the gap is people, not software.
The Bejamas take
Magnolia’s fork is narrower than AEM’s or Sitecore’s, which makes it easier to answer: is the Java estate — or the residency rule — actually load-bearing? When it is, staying is defensible, and decoupling the front end over Magnolia’s delivery APIs is a modernization we’re happy to run. When it isn’t, you’re paying for a Java platform and a Java staffing line to publish web pages, and a composable stack does that for less with editors who don’t queue behind developers. The same question runs through the DACH corporate web, where TYPO3 estates raise it in a more fragmented form. In an audit we map what actually depends on Magnolia, model staying versus moving, and recommend the path honestly — then, if it’s a migration, we plan and run it with the redirect map, content migration, and SEO controls treated as first-class work.