Für Adobe Commerce sollte der Migrationsansatz aus dem geplanten Betriebsmodell abgeleitet werden und nicht nur aus der Anzahl der Datensätze. Adobe Commerce kann Configurable Products, mehrere Websites, Stores und Store Views, B2B-Company-Accounts, Shared Catalogs, unternehmensspezifische Preise, Kundengruppen, Content Staging, Custom Attributes, Integrationen und Extension-eigene Datensätze kombinieren. Der Service-Pfad muss deshalb unterscheiden, welche Strukturen gewöhnliche unterstützte Daten sind, welche Zielkonfiguration benötigen, welche durch klar begrenzte Add-ons abgedeckt werden können und welche eine individuelle Prüfung über Custom Service erfordern.
Ein großes Adobe-Commerce-Projekt benötigt nicht automatisch den komplexesten Service. Standard Service kann passend bleiben, wenn der Migrationspfad unterstützt wird, Quelldatensätze erkennbare Strukturen verwenden und der Kunde den Service selbstständig bedienen und validieren kann. Managed Service gewinnt an Wert, wenn Koordination und Validierungsaufwand hoch sind. Add-ons adressieren klar abgegrenzte unterstützte Anforderungen an Datensatzfilterung, Feldwert-Transformation oder Feld-Neuzuordnung. Custom Service ist der richtige Eskalationspfad, wenn das gewünschte Ergebnis von nicht unterstützten Datensätzen, Custom Modules, individuellen Transformationen, nicht standardisierten B2B-Strukturen, Kennungen externer Systeme oder eigener Migrationslogik abhängt.
Innerhalb der Next-Cart Migration Services trennt diese Evidenz unterstützten Scope, Ausführungsverantwortung, begrenzte Add-on-Anforderungen und individuell zu prüfende Adobe-Commerce-Anforderungen.
Mit dem Adobe-Commerce-Betriebsmodell beginnen
Adobe-Commerce-Projekte sollten nach dem Betriebsmodell klassifiziert werden, das die Zielplattform unterstützen muss. Ein B2C-Shop mit einer Marke, einer Website und konventionellen Produkten führt zu einer anderen Migrationsentscheidung als eine Enterprise-Implementierung mit mehreren Websites, regionalen Store Views, Company Accounts, Shared Catalogs, käuferspezifischen Preisen und eng verbundenen ERP- oder PIM-Systemen.
Adobe Commerce verwendet eine Hierarchie aus Website, Store und Store View. Websites können eigene Domains und Checkout-Scopes haben. Stores können unterschiedliche Root Categories verwenden. Store Views unterstützen häufig Sprach- oder Darstellungsvarianten. B2B Shared Catalogs können steuern, welche Produkte und Preise den zugeordneten Unternehmen sichtbar sind. Diese Strukturen gehören zur Zielarchitektur und sind nicht nur Labels auf migrierten Datensätzen.
| Frage zum Betriebsmodell | Signal für geringere Komplexität | Signal für höhere Komplexität |
|---|---|---|
| Website- und Store-Scope | Eine Website, ein Store, wenige Store Views | Mehrere Websites, regionale Stores, unterschiedliche Root Categories, separate Domains oder Scope-spezifische Konfiguration |
| Katalogstruktur | Simple und Configurable Products mit erkennbaren Attributen | Bundles, Grouped Products, Custom Product Types, komplexe Attribute Sets, gestagte Inhalte oder Extension-erzeugte Beziehungen |
| Kundenmodell | Gewöhnliche Kunden und Kundengruppen | Companies, Company Users, Shared Catalogs, verhandelte Preise, Berechtigungen, Kredit oder Genehmigungsabläufe |
| Integrationsverantwortung | Wenige externe Referenzen | ERP, PIM, OMS, WMS, CRM, Marketplace, Tax, Payment oder Fulfillment steuern geschäftskritische Werte |
| Anpassung | Standardfelder und unterstützte Datensätze | Custom Modules, Datenbankspalten, Extension Tables, Custom APIs, individuelle Workflows oder Kennungen externer Systeme |
Der Migrationsansatz sollte erst ausgewählt werden, wenn dieses Modell dokumentiert ist. Andernfalls kann ein Projekt als Standard-Katalogtransfer eingeordnet werden, obwohl das Unternehmen erwartet, dass Enterprise-B2B- und Multi-Site-Funktionen automatisch betriebsbereit werden.
Wann Standard Service passend sein kann
Standard Service eignet sich, wenn der Migrationspfad von der Quellplattform zu Adobe Commerce unterstützt wird, die Daten über die unterstützte Verbindung zugänglich sind und das gewünschte Ergebnis innerhalb des Standard-Migrationsverhaltens liegt. Bei diesem Next-Cart-Service bleibt der Kunde für Vorbereitung, Verbindungsdaten, Konfigurationsentscheidungen, Ausführungsentscheidungen und Validierung verantwortlich.
Ein guter Kandidat für Standard Service besitzt typischerweise:
- einen klaren Scope für Produkte, Kunden, Bestellungen und Inhalte;
- erkennbare Produkttypen und Variantenbeziehungen;
- konsistente SKUs und Produktkennungen;
- nachvollziehbare Kategorien, Attribute und Attributwerte;
- gewöhnliche Kunden- und Adressdatensätze;
- historische Bestellungen ohne verborgenen, für die Interpretation notwendigen Kontext externer Systeme;
- eine definierte Zuordnung zu Website, Store und Store View;
- keine Erwartung, dass Extensions, B2B-Module oder Integrationen durch die Standard-Datenmigration neu aufgebaut werden;
- ein Team, das Demo Migration und Full Migration detailliert prüfen kann.
Standard Service sollte nicht allein wegen eines großen Katalogs ausgeschlossen werden. Das Datenvolumen wird über den gewählten Entity Points Plan abgedeckt. Entscheidend ist vielmehr, ob die Datensätze in unterstützten Strukturen bleiben und ob der Kunde das Ergebnis selbstständig validieren kann.
Schwächer passt Standard Service, wenn Produkte von Custom Types abhängen, Unternehmenspreise außerhalb erkennbarer B2B-Strukturen gespeichert sind, externe Kennungen Fulfillment steuern oder der Händler erwartet, dass Zielkonfiguration und Modulimplementierung automatisch aus dem Datentransfer entstehen.
Wann Managed Service die sicherere Wahl ist
Managed Service ist sinnvoll, wenn die Migration weitgehend im unterstützten Verhalten bleibt, der Kunde aber Next-Cart-Spezialisten für Ausführung und strukturierte Koordination benötigt. Das kann den operativen Druck bei großen Katalogen, mehreren Business-Teams, engen Launch-Fenstern oder hohem Validierungsaufwand reduzieren.
Managed Service ist häufig sinnvoller, wenn:
- Katalog-, Kunden- und Bestellvolumen einen hohen Prüfaufwand verursachen;
- mehrere Websites, Stores oder Store Views von unterschiedlichen Ownern validiert werden müssen;
- Business-Teams einen koordinierten Migrationszeitplan benötigen;
- B2B-, regionale oder Channel-Stakeholder repräsentative Stichproben freigeben müssen;
- die Quelldaten verständlich, aber uneinheitlich genug für sorgfältige operative Prüfung sind;
- der Händler Konfiguration und Ausführung nicht sicher allein steuern kann;
- das Launch-Fenster kontrolliertes Issue Tracking und Eskalation erfordert.
Managed Service erweitert die Standardunterstützung nicht automatisch. Er verändert, wer Ausführung und Koordination übernimmt. Wenn das gewünschte Ergebnis nicht unterstützte Company-Strukturen, Custom-Module-Daten, individuelle Transformationen oder nicht standardisierte externe Beziehungen umfasst, kann für diese Anforderungen weiterhin Custom Service erforderlich sein.
Eine hilfreiche Entscheidungsregel ist die Trennung von Ausführungsaufwand und Anpassungsaufwand. Managed Service adressiert den ersten, Custom Service den zweiten. Manche Enterprise-Projekte benötigen beides: verwaltete Ausführung und separat vereinbarte Anpassungen.
Wo Add-ons passen
Add-ons sind geeignet, wenn die Hauptmigration Standard bleibt, aber eine klar begrenzte unterstützte Anforderung das gewünschte Ergebnis verändert. Für Adobe Commerce sind insbesondere Datensatzfilterung anhand von Feldbedingungen je Datenkategorie, ausdrucksbasierte Transformation von Feldwerten und Neuzuordnung unterstützter Quellfelder relevant.
Beispiele für Adobe Commerce können sein:
- Product-Feldbedingungen, um inaktive oder obsolete Produkte auszuschließen;
- Customer- oder Order-Feldbedingungen, um Testkunden oder irrelevante historische Bestellungen auszuschließen;
- Ausdrücke, um unterstützte Feldwerte während der Migration zu verändern;
- unterstützte Standardfelder von Products, Categories, Customers oder Orders auf kompatible unterstützte Zielfelder umzuleiten, ohne den Wert zu verändern;
- ausgewählte Inhalts- oder SEO-bezogene Informationen zu erhalten, sofern der Migrationspfad dies unterstützt;
- Data Filter, Advanced Data Mapping oder Data Transformation für einen klar definierten unterstützten Bedarf einzusetzen.
Add-ons dürfen nicht als Sammelbegriff für jede komplexe Adobe-Commerce-Anforderung verwendet werden. Die Neuzuordnung eines unterstützten Feldes unterscheidet sich vom Auslesen von Datensätzen aus einem Custom B2B Module. Alte Bestellungen über eine Order-Feldbedingung zu filtern ist etwas anderes als einen Company-Genehmigungsworkflow neu aufzubauen. Ersteres kann in ein Add-on passen; Letzteres benötigt Custom-Service-Prüfung oder eine separate Zielimplementierung.
Die Grenze verläuft danach, ob die Anforderung innerhalb des unterstützten Migrationsverhaltens bleibt. Wenn ja, kann ein Add-on ausreichen. Wenn nicht standardisierte Extraktion, Transformation, Logik oder Ownership-Interpretation erforderlich ist, gehört sie in die Custom-Service-Prüfung.
Wann Custom Service geprüft werden sollte
Custom Service sollte geprüft werden, wenn das gewünschte Ergebnis nicht allein mit unterstützten Standarddatensätzen und begrenzten Add-ons erreicht werden kann. Bei Adobe Commerce entsteht dieser Bedarf häufig durch das Extension-Ökosystem, B2B-Strukturen, Multi-Site-Scope und Abhängigkeiten von externen Systemen.
Typische Eskalationssignale sind:
- durch Module erzeugte Custom Product Types oder Beziehungen;
- Custom Attributes, die eine individuelle Zieltransformation benötigen;
- Company Accounts, Company Users, Shared Catalogs oder verhandelte Preise in nicht standardisierten Strukturen;
- Custom Checkout Fields oder Order-Daten in Extension Tables;
- ERP-, PIM-, OMS-, WMS-, CRM-, Tax- oder Fulfillment-Kennungen, die in einem bestimmten Zielfeld erhalten werden müssen;
- individuelle Regeln für Website-/Store-/Store-View-Zuordnung;
- nicht unterstützte Datensätze aus Marketplace-, Subscription-, Loyalty-, Quoting-, Approval- oder Returns-Modulen;
- Custom Database Columns, APIs oder Integration Tables;
- eine Custom Platform auf einer Seite des Migrationspfads;
- Anforderungen, die die Standard-Migrationslogik verändern.
Custom Service umfasst nicht automatisch Entwicklung von Adobe-Commerce-Modulen, Installation von Extensions, B2B-Konfiguration, Einrichtung von Shared Catalogs, Aufbau von Websites oder Store Views, Theme-Implementierung, Payment- oder Shipping-Konfiguration, Integration Deployment oder einen vollständigen Neuaufbau des Zielshops. Diese Aufgaben sind nur enthalten, wenn sie ausdrücklich als Teil des Service-Scopes vereinbart wurden.
Entity Points und Enterprise-Scope planen
Entity Points bilden den Kapazitätsrahmen für berechtigte migrierte Datensätze. Bei späteren Adobe-Commerce-Aktivitäten bleiben bereits gezählte berechtigte Datensätze auf demselben Migrationspfad einmal gezählt; Website-, Store-View-, B2B- und Extension-Komplexität wird separat beurteilt. Categories, Attributes, Companies, Shared Catalogs, Websites, Store Views, Custom Fields, Modules und externe Kennungen sind keine eigenständigen Entity-Points-Datensatztypen, können aber die Komplexität erhöhen.
Diese Trennung ist bei Adobe Commerce wesentlich. Zwei Projekte können denselben Entity Points Plan verwenden und dennoch unterschiedliche Service-Pfade benötigen. Ein großer Katalog mit gewöhnlichen Produkten kann zu Standard Service passen. Ein kleinerer Katalog kann Custom Service erfordern, wenn jedes Produkt von Custom Attributes, unternehmensspezifischen Preisen oder integrationsgesteuerten Kennungen abhängt.
Bei späteren Aktivitäten werden neu hinzugekommene berechtigte Products, Customers, Orders oder Blog Posts beim ersten Migrieren möglicherweise als Entity Points gezählt.
Die Entity-Points-Planung sollte beantworten:
| Planungsfrage | Warum sie wichtig ist |
|---|---|
| Welche berechtigten Datensätze liegen im freigegebenen Scope? | Bestimmt den passenden Entity Points Plan. |
| Welche Datensätze sind obsolet, dupliziert oder für den Launch nicht erforderlich? | Unterstützt Filterentscheidungen und vermeidet unnötigen Kapazitätsverbrauch. |
| Welche Datensätze wurden innerhalb der gekauften Migration auf dem festen Pfad bereits gezählt? | Verhindert falsche Annahmen über doppelten Verbrauch. |
| Welche neuen berechtigten Datensätze können vor dem Launch entstehen? | Unterstützt die Planung später benötigter Kapazität. |
| Welche komplexen Strukturen sind keine separaten Entity-Points-Typen? | Hält Komplexitätsbewertung und Volumenbewertung getrennt. |
Entity Points helfen, die Migration zu dimensionieren. Sie beweisen nicht, dass B2B-, Multi-Site-, Extension- oder Integrationsanforderungen unterstützt werden.
Was Demo Migration beweisen sollte
Demo Migration sollte die Service-Pfad-Entscheidung mit repräsentativen und schwierigen Datensätzen testen. Nur einfache Produkte auszuwählen kann bei Adobe Commerce ein falsches Sicherheitsgefühl erzeugen.
Die Stichprobe sollte, soweit relevant, enthalten:
- simple, configurable, bundled, grouped, virtual oder downloadable Products;
- Produkte mit komplexen Attributen und Store-View-spezifischen Werten;
- Kategorien, die von unterschiedlichen Stores oder Root Catalogs verwendet werden;
- Kunden aus wichtigen Gruppen oder Company-Kontexten;
- Bestellungen mit Rabatten, Steuern, Refunds, ungewöhnlichen Status oder externen Kennungen;
- priorisierte CMS Pages, Blog Posts und URL-sensitive Datensätze;
- Datensätze, die von Extensions oder Integrationen beeinflusst werden;
- Beispiele aus jeder Website, jedem Store oder jeder Store View, die für den Launch relevant ist.
Demo Migration sollte vier Fragen beantworten:
- Werden Standarddatensätze korrekt dargestellt?
- Bleiben Store-Scope- und B2B-Beziehungen sinnvoll?
- Welche Lücken lassen sich durch unterstützte Konfiguration oder Add-ons schließen?
- Welche Lücken erfordern Custom Service oder separate Zielimplementierung?
Eine erfolgreiche Demo Migration ist nicht nur ein Vergleich der Datensatzanzahl. Sie liefert Nachweise dafür, dass der gewählte Service-Pfad tragfähig ist, bevor Full Migration ausgeführt wird. Zeigt die Stichprobe nicht unterstützte Strukturen oder verborgene Ownership, sollte der Ansatz vor Ausführung des vollständigen Scopes geändert werden.
Additional Migration Options für Adobe Commerce
Additional Migration Options unterstützen spätere Migrationsaktivitäten, wenn die Quelle aktiv bleibt, sich die Zielkonfiguration ändert oder der Händler ein anderes Migrationsergebnis benötigt. Die gewählte Aktion sollte davon abhängen, ob die zuvor akzeptierte Konfiguration weiterhin gültig ist.
| Aktuelle Aktion | Geeignete Situation | Fokus der erneuten Validierung in Adobe Commerce |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Das akzeptierte Mapping und der Scope bleiben gültig und spätere Quellaktivitäten sollen mit derselben Konfiguration verarbeitet werden. | Neue Products, Customers, Orders, Blog Posts, Store-Scope-Werte, URLs und integrationsbezogene Kennungen. |
| Continue the Migration with a New Configuration | Der Migrationspfad bleibt gleich, aber Filterung, Mapping, Store-Zuordnung oder andere unterstützte Konfiguration muss geändert werden. | Geänderte Produktstrukturen, Website-/Store-/Store-View-Zuordnung, Attribute Mapping, B2B-Scope, Inhalte und URL-Funktion. |
| Perform a New Migration | Der Händler benötigt ein eigenständiges Migrationsergebnis, statt die frühere Konfiguration fortzusetzen. | Gesamter Ziel-Scope, B2B- und Store-Hierarchie, Produktmodell, Integrationsverantwortung, SEO und Abnahmekriterien. |
Diese Aktionen implementieren nicht automatisch Adobe-Commerce-Module, Shared Catalogs, Company Permissions, externe Integrationen, Themes oder Zielkonfiguration. Sie arbeiten innerhalb des vereinbarten Migration-Service-Scopes und lassen den gekauften festen Pfad von Source Platform zu Target Platform unverändert. Eine andere Source Platform oder Target Platform erfordert eine separat gekaufte Migration.
Abschließende Entscheidung über den Service-Pfad
Der stärkste Adobe-Commerce-Ansatz ist der leichteste Service-Pfad, der die erforderliche geschäftliche Bedeutung erhalten und ein Ergebnis erzeugen kann, das der Händler verlässlich validieren kann.
| Evidenz | Wahrscheinlicher Ansatz |
|---|---|
| Unterstützte Datensätze, gewöhnliche Strukturen, klarer Scope, kundenseitige Ausführung und Validierung | Standard Service |
| Unterstützter Scope, aber anspruchsvolle Koordination, Validierung oder Launch-Planung | Managed Service |
| Standardmigration mit begrenztem unterstütztem Bedarf an Datensatzfilterung, Feldwert-Transformation oder Feld-Neuzuordnung | Standard oder Managed Service mit Add-ons |
| Nicht unterstützte Datensätze, Custom Modules, individuelle Transformation, B2B- oder Integrationskomplexität außerhalb des Standardverhaltens | Custom Service, gegebenenfalls mit Expert Handle und vereinbarten Add-ons |
Die Entscheidung sollte vor Full Migration dokumentiert und anhand der Nachweise aus Demo Migration bestätigt werden. Ein Projekt sollte nicht allein deshalb hochgestuft werden, weil Adobe Commerce eine Enterprise-Plattform ist. Gleichzeitig sollte es nicht auf einem zu leichten Service-Pfad bleiben, wenn das akzeptierte Zielergebnis von nicht unterstützten Enterprise-Strukturen abhängt.
Fazit
Die Auswahl des Migrationsansatzes für Adobe Commerce hängt vom Zusammenspiel aus Datensatz-Scope, Enterprise-Betriebsstruktur, Ausführungsverantwortung und Anpassungsbedarf ab. Standard Service kann saubere und unterstützte Migrationspfade abdecken. Managed Service hilft bei hohem Koordinations- und Validierungsaufwand. Add-ons adressieren begrenzte unterstützte Anforderungen. Custom Service behandelt individuelle und nicht standardisierte Anforderungen.
Die endgültige Entscheidung sollte Website-/Store-/Store-View-Hierarchie, Produkttypen, B2B-Company- und Shared-Catalog-Kontext, externe Systeme, Entity Points und die Nachweise aus Demo Migration berücksichtigen. Additional Migration Options werden anschließend danach gewählt, ob die akzeptierte Konfiguration gültig bleibt, angepasst werden muss oder durch ein neues Migrationsergebnis ersetzt werden soll.
Häufige Fragen
Kann ein großer Adobe-Commerce-Katalog Standard Service verwenden?
Ja. Das Datensatzvolumen allein bestimmt den Service-Pfad nicht. Ein großer Katalog kann Standard Service nutzen, wenn der Migrationspfad unterstützt wird, Produktstrukturen erkennbar sind und der Kunde den Service ausführen und validieren kann. Entity Points decken die Kapazität berechtigter Datensätze ab; strukturelle Komplexität wird separat beurteilt.
Wann ist Managed Service für Adobe Commerce geeigneter?
Managed Service ist sinnvoll, wenn die Migration im unterstützten Verhalten bleibt, Ausführung, Koordination oder Validierung jedoch anspruchsvoll sind. Das gilt besonders für Projekte mit mehreren Teams, mehreren Storefront-Scopes, hohem Prüfaufwand und engen Launch-Zeitplänen.
Decken Add-ons Custom Modules in Adobe Commerce ab?
In der Regel nicht. Add-ons unterstützen begrenzte Anforderungen innerhalb des unterstützten Migrationsverhaltens. Daten in Custom Modules, Extension Tables, individuellen B2B-Strukturen oder externen Systemen benötigen meist eine Prüfung im Rahmen von Custom Service.
Was sollte Demo Migration für Adobe Commerce beweisen?
Sie sollte zeigen, dass repräsentative Produkte, Kunden, Bestellungen, Inhalte, Store-Scopes, B2B-Beziehungen, URLs und integrationsbezogene Felder ihre Bedeutung behalten. Außerdem sollte sie sichtbar machen, ob Lücken zu Konfiguration, Add-ons, Custom Service oder separater Zielimplementierung gehören.
Welche Additional Migration Option sollte gewählt werden?
Verwenden Sie Continue the Migration with the Last Used Configuration, wenn das akzeptierte Setup gültig bleibt; Continue the Migration with a New Configuration, wenn unterstützte Einstellungen geändert werden müssen; und Perform a New Migration, wenn ein eigenständiges Migrationsergebnis mit vollständiger erneuter Validierung benötigt wird.