Adobe Experience Manager6.1 Planung eines erfolgreichen AEM Upgrades Christoph Behounek, eggs unimedia Adobe Experience Manager
Ohne Planung funktioniert es nicht
Planung eines erfolgreichen AEM Updates 3
(Probleme) mit der derzeit verwendeten AEM Version Content Creation Wo gibt es aktuell Probleme - bei der Content Erstellung - bei den Prozessen Betrieb Wo sieht die IT Potentiale? - Performance AEM6.1 Welche aktuellen Probleme können durch neue und verbesserte Funktionalitäten gelöst werden? - Communities - Forms etc.
mit AEM6.1 Fachliche Anforderungen Können diese mit AEM6.1 abgedeckt werden? Technische Anforderungen Können diese mit AEM6.1 abgedeckt werden?
3. Identifikation der technischen Software Code Nicht-Aktualisierter und nicht gewarteter Code Technische Infrastruktur Fehlende Versionsverwaltung, Datensicherung, Build-Tools, Continuous Integration Abhängigkeiten Seiteneffekte, Abhängigkeiten von Komponenten, Schnittstellen
3.1. Systemarchitektur Hardware Was wird benötigt? Unterschiede zu Status Quo? Kosten? Konfigurationen Was wird benötigt? Backups Backup & Restore
3. Applikations-Architektur AEM Kernfunktionalitäten Welche AEM-Standardkomponenten wurden individuell angepasst? Können sie wiederverwendet werden? Applikation Welche Teile der Applikation müssen angepasst warden, z.b. - Service Berechtigungskonzept - Session Handling Bibliotheken Austausch veralteter Bibliotheken Austausch nicht mehr weiterentwickelter Klassen und Funktionen
3.3. Content-Architektur Content-Architektur Sind Anpassungen notwendig? - Content Hierarchie etc. Multi-Site-Manager Sind Anpassungen notwendig? - neue Sprachversionen etc.
3.4. Administration, Backend, Prozesse und Workflows Workflows Sind Anpassungen notwendig? Inbox und Notifications Sind Anpassungen notwendig? UX Sind Anpassungen notwendig? Granite UI (für die Touch Oberfläche)
3.5 Systemintegration Drittsysteme die von AEM angesprochen werden Drittsysteme die AEM ansprechen
3.6 Test und Release Konzept Test Anpassungen der Tests: - Smoke Tests - Komponenten Tests - Last- und Performance Tests Release Prozess Anpassung des Release Prozesses: - Automatisierter Release Prozess - Release Planung
4. Upgrade-Strategien In-Place Upgrade Update der Server gem. Adobe Doku Migration auf neuen Server Aufsetzen einer komplett neuen Instanz Content Migration von der alten auf die neue Instanz 4. Upgrade Strategie
4.1 Upgrade-Strategien: Inplace Upgrade der bestehenden Installation Bsp: - CQ -> AEM6.1 - TarMK ->MongoMK Anpassung der Applikation Refactoring des Codes Testen der angepassten Applikation gegen alten Datenbestand 4. Upgrade Strategie
4.1 Upgrade-Strategien: Inplace CQ5.6 -> AEM6.1 CQ5.6 AEM6.1 AEM6.1 CQ5.6 Apache SLING Apache Jackrabbit Oak Apache Felix (OSGi) Content 4. Upgrade Strategie
4.1 Vor- und Nachteile eines Inplace Upgrades Pro Contra Erhalt der Versionierung Altlasten Seiteneffekte mit alten Paketen Nur Big Bang möglich 4. Upgrade Strategie
4.2 Upgrade-Strategien: Migration auf ein neues System Aufsetzen eines neuen Systems Production-ready, ohne Applikation Installation der migrierten Applikation Test der Applikation gegen Testdaten Content Migration des alten Datenbestands 4. Upgrade Strategie
4.2 Upgrade-Strategien: Migration auf ein neues System CQ5.6 AEM6.1 CQ5.6 Apache SLING Apache Jackrabbit Apache Felix (OSGi) AEM6.1 Apache SLING Apache Oak Apache Felix (OSGi) Content 4. Upgrade Strategie
4.2 Vor- und Nachteile der Migration auf ein neues System Pro Contra Jungfräuliches System Nicht mehr benötigte Funktionen lassen sich leicht entfernen Nur Nötiges wird übernommen Keine Versionsübernahme möglich Datenübernahme Strategie 4. Upgrade Strategie
5. Kosten - Lizenzen Migration keine Migration Upgrade kostenlose Upgrademöglichkeit im Rahmen des Platinum M&S Vertrags Extended Support Erhöhte Supportkosten Auslaufender Support anderer Produkte (Java, etc.) 4. Upgrade Strategie 5. Kosten
5. Kosten Einarbeitung Migration keine Migration Redakteure Neue User Interfaces Neue Funktionen Neue Workflows Administratoren Neues System Neue Plattform Entwickler Neue Komponentensprache Neue Frameworks 4. Upgrade Strategie 5. Kosten
5. Kosten - Softwareentwicklung Migration keine Migration Projektkosten - neue Infrastruktur - Funktionale und technische Anpassungen - Entwicklung (Komponenten, Templates, Workflows) - Testing - Go-Live - Dokumentation Wartungskosten - für Legacy System - Kosten entgangener Gewinn - Bugwelle an Altlasten wird immer höher 4. Upgrade Strategie 5. Kosten
6. Chancen & Risiken Migration Keine Migration Seiteneffekte Unwegbarkeiten Projektkosten Bereinigung von Altlasten Verschieben von Problemen Kosten der Mig. wachsen exponent. Abhängigkeiten/Seiteneffekte Einarbeitung Kontinuierliche Codeverbesserung 4. Upgrade Strategie 5. Kosten 6. Projektrisiken
7. Entscheidungsfindung für / gegen Migration Pro Contra Verbesserte Sicherheit Up-to-Date Bereinigung von Altlasten Kosten Projekt Abhängigkeiten/Seiteneffekte Einarbeitung Kontinuierliche Codeverbesserung 4. Upgrade Strategie 5. Kosten 6. Projektrisiken 7. Entscheidung
8. Empfehlungen In-Place Upgrade Nur als Big Bang möglich Erstkosten meist geringer DevOps meist höher Migration auf neuen Server Eignet sich gut in Kombination mit einem Redesign Erstkosten meist höher DevOps meist geringer Strategie hängt sehr stark vom Status Quo ab Unabhängige Empfehlung Stetige Wartung der Applikation (Bugwelle)
9. Fazit