AEM 6.5 Support-Ende Termine je Betriebsmodell, die drei Wege danach und wie Zielwerte die Migration absichern
Für Adobe Experience Manager 6.5 laufen die Supportzeiträume aus. Damit steht für viele Plattformen im DACH-Raum eine Migration an, und jede Migration verschiebt Ladezeit, Reaktionszeit und Layoutstabilität. Diese Seite fasst die Termine nach den Angaben von Adobe zusammen, ordnet die drei Wege nach AEM 6.5 aus Sicht der Performance ein und beschreibt, wie Zielwerte vor dem ersten Sprint verhindern, dass die neue Plattform langsamer wird als die alte.
Termine nach Adobe, Stand 31. Oktober 2026Verbindlich ist die jeweils aktuelle Angabe von Adobe
AEM 6.5 Support-Ende: die Termine je Betriebsmodell
| Betriebsmodell | Termin | Quelle |
|---|---|---|
| Adobe Managed Services | Support endete am 31. August 2026 | Adobe Release-Roadmap |
| On-Premises, Kernsupport | Ende geplant für Februar 2027 | Adobe Release-Roadmap |
| On-Premises, erweiterter Support | bis Februar 2028, Konditionen über Adobe | Adobe-Wissensdatenbank |
Nach dem Ende des Supports liefert Adobe für die betroffene Version keine Service Packs und Sicherheitsupdates mehr im Rahmen des regulären Supports. Für Betreiber heißt das: Die Entscheidung über den weiteren Weg fällt jetzt, und mit ihr die Entscheidung, ob Performance Teil der Anforderungen ist oder erst nach dem Livegang auffällt.
Drei Wege nach AEM 6.5: 6.5 LTS, Cloud Service oder Edge Delivery Services
AEM 6.5 LTS: gleiche Architektur, gleiche Performance-Schulden
Adobe führt AEM 6.5 als Version mit Langzeitsupport fort. Die Architektur mit Publish-Instanzen, Dispatcher und Client Libraries bleibt erhalten, und mit ihr alle bestehenden Ursachen langsamer Seiten. Der Weg verschafft Zeit, verbessert aber keinen Wert, solange nicht gleichzeitig an Cache, Bündeln und Drittanbietern gearbeitet wird.
AEM as a Cloud Service: Auslieferung aus dem Dienst, Browser unverändert
Im Cloud Service gehören CDN, Skalierung und Aktualisierungen zum Dienst, Deployments laufen über die Pipeline des Cloud Manager. Das verbessert die Ausgangslage für die Antwortzeit. Was im Browser geschieht, Client Libraries, Tags, Einwilligung und Personalisierung, wandert unverändert mit. Eine Plattform, die nach der Migration dieselben Bündel ausliefert, erreicht bei Reaktionszeit und Layoutstabilität dieselben Werte wie vorher.
Edge Delivery Services: neue Auslieferung, neues Frontend
Edge Delivery Services ersetzt die klassische Auslieferung und verlangt ein neu gebautes Frontend. Die Architektur ist schlanker, die gute Ausgangslage im Labor hält in der Produktion aber nur, wenn Tag Manager, Einwilligungsdialog und Personalisierung nicht unverändert übernommen werden. Im AEM Core Web Vitals Benchmark 2026 bestehen Auftritte mit Edge Delivery Services zu 54,0 Prozent die Core Web Vitals, die klassische Auslieferung zu 49,4 Prozent.
Ausgangswert vor der Migration: was auf der 6.5-Plattform gemessen werden muss
- Felddaten je Seitentyp und Markt aus dem Chrome User Experience Report, getrennt nach Mobil und Desktop, als Ausgangswert für die Abnahme.
- Trefferquote des Dispatcher-Caches und Antwortzeit der Publish-Instanzen je Seitentyp.
- Größe der Client Libraries je Seitentyp und der Teil davon, der vor der ersten Interaktion ausgeführt wird.
- Ein Inventar aller Drittanbieter-Skripte mit Eigentümer und Blockierzeit.
- Die Renditions der Bilder im sichtbaren Bereich und ihre Größe auf Mobilgeräten.
Im eigenen Abruf liefern 140 von 486 erkannten AEM-Auftritten im DACH-Raum noch über die Pfade der Generationen bis 6.3 aus. Für diese Plattformen ist der Ausgangswert besonders wichtig, weil die Migration dort zugleich ein Generationswechsel ist.
Performance-Abnahme in der Migration: Zielwerte vor dem ersten Sprint
Die Zielwerte je Seitentyp gehören in das Lastenheft der Migration, bevor die erste Komponente gebaut wird. Als Untergrenze gilt der gemessene Ausgangswert: Kein Seitentyp darf nach der Migration langsamer sein als vorher. Darüber stehen die Zielwerte für Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift. Jeder migrierte Bereich wird einzeln gegen echte Nutzerdaten abgenommen, damit eine Verschlechterung einem Bereich zugeordnet werden kann statt erst nach dem vollständigen Livegang als eine einzige Zahl aufzufallen.
Die Formulierungen dafür stehen in der Vorlage Performance-Anforderungen im Lastenheft. Wie Implementierungspartner und unabhängige Abnahme dabei zusammenarbeiten, beschreibt Performance-Partner für AEM- und Magnolia-Agenturen. Die technischen Ursachen auf AEM-Plattformen erläutert Adobe Experience Manager Performance.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie erhalten die Google-Nutzerdaten Ihrer Plattform im Vergleich zu zwei Wettbewerbern, unabhängig davon, ob wir zusammenarbeiten.
Häufige Fragen zum Support-Ende von AEM 6.5
Wann endet der Support für AEM 6.5?
Laut Release-Roadmap von Adobe endete der Support für AEM 6.5 auf Adobe Managed Services am 31. August 2026. Für On-Premises ist das Ende des Kernsupports für Februar 2027 geplant, erweiterter Support ist laut Adobe-Wissensdatenbank bis Februar 2028 möglich. Verbindlich ist die jeweils aktuelle Angabe von Adobe.
Wird eine AEM-Plattform durch den Wechsel in den Cloud Service schneller?
In der Auslieferung meist ja, weil CDN und eine aktuelle Cache-Schicht zum Dienst gehören. In den Core Web Vitals nicht automatisch, weil Reaktionszeit und Layoutstabilität überwiegend im Browser entstehen. Ohne Zielwerte und Arbeit an Client Libraries, Tags und Personalisierung bleiben diese Werte nach der Migration gleich.
Wann sollte die Performance-Messung in einer Migration beginnen?
Vor der Migration. Ohne Ausgangswert je Seitentyp lässt sich nach dem Livegang weder belegen, ob die neue Plattform schneller ist, noch eine Verschlechterung einem migrierten Bereich zuordnen.