Adobe Commerce sollte als Betriebsumgebung für Enterprise Commerce geplant werden, nicht lediglich als größere Storefront aus der Magento-Familie. Bei einer Migration zu Adobe Commerce können gewöhnliche Commerce-Datensätze wie Products, Categories, Customers, Orders, Reviews, Coupons, CMS Pages und Blog Posts übertragen werden. Häufig kommt jedoch eine stärkere Ebene der geschäftlichen Governance hinzu: Unternehmenskonten, Käuferrollen, Shared Catalogs, Angebotsprozesse, Regeln für Bestellungen, Storefronts mit unterschiedlichem Scope, geplante Inhalte, benutzerdefinierte Module und Abhängigkeiten von externen Systemen.
Diese Enterprise-Ebene verändert den Ausgangspunkt der Migrationsplanung. Entscheidend ist nicht nur, ob Quelldatensätze übertragen werden können. Wichtiger ist, ob die migrierten Datensätze nach dem Launch die erwarteten Handelsregeln, Käuferbeziehungen, Storefront-Scope-Strukturen, Preislogik, Content-Prozesse und Integrationsverantwortlichkeiten unterstützen.
Adobe Commerce basiert wie Magento Open Source auf der Magento-Familie. Deshalb bleiben Produkttypen, Attribute, Attribute Sets, Website-/Store-/Store-View-Scope, Categories, URLs und durch Extensions geprägte Anpassungen relevant. Der Unterschied besteht darin, dass Adobe Commerce auf diesen Strukturen häufig zusätzliche Anforderungen des Enterprise-Betriebs aufbaut. Die Migrationsplanung sollte die Datendisziplin der Magento-Familie beibehalten und zugleich B2B, Governance, Staging, Skalierung und organisatorische Verantwortlichkeit stärker berücksichtigen.
Adobe Commerce als unternehmensweite Zielplattform
Adobe Commerce wird typischerweise gewählt, wenn der Zielshop mehr betriebliche Steuerung benötigt als eine kleine Katalog-Storefront. Unternehmen können B2B-Kontostrukturen, vertraglich geprägte Katalogsichtbarkeit, unternehmensspezifische Einkaufsregeln, mehrere Storefronts, lokalisierte Inhalte, gesteuertes Merchandising, formellere Freigabeprozesse sowie Integrationen mit ERP-, PIM-, CRM-, Steuer-, Lager-, Marketplace-, Analytics- oder Marketingsystemen benötigen.
Damit wird die Migration zu einer Aufgabe der Geschäftsstruktur. Produktdaten, Kundendatensätze, Bestellhistorie und Inhalte bleiben wichtig, müssen aber im Kontext der Adobe-Commerce-Umgebung bewertet werden, die diese Informationen später verwendet.
| Adobe-Commerce-Bereich | Bedeutung für die Migration | Frühe Planungsentscheidung |
|---|---|---|
| Website-, Store- und Store-View-Scope | Storefronts können Regionen, Marken, Sprachen, Geschäftsmodelle oder Katalogkontexte darstellen. | Festlegen, welche Werte global, auf Website-, Store- oder Store-View-Ebene gelten. |
| Produkttypen und Attribute | Die Produktstruktur kann Varianten, Filterung, Suche, Merchandising und Integrationen beeinflussen. | Produkttypen, Attribute und Attribute Sets vor der Migration klassifizieren. |
| B2B-Unternehmenskonten | Geschäftskunden können Unternehmensadministratoren, Benutzer, Berechtigungen, Kredit, Angebote und Bestellanforderungen haben. | Klären, ob Quelldaten zu Customers Einzelkonten, Unternehmensdaten oder benutzerdefinierte Beziehungsdaten darstellen. |
| Shared Catalogs und Preise | Produktsichtbarkeit und Preise können sich je nach Käuferkontext unterscheiden. | Klären, ob Preislisten, Customer Groups oder Vertragspreise aus der Quelle unterstütztes Mapping, Konfiguration oder eine Prüfung außerhalb des Standardscope benötigen. |
| Content Staging | Änderungen an Merchandising und Inhalten können terminiert werden. | Migrierte Inhalte von zielseitiger Kampagnenplanung und Governance trennen. |
| Extensions und Integrationen | Enterprise-Shops hängen häufig von Modulen und externen Systemen ab. | Nicht unterstützte Extension-Datensätze, externe IDs und benutzerdefinierte Workflows früh identifizieren. |
Adobe Commerce kann anspruchsvolle Commerce-Abläufe unterstützen. Die Qualität der Migration hängt jedoch davon ab, ob die Zielstrukturen vor einer umfassenden Migration definiert wurden. Ohne diese Entscheidungen können Daten zwar in Adobe Commerce vorhanden sein, das vorgesehene Geschäftsmodell aber dennoch verfehlen.
Die Grundlage der Magento-Familie bleibt wichtig
Adobe Commerce gehört zur Architektur der Magento-Familie. Viele Migrationsfragen aus Magento Open Source bleiben deshalb relevant: Produkttypen, Attribute, Attribute Sets, Categories, Store-Hierarchie, URL Rewrites, Customer Groups, Bestellhistorie, Annahmen zum Bestand, Module und benutzerdefinierte Felder.
Ein Fehler wäre, daraus abzuleiten, dass die Planung für Magento Open Source unverändert übernommen werden kann. Adobe Commerce ergänzt Enterprise-Anforderungen. Ein Quellprodukt braucht weiterhin den richtigen Produkttyp der Magento-Familie, kann aber zusätzlich käuferspezifische Sichtbarkeit oder Preise aus Shared Catalogs benötigen. Ein Customer-Datensatz braucht weiterhin korrekte Profildaten, kann aber außerdem Unternehmenszugehörigkeit, Kontorollen, Einkaufsberechtigungen oder den Kontext eines Vertriebsmitarbeiters erfordern. Eine CMS Page kann migriert werden, während der Zeitpunkt ihrer Veröffentlichung zusätzlich durch Staging oder Kampagnen-Governance bestimmt wird.
Die Verwandtschaft sollte daher als Abgrenzung genutzt werden:
| Gemeinsames Thema der Magento-Familie | Enterprise-Erweiterung in Adobe Commerce |
|---|---|
| Configurable Products und zugehörige Simple Products | Käuferspezifische Sichtbarkeit, B2B-Preise, kontobasierte Bestellungen und repräsentative Enterprise-Validierung. |
| Attribute und Attribute Sets | Katalog-Governance über Abteilungen, Integrationen sowie PIM- oder ERP-Verantwortlichkeiten hinweg. |
| Website-/Store-/Store-View-Scope | Trennung nach Marken, Regionen, Sprachen und B2B-/B2C-Storefronts. |
| Customer Groups | Zuweisung von Shared Catalogs, Verhalten von Unternehmenskonten, Preise, Steuern und Handelsregeln. |
| URL Rewrites und CMS-Inhalte | SEO-Kontinuität plus Kampagnenzeitpunkt, gestaffelte Inhalte und Enterprise-Freigaben. |
| Extensions und benutzerdefinierte Daten | Prüfung eines individuell vereinbarten Scope, wenn Module oder externe Systeme geschäftskritische Datensätze verwalten. |
Diese Abgrenzung hält die Darstellung von Adobe Commerce präzise. Adobe Commerce ist nicht lediglich „Magento mit mehr Funktionen“. Es ist eine Zielplattform, auf der das Datenmodell der Magento-Familie häufig Enterprise-Governance unterstützen muss.
Storefront-Scope und Geschäftsstruktur
Scope-Entscheidungen sollten bei Adobe Commerce früh getroffen werden, weil sie das Verhalten migrierter Datensätze verändern können. Ein Unternehmen kann getrennte Websites für Marken, Länder, Geschäftsbereiche, B2B- und B2C-Kanäle, Basiswährungen, Steuerkontexte oder die Trennung von Kundenkonten einsetzen. Stores können über Root Categories die Katalognavigation steuern. Store Views dienen häufig Sprachen und lokalisierter Darstellung.
Quellshops trennen diese Konzepte nicht immer auf dieselbe Weise. Eine Quellplattform kann Sprachwerte in einem Übersetzungs-Plugin, Markenwerte in Categories, regionale Preise in benutzerdefinierten Feldern, Kundensichtbarkeit in einer App und B2B-Berechtigungen in einem separaten System speichern. Werden solche Werte ohne Adobe-Commerce-Scope-Plan migriert, kann das Ergebnis vollständig aussehen und dennoch kommerziell falsch sein.
Die Scope-Planung sollte praktische Fragen beantworten:
| Scope-Frage | Warum sie wichtig ist |
|---|---|
| Welche Websites wird es zum Launch geben? | Die Website-Struktur kann Kontotrennung, Handelskontext, Währung und Konfiguration beeinflussen. |
| Welche Stores und Root Categories unterstützen jede Storefront? | Navigation und Katalogorganisation können sich nach Geschäftsbereich oder Region unterscheiden. |
| Welche Store Views benötigen lokalisierte Werte? | Produktnamen, Beschreibungen, URLs, Metadaten, CMS Pages und Blog Posts können sprachspezifische Behandlung erfordern. |
| Welche Werte gelten global und welche innerhalb eines Scope? | Falsche Vererbung kann lokalisierte oder geschäftsspezifische Daten überschreiben. |
| Welche Strukturen der Quellplattform sind kein echter Adobe-Commerce-Scope? | Categories, Tags, Customer Groups oder benutzerdefinierte Felder können fälschlich als Websites oder Store Views interpretiert werden. |
Ein Migrationsplan sollte nicht alle Datensätze in einen Default-Scope fallen lassen, sofern das Unternehmen diese Struktur nicht bewusst gewählt hat.
Katalog-Governance und Produktbedeutung
Katalog-Governance in Adobe Commerce beginnt mit der Bedeutung der Produkte. Simple, Configurable, Grouped, Bundle, Virtual, Downloadable und Gift Card Products können unterschiedliche Migrationsfolgen haben. Configurable Products sind besonders wichtig, weil das sichtbare Parent Product und die zugeordneten Simple Products SKU, Optionen, Preis, Bilder und Bestandsbedeutung so bewahren müssen, dass Käufer und Administratoren sie sinnvoll nutzen können.
Auch Attribute und Attribute Sets brauchen Governance. Attribute können Produktseiten, Suche, Layered Navigation, Produktvergleich, Promotions, Reporting oder Integrationslogik unterstützen. In einer Enterprise-Umgebung verursacht ein schlecht migriertes Attribut mehr als kosmetische Unordnung. Es kann Produktsuche, PIM-Abgleich, ERP-Referenzen, Angebotsgenauigkeit, Marketplace-Exporte oder interne Pflege beeinträchtigen.
Die Katalogplanung sollte Darstellungsdaten von Betriebsdaten unterscheiden:
| Art des Quellfelds | Planungsfrage für Adobe Commerce |
|---|---|
| Produktspezifikationen | Soll der Wert für Kunden sichtbar, suchbar, filterbar, vergleichbar oder nur intern sein? |
| Variantensteuernde Optionen | Soll der Wert Configurable Products oder eine andere Produktstruktur unterstützen? |
| B2B-Preis- oder Verfügbarkeitskennzeichen | Gehören sie zu Shared Catalogs, Customer Groups, benutzerdefinierter Logik oder externen Systemen? |
| ERP-/PIM-/Marketplace-IDs | Sollen sie in unterstützte Felder gemappt, durch unterstütztes Mapping oder Konfigurationsanpassungen erhalten oder außerhalb des Standardscope behandelt werden? |
| Alte oder doppelte Attribute | Sollen sie bereinigt, zusammengeführt, ausgeschlossen oder für historische Referenz erhalten werden? |
Bei einer Adobe-Commerce-Migration sollte nicht die Zahl der migrierten Felder maximiert werden. Erhalten werden sollten die Felder, die das Katalog-Governance-Modell der Zielumgebung unterstützen.
B2B-Unternehmenskonten und Käuferbeziehungen
B2B ist häufig die deutlichste Abgrenzung von Adobe Commerce gegenüber Magento Open Source. Unternehmenskonten können Unternehmensadministratoren, Benutzer, Rollen, Berechtigungen, Unternehmenskredit, Bestellprozesse, Angebotsberechtigungen, Zahlungs- und Versandbeschränkungen sowie Beziehungen zu Shared Catalogs umfassen. Diese Strukturen verändern die Bedeutung der Customer-Migration.
Ein Customer aus der Quelle ist nicht automatisch ein Unternehmenskonto. Eine Wholesale Customer Group ist nicht automatisch eine Käuferhierarchie. Eine Händlerpreisliste entspricht nicht zwangsläufig einem Shared Catalog. Ein Feld für Vertriebsmitarbeiter ist nicht automatisch eine native Adobe-Commerce-Unternehmenszuordnung. Diese Unterschiede sollten geprüft werden, bevor der Migrationsscope akzeptiert wird.
Für die B2B-Migrationsplanung sollten repräsentative Beispiele vorbereitet werden:
| B2B-Beispiel | Nutzen für die Migration |
|---|---|
| Unternehmen mit einem Administrator und mehreren Käufern | Prüft Erwartungen an Kontohierarchie und Benutzerbeziehungen. |
| Unternehmen mit käuferspezifischer Preisgestaltung oder Produktsichtbarkeit | Prüft Auswirkungen auf Shared Catalogs oder Customer Groups. |
| Customer mit Angebots- oder Bestellworkflow | Zeigt zielseitige Konfigurations- und Validierungsanforderungen. |
| Unternehmen mit Kredit oder eingeschränkten Zahlungs-/Versandmethoden | Trennt historische Daten von der aktiven kommerziellen Einrichtung. |
| B2B-Quelldatensatz, der durch benutzerdefinierte Felder oder externes CRM/ERP gesteuert wird | Zeigt den Bedarf an individueller Scope- oder Integrationsprüfung. |
Der Erfolg einer B2B-Migration wird nicht durch die Anzahl von Customer-Datensätzen bewiesen. Er zeigt sich, wenn Käufer sich anmelden, den richtigen Katalog und die richtigen Preise sehen, die vorgesehenen Berechtigungen nutzen und der geschäftliche Einkaufsprozess nach dem Launch funktioniert.
Content Staging, Merchandising und Launch-Zeitpunkt
Adobe Commerce Content Staging kann beeinflussen, wie Teams den Launch-Zeitpunkt planen. Products, Categories, Cart Price Rules, Catalog Price Rules, CMS Pages, CMS Blocks und Widgets können Teil geplanter Merchandising- oder Content-Kampagnen sein. Die Migration darf nicht davon ausgehen, dass mit der Übertragung von Inhalten automatisch auch die Kampagnen-Governance rekonstruiert wird.
Ein Quellshop kann geplante Promotions, saisonale Landing Pages, zukünftige Produktlaunches, Kampagnenbanner oder Content-Revisionen verwenden, die über Apps oder redaktionelle Workflows verwaltet werden. Die Migrationsplanung sollte diese Erwartungen klassifizieren. Manche Inhalte sollten als Datensätze migriert werden. Andere müssen in Adobe Commerce neu aufgebaut oder geplant werden. Wieder andere erfordern eine manuelle Prüfung, weil der Quellworkflow kein direktes Gegenstück in der Zielumgebung hat.
Die Launch-Planung sollte deshalb unterscheiden:
| Content- oder Merchandising-Element | Planungsbehandlung |
|---|---|
| Gewöhnliche CMS Pages und Blog Posts | Soweit unterstützt migrieren und Inhalte, URLs sowie Metadaten validieren. |
| Geplante Promotions | Klären, ob Regeln migriert werden, zielseitig eingerichtet oder Kampagnen manuell neu aufgebaut werden müssen. |
| Saisonale Landing Pages | URL-Kontinuität, Content Blocks, Medien und Launch-Zeitpunkt validieren. |
| Page-Builder- oder App-eigene Inhalte | Auf unterstützten Scope, manuellen Neuaufbau oder nicht standardmäßige Behandlung prüfen. |
| Kampagnen-Governance | Als zielseitige Workflow-Planung behandeln, nicht lediglich als Datenübertragung. |
Content Staging bietet Mehrwert, wenn der Händler es gezielt einsetzen kann. Es wird zum Risiko, wenn Teams annehmen, dass die Terminierungslogik der Quelle mit übertragen wurde, nur weil Inhaltsdatensätze im Zielshop vorhanden sind.
Integrationen und Enterprise-Verantwortung
Adobe-Commerce-Projekte hängen häufig von Systemen außerhalb der Storefront ab. ERP kann Product-IDs, Kundenkonten, Rechnungen oder Bestand verwalten. PIM kann Attribute und Produktinhalte verwalten. CRM kann Unternehmensbeziehungen oder Vertriebszuordnungen verwalten. Steuer- und Versandsysteme können Checkout-Entscheidungen steuern. Marketplace-, Analytics-, Loyalty-, Subscription- oder Marketingtools können Datensätze verwalten, die wie Commerce-Daten aussehen, aber keine nativen Plattformdaten sind.
Vor der Wahl des Migrationspfads sollte die Migrationsplanung den Datenverantwortlichen bestimmen. Zeigt die Quellplattform lediglich einen Wert an, der von einem anderen System verwaltet wird, erhält die Übertragung des sichtbaren Felds den Geschäftsprozess möglicherweise nicht. Hat ein Modul die Daten erzeugt, sind sie unter Umständen nicht im Standardexport enthalten. Schreibt eine benutzerdefinierte Integration Werte in private Felder, können eine Prüfung außerhalb des Standardscope oder separate Implementierungsarbeiten nötig sein.
Die Planungsabgrenzung ist klar:
| Anforderung | Bessere Einordnung |
|---|---|
| Unterstützter Datensatz erfordert Filter- oder Mapping-Anpassung | Benötigte Filterung oder das Mapping ausdrücklich planen. |
| Unterstützter Datensatz erfordert konfigurationsbewusste Behandlung | Migrationsbehandlung von zielseitiger Konfiguration trennen. |
| Extension- oder App-eigene Datensätze müssen erhalten werden | Erfordert Prüfung außerhalb des Standardscope. |
| Kennungen externer Systeme müssen operativ nutzbar bleiben | Individuelle Scope- oder Integrationsprüfung. |
| Aktive Integration muss nach der Migration verbunden werden | Zielseitige Implementierung, nicht allein migrierte Daten. |
Adobe Commerce gibt Unternehmen die Flexibilität für komplexe Betriebsmodelle. Diese Flexibilität hilft jedoch nur, wenn Datenverantwortung und Integrationszuständigkeit klar festgelegt sind.
Fazit
Die Planung einer Adobe-Commerce-Migration sollte mit dem Enterprise-Betriebsmodell beginnen, das der Zielshop unterstützen muss. Product-Datensätze, Customer-Profile, Orders, Categories, CMS Pages, Blog Posts und URLs bleiben wichtig, bilden aber nur einen Teil des Gesamtbilds. Der Migrationsplan muss auch B2B-Unternehmenskonten, Shared Catalogs, Storefront-Scope, Beziehungen zwischen Configurable Products, Attribute und Attribute Sets, Content Staging, Integrationen, benutzerdefinierte Module und Validierungsverantwortung berücksichtigen.
Eine gute Adobe-Commerce-Migration ist nicht die breitestmögliche Datenübertragung. Sie ist ein kontrollierter Wechsel in eine Enterprise-Commerce-Umgebung, in der migrierte Datensätze, Zielkonfiguration, vereinbarter Migrationsscope und geschäftliche Validierung nach dem Launch dasselbe Handelsmodell unterstützen.
Häufige Fragen
Wie unterscheidet sich Adobe Commerce bei der Migrationsplanung von Magento Open Source?
Adobe Commerce teilt die Grundlage der Magento-Familie, verlangt bei der Migrationsplanung jedoch meist stärkere Aufmerksamkeit für Enterprise-Funktionen wie B2B-Unternehmenskonten, Shared Catalogs, Angebots- und Bestellworkflows, Content Staging, Governance und Integrationen.
Erfordert jede Adobe-Commerce-Migration eine B2B-Planung?
Nein. Manche Adobe-Commerce-Shops sind hauptsächlich B2C- oder Content-orientiert. B2B-Planung wird wichtig, wenn das Quellgeschäft Unternehmenskonten, Wholesale-Käufer, Händlerpreise, vertriebsunterstützten Einkauf, Angebotsworkflows oder kontospezifischen Katalogzugriff nutzt.
Warum ist der Storefront-Scope bei einer Adobe-Commerce-Migration wichtig?
Website-, Store- und Store-View-Scope können Katalogzuordnung, lokalisierte Inhalte, URLs, Währung, Konfiguration und Käuferkontext beeinflussen. Werden Daten in den falschen Scope migriert, kann der Zielshop vollständig aussehen und dennoch falsch funktionieren.
Wie sollten benutzerdefinierte Daten in Adobe Commerce behandelt werden?
Unterstütztes Mapping oder Konfigurationsanpassungen können klar abgegrenzte Anforderungen an Filterung, Mapping oder Konfiguration abdecken. Nicht unterstützte Extension-Daten, benutzerdefinierte Felder, Kennungen externer Systeme, individuelle Transformationen sowie komplexe B2B- oder Integrationslogik erfordern eine Prüfung außerhalb des Standardscope.
Was sollte nach einem repräsentativen Adobe-Commerce-Test zuerst validiert werden?
Beginnen Sie mit repräsentativen Beispielen für Katalog, Scope, Customers, Unternehmen, Shared Catalogs, URLs und integrationsabhängige Daten. Ziel ist der Nachweis, dass die Datensätze die benötigten Adobe-Commerce-Funktionen unterstützen, nicht nur, dass die Datensatzanzahl übereinstimmt.