Adobe Commerce Deep Dive: Zwischen Magento-Flexibilität, SaaS und neuen Commerce-Architekturen

1. Executive Snapshot: Eine Marke, mehrere Architekturentscheidungen

Adobe Commerce lässt sich heute nicht mehr sinnvoll als eine einzige E-Commerce-Plattform mit unterschiedlichen Hostingoptionen beschreiben.

Unter derselben Marke stehen mehrere Architekturmodelle, die sich grundlegend darin unterscheiden, wie sie betrieben werden, welche Anpassungen möglich sind und wo die Verantwortung für Handelsprozesse liegt.

Die klassische, aus Magento hervorgegangene Adobe-Commerce-Architektur erlaubt tiefgreifende Anpassungen des Commerce-Kerns. Unternehmen können individuelle Geschäftslogik, Datenstrukturen und Integrationen weitgehend selbst gestalten. Diese Freiheit ist insbesondere dort wertvoll, wo Geschäftsprozesse nicht ohne Weiteres in standardisierte Abläufe passen. Sie geht allerdings mit erheblicher Verantwortung für Entwicklung, Betrieb, Sicherheit und Weiterentwicklung einher.

Mit Adobe Commerce as a Cloud Service verfolgt Adobe einen anderen Ansatz. Der Hersteller übernimmt den Betrieb und die kontinuierliche Aktualisierung des Commerce-Kerns. Individuelle Funktionen werden über unterstützte APIs, Events und externe Anwendungen realisiert. Die technische Verantwortung verschwindet dadurch nicht. Sie verlagert sich teilweise vom Plattformkern in die Integration und den Betrieb ergänzender Dienste.

Adobe Commerce Optimizer eröffnet einen dritten Weg. Unternehmen können Produktpräsentation, Suche und Merchandising modernisieren, während eine bestehende Adobe-Commerce-Installation oder eine andere Plattform weiterhin die Transaktionen verarbeitet.

Diese Optionen unterscheiden sich nicht nur in der Infrastruktur. Sie bestimmen, wo Geschäftslogik ausgeführt wird, welche Datenmodelle erweitert werden können und welche Abhängigkeiten bei zukünftigen Veränderungen entstehen.

Für Handelsunternehmen ist die Entscheidung deshalb differenzierter geworden.

Wer Adobe Commerce bewertet, muss zunächst klären, welche Teile der Handelsarchitektur eigene technische Kontrolle benötigen, welche standardisiert werden können und welche Konsequenzen daraus für Betrieb, Integrationsfähigkeit und zukünftige Änderungen entstehen.

Das Entscheidungsprofil auf einen Blick

Die klassischen Adobe-Commerce-Modelle sind insbesondere dort prüfenswert, wo umfangreiche individuelle Geschäftsprozesse, bestehende PHP-Erweiterungen oder komplexe Integrationen hohe technische Kontrolle erfordern.

Adobe Commerce as a Cloud Service ist eine eigenständige Option für Unternehmen, die weniger Verantwortung für den Plattformkern übernehmen möchten und deren Anforderungen sich mit den unterstützten Schnittstellen und externen Erweiterungsmodellen wirtschaftlich realisieren lassen.

Adobe Commerce Optimizer kommt in Betracht, wenn Produktsuche, Katalogdarstellung und Merchandising weiterentwickelt werden sollen, ohne den vorhandenen transaktionalen Commerce-Kern grundsätzlich zu ersetzen.

Alle drei Wege können für internationale B2C- und B2B-Geschäftsmodelle relevant sein. Ihre konkrete Eignung hängt jedoch von unterschiedlichen funktionalen, technischen und wirtschaftlichen Voraussetzungen ab.

Die zentrale Einordnung: Adobe Commerce bietet mehrere Wege zwischen tiefgreifender Individualisierung und stärker standardisiertem Plattformbetrieb. Entscheidend ist nicht die größtmögliche Funktionsvielfalt, sondern die passende Verteilung von technischer Kontrolle, Betriebsverantwortung und Veränderbarkeit.

2. Was Adobe Commerce heute eigentlich bezeichnet

Die Produktgeschichte von Adobe Commerce beginnt bei Magento, dessen modular erweiterbare Architektur lange zu den prägenden Technologien im anspruchsvolleren E-Commerce gehörte.

Magento wurde 2018 von Adobe übernommen. Der kommerzielle Produktname entwickelte sich später zu Adobe Commerce. Magento Open Source besteht daneben weiterhin als eigenständige Open-Source-Software.

Diese historische Verbindung erklärt, warum zahlreiche Unternehmen Adobe Commerce noch immer vor allem mit PHP, individuellen Modulen und tiefgreifenden Anpassungen verbinden.

Für eine aktuelle Architekturentscheidung reicht dieses Bild nicht mehr aus.

Magento Open Source

Magento Open Source stellt einen eigenständig betriebenen Commerce-Kern mit umfangreichen Erweiterungsmöglichkeiten bereit.

Unternehmen tragen die Verantwortung für Hosting, technische Infrastruktur, Updates, Sicherheitsmaßnahmen und die eingesetzten Erweiterungen.

Die Software teilt wesentliche technische Grundlagen mit der klassischen kommerziellen Adobe-Commerce-Architektur. Funktional und lizenzrechtlich sind beide Angebote jedoch nicht identisch.

Insbesondere die erweiterten kommerziellen B2B-Funktionen von Adobe Commerce gehören nicht automatisch zum Funktionsumfang von Magento Open Source.

Adobe Commerce on-premises und on Cloud Infrastructure

Die klassischen kommerziellen Adobe-Commerce-Modelle beruhen auf der Commerce Foundation.

Bei Adobe Commerce on-premises liegt die Verantwortung für die Infrastruktur beim Händler oder seinem Hostingpartner.

Adobe Commerce on Cloud Infrastructure stellt dagegen eine von Adobe bereitgestellte Plattforminfrastruktur zur Verfügung. Es handelt sich um ein Platform-as-a-Service-Modell, nicht um ein vollständig verwaltetes SaaS-Angebot.

Adobe verantwortet dabei wesentliche Teile der Hostingplattform. Anwendungscode, individuelle Erweiterungen, Konfiguration und Aktualisierungen auf Anwendungsebene bleiben im Rahmen der jeweiligen Verantwortungsverteilung beim Händler beziehungsweise seinen Implementierungspartnern.

Beide Modelle unterstützen die PHP-basierte Erweiterung des Commerce-Kerns sowie externe Integrationsmodelle.

Adobe Commerce as a Cloud Service

Adobe Commerce as a Cloud Service ist ein eigenständiges SaaS-Angebot mit einem von Adobe verwalteten transaktionalen Commerce-Kern.

Die Plattform wird kontinuierlich aktualisiert. Händler erhalten keine Möglichkeit, den Kerncode durch eigene PHP-Module zu verändern.

Erweiterungen erfolgen über unterstützte APIs, Ereignisse, Adobe Developer App Builder und ergänzende externe Dienste.

Adobe verwendet auch hier den Begriff Commerce Foundation. Daraus lässt sich jedoch keine identische interne Implementierung mit den klassischen Bereitstellungsmodellen ableiten.

Gemeinsam ist den transaktionalen Adobe-Commerce-Varianten die grundsätzliche Verantwortung für Commerce-Kernprozesse. Die technische Ausgestaltung und die zugänglichen Erweiterungspunkte unterscheiden sich.

Adobe Commerce Optimizer

Adobe Commerce Optimizer ist keine weitere Hostingvariante der Commerce Foundation.

Die SaaS-Lösung stellt Dienste für Katalogverarbeitung, Product Discovery und Merchandising bereit.

Sie kann mit einer klassischen Adobe-Commerce-Installation oder einem Commerce-Backend eines Drittanbieters kombiniert werden.

Warenkorb, Checkout, Kundenkonten, Bestellungen und die dazugehörigen Transaktionen bleiben beim jeweiligen Backend.

Damit ist Optimizer eine mögliche Ergänzung zu einer bestehenden Handelsarchitektur, aber kein eigenständiger Ersatz für deren transaktionalen Kern.

Die Architekturmodelle im Überblick

Die Architekturberatung von Adobe empfiehlt inzwischen ausdrücklich, bei der Frage zu beginnen, welches System Warenkorb, Checkout, Bestellungen und weitere Transaktionen verantwortet.

Erst danach soll entschieden werden, welche Merchandising- und Storefront-Services sinnvoll ergänzt werden.

Diese Reihenfolge ist auch aus unabhängiger Sicht plausibel.

Wer den transaktionalen Kern kontrolliert, verantwortet wesentliche Teile des Kundenversprechens. Dazu gehören verbindliche Preise, die tatsächliche Lieferbarkeit, die Bestellauslösung und die Verbindung zur Zahlungsabwicklung.

Die wichtigste Unterscheidung verläuft deshalb nicht zwischen Cloud und On-Premise, sondern zwischen Transaktionsverantwortung, Erweiterungsmodell und ergänzenden Commerce Services.

3. Die klassische Magento-Architektur: Freiheit und Verantwortung

Die technische Flexibilität der klassischen Magento- und Adobe-Commerce-Architektur ist kein bloßes historisches Verkaufsargument.

Das System erlaubt umfangreiche Eingriffe in die Geschäftslogik und das zugrunde liegende Datenmodell.

Entwickler können Module erstellen, bestehende Abläufe über Plugins und Observer erweitern und individuelle Dienste mit der Plattform verbinden.

Dependency Injection, Service Contracts, REST und GraphQL stellen unterschiedliche Erweiterungs- und Integrationsmöglichkeiten bereit.

Das Datenmodell arbeitet unter anderem mit Entity-Attribute-Value-Strukturen. Hinzu kommen Mechanismen für Indexierung, Suche, Caching und asynchrone Verarbeitung.

Die Multiwebsite- und Multistore-Architektur ermöglicht die Verwaltung mehrerer Marken, Länder, Websites und Store Views innerhalb einer Installation.

Diese Fähigkeiten sind besonders relevant, wenn Handelsunternehmen Anforderungen besitzen, die sich mit standardisierten Prozessen nicht angemessen abbilden lassen.

Wenn Individualisierung einen wirtschaftlichen Wert besitzt

Ein Unternehmen mit komplexen B2B-Preisstrukturen, ungewöhnlichen Produktkonfigurationen oder eng mit dem ERP verknüpften Geschäftsprozessen kann von den Eingriffsmöglichkeiten einer klassischen Adobe-Commerce-Installation profitieren.

Dasselbe gilt für bestehende Commerce-Landschaften, in denen über Jahre individuelle Funktionen entstanden sind, die geschäftskritische Abläufe unterstützen.

Solche Anpassungen sind nicht grundsätzlich technische Verschuldung.

Sie können bewusst entwickelte Fähigkeiten darstellen, die einen Unterschied im Wettbewerb ermöglichen oder besondere Anforderungen des Geschäftsmodells erfüllen.

Ihr Wert hängt davon ab, wie zuverlässig sie funktionieren, wie gut sie dokumentiert sind und wie wirtschaftlich sie weiterentwickelt werden können.

Die entscheidende Frage lautet, ob die gewonnene fachliche Freiheit in einem angemessenen Verhältnis zur langfristigen technischen Verantwortung steht.

Der Preis tiefgreifender Anpassungen

Probleme entstehen insbesondere dort, wo Erweiterungen stark von internen Implementierungsdetails der Plattform abhängen.

Eine Anpassung, die tief in Bestellverarbeitung, Preisberechnung oder Kataloglogik eingreift, kann bei einem Versionswechsel erheblich aufwendiger zu aktualisieren sein als eine sauber über unterstützte APIs integrierte Funktion.

Hinzu kommen Abhängigkeiten zwischen Modulen, unterschiedlichen Drittanbietererweiterungen und der zugrunde liegenden technischen Infrastruktur.

Gerade bei langjährig betriebenen Installationen können fachlich überschaubare Veränderungen technisch unverhältnismäßig aufwendig werden.

Die Ursache liegt dann nicht zwingend in der gewählten Plattform, sondern möglicherweise in der konkreten Erweiterungsarchitektur.

Wartbarkeit hängt stark von der Qualität der Implementierung ab.

Die technische Disziplin bei Erweiterungen, automatisierte Tests und die kontinuierliche Modernisierung des Systems sind deshalb ebenso wichtig wie dessen ursprünglicher Funktionsumfang.

Eine weiterhin aktiv entwickelte Architektur

Adobe entwickelt die klassische Commerce-Linie weiterhin.

Adobe Commerce 2.4.9 wurde am 12. Mai 2026 veröffentlicht. Die Version unterstützt PHP 8.5 sowie aktualisierte Datenbank-, Such- und Messaging-Technologien.

Zu den dokumentierten technischen Weiterentwicklungen gehören unter anderem die Unterstützung neuer MariaDB-Versionen, OpenSearch 3 und Apache ActiveMQ Artemis.

Für die Release-Linie 2.4.9 ist regulärer Support bis zum 31. Mai 2029 vorgesehen.

Die Unterstützung anderer Release-Linien unterscheidet sich nach Version und Supportmodell. Für bestehende Installationen muss daher auch der konkrete Patchstand geprüft werden.

Diese kontinuierliche Produktpflege ist für Investitionsentscheidungen relevant.

Sie widerlegt die Annahme, die klassische Adobe-Commerce-Architektur werde bereits ausschließlich durch die neue SaaS-Variante ersetzt.

Die Weiterentwicklung des Plattformkerns entbindet Händler allerdings nicht von der Verantwortung für eigene Erweiterungen und deren Kompatibilität.

Was bestehende Händler zuerst prüfen sollten

Für Unternehmen mit einer vorhandenen Adobe-Commerce-Installation empfiehlt sich zunächst eine Bestandsaufnahme der Individualisierungen.

Welche Anpassungen erzeugen heute einen geschäftlichen Mehrwert? Welche ersetzen Funktionen, die inzwischen im Standard verfügbar sind? Welche greifen auf interne Plattformdetails zu? Welche könnten über stabile APIs oder externe Services realisiert werden?

Ebenso wichtig ist der tatsächliche Betriebszustand.

Wie zuverlässig erfolgen Sicherheitsupdates und Versionswechsel? Welche Fehler wiederholen sich? Wie hoch ist die Abhängigkeit von einzelnen Entwicklern oder Implementierungspartnern?

Erst wenn diese Fragen beantwortet sind, lässt sich beurteilen, ob ein Upgrade innerhalb der bestehenden Architektur, eine gezielte Modernisierung oder ein grundsätzlicher Architekturwechsel wirtschaftlich sinnvoll ist.

4. Adobe Commerce as a Cloud Service: Ein anderes Erweiterungsmodell

Adobe Commerce as a Cloud Service verändert die technische Beziehung zwischen dem Händler und seiner Commerce-Plattform.

Im klassischen Adobe-Commerce-Modell kann ein Unternehmen den Anwendungskern durch eigene PHP-Komponenten erweitern.

Im SaaS-Modell bleibt dieser Kern unter der Kontrolle von Adobe.

Individuelle Anforderungen müssen über dokumentierte und unterstützte Erweiterungspunkte umgesetzt werden.

Adobe unterscheidet ausdrücklich zwischen In-Process- und Out-of-Process-Erweiterungen.

Diese Unterscheidung prägt die Architektur stärker als die Frage, in welchem Rechenzentrum die Anwendung betrieben wird.

Von internen Modulen zu externen Diensten

In-Process-Erweiterungen laufen innerhalb der Commerce-Anwendung. Sie können auf interne Abläufe und Datenstrukturen zugreifen und Geschäftslogik unmittelbar beeinflussen.

Out-of-Process-Erweiterungen werden außerhalb des Commerce-Kerns ausgeführt.

Die Kommunikation erfolgt über definierte APIs, Ereignisse und Integrationsmechanismen.

Adobe Developer App Builder bildet dafür eine zentrale Entwicklungsumgebung. Adobe I/O Events, Webhooks und weitere Event-Mechanismen ermöglichen die Anbindung individueller Anwendungen.

API Mesh unterstützt die Zusammenführung und Erweiterung von API-Zugriffen. Über unterstützte UI-Erweiterungen können außerdem bestimmte Verwaltungsoberflächen angepasst werden.

Diese Architektur schafft eine klarere Trennung zwischen Plattformkern und individuellen Funktionen.

Sie verändert aber auch die Bedingungen, unter denen Geschäftslogik ausgeführt wird.

Eine Anpassung, die früher als PHP-Modul Teil der Commerce-Anwendung war, kann im SaaS-Modell zu einem eigenständigen Dienst mit eigener Ausführung, Datenhaltung und Überwachung werden.

Nicht jede Anpassung lässt sich gleichwertig verlagern

Die aktuelle Adobe-Dokumentation beschreibt konkrete Unterschiede zwischen den Erweiterungsmöglichkeiten klassischer Installationen und Cloud Service.

Im PaaS-Modell sind weitreichende Änderungen des Datenmodells sowie eigene Anpassungen von Suchindex und Administrationsoberfläche möglich.

Cloud Service erlaubt demgegenüber Erweiterungen über unterstützte Attribute und externe Dienste.

Individuelle Suchindex-Anpassungen benötigen gegebenenfalls Drittanbieterlösungen. Auch für eigene E-Mail-Typen bestehen engere Grenzen als im klassischen Modell.

Die Erweiterung der Commerce APIs folgt ebenfalls unterschiedlichen Mechanismen.

Während klassische Installationen native REST- und GraphQL-Erweiterungen erlauben, verwendet das SaaS-Modell für zusätzliche API-Funktionen insbesondere externe Dienste und API Mesh.

Diese Unterschiede bedeuten nicht, dass bestimmte Geschäftsanforderungen unter SaaS prinzipiell unerfüllbar wären.

Sie können jedoch dazu führen, dass eine zuvor interne Funktion neu entwickelt, anders integriert oder durch einen zusätzlichen Dienst ersetzt werden muss.

Die technische Machbarkeit und ihre wirtschaftlichen Folgen sind jeweils konkret zu prüfen.

Datenhaltung und persistente Geschäftsobjekte

Die klassische Architektur ermöglicht eigene Datenbankstrukturen, Dateispeicherung, Caches und Warteschlangen innerhalb des Anwendungssystems.

Cloud Service stellt dafür ein anderes Modell bereit.

Eigene Attribute können im Rahmen der unterstützten Erweiterungsmechanismen angelegt werden. Darüber hinausgehende individuelle Datenmodelle erfordern möglicherweise externe Speicherung.

Adobe dokumentiert Database Storage für App Builder im Oktober 2026 noch als Early Access.

Für längerfristig persistente Datenhaltung können daher zusätzliche Infrastruktur und eigenständige Betriebsverantwortung erforderlich sein.

Das ist insbesondere bei individuell entwickelten Geschäftsobjekten, Prozesshistorien, branchenspezifischen Datenmodellen oder umfangreichen Integrationszuständen relevant.

Wenn ein Unternehmen bestimmte Daten langfristig vorhalten und revisionssicher verarbeiten muss, sollte die Architektur diese Anforderungen ausdrücklich berücksichtigen.

Betriebsentlastung und neue Abhängigkeiten

Adobe übernimmt im Cloud Service die Bereitstellung und kontinuierliche Aktualisierung wesentlicher Plattformkomponenten.

Der Händler muss deshalb nicht dieselben Infrastruktur- und Update-Aufgaben für den Commerce-Kern erfüllen wie bei einer klassischen Installation.

Das bedeutet jedoch keine vollständige Entlastung vom technischen Betrieb.

Externe Anwendungen, individuelle Integrationen und zusätzliche Datenhaltungsdienste müssen weiterhin überwacht, gewartet und abgesichert werden.

Die kontinuierliche Aktualisierung des Plattformkerns verlangt zudem, dass eigene Erweiterungen mit unterstützten Schnittstellen kompatibel bleiben.

Besondere Aufmerksamkeit verdienen asynchrone Prozesse.

Ereignisse können verzögert verarbeitet oder erneut zugestellt werden. Integrationsdienste können vorübergehend ausfallen. Kritische Geschäftsprozesse benötigen deshalb nachvollziehbare Zustände, Wiederholungsmechanismen und eine angemessene Fehlerbehandlung.

Auch die Beobachtbarkeit unterscheidet sich.

Bei klassischen PaaS-Installationen besteht ein direkterer Zugang zu anwendungsbezogenen Betriebsinformationen, unter anderem über New Relic.

Bei Cloud Service verantwortet Adobe einen größeren Teil der Plattformüberwachung. Für eigene App-Builder-Anwendungen und Storefronts stehen andere Mechanismen wie OpenTelemetry und Real User Monitoring zur Verfügung.

Ein Unternehmen muss deshalb nicht mehr sämtliche technischen Details des Commerce-Kerns selbst kontrollieren. Es muss aber weiterhin verstehen können, warum ein geschäftskritischer Prozess innerhalb seiner gesamten Commerce-Architektur erfolgreich war oder fehlgeschlagen ist.

Regionale Verfügbarkeit und Compliance

Adobe beschreibt Cloud Service als global verfügbares Angebot.

Die konkrete Bereitstellung in einer gewünschten Produktionsregion muss jedoch mit Adobe geklärt werden.

Aus der allgemeinen Produktverfügbarkeit lässt sich keine beliebige Hostingregion oder garantierte EU-Datenresidenz ableiten.

Auch Compliance-Anforderungen sind architekturspezifisch zu prüfen.

Adobe nennt für Cloud Service unter anderem SOC 2, PCI, ISO und GDPR-bezogene Compliance-Angaben. HIPAA-Unterstützung wird in der aktuellen Gegenüberstellung dagegen ausdrücklich nicht als verfügbar bezeichnet.

Für europäische Handelsunternehmen sind die konkrete vertragliche Ausgestaltung, Auftragsverarbeitung, Datenflüsse und gegebenenfalls Anforderungen an Datenresidenz entscheidend.

Migration ist kein Rehosting

Der Wechsel von einer klassischen Adobe-Commerce-Installation zu Adobe Commerce as a Cloud Service entspricht keinem gewöhnlichen Umzug auf eine neue Hostingplattform.

Adobe unterscheidet in seiner Migrationsdokumentation ausdrücklich zwischen Anwendung, Daten, Storefront und Integrationen.

Bestehende PHP-Module lassen sich nicht unverändert in die SaaS-Plattform übernehmen.

Ihre Funktionen müssen analysiert und gegebenenfalls durch Standardfunktionen, unterstützte APIs oder externe Anwendungen neu umgesetzt werden.

Adobe bietet mit Commerce Developer Agent und Commerce Developer MCP AI-gestützte Werkzeuge an, die Entwicklungs- und Migrationsaufgaben unterstützen können.

Deren Funktionsumfang und tatsächliche Verfügbarkeit sind von den Commerce-Funktionen für Endkunden zu unterscheiden.

Entwicklungsautomatisierung ersetzt weder die fachliche Entscheidung über notwendige Individualisierungen noch Architekturprüfungen, Integrationstests und Abnahme.

Cloud Service reduziert die Verantwortung für den Plattformkern. Die Verantwortung für die fachliche Richtigkeit und den zuverlässigen Betrieb der vollständigen Handelslösung bleibt bestehen.

Für Unternehmen mit überwiegend standardisierten Prozessen kann dieses Modell wirtschaftlich attraktiv sein.

Bei stark individualisierten Commerce-Landschaften muss dagegen sorgfältig geprüft werden, welche Funktionen neu entwickelt werden müssen und welche Abhängigkeiten dadurch entstehen.

5. Commerce Optimizer: Modernisierung ohne Austausch des Commerce-Kerns

Nicht jede Modernisierung eines E-Commerce-Systems muss mit dem Austausch der transaktionalen Plattform beginnen.

Gerade bei etablierten Handelsunternehmen können Warenkorb, Checkout, Bestellverarbeitung und ERP-Integration zuverlässig funktionieren, während Produktsuche, Katalogdarstellung oder Merchandising den gestiegenen Anforderungen nicht mehr entsprechen.

Adobe Commerce Optimizer adressiert diese Trennung.

Die SaaS-Lösung stellt Dienste für die Aufnahme und Verarbeitung von Produktdaten sowie für Suche, Empfehlungen und Merchandising bereit.

Sie kann mit bestehenden Adobe-Commerce-Installationen oder einem Commerce-Backend eines anderen Herstellers verbunden werden.

Ein zusätzlicher Service statt eines neuen Commerce-Kerns

Bei Nutzung von Optimizer bleibt das bestehende Backend für Transaktionen verantwortlich.

Produkt- und Preisdaten werden an Optimizer übertragen und dort für Discovery- und Merchandising-Prozesse bereitgestellt.

Die Storefront kann diese Dienste verwenden, während Warenkorb, Checkout, Kundenkonten und Bestellungen weiterhin mit dem transaktionalen Backend verbunden bleiben.

Für klassische Adobe-Commerce-Installationen dokumentiert Adobe einen eigenen Optimizer Connector.

Dieser überträgt unter anderem Katalog-, Kategorie- und Preisdaten in das Datenmodell von Optimizer.

Adobe Commerce bleibt dabei das führende System für die entsprechenden Produkt- und Preisinformationen.

Der Connector bildet vorhandene Websites, Store Views und Kundengruppen auf Catalog Sources, Price Books und weitere Optimizer-Strukturen ab.

Das ermöglicht eine Modernisierung der Produkterfahrung, ohne die vorhandene transaktionale Plattform vollständig neu aufzubauen.

Connector und B2B sind getrennt zu betrachten

Der Basisconnector ist auf B2C-Katalogsynchronisierung mit Adobe Commerce on Cloud beziehungsweise on-premises ausgerichtet.

Adobe dokumentiert darüber hinaus einen gesonderten B2B-Connector, der Shared Catalogs und Company-Zuordnungen in geschützte Katalogansichten überführen kann.

Diese Erweiterung ist für B2B-Händler relevant, weil Sichtbarkeit und Berechtigung von Produktdaten häufig vom jeweiligen Kundenunternehmen abhängen.

Sie bedeutet jedoch nicht, dass sämtliche B2B-Geschäftsprozesse durch Optimizer übernommen werden.

Angebotsprozesse, Bestellfreigaben, Warenkorb und Checkout bleiben weiterhin bei den dafür verantwortlichen Systemen.

Auch Berechtigungen müssen über die gesamte Integrationsarchitektur hinweg korrekt durchgesetzt werden.

Die Unterscheidung zwischen Katalogsichtbarkeit und transaktionaler Autorisierung ist deshalb wesentlich.

Integration mit Drittanbieterplattformen

Commerce Optimizer kann auch mit einem fremden Commerce-Kern verwendet werden.

Dafür müssen Katalog- und Preisdaten bereitgestellt sowie die Verbindungen zu Warenkorb und Checkout hergestellt werden.

Adobe dokumentiert unter anderem einen App-Builder-basierten Connector für Salesforce Commerce Cloud B2C.

Das zeigt, dass nicht jede Integration zwingend vollständig individuell entwickelt werden muss.

Allerdings sind solche Connectoren an konkrete Produktvarianten und technische Voraussetzungen gebunden.

Ein für Salesforce Commerce B2C entwickelter Connector belegt beispielsweise keine automatische Kompatibilität mit anderen Salesforce-Commerce-Produkten.

Bei weiteren Backends müssen verfügbare Integrationsbausteine, notwendige Eigenentwicklungen und deren langfristige Pflege einzeln bewertet werden.

Datenkonsistenz bleibt eine operative Herausforderung

Eine zusätzliche Katalog- und Merchandising-Schicht schafft neue Möglichkeiten, aber auch eine weitere Ebene der Datenverarbeitung.

Preise, Verfügbarkeiten und Produktinformationen verändern sich im operativen Geschäft.

Wenn eine Storefront Informationen aus Optimizer verwendet, der Checkout aber auf dem bisherigen Commerce-System basiert, müssen die Verantwortlichkeiten für Datenaktualität und verbindliche Transaktionsentscheidungen eindeutig definiert sein.

Insbesondere bei kundenspezifischen Preisen, zeitlich begrenzten Aktionen oder begrenzten Beständen können Unterschiede zwischen angezeigten und tatsächlich gültigen Informationen entstehen.

Die Integrationsarchitektur muss deshalb festlegen, welche Daten synchronisiert werden, wann eine erneute Prüfung erfolgt und wie Abweichungen behandelt werden.

Für einen Händler kann dies bedeuten, dass der angezeigte Preis unmittelbar vor der Bestellauslösung durch das führende Transaktionssystem erneut bestätigt werden muss.

Auch die Überwachung der Datenfeeds gehört zum Betrieb.

Der Optimizer Connector stellt dafür Funktionen zur Kontrolle des Synchronisierungsstatus bereit. Unternehmen müssen dennoch definieren, wie fehlerhafte oder verzögerte Datenübertragungen erkannt und behandelt werden.

Kapazitäts- und Lizenzgrenzen

Adobe unterscheidet bei Optimizer zwischen lizenzabhängigen Kapazitäten und festen technischen Systemgrenzen.

Lizenzabhängige Kapazitäten können durch zusätzliche Pakete oder individuelle Vereinbarungen erweitert werden.

Feste Systemgrenzen lassen sich dagegen nicht einfach durch eine größere Lizenz aufheben.

Die dokumentierte Basisausstattung umfasst beispielsweise 250.000 SKUs je Catalog Source. Für Produktaktualisierungen, Catalog Variations, API-Abfragen und weitere Dimensionen bestehen zusätzliche Grenzwerte.

Diese Angaben sind keine allgemeinen Leistungsgrenzen des gesamten Adobe-Commerce-Portfolios.

Sie betreffen die jeweilige Optimizer-Konfiguration und müssen anhand des aktuellen Vertrags- und Produktstandes geprüft werden.

Für die Architekturplanung sind insbesondere Sortimentstiefe, Anzahl der Märkte, Preisbuchstrukturen und Häufigkeit der Datenänderungen relevant.

Auch die Nutzung zusätzlicher Katalogquellen und Storefronts kann die erforderliche Kapazität beeinflussen.

Ein groß angelegtes Optimizer-Projekt benötigt deshalb eine Dimensionierung, die technische Grenzen und Lizenzmodell gemeinsam betrachtet.

Ein eigenständiger Modernisierungspfad

Commerce Optimizer eröffnet eine Option zwischen unverändertem Weiterbetrieb und vollständigem Plattformwechsel.

Seine Eignung hängt davon ab, ob die wesentlichen Defizite tatsächlich bei Produkterkennung, Katalogdarstellung und Merchandising liegen.

Wenn die Probleme dagegen in einer unzureichenden Bestelllogik, nicht tragfähigen ERP-Integration oder strukturellen Checkout-Grenzen bestehen, beseitigt eine zusätzliche Discovery-Schicht diese Ursachen nicht.

Eine weitere Einschränkung betrifft das Adobe-Portfolio selbst.

Die direkte Integration zwischen Adobe Commerce as a Cloud Service und Commerce Optimizer wird von Adobe im Oktober 2026 weiterhin als Roadmap-Thema beschrieben.

Beide Lösungen sollten deshalb nicht als bereits integrierte SaaS-Gesamtarchitektur vorausgesetzt werden.

6. Commerce-Funktionen und B2B: Was der jeweilige Kern tatsächlich leistet

Adobe Commerce besitzt in seinen transaktionalen Produktvarianten ein breites Fundament für klassische E-Commerce-Prozesse.

Dazu gehören Produktkataloge, Varianten, konfigurierbare Produkte, Bundles, Kundengruppen, Preisregeln, Promotions, Warenkorb, Checkout, Zahlungsintegration und Auftragsverwaltung.

Für internationale Handelsunternehmen sind die Möglichkeiten zur Modellierung mehrerer Websites, Stores und Store Views relevant.

Allerdings unterscheiden sich die klassischen und neuen Architekturmodelle hinsichtlich der konkreten Umsetzung und der verfügbaren Erweiterungswege.

Eine Funktion, die innerhalb einer klassischen Installation durch ein PHP-Modul realisiert wird, kann in Cloud Service eine andere technische Lösung benötigen.

B2B als wesentliche Adobe-Commerce-Fähigkeit

Die kommerziellen Adobe-Commerce-Modelle bieten zahlreiche Funktionen für B2B-Geschäftsprozesse.

Dazu gehören unter anderem Firmenkonten, Benutzer- und Rollenmodelle, kundenspezifische Kataloge, Angebotsprozesse, Purchase Orders, Genehmigungsregeln und Einkaufslisten.

Diese Funktionen können eine wichtige Grundlage für Geschäftskundenportale und digitale Beschaffungsprozesse bilden.

Bei klassischen Adobe-Commerce-Installationen ist Adobe Commerce B2B als separat lizenzierte Erweiterung zu berücksichtigen.

Adobe Commerce as a Cloud Service enthält zentrale B2B-Funktionen bereits im Kernangebot.

Adobe nennt dabei ausdrücklich Company Management und Quoting.

Zusätzliche B2B-Storefront-Komponenten wurden im Verlauf des Jahres 2026 dokumentiert.

Daraus darf jedoch nicht geschlossen werden, dass alle spezialisierten B2B-Funktionen in den klassischen und neuen Architekturen identisch verfügbar sind.

Die genaue Unterstützung von Purchase Orders, mehrstufigen Freigaben, kundenspezifischen Preisregeln und besonderen Beschaffungsprozessen muss für die jeweilige Architektur geprüft werden.

Die Grenze zwischen B2B-Funktion und Beschaffungsprozess

Ein Commerce-System kann Purchase Orders oder Angebotsprozesse unterstützen, ohne sämtliche organisatorischen Beschaffungsregeln eines Kundenunternehmens abzubilden.

In komplexen Organisationen werden Budgets, Einkaufsberechtigungen, Kostenstellen, Rahmenverträge und Freigaben häufig außerhalb des Commerce-Systems verwaltet.

Die technische Architektur muss dann sicherstellen, dass Bestellungen und Genehmigungen mit den führenden Unternehmenssystemen übereinstimmen.

Auch kundenspezifische Preise können deutlich komplexer sein als die Zuordnung einer einfachen Preisliste.

Sie können von Verträgen, Mengenstaffeln, Lieferorten, Währungen und individuellen Vereinbarungen abhängen.

Wenn die verbindliche Preisberechnung im ERP erfolgt, muss Adobe Commerce diese Verantwortung respektieren und zuverlässig integrieren.

B2B im klassischen und im SaaS-Modell

Die klassische Magento-Architektur bietet umfangreiche Möglichkeiten, solche Prozesse individuell anzupassen.

Cloud Service verwendet dagegen einen stärker standardisierten Kern mit externen Erweiterungen.

Für einen Händler, dessen B2B-Anforderungen weitgehend den dokumentierten Standardfunktionen entsprechen, kann dieses Modell den Betrieb vereinfachen.

Bei stark individualisierten Beschaffungsprozessen muss geprüft werden, ob die unterstützten Datenmodelle, APIs und Ereignisse die erforderlichen Geschäftsregeln vollständig abbilden können.

Dazu gehört insbesondere die Frage, wo verbindliche Entscheidungen getroffen werden.

Eine externe Genehmigungslogik darf nicht lediglich eine Benutzeroberfläche beeinflussen, wenn sie tatsächlich verhindern soll, dass nicht autorisierte Bestellungen ausgelöst werden.

Ebenso müssen geschützte B2B-Kataloge, kundenspezifische Preise und Bestellberechtigungen konsistent zusammenwirken.

Für Magento Open Source gilt zusätzlich, dass kommerzielle Adobe-B2B-Funktionen nicht automatisch enthalten sind. Entsprechende Anforderungen können Drittanbietererweiterungen oder individuelle Entwicklungen notwendig machen.

Die grundsätzliche B2B-Eignung von Adobe Commerce ist daher gut dokumentiert. Die Eignung für einen konkreten Beschaffungsprozess ergibt sich erst aus der Prüfung von Funktionen, Berechtigungen und Integration.

7. Unified Commerce: Die Grenzen der Adobe Experience Cloud

Adobe Commerce kann mit zahlreichen Technologien aus dem Adobe-Ökosystem kombiniert werden.

Adobe Experience Manager unterstützt Content- und Experience-Management. Adobe Experience Manager Assets adressiert die Verwaltung digitaler Inhalte.

Adobe Analytics liefert analytische Funktionen. Adobe Experience Platform, Real-Time CDP, Journey Optimizer und Adobe Target können für Kundendaten, Zielgruppen, Personalisierung und kanalübergreifende Kommunikation relevant sein.

Diese Breite ist für Unternehmen interessant, die Commerce als Bestandteil einer umfassenden digitalen Kundenarchitektur betrachten.

Sie sagt jedoch noch wenig darüber aus, wie zuverlässig operative Handelsprozesse über mehrere Kanäle hinweg funktionieren.

Kundenerlebnis und operative Handelsprozesse

Ein Kunde kann über Website, App, Marktplatz oder Filiale mit demselben Handelsunternehmen interagieren.

Für ein konsistentes Einkaufserlebnis müssen mehr als Inhalte und Kundenprofile abgestimmt werden.

Der Kunde benötigt verlässliche Informationen über Preise, Verfügbarkeit, Liefermöglichkeiten und den Status seiner Bestellung.

Er soll gegebenenfalls online bestellen und in der Filiale abholen können. Eine Retoure aus einem Onlinekauf soll möglicherweise im stationären Handel bearbeitet werden.

Diese Prozesse hängen von einer gemeinsamen operativen Logik ab.

Adobe Commerce kann digitale Commerce-Prozesse verantworten. Filialkassen, Warenwirtschaft, Bestandsführung und Auftragsorchestrierung liegen jedoch häufig in anderen Systemen.

Bestandsführung und Reservierung

Ein Artikel kann im Onlinekatalog verfügbar erscheinen, obwohl die tatsächlich verkaufbare Menge bereits für andere Aufträge reserviert wurde.

Solche Abweichungen entstehen nicht zwingend durch eine unzureichende Commerce-Plattform.

Häufig liegen die Ursachen in unterschiedlichen Bestandsdefinitionen, verzögerter Synchronisierung oder fehlenden Vereinbarungen zwischen ERP, POS, OMS und Commerce-System.

Adobe Commerce verfügt über Funktionen zur Bestandsverwaltung und kann Bestände verschiedener Quellen in seine Verkaufsprozesse einbeziehen.

Das ist jedoch von einer vollständigen kanalübergreifenden Bestands- und Auftragsorchestrierung zu unterscheiden.

Für Click & Collect muss beispielsweise geklärt werden, welches System einen Bestand verbindlich reserviert, wann eine Reservierung verfällt und wer die tatsächliche Abholung bestätigt.

Für Ship-from-Store kommen weitere Anforderungen hinzu.

Welche Filiale darf einen Auftrag erfüllen? Wie werden Versandkapazitäten berücksichtigt? Wie werden fehlerhafte Bestände behandelt? Was geschieht, wenn ein bereits bestätigter Auftrag aus der vorgesehenen Filiale nicht erfüllt werden kann?

Diese Entscheidungen müssen über mehrere operative Systeme hinweg zuverlässig umgesetzt werden.

Order Management ist nicht gleich Order Orchestration

Adobe Commerce verfügt über Funktionen zur Verwaltung von Bestellungen und deren Status.

Diese Fähigkeiten dürfen nicht mit einer vollständigen, kanalübergreifenden Auftragsorchestrierung gleichgesetzt werden.

Ein Order Management System kann unter anderem Routing, Fulfilment-Entscheidungen und kanalübergreifende Prozesssteuerung übernehmen.

Welche Funktionen tatsächlich benötigt werden, hängt von der Handelsorganisation ab.

Das frühere Produkt Adobe Commerce Order Management hat sein End of Life erreicht und wird nicht mehr unterstützt.

Es darf deshalb nicht als aktuell verfügbares Standardprodukt in eine neue Adobe-Commerce-Architektur eingeplant werden.

Die notwendigen Funktionen müssen über die vorhandenen Systeme, andere unterstützte Lösungen oder geeignete Integrationen abgedeckt werden.

Die Experience Cloud ergänzt, aber ersetzt keine Prozessverantwortung

Adobe Experience Cloud kann helfen, Inhalte, Kundendaten und Interaktionen über unterschiedliche digitale Berührungspunkte hinweg zu verbinden.

Die operative Verantwortung für Bestände, Aufträge, Retouren und Service liegt damit aber noch nicht automatisch in einem gemeinsamen System.

Ein Unternehmen muss beispielsweise festlegen, welches System die verbindliche Kundenidentität verwaltet und wie diese mit Commerce-Konten, Loyalty-Programmen und Serviceprozessen verbunden wird.

Ebenso muss klar sein, welche Datenquelle bei widersprüchlichen Informationen maßgeblich ist.

Die Integration einer Customer Data Platform löst solche Fragen nicht allein.

Unified Commerce ist eine Governance-Aufgabe

Wenn Commerce, ERP, Filialorganisation und Customer Service unterschiedliche Definitionen von Verfügbarkeit, Auftragsstatus oder Kundenidentität verwenden, entstehen auch bei technisch funktionierenden Schnittstellen widersprüchliche Ergebnisse.

Eine tragfähige Unified-Commerce-Architektur benötigt deshalb klare Verantwortlichkeiten für Stammdaten, operative Entscheidungen und Fehlerbehandlung.

Dazu gehören auch organisatorische Zuständigkeiten.

Wer korrigiert fehlerhafte Bestände? Wer entscheidet über die Behandlung gescheiterter Reservierungen? Welches Team verantwortet eine Retoure, die mehrere Kanäle berührt?

Adobe Commerce kann ein wichtiger Bestandteil dieser Architektur sein.

Die Verantwortung für das gesamte Handelsmodell bleibt jedoch beim Unternehmen.

8. Agentic Commerce: Von Produktdiscovery zu delegierten Käufen

AI verändert die Art, wie Kunden Produkte entdecken, vergleichen und Kaufentscheidungen vorbereiten.

Anstatt ausschließlich durch Kategorien und Filter zu navigieren, können sie Anforderungen in natürlicher Sprache formulieren.

AI-Assistenten können daraus Produktvorschläge, Variantenvergleiche und weitere Interaktionen ableiten.

Für Commerce-Plattformen entsteht damit eine neue Anforderung.

Produktinformationen und Geschäftsprozesse müssen nicht nur für menschliche Nutzer zugänglich sein, sondern zunehmend auch für maschinelle Systeme, die im Auftrag eines Nutzers handeln sollen.

Adobe entwickelt dafür unterschiedliche Technologien.

Deren Zweck, Produktzuordnung und tatsächliche Verfügbarkeit müssen allerdings sorgfältig getrennt werden.

Aktuelle Product-Discovery-Funktionen

Adobe Brand Concierge unterstützt AI-gestützte Produktberatung und Discovery.

Die Verbindung zu Commerce-Daten kann über dokumentierte Commerce-MCP-Funktionen erfolgen.

Adobe beschreibt dabei insbesondere katalogbezogene Anwendungsfälle wie Produktsuche, Produktdetails und Vergleiche.

Das sind relevante Fähigkeiten für eine dialogbasierte Produkterfahrung.

Die aktuelle Adobe-Dokumentation grenzt den verfügbaren Funktionsumfang jedoch gegenüber weitergehenden Commerce-Aktionen ab.

Warenkorb- und Checkout-Funktionen werden im Zusammenhang mit Brand Concierge als zukünftige Erweiterungen beschrieben.

Damit ist Product Discovery nicht mit einem vollständig ausführbaren Einkauf gleichzusetzen.

Commerce MCP und dialogbasierter Checkout

Adobe zeigt in einer separaten Commerce-MCP-Demonstration einen weiterreichenden Ablauf.

Darin können Produktberatung, Warenkorbverwaltung und Checkout innerhalb einer Konversation stattfinden.

Die betreffende Dokumentationsseite ist am 28. Oktober 2026 weiterhin als „Coming Soon“ gekennzeichnet.

Eine Demonstration zeigt, wie ein technischer Ablauf gestaltet werden kann.

Sie belegt weder eine allgemeine Produktverfügbarkeit noch die Unterstützung sämtlicher erforderlicher Integrationen, Berechtigungen oder Zahlungsprozesse.

Für die Bewertung müssen deshalb vier Kategorien auseinandergehalten werden.

Dokumentierte aktuelle Funktionen sind solche, die Adobe für ein konkretes Produkt und einen definierten Anwendungsfall als verfügbar beschreibt.

Demos und Previews zeigen mögliche oder teilweise implementierte Abläufe, ohne damit die allgemeine Produktionsreife zu belegen.

Ankündigungen und Roadmaps beschreiben beabsichtigte Produktentwicklungen.

Individuelle Implementierungen können zusätzliche Möglichkeiten eröffnen, deren Funktionsumfang und Betrieb jedoch nicht mit nativen Standardfunktionen verwechselt werden dürfen.

Diese Unterscheidung ist besonders wichtig, weil verschiedene Adobe-Produkte und Entwicklerwerkzeuge mit dem Begriff MCP arbeiten.

Commerce Developer Agent und Developer MCP

Commerce Developer Agent und Commerce Developer MCP richten sich an Entwickler und technische Architekten.

Sie unterstützen Aufgaben rund um die Entwicklung, Analyse und mögliche Migration von Commerce-Erweiterungen.

Im Zusammenhang mit Adobe Commerce as a Cloud Service können solche Werkzeuge beispielsweise bei der Übertragung bisheriger PHP-Anpassungen in externe App-Builder-Anwendungen relevant werden.

Adobe demonstriert darüber hinaus agentengestützte Entwicklungsabläufe, deren vollständiger Reifegrad gesondert geprüft werden muss.

Diese Funktionen betreffen die Softwareentwicklung.

Ein Entwickleragent, der Quellcode analysiert oder einen Integrationsdienst erzeugt, besitzt eine andere Aufgabe als ein Käuferagent, der Waren auswählt und Bestellungen auslöst.

Die Verwendung verwandter AI-Technologien oder gemeinsamer Protokolle macht diese beiden Anwendungsbereiche nicht gleichwertig.

MCP, UCP, ACP und AP2

Model Context Protocol, kurz MCP, ermöglicht AI-Anwendungen die Nutzung strukturierter Werkzeuge und Datenquellen.

Ein MCP-Server kann damit einen kontrollierten Zugang zu bestimmten Commerce-Funktionen bereitstellen.

Andere Protokolle adressieren zusätzliche Aspekte agentengestützter Handelsprozesse.

Universal Commerce Protocol und Agentic Commerce Protocol beschäftigen sich mit standardisierten Commerce-Interaktionen.

Agent Payments Protocol adressiert Fragen der Autorisierung und Nachvollziehbarkeit agentengestützter Zahlungen.

Adobe hat am 18. Februar 2026 öffentlich seine Absicht zur Unterstützung von UCP und ACP erklärt und dabei auf die bereits angekündigte Unterstützung von AP2 verwiesen.

Diese Erklärung ist ein relevantes Signal für die strategische Ausrichtung.

Sie ist jedoch nicht mit dem Nachweis einer vollständigen produktiven Implementierung in sämtlichen Adobe-Commerce-Varianten gleichzusetzen.

Für eine konkrete Plattformentscheidung müsste geprüft werden, welche Protokollversionen, Aktionen, Authentifizierungsmechanismen und Zahlungsabläufe tatsächlich unterstützt werden.

Ebenso muss zwischen der Bereitstellung von Werkzeugen und der Berechtigung zur Ausführung geschäftlicher Transaktionen unterschieden werden.

Die vollständige Prozesskette

Ein agentengestützter Einkauf beginnt gewöhnlich mit Produkterkennung, Beratung und Variantenklärung.

Darauf können Warenkorbvorbereitung, verbindliche Preis- und Bestandsprüfung sowie Lieferauswahl folgen.

Beim Checkout entstehen zusätzliche Anforderungen an Kundenbestätigung und Zahlungsautorisierung.

Nach der Bestellung werden Bestellbestätigung, Änderungen, Stornierung, Retoure und gegebenenfalls Erstattung relevant.

Diese Schritte unterscheiden sich in ihrer technischen und rechtlichen Bedeutung.

Eine AI-Anwendung, die Produkte recherchieren darf, muss deshalb nicht zugleich berechtigt sein, einen Vertrag im Namen eines Kunden abzuschließen.

Auch die Fähigkeit, einen Warenkorb zu verändern, sagt noch nichts darüber aus, ob eine Zahlung autorisiert werden kann.

Für einen vollständig agentischen Kaufprozess müssen die einzelnen Fähigkeiten über mehrere Systeme hinweg zusammenwirken.

Identität, Autorisierung und Governance

In einer agentischen Commerce-Architektur sind mehrere Beteiligte zu unterscheiden.

Dazu gehören der menschliche Kunde, gegebenenfalls seine Organisation, der externe Agent, dessen Anbieter, der Händler, die Commerce-Plattform und die beteiligten Zahlungs- und Integrationsdienste.

Ein Agent muss technisch authentifiziert werden.

Zusätzlich muss feststehen, für wen er handelt und welche Befugnisse ihm tatsächlich übertragen wurden.

Ein Kunde könnte beispielsweise erlauben, einen konkreten Warenkorb vorzubereiten, die endgültige Bestellung aber selbst bestätigen.

Ein weitergehendes Mandat könnte einem Agenten erlauben, innerhalb eines bestimmten Budgets eigenständig einzukaufen.

Dafür wären zusätzliche Regeln erforderlich.

Sie könnten zulässige Produktkategorien, maximale Gesamtpreise, Lieferorte, Ersatzartikel oder wiederkehrende Verpflichtungen betreffen.

Auch der Widerruf eines Mandats und die Nachvollziehbarkeit bereits ausgeführter Entscheidungen müssen berücksichtigt werden.

Im B2B-Handel kommen organisationsbezogene Budgets, Rollen, Kostenstellen und Freigabeprozesse hinzu.

Solche Regeln sollten technisch überprüfbar und durchsetzbar sein.

Natürlichsprachliche Anweisungen an ein AI-Modell reichen als alleinige Grundlage für verbindliche Autorisierungsgrenzen nicht aus.

Ein API-Zugriff ist keine Handlungsvollmacht.

Die Fähigkeit einer Commerce-Plattform, Daten oder Aktionen über Schnittstellen bereitzustellen, belegt noch keine vollständige Delegationsarchitektur.

Was Adobe heute tatsächlich abdeckt

Adobe dokumentiert zum Recherchestichtag unterschiedliche Fähigkeiten für Product Discovery, AI-gestützte Entwicklung und die Integration von Commerce-Daten in agentische Anwendungen.

Weitergehende transaktionale Abläufe werden teilweise demonstriert oder strategisch angekündigt.

Eine allgemein verfügbare native Architektur, die autonome Käufe innerhalb delegierter Kundenmandate einschließlich sämtlicher Autorisierungs-, Zahlungs- und nachgelagerter Serviceprozesse vollständig abdeckt, ist aus den geprüften Quellen nicht nachgewiesen.

Damit ist keine Aussage über grundsätzliche technische Unmöglichkeit verbunden.

Individuelle Implementierungen können zusätzliche Fähigkeiten schaffen.

Sie benötigen allerdings eine eigene Bewertung von Identität, Berechtigungen, Integration, Betrieb, Datenschutz und Transaktionssicherheit.

Konsequenzen für bestehende Adobe-Commerce-Landschaften

Für Agentic Commerce ist nicht allein entscheidend, ob Adobe eine bestimmte AI-Funktion anbietet.

Mindestens ebenso wichtig ist, wie zuverlässig sich Produktdaten, Preise, Bestände, Kundenberechtigungen und Transaktionen über kontrollierte Schnittstellen bereitstellen lassen.

Eine bestehende Adobe-Commerce-Installation kann dafür eine geeignete Grundlage sein, sofern ihre APIs und Integrationen die erforderlichen Abläufe unterstützen.

Auch externe Services können ergänzende Funktionen bereitstellen, ohne den Commerce-Kern vollständig auszutauschen.

Die Entwicklung agentischer Handelsprozesse ist deshalb für sich genommen kein ausreichender Grund für einen Plattformwechsel.

Sie erhöht vielmehr die Bedeutung sauber definierter Systemverantwortung, überprüfbarer Transaktionsregeln und langfristig wartbarer Schnittstellen.

9. Wirtschaftlichkeit: Total Cost of Ownership und Total Cost of Change

Die Wirtschaftlichkeit von Adobe Commerce lässt sich nicht mit einer allgemeinen Aussage über Lizenzkosten oder Implementierungsbudgets beschreiben.

Zu unterschiedlich sind die verfügbaren Architekturmodelle, bestehenden Systemlandschaften und individuellen Geschäftsanforderungen.

Eine klassische Adobe-Commerce-Installation mit umfangreichen PHP-Anpassungen verursacht andere laufende Kosten als ein SaaS-System mit externen Integrationsdiensten.

Ebenso unterscheidet sich die wirtschaftliche Betrachtung einer vollständigen Cloud-Service-Migration von der gezielten Ergänzung eines bestehenden Commerce-Backends durch Optimizer.

Die Kosten der klassischen Architektur

Bei klassischen Installationen entstehen Aufwendungen für Infrastruktur, Betrieb, Sicherheitsupdates, Versionswechsel und Wartung individueller Funktionen.

Hinzu kommen Tests und Anpassungen, wenn Drittanbietererweiterungen oder technische Plattformkomponenten aktualisiert werden müssen.

Entscheidend ist der konkrete Zustand der Architektur.

Ein gut strukturiertes System mit klar abgegrenzten Erweiterungen und automatisierten Tests kann langfristig einfacher zu betreiben sein als eine vergleichbare Installation mit unkoordiniertem Customizing.

Die technische Qualität ist deshalb für die Wirtschaftlichkeitsbewertung wichtiger als das Alter der Plattform allein.

Die Kosten der SaaS-Architektur

Cloud Service verlagert den Betrieb des Commerce-Kerns zu Adobe.

Dadurch können bestimmte Infrastruktur- und Upgrade-Aufgaben entfallen oder deutlich reduziert werden.

Allerdings entstehen möglicherweise zusätzliche Aufwendungen für App Builder, API Mesh, externe Datenhaltung, Monitoring und individuelle Integrationsdienste.

Auch die Migration bestehender Funktionen kann erhebliche Entwicklungsarbeit erfordern.

Wenn ein Händler bisher umfangreiche PHP-Anpassungen nutzt, muss geprüft werden, welche davon durch Standardfunktionen ersetzt werden können und welche neu entwickelt werden müssen.

Die wirtschaftliche Betrachtung darf daher nicht bei den Kosten des Plattformkerns enden.

Sie muss die vollständige Handelslösung einschließlich aller für den Geschäftsbetrieb notwendigen externen Komponenten erfassen.

Die Kosten einer zusätzlichen Optimizer-Schicht

Commerce Optimizer kann eine gezielte Modernisierung ermöglichen, ohne einen vollständigen Plattformwechsel auszulösen.

Dafür entstehen zusätzliche Lizenz-, Integrations- und möglicherweise nutzungsabhängige Kosten.

Das vorhandene Commerce-Backend muss weiterhin betrieben und gepflegt werden.

Zugleich können bestehende Funktionen für Suche, Indexierung und Merchandising möglicherweise entlastet oder ersetzt werden.

Die wirtschaftliche Frage lautet, welcher tatsächliche Mehrwert aus dem ergänzenden Service entsteht und welche bisherigen oder zukünftigen Kosten dadurch reduziert werden können.

Dafür benötigt ein Unternehmen ein konkretes Zielbild und nachvollziehbare Annahmen.

Total Cost of Change

Neben den Total Cost of Ownership sollte eine zweite Perspektive berücksichtigt werden.

Total Cost of Change beschreibt die wirtschaftlichen Folgen zukünftiger Veränderungen an der Commerce-Architektur.

Ein Beispiel ist die Änderung einer kundenspezifischen Preislogik.

In einer klassischen Adobe-Commerce-Installation kann diese Funktion als PHP-Erweiterung tief mit dem Commerce-Kern verbunden sein.

Eine Anpassung erfordert dann möglicherweise Änderungen am Modul, Regressionstests und eine Prüfung der Auswirkungen auf andere Erweiterungen.

Wird dieselbe fachliche Logik als externer Dienst betrieben, verändern sich die Abhängigkeiten.

Der Dienst kann unabhängig entwickelt werden, muss jedoch zuverlässig mit den relevanten Commerce APIs kommunizieren. Fragen der Antwortzeit, Verfügbarkeit, Datenkonsistenz und Fehlerbehandlung werden wichtiger.

Welcher Ansatz langfristig günstiger ist, lässt sich aus dem Erweiterungsmodell allein nicht ableiten.

Ein zweites Beispiel betrifft die Einführung eines neuen B2B-Freigabeprozesses.

Wenn dieser Prozess bereits weitgehend dem Plattformstandard entspricht, kann eine standardisierte Umsetzung den Aufwand begrenzen.

Wenn dagegen zusätzliche Regeln aus ERP, Einkaufssystem und organisatorischen Genehmigungsstrukturen erforderlich sind, entsteht unabhängig vom Plattformmodell erheblicher Integrationsbedarf.

Ein drittes Beispiel ist die Einführung eines neuen Absatzkanals.

Eine gut getrennte Commerce-Architektur kann vorhandene Geschäftslogik über APIs wiederverwenden.

Wenn dagegen wesentliche Prozesse eng mit einer bestimmten Storefront verbunden sind, wird ihre Wiederverwendung schwieriger.

Diese Beispiele verdeutlichen, warum die laufenden Betriebskosten allein keine ausreichende Entscheidungsgrundlage darstellen.

Die wirtschaftliche Qualität einer Architektur zeigt sich auch daran, wie sie auf neue Anforderungen reagiert.

Unterschiedliche Modernisierungswege

Für bestehende Adobe-Commerce-Landschaften lassen sich mehrere grundsätzliche Optionen unterscheiden.

Der Weiterbetrieb mit gezielter Modernisierung kann sinnvoll sein, wenn die vorhandene Architektur stabil ist und ihre Individualisierungen weiterhin geschäftlichen Wert schaffen.

Ein Upgrade innerhalb der klassischen Architektur kann technische Risiken reduzieren und den unterstützten Produktstand sichern, ohne das gesamte Erweiterungsmodell zu verändern.

Eine neue Storefront kann die Kundenerfahrung modernisieren, während der vorhandene Commerce-Kern bestehen bleibt.

Commerce Optimizer kann ergänzend Discovery und Merchandising weiterentwickeln.

Die Migration zu Adobe Commerce as a Cloud Service ist ein umfassenderer Architekturwechsel, der die Verantwortung für Betrieb und Erweiterbarkeit neu verteilt.

Ein vollständiger Wechsel auf eine andere Commerce-Plattform bildet eine weitere Option.

Diese Wege sind keine gleichwertigen Schritte eines vorgegebenen Migrationspfades.

Jeder besitzt andere Voraussetzungen, wirtschaftliche Folgen und technische Risiken.

Die Auswahl sollte sich deshalb aus konkreten Anforderungen und einer belastbaren Bewertung des vorhandenen Systems ergeben.

10. Strukturelle Grenzen und Kriterien für einen Plattformwechsel

Die Frage nach einem Plattformwechsel wird häufig gestellt, bevor die Ursachen bestehender Probleme ausreichend geklärt sind.

Eine langsame Storefront, hohe Entwicklungskosten oder aufwendige Integrationen können auf strukturelle Architekturgrenzen hinweisen.

Sie können aber ebenso aus unzureichender Implementierung, fehlender technischer Governance oder organisatorischen Problemen entstehen.

Diese Ursachen müssen getrennt bewertet werden.

Fehlende Standardfunktion oder tatsächliche Plattformgrenze

Eine fehlende Standardfunktion bedeutet zunächst, dass eine Anforderung nicht unmittelbar durch die vorhandene Plattformkonfiguration erfüllt wird.

Sie kann möglicherweise über eine unterstützte Erweiterung, eine API oder einen externen Dienst realisiert werden.

Auch ein unzureichendes Frontend rechtfertigt nicht unmittelbar den Austausch des Commerce-Kerns.

Wenn Katalog, Preisberechnung, Checkout und Bestellverarbeitung zuverlässig funktionieren, kann eine gezielte Storefront-Modernisierung wirtschaftlich sinnvoll sein.

Ähnliches gilt für Discovery- und Merchandising-Anforderungen, die durch eine ergänzende Serviceschicht adressiert werden können.

Dagegen lässt sich eine strukturelle Begrenzung nicht immer durch zusätzliche Entwicklung aufheben.

Die Grenzen der einzelnen Adobe-Architekturen

Bei Adobe Commerce as a Cloud Service ist die fehlende Möglichkeit direkter PHP-Kerneingriffe eine dokumentierte Architekturgrenze.

Ob daraus ein geschäftliches Problem entsteht, hängt davon ab, ob sich die betreffende Funktion mit den unterstützten APIs, Events und externen Diensten zuverlässig realisieren lässt.

Auch die begrenzten Möglichkeiten für individuelle Suchindex-Anpassungen und die Anforderungen an externe Datenhaltung können für spezielle Anwendungsfälle relevant werden.

Bei Commerce Optimizer ist die fehlende eigene Transaktionsverantwortung eine klare Produktgrenze.

Die Lösung benötigt für Warenkorb, Checkout und Bestellungen ein entsprechendes Backend.

Sie kann Probleme im Bereich Produkterkennung adressieren, aber nicht sämtliche Defizite einer bestehenden transaktionalen Architektur beheben.

Bei klassischen Adobe-Commerce-Installationen können die Grenzen weniger eindeutig sein.

Ihre umfangreichen Anpassungsmöglichkeiten erlauben viele individuelle Lösungen.

Eine Grenze kann hier vor allem dann entstehen, wenn die kumulierten Kosten, technischen Abhängigkeiten oder Risiken notwendiger Veränderungen wirtschaftlich nicht mehr tragfähig sind.

Nicht jede solche Situation rechtfertigt eine vollständige Ablösung.

Mitunter kann eine gezielte Entkopplung einzelner Funktionen die sinnvollere Lösung sein.

Wann eine Migration zu Cloud Service sinnvoll wird

Eine Migration auf Cloud Service sollte insbesondere dann geprüft werden, wenn die Entlastung vom Betrieb des Commerce-Kerns einen wirtschaftlichen Nutzen verspricht und sich die wesentlichen Geschäftsprozesse mit den verfügbaren SaaS-Erweiterungsmöglichkeiten abbilden lassen.

Dafür müssen bestehende Customizations, Integrationen, Datenmodelle und Storefront-Anforderungen einzeln bewertet werden.

Ebenso sind die Folgen für Datenqualität, Sicherheit, Monitoring und organisatorische Verantwortlichkeiten zu berücksichtigen.

Ein Unternehmen sollte dabei nicht nur die Zielarchitektur betrachten, sondern auch den Weg dorthin.

Während einer Migration müssen bestehende Kunden- und Bestellprozesse weiter funktionieren.

Die Migration von Daten, Integrationen und individuellen Funktionen benötigt deshalb eine kontrollierte Übergangsarchitektur und belastbare Abnahmekriterien.

Wann ein vollständiger Plattformwechsel begründbar ist

Ein Wechsel zu einer anderen Commerce-Plattform kann gerechtfertigt sein, wenn wesentliche Geschäftsanforderungen innerhalb der vorhandenen Architektur nicht mehr angemessen erfüllt werden können.

Dafür reicht die Feststellung, dass eine andere Plattform eine bestimmte Funktion im Standard anbietet, nicht aus.

Zu prüfen ist vielmehr, ob die vorhandene Lösung durch wirtschaftlich vertretbare Erweiterungen oder Modernisierungsschritte weiterhin tragfähig bleibt.

Ein Wechsel kann auch dann sinnvoll werden, wenn die langfristigen Kosten und Risiken der bestehenden Architektur nicht mehr in einem angemessenen Verhältnis zum geschäftlichen Nutzen stehen.

Dazu gehören technische Abhängigkeiten, mangelnde Wartbarkeit, schwer beherrschbare Integrationsrisiken und fehlende interne Fähigkeiten.

Die Entscheidung sollte jedoch die Kosten und Risiken einer Migration selbst ausdrücklich berücksichtigen.

Erst Anforderungen klären, dann Architektur wählen

Eine belastbare Entscheidung beginnt mit den tatsächlich kritischen Geschäftsanforderungen.

Danach folgt die Analyse der bestehenden Systemlandschaft und ihrer Probleme.

Erst wenn klar ist, welche Grenzen technisch, organisatorisch oder wirtschaftlich bedingt sind, können geeignete Modernisierungswege verglichen werden.

Für Adobe Commerce ist diese Reihenfolge besonders wichtig, weil bereits innerhalb des eigenen Produktportfolios mehrere unterschiedliche Architekturentscheidungen möglich sind.

Ein Händler muss daher nicht zwischen unverändertem Weiterbetrieb und vollständiger Ablösung wählen.

Er kann auch gezielt einzelne Komponenten modernisieren, individuelle Funktionen entkoppeln oder den Betriebsansatz verändern.

Die richtige Entscheidung ergibt sich aus den konkreten Anforderungen und der wirtschaftlichen Tragfähigkeit, nicht aus einem allgemeinen Urteil über eine Plattformgeneration.

11. Management-Fazit: Die richtige Form technischer Kontrolle

Adobe Commerce steht heute für unterschiedliche Vorstellungen von Flexibilität.

Die klassische Magento-Architektur ermöglicht weitreichende Eingriffe in Geschäftslogik, Datenmodell und technische Abläufe.

Diese Freiheit kann für komplexe Handelsmodelle wertvoll sein. Sie verlangt allerdings dauerhaft Kompetenzen für Entwicklung, Sicherheit, Betrieb und Modernisierung.

Adobe Commerce as a Cloud Service verfolgt einen stärker standardisierten Ansatz.

Der Hersteller übernimmt Verantwortung für den Plattformkern, während individuelle Funktionen über definierte Schnittstellen und externe Dienste realisiert werden.

Dadurch können bestimmte Betriebsaufgaben entfallen. Gleichzeitig verändert sich die Art technischer Abhängigkeiten.

Adobe Commerce Optimizer eröffnet einen zusätzlichen Modernisierungspfad, bei dem Produkterkennung und Merchandising weiterentwickelt werden können, ohne den transaktionalen Commerce-Kern grundsätzlich zu ersetzen.

Für Unified Commerce bleibt entscheidend, wie zuverlässig Adobe Commerce mit ERP, OMS, POS, Bestandsmanagement und Customer Service zusammenarbeitet.

Eine umfangreiche Experience Cloud ersetzt keine klare operative Verantwortung.

Agentic Commerce erhöht die Anforderungen an Datenzugang, Schnittstellen, Identität und Autorisierung.

Die heute dokumentierten Adobe-Funktionen bilden dafür unterschiedliche technische Grundlagen, belegen aber noch keine vollständig allgemein verfügbare Architektur für autonome Käufe innerhalb delegierter Kundenmandate.

Aus diesen Entwicklungen ergibt sich weder, dass klassische Adobe-Commerce-Installationen überholt sind, noch dass eine neue SaaS-Architektur zwangsläufig wirtschaftlicher wäre.

Die entscheidende Frage ist, an welchen Stellen ein Handelsunternehmen technische Kontrolle benötigt, wo Standardisierung sinnvoll ist und welche Architektur diese Unterscheidung langfristig wirtschaftlich trägt.

Wer Adobe Commerce bewertet, sollte deshalb nicht nur Funktionen und Lizenzmodelle gegenüberstellen.

Er sollte verstehen, welche Systeme die Geschäftsprozesse verantworten, wie sich bestehende Individualisierungen weiterentwickeln lassen und welche Kosten zukünftige Veränderungen verursachen.

Erst daraus entsteht eine belastbare Entscheidung über Weiterbetrieb, Modernisierung, Migration oder Plattformwechsel.

---

Quellen und Methodik

Recherchestichtag: 28. Oktober 2026

Diese Analyse basiert auf öffentlich zugänglicher technischer Dokumentation, Produktinformationen und Release Notes von Adobe sowie einer unabhängigen fachlichen Bewertung der daraus entstehenden Architektur- und Betriebsfolgen.

Die herstellerseitig dokumentierte Verfügbarkeit einer Funktion wird von deren praktischer Eignung in einer konkreten Implementierung unterschieden.

Wirtschaftliche Schlussfolgerungen zu Betriebsaufwand, Integrationskomplexität und zukünftigen Änderungskosten beruhen auf der Analyse der dokumentierten Architekturmodelle. Sie sind keine unabhängig gemessenen Vergleichswerte.

Für allgemeine Implementierungsbudgets, Projektlaufzeiten oder Performancevergleiche liegen keine hinreichend belastbaren, vergleichbaren unabhängigen Nachweise vor. Deshalb werden keine pauschalen Werte angegeben.

Die wesentlichen Primärquellen sind:

Produktidentität und Architektur

1. Adobe Experience League. Choose a Commerce Option. Produktvarianten, transaktionale Verantwortung und Integrationsgrenzen. Aktualisiert im Oktober 2026.
https://experienceleague.adobe.com/en/docs/commerce/information-center/explore-platforms-and-services/choose-commerce-option

2. Adobe Experience League. Adobe Commerce Platforms and Services. Abgrenzung der klassischen, SaaS- und Optimizer-Angebote.
https://experienceleague.adobe.com/en/docs/commerce/information-center/explore-platforms-and-services/platform-and-services

3. Adobe Experience League. Adobe Commerce SaaS vs. PaaS Feature Comparison. Erweiterungsmodelle, Datenhaltung, Betriebsverantwortung und Funktionsunterschiede. Aktualisiert am 20. Oktober 2026.
https://experienceleague.adobe.com/en/docs/commerce/cloud-service/feature-comparison

Release- und Supportinformationen

4. Adobe Experience League. Released Versions. Produktversionen und Supportfristen.
https://experienceleague.adobe.com/en/docs/commerce-operations/release/versions

5. Adobe Experience League. Adobe Commerce 2.4.9 Release Notes. Technische Weiterentwicklung der klassischen Commerce-Architektur.
https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9

Migration und Erweiterbarkeit

6. Adobe Experience League. Migrate to Adobe Commerce as a Cloud Service. Anwendung, Daten, Storefront und Integrationen.
https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview

Commerce Optimizer

7. Adobe Experience League. Adobe Commerce Optimizer Connector. Synchronisierung, Systemverantwortung und unterstützte Anwendungsszenarien.
https://experienceleague.adobe.com/en/docs/commerce/aco-optimizer-connector/overview

8. Adobe Experience League. Adobe Commerce Optimizer Limits and Boundaries. Lizenzabhängige Kapazitäten und technische Systemgrenzen. Aktualisiert am 21. Oktober 2026.
https://experienceleague.adobe.com/en/docs/commerce/optimizer/boundaries-limits

9. Adobe Experience League. Salesforce Commerce Connector for Adobe Commerce Optimizer. Drittanbieterintegration und deren Grenzen.
https://experienceleague.adobe.com/en/docs/commerce/optimizer/developer/salesforce-connector

Unified Commerce

10. Adobe Experience League. Implementation Playbook Glossary. Produktstatus des früheren Adobe Commerce Order Management.
https://experienceleague.adobe.com/en/docs/commerce-operations/implementation-playbook/glossary

Agentic Commerce

11. Adobe Experience League. Commerce MCP Overview. Dialogbasierte Commerce-Funktionen und dokumentierter Entwicklungsstatus. Aktualisiert am 8. Oktober 2026.
https://experienceleague.adobe.com/en/docs/commerce-learn/ai-and-agentic-commerce/commerce-mcp/commerce-mcp-overview

12. Adobe Experience League. Brand Concierge Documentation. Produktdiscovery, Commerce-Integration und dokumentierter Funktionsumfang.
https://experienceleague.adobe.com/en/docs/brand-concierge/content/documentation/concierge-management/concierge-management

13. Adobe Business Blog. Adobe Commerce Commits to Agentic Commerce Standards. Offizielle Positionierung zu UCP, ACP und AP2 vom 18. Februar 2026.
https://business.adobe.com/blog/adobe-commerce-commits-to-agentic-commerce-standards

Die Quellen dokumentieren den zum Recherchestichtag öffentlich nachvollziehbaren Produktstand.

Produktfunktionen, Roadmaps, Lizenzbedingungen und regionale Verfügbarkeiten können sich verändern.

Eine konkrete Architektur- oder Plattformentscheidung erfordert deshalb die Prüfung der jeweils aktuellen technischen, organisatorischen und vertraglichen Voraussetzungen.

---

Über den Autor

Andreas Rieger ist unabhängiger E-Commerce-Berater mit mehr als 20 Jahren Erfahrung in digitalen Handelsmodellen, Plattformarchitekturen und der Weiterentwicklung komplexer Commerce-Organisationen.

Er berät Unternehmen herstellerneutral bei der Bewertung bestehender Systemlandschaften und der strukturierten Auswahl geeigneter E-Commerce-Plattformen.

Weitere Informationen zur neutralen Plattformauswahl und Architekturberatung.