Erprobt und Risikofrei die Wege von Magnolia zu Adobe Experience Manager (AEM)

Eine erfolgreiche Migration basiert auf einem klaren Verständnis der technischen Beziehung zwischen AEM und Magnolia. Obwohl sie sich in ihrem Ansatz unterscheiden, sind es ihre gemeinsamen Grundlagen, die eine strukturierte Migration möglich machen.

Der Migrationspfad ist deutlich risikoärmer, da beide Plattformen auf einem gemeinsamen Java-Erbe aufbauen:

Das Verständnis der Unterschiede in ihrer Architektur ist der Schlüssel zur Gestaltung Ihrer neuen, flexibleren Umgebung in Magnolia.

Jede Projektumsetzung und jede Betriebsarchitektur ist einzigartig. Bei einer Migration gibt es daher keine Einheitslösung für alle also kein „One fit’s All". Sie sollte stets auf der Grundlage Ihrer bestehenden Geschäfts- und Betriebs KPIs basieren. Dabei haben sich zwei verschieden Strategien hervorgehoben welche Sie als „Best Practise“ wählen können- jede dieser Strategien ist darauf ausgelegt, Ihnen maximale Effizienz entsprechend Ihren Geschäfts- und IT-Zielen zu bieten.
 

Bei dieser Strategie werden Ihre AEM-Komponenten und -Vorlagen nativ in Magnolia neu erstellt, um Ihre gesamte Komponentenarchitektur mit Magnolias Light Development-Prinzipien zu modernisieren. Mit Light Development können Seitenvorlagen, Komponenten, Dialogdefinitionen, Themes und Styling sowie einige Integrationen mit Front-End-Technologien durchgeführt werden, wodurch Magnolia für Ihre Front-End-Entwickler zugänglicher wird und die Entwicklung ohne schwergewichtige Java-Builds beschleunigt wird. KI-Tools wie Claude und Gemini können Ihre Kosten und die Zeit bis zur Markteinführung im Vergleich zu traditionellen, vollständig manuellen Ansätzen drastisch reduzieren.

AEM-Komponentenstrukturen (dialog.xml, HTL-Skripte) werden in ihre Magnolia-Äquivalente übersetzt (YAML-Definitionen, FreeMarker-Vorlagen oder komplette Headless-Ansätze). Dies ist eine Gelegenheit, Ihre Komponentenbibliothek zu konsolidieren und technische Schulden zu beseitigen.

Für diesen Weg ist ein automatisiertes Tool wie der Migration Accelerator die empfohlene Vorgehensweise. Es ersetzt monatelange benutzerdefinierte Skripterstellung durch einen schnellen, konfigurationsbasierten Workflow. Das Tool nutzt eine KI-gestützte Schnittstelle, um Inhalte aus den alten AEM-Seiten direkt in Ihre neuen Magnolia-Komponenten zu übertragen, wobei die Datenumwandlung und -bereinigung automatisch erfolgt.

Unternehmen, die eine komplette architektonische Erneuerung wünschen, das moderne Entwicklungsmodell von Magnolia vollständig übernehmen wollen und deren Priorität die Geschwindigkeit und Vorhersehbarkeit des Migrationsprojekts ist.

Bereiten Sie die neue Umgebung und die CI/CD-Prozesse vor der Entwicklung oder Migration vor.

Diese Strategie ist für Unternehmen gedacht, deren primäres Ziel es ist, die AEM-Lizenzkosten zu eliminieren und gleichzeitig 100 % ihrer vorhandenen AEM-Inhalte und -Komponenten wiederzuverwenden. Die weitere Entwicklung wird dann auf einem erneuerten Stack fortgesetzt.

Bei diesem Ansatz verbindet die Magnolia CMS-Authoring-Schnittstelle mit der Open-Source-Laufzeitumgebung Apache Sling. Ihre vorhandenen AEM-Komponenten und -Inhalte werden auf dieser kompatiblen Laufzeitumgebung ausgeführt, während ein benutzerdefinierter Integrationsadapter es der modernen Benutzeroberfläche von Magnolia ermöglicht, sie nahtlos zu bearbeiten und darzustellen. Der Adapter wandelt AEM-Dialoge dynamisch um und fügt die erforderlichen Metadaten ein, damit Magnolias Editor funktioniert. Außerdem liefert er die fehlenden Teile in Apache Sling im Vergleich zu einem vollständigen AEM-Produkt. In diesem Szenario gibt es keine "Inhaltsmigration", da der JCR von beiden Systemen gemeinsam genutzt wird. Dieser Ansatz bietet ein voll funktionsfähiges, produktionsbereites Setup für bestehende Inhalte, Komponenten und Code.

Und ermöglicht so einen Parallel-Betrieb beider Applikationen und einen nahtlosen Übergang von veralteter Technologie hin zu einer neuen flexiblen und effizienten Applikationsarchitektur. Risiken werden hierbei maximal minimiert da stehts eine fall-back Ebene zur Verfügung steht. Für die Redaktion erfolgt der Übergang in der Nutzung des bestehenden Systems zur neuen Applikation ohne aufwändige Trainings quasi „on the job“.

Es wird kein Tool zur Migration von Inhalten benötigt. Der gesamte Aufwand konzentriert sich auf die einmalige Entwicklung des Integrationsadapters.

Unter der Haube basiert AEM auf dem Open-Source-Framework Apache Sling. Alle Kernfunktionen für Java Runtime (OSGI Container), Java Content Repository (JCR Jackrabbit), Component Rendering (Sling Resources) und Content Package Management (FileVault) sind in Apache Sling enthalten. Dieses Framework kann als Erweiterung in das Magnolia CMS eingebettet werden, und zwar völlig unabhängig von einer AEM-Instanz und vor allem ohne die Notwendigkeit einer AEM-Lizenz. Daher ist es möglich, bestehenden Code, Komponenten und Content-Pakete ohne Änderungen und ohne die Notwendigkeit einer Komponenten-/Inhaltsmigration wiederzuverwenden.

Natürlich deckt Apache Sling nicht alle Funktionen ab, die das AEM-Produkt bietet. Am wichtigsten ist, dass es keine Unterstützung für das Authoring gibt. Dies wird durch den "Integration Adapter" abgedeckt, der die Magnolia-Authoring-Erfahrung mit dem Apache Sling-Komponenten-Rendering verbindet. Während für Standard-AEM-Dialogdefinitionen die Dialogtransformation dynamisch durchgeführt werden kann, gibt es möglicherweise benutzerdefinierte Dialogerweiterungen im Projekt, die individuell angepasst werden müssen. Um Migrationsaufwand zu vermeiden, kann der Integrationsadapter so angepasst werden, dass die speziellen Anforderungen des Projekts bereits im Integrationsadapter selbst berücksichtigt werden.

Große Unternehmen mit einem umfangreichen, standardisierten AEM-Komponenten-Ökosystem, bei denen ein Umbau zum Zeitpunkt der Entscheidung, AEM abzulösen, finanziell oder logistisch nicht machbar ist und der primäre Geschäftsfaktor eine sofortige und drastische Senkung der Gesamtbetriebskosten ist. In der Regel wird diese Strategie verwendet, um den Betrieb aufrechtzuerhalten und die Geschäftskontinuität zu gewährleisten, und es ist keine weitere Entwicklung erforderlich. Neue Implementierungen werden in der Regel zu einem späteren Zeitpunkt auf einer neuen Basis durchgeführt (oder können sogar auf dieser hybriden Basis fortgesetzt werden).

Bereiten Sie die neue Umgebung und die CI/CD-Prozesse vor der Entwicklung oder Migration vor.

Hier gibt es nichts zu tun, da alle Komponenten/Inhaltspakete unverändert wiederverwendet werden.

Der Weg von AEM zu Magnolia ist flexibel. Ihre Geschäftsziele sollten Ihre technische Strategie bestimmen.

Ganz gleich, ob Sie eine vollständige Aktualisierung der Plattform oder eine revolutionäre Hybridlösung zur Maximierung der Wiederverwendung anstreben, es gibt eine bewährte und technisch robuste Strategie, um Ihre Ziele mit Magnolia zu erreichen.

Melden Sie sich für einen kostenloses Discovery Call ohne Verpflichtungen an, um mit einem Migrationsexperten Ihre gesamte Reise zu entwerfen.