How Infosys automates AEM to Magnolia DXP migrations

Enterprise organizations are migrating away from platforms like Adobe Experience Manager (AEM) primarily because the total cost of ownership no longer justifies the value they actually receive. Platforms like Magnolia DXP offer a composable, cost-efficient alternative that preserves flexibility without forcing companies to pay for capabilities they will never activate.

Nagarajan Kuppuswamy, Principal Technology Architect at Infosys, frames the decision in concrete terms:

Beyond licensing costs, structural problems drive enterprises toward migration. Many large organizations accumulate multiple CMS installations across regions and business units — AEM in one market, Drupal in another, FirstSpirit (CrownPeak) in a third — creating fragmented content operations that are expensive and difficult to maintain. The siloed digital asset management (DAM) that accompanies this fragmentation compounds the cost.

Magnolia DXP addresses these structural challenges through its composable architecture. The platform delivers a lower total cost of ownership, enterprise-grade Java support, strong headless support for content delivery to any channel, native DAM capabilities, and deep integration with third-party tools via APIs — including CDP, personalization, and commerce platforms. Infosys is a global systems integrator partner for Magnolia DXP, enabling it to deploy and configure the platform at enterprise scale across all of these dimensions.

The result: organizations paying a premium for legacy platforms can consolidate onto Magnolia DXP and redirect budget toward composable integrations that actually match their use cases.

Enterprise organizations recognize the pain of their legacy CMS — but fear the pain of migration even more. Three concerns consistently surface: will content be lost, how long will it take, and what will it cost to fix what breaks along the way.

The risk of content loss is real but manageable. The rich text fallback strategy is a data preservation approach that ensures no content is discarded during migration, even when the source content type has no direct equivalent in the target CMS.

When a content type defined in the source system has no identical equivalent in Magnolia DXP, the Infosys CMS Automigrator falls back to mapping that content into a rich text field, preserving it intact for later reuse or repurposing by the content team. As Nagarajan Kuppuswamy explains: 

The AI layer of the accelerator further reduces data loss risk by suggesting the nearest-fit content type mapping when an exact match is unavailable, so that even edge-case content lands somewhere meaningful rather than being dropped.

Two technical pitfalls account for a disproportionate share of migration failures: poorly defined asset taxonomies and conflating product data with CMS content.

Magnolia DXP's best-practice limit is fewer than 500 assets per folder. When source taxonomies group tens of thousands of assets into a single folder, performance degrades sharply after migration — authors experience slow load times and perceive the migration as a failure, even though the content arrived intact. Taxonomy must be redefined and validated before a single asset moves.

The second pitfall is using CMS as a Product Information Management (PIM) system. Magnolia DXP integrates with third-party PIM systems via APIs — that is the correct architectural pattern. CMS is designed to hold marketing content and static assets; product catalog data belongs in a dedicated PIM, exposed back to Magnolia DXP through APIs. Migrating PIM data wholesale into Magnolia DXP is a sure path to performance problems and post-migration rework.

Without tooling, a migration of significant scale can stretch across years. With the Infosys CMS Automigrator, the same migration compresses into months or weeks depending on whether the CMS is already onboarded into the migrator or not. The specific timeline depends on content volume, source system complexity, and the degree of component consolidation required — but the order-of-magnitude difference between manual and automated migration is consistent across engagements.

The Infosys CMS Automigrator is an AI-powered end-to-end migration accelerator that automates the full lifecycle of website migration — from asset extraction through content transformation, code migration, and automated page authoring — without requiring manual re-authoring of individual pages. The Infosys CMS Automigrator automates migrations from AEM to Magnolia DXP, covering all interdependent steps that traditional migration scripts address only in isolation.

A mapping sheet is a schema-alignment document that defines how each content type, field, and asset in the source CMS maps to its nearest equivalent in Magnolia DXP. It is the primary input to the Infosys CMS Automigrator — if the mapping sheet is incomplete or incorrect, the accelerator cannot produce a clean migration.

The mapping process is collaborative by design. The Infosys team works directly with business users and content owners to review every content-type mismatch, explain the trade-offs among available Magnolia DXP equivalents, and obtain sign-off on the chosen approach before any automated run begins. "As I keep telling Ravi and the team, we want to remove the word 'manual' from our vocabulary. We first create a mapping sheet, which is the input to the accelerator. If the mapping sheet is not right, the accelerator cannot work properly," said Nagarajan Kuppuswamy. This consultative step is what enables the automation to run reliably and without surprises.

The migration follows a strict sequence: assets first, then content, then code, and finally page authoring. The order is not arbitrary — each phase creates dependencies the next phase relies on.

Assets migrate first because taxonomy changes produce new URLs, and those new URLs must be embedded into content before content migration begins. The accelerator maintains a staging repository of all migrated asset references so the content migration phase can perform automated URL replacement within content item.

Content migration follows, applying template-to-content mapping and performing media replacement so that images, PDFs, and linked assets point to their new destinations. Code migration then handles template layouts and component definitions. Finally, page authoring is automated based on how pages were structured in the source system — components, content assignments, and publish states are replicated in Magnolia DXP without manual re-authoring.

Traditional migration scripts are deterministic and point-to-point — built for one source CMS and one destination, they cannot be reused across engagements without significant rewriting. The Infosys CMS Automigrator uses AI to generalize the transformation engine so that any source CMS can be onboarded with minimal configuration change.

The AI layer performs several validation and sanitization functions across every migration run:

The AI's role is to make the process faster and more reliable — not to lower the quality bar. As Ravi puts it:

Best practices for Magnolia DXP must still be followed in full.

Enterprise AEM installations accumulate components over years of development, often resulting in hundreds of overlapping or redundant definitions. The Infosys CMS Automigrator handles component consolidation as part of the transformation layer — splitting components that need to be decomposed, merging components that serve the same function, and restructuring the result to align with Magnolia DXP best practices.

This consolidation reduces ongoing maintenance burden and simplifies authoring in the target Magnolia DXP instance — directly supporting the ease-of-use and TCO benefits that motivated the migration.

Migrating content successfully is only half of the challenge. Content authors who have spent years in AEM need structured training on Magnolia DXP before they can operate effectively in the new environment — and that training must be grounded in the structural changes the migration actually introduced.

For example, the agrochemical engagement involved migrating FirstSpirit "entities" — a data type with no equivalent in Magnolia DXP — into Magnolia DXP content apps, then exposing them as headless APIs for the website to consume. Authors who worked with entities in FirstSpirit need a clear explanation of where that data now lives and how to manage it going forward.

Best practices cannot be retrofitted after go-live. If Magnolia DXP is handed over with incorrect taxonomy — for example, a folder containing tens of thousands of assets — the performance degradation authors experience will read as a product failure rather than a configuration error. Training and best-practice governance must therefore begin during the migration engagement, not after handover.

An AEM-to-Magnolia DXP migration succeeds or fails during the preparation phase, before a single asset is moved. The initial evaluation must address four dimensions.

Many AEM license agreements carry multi-year renewal terms. Organizations approaching a renewal decision have a defined window in which migration is most financially advantageous — before the next contract locks in another cycle of elevated licensing cost. Infosys's delivery record on a 125-website, 30,000-page migration, combined with Magnolia DXP's licensing model and composable architecture, means organizations can realistically complete a migration and demonstrate ROI within a single contract cycle.

As a global systems integrator and Magnolia DXP partner, Infosys brings both the tooling and the enterprise delivery experience to execute migrations at scale. Organizations that have already built on AEM, Drupal, or FirstSpirit can begin with the Infosys CMS Automigrator in its current configuration — Infosys does not rebuild the accelerator for each new client engagement. Configuration changes are sufficient to accommodate new source system customizations.

For more on how Magnolia DXP enables composable digital experiences, see Magnolia DXP features overview, pricing and licensing, customer stories, and composable DXP architecture.

Adobe, Adobe Experience Manager, and AEM are trademarks of Adobe Inc. Sitecore is a trademark of Sitecore Corporation A/S. Drupal is a trademark of Dries Buytaert. Magnolia DXP is not affiliated with, sponsored by, or endorsed by Adobe, Sitecore, or the Drupal project.