Leitfaden: Von AEM zu Magnolia DXP wechseln

Der Wechsel von Adobe Experience Manager (AEM) zu Magnolia ist ein strukturiertes Projekt mit bekanntem Ablauf. Beide Plattformen speichern Inhalte in einem Java Content Repository (JCR), daher lässt sich der Großteil der Inhalte per Skript migrieren. Die eigentliche Arbeit steckt in Komponenten, Templates und Integrationen.

Dieser Leitfaden richtet sich an Teams, die Magnolia evaluieren und vor einer Entscheidung wissen möchten, was eine Migration umfasst. Er behandelt:

Der Leitfaden geht von einem AEM-Sites-Bestand aus, der auf dem Seiten- und Komponentenmodell basiert. Liegen Teile Ihrer Inhalte außerhalb des Repositorys, legt die Discovery dafür einen eigenen Extraktionsweg fest.

AEM und Magnolia teilen eine Basis aus Java und JCR. Genau das macht eine weitgehend automatisierte Content-Migration möglich. Konzepte, die Ihr Team bereits kennt, haben eine direkte Entsprechung.

Beide Plattformen basieren auf einem JCR, modellieren Inhalte und Rendering aber unterschiedlich. In diese Unterschiede fließt der Migrationsaufwand, und für jeden gibt es ein bekanntes Mapping.

Von Projekt zu Projekt unterschiedlich ist, wie viel kundenspezifische Logik auf diesen Strukturen aufsetzt. Genau das misst die Discovery.

Jedes AEM-Artefakt eines typischen Sites-Projekts hat ein Ziel in Magnolia. Dieses Mapping steuert die Migrationsskripte, damit dieselbe Eingabe immer dasselbe Ergebnis liefert.

Manches lässt sich nicht automatisch abbilden: kundenspezifische Java-Services, Workflows und Integrationscode. Die Discovery listet jeden dieser Punkte auf und entscheidet, ob er neu gebaut, durch eine Magnolia-Funktion ersetzt oder stillgelegt wird.

Die Umstellungsstrategie legt fest, wann Traffic und Redaktion von AEM zu Magnolia wechseln. Die entscheidende Frage ist einfach: Kann Ihre Redaktion Inhaltsänderungen für ein festgelegtes Zeitfenster pausieren – und für welchen Teil des Bestands?

AEM bedient weiterhin den gesamten Traffic und bleibt Redaktionsplattform, bis der komplette Bestand in Magnolia bereitsteht. Vor dem Go-live endet die Pflege in AEM. Dieser Freeze schafft eine feste inhaltliche Basis.

Im Freeze-Zeitfenster migriert das Team die letzten Inhaltsänderungen, validiert die migrierten Inhalte und kritische Funktionen und führt die vereinbarten Go/No-go-Prüfungen durch. Danach wechseln Traffic und Redaktion in einer koordinierten Umstellung zu Magnolia.

Die Migration läuft in Wellen, jeweils ein Mandant (Site, Markt oder Geschäftsbereich) nach dem anderen. Jeder Mandant wird einzeln migriert, validiert und umgestellt. Nur der Mandant in seinem Umstellungsfenster pausiert; alle anderen pflegen wie gewohnt in AEM.

Ist überhaupt kein Freeze akzeptabel, auch nicht pro Mandant, laufen beide Plattformen parallel und die Redaktion pflegt jede Änderung in beiden. Das erhöht den redaktionellen Aufwand und das Fehlerrisiko. Beschränken Sie diese Phase auf einen kurzen, kontrollierten Zeitraum mit schriftlich festgelegten Redaktionsabläufen.

Bei jedem Bestand, der über eine Handvoll Seiten hinausgeht, migrieren Sie zuerst Komponenten und Templates, danach die Seiten. Sobald die Zielstruktur validiert ist, wird die Seitenmigration im Wesentlichen zu einer Datenmigration, die sich skalieren lässt.

Das funktioniert wie eine Datenbankmigration: erst Schema und Beziehungen anlegen, dann die Zeilen laden.

1. Komponenten- und Seiten-Templates migrieren. Plattformweite Komponenten zuerst, da die meisten Mandanten sie nutzen. Mandantenspezifische Komponenten folgen.
2. Jede Komponente einmal validieren. Felder, Dialoge, Rendering und visuelle Übereinstimmung mit der Quelle prüfen.
3. Das validierte Muster wiederverwenden – für jede Instanz dieser Komponente im gesamten Bestand. Sonderfälle und spezielle Anforderungen prüfen weiterhin Menschen.
4. Seiten gesammelt laden – auf Basis der validierten Struktur.

Ein Vorgehen Seite für Seite ist nur für einen kleinen Proof of Concept sinnvoll. Im großen Maßstab entsteht doppelter Aufwand, weil verschiedene Personen dieselbe Komponente auf unterschiedlichen Seiten lösen.

Für die Validierung gilt dieselbe Logik. Niemand muss jede Seite prüfen. Prüfungen auf Template-Ebene plus Stichproben decken den Bestand ab; wie tief die Stichproben gehen, bestimmen die Anforderungen Ihres Projekts.

Eine Migration durchläuft vier Phasen. Die technische Arbeit in der Umsetzungsphase folgt einem festen Ablauf aus vier Schritten, der sich in jeder Welle wiederholt.

Die Discovery findet einmal statt. Umsetzung, Validierung und Go-live wiederholen sich in jeder Welle; Hypercare folgt auf den letzten Go-live.

Das Team analysiert Ihre AEM-Umgebung: Architektur, Inhaltsstruktur, Integrationen, Anpassungen und Abhängigkeiten. Skripte und KI-gestützte Analyse beschleunigen die Inventur; Fachleute bewerten sie. Das Ergebnis sind vereinbarter Umfang, Wellenstruktur, Zeitplan, Rollen, Kosten und Erfolgskriterien.

Die Wellen beginnen meist mit einem Pilotmarkt oder einer Pilot-Site. Jede weitere Welle baut auf dem auf, was frühere Wellen validiert haben. Innerhalb jeder Welle folgt die Arbeit vier Schritten:

1. Inventur. Jedes AEM-Artefakt erfassen (Komponenten, Templates, Content Fragment Models, Experience Fragments, Assets, Tags) und seinem Magnolia-Ziel zuordnen.
2. Aufbau. Komponenten und Seiten-Templates in Light Modules generieren, um die Grundmuster festzulegen. Danach Content Types und Content Apps aufbauen.
3. Migration. Inhalte in der Reihenfolge ihrer Abhängigkeiten migrieren: Tags, dann Assets mit Binärdateien und Metadaten, dann Content Fragments und Experience Fragments, dann den gesamten Seitenbaum mit Komponenten und Live-Copy-Beziehungen.
4. Prüfung. Referenzlinks aktualisieren, externe Integrationen wie Analytics, CRM und PIM neu anbinden und QA durchführen.

Technisch ist Schritt 3 eine ETL-Pipeline (Extract, Transform, Load):

Führen Sie die erste Migration und Validierung in einer niedrigeren Umgebung durch und übertragen Sie validierte Inhalte dann in die höheren Umgebungen.

Jede Welle durchläuft QA, Funktionstests und Inhaltsprüfungen durch Ihre eigene Redaktion. Danach führt Magnolia einen Pre-go-live-Check durch. Nichts geht live, bevor es die vereinbarten Kriterien erfüllt und freigegeben ist.

Nach dem letzten Go-live bleibt das Delivery-Team für eine vereinbarte Hypercare-Phase an Bord, überwacht die Performance und behebt Fehler. Sobald alles stabil läuft, befähigt ein strukturierter Wissenstransfer Ihr Team, Magnolia eigenständig zu betreiben.

Manche Migrationen sind nach etwa sechs Monaten abgeschlossen. Größere Bestände brauchen mehr Wellen; den Zeitplan für Ihren Bestand bestätigt die Discovery.

Die Migration selbst läuft als deterministische, wiederholbare Skripte. KI unterstützt Menschen bei Analyse und Verfeinerung, bleibt aber aus den Skripten heraus, die Ihre Inhalte migrieren.

Der Grund ist Reproduzierbarkeit. Migrationen laufen mehrfach: Generalproben, Delta-Läufe vor der Umstellung, Korrekturen nach einer Mapping-Änderung. Jeder Lauf muss aus derselben Eingabe dasselbe Ergebnis liefern. Drei Ansätze wurden abgewogen:

In der Praxis teilt sich die Arbeit so auf:

Für die meisten Evaluierungen sind zwei Folgen wichtig. Erstens: Der Massenimport der Inhalte läuft nicht durch ein KI-Modell. Zweitens: Die KI-gestützte Verfeinerung ist optional – die Migration funktioniert also auch, wenn Ihre Richtlinien den Einsatz von KI einschränken.

Bei einer toolgestützten Migration sind Seiten günstig – die Arbeit steckt in den Komponenten. Seiten werden in skriptgesteuerten Batches geladen, sobald ihre Komponenten validiert sind, und jede validierte Komponente wird für alle Instanzen im Bestand wiederverwendet. Der Aufwand richtet sich daher nach Anzahl und Komplexität Ihrer Komponenten, nicht nach der Seitenzahl.

Dafür brauchen Sie keine Faustregeln. Das Migrations-Toolkit enthält einen Estimator, der Ihren AEM-Bestand vor der Entscheidung scannt; die Discovery macht daraus einen vereinbarten Umfang, einen Wellenplan und ein Budget. Der meiste Aufwand fällt an vorhersehbaren Stellen an.

Die wichtigsten Aufwandstreiber sind:

Wenn Sie diese Fragen vor der Discovery beantworten, wird sie kürzer und die Schätzung genauer.

Sie können eine Migration mit Ihrem eigenen Team, mit einem Partner oder mit Magnolia umsetzen. Wenn Magnolia die Verantwortung übernehmen soll, deckt das Migrationsprogramm Magnolia Navigator den gesamten Weg von der Discovery bis zur Übergabe ab.

Bei Magnolia Navigator führen ein namentlich benannter Delivery Lead und ein Team mit Erfahrung in AEM und Magnolia die vier Phasen dieses Leitfadens durch. Umfang und Investition werden in der Discovery vereinbart und wachsen nicht ohne Ihre Freigabe. Nach dem Go-live bereiten Hypercare und ein strukturierter Wissenstransfer Ihr Team auf den Betrieb von Magnolia vor; danach stehen Ihnen Magnolia Professional Services und SLA-basierter Support weiter zur Verfügung. Gemischte Teams mit Ihren Entwicklern oder einem Partner sind möglich.

Nächster Schritt: Sprechen Sie mit einem Migrationsexperten, um Ihre Migration zu planen, oder lesen Sie den Vergleich Magnolia vs. Adobe Experience Manager.

Adobe und Adobe Experience Manager sind eingetragene Marken oder Marken von Adobe in den USA und/oder anderen Ländern. Aussagen zu AEM in diesem Leitfaden basieren auf der öffentlichen Dokumentation von Adobe, abgerufen am 27. Oktober 2026: