Bei der Planung einer Migration zu Adobe Commerce geht es nicht nur darum, ob Produkte, Kunden, Bestellungen, Kategorien, CMS Pages, Blog Posts und Reviews übertragen werden können. Entscheidend ist vielmehr, ob diese Datensätze das Enterprise-Betriebsmodell unterstützen können, das Adobe Commerce nach dem Launch abbilden soll. Produktstruktur, Storefront-Umfang, B2B-Unternehmensbeziehungen, Shared Catalogs, Kundengruppen, Content Staging, Bestandsverantwortung, URLs und Integrationen verändern die Art, wie Quelldaten interpretiert werden müssen.
Ein Quellshop kann sauber strukturierte Datensätze enthalten und dennoch nicht die Struktur bieten, die Adobe Commerce benötigt. Ein Kunde kann vorhanden sein, ohne über die erforderliche Unternehmensberechtigung zu verfügen. Ein Produkt kann existieren, aber dem falschen Attribute Set, der falschen Website, keiner passenden Child-SKU-Beziehung oder nicht dem richtigen Shared Catalog zugeordnet sein. Eine Seite kann übertragen werden und dennoch Zeitplanung, Lokalisierung oder die Bedeutung ihrer Route verlieren. Die Prüfung des Datenmodells sollte deshalb die geschäftliche Funktionsweise bewerten und nicht nur das Vorhandensein einzelner Felder.
Die Datenbedeutung in Adobe Commerce beginnt beim Enterprise-Betriebsmodell
Adobe Commerce übernimmt einen großen Teil der Datenbasis aus der Magento-Familie. Für eine Migration ist die Interpretation jedoch eine andere, weil Adobe Commerce häufig für stärker gesteuerte Commerce-Prozesse gewählt wird. Derselbe Produkt-, Kunden-, Bestell- oder Seiten-Datensatz kann in einer Multi-Storefront-Struktur, bei B2B-Einkäufen, Genehmigungsregeln, kundengruppenspezifischen Preisen, Shared-Catalog-Sichtbarkeit, Enterprise-Integrationen oder geplanten Inhaltsaktivitäten eine zusätzliche Rolle übernehmen.
| Datenbereich | Bedeutung in Adobe Commerce | Konsequenz für die Migrationsplanung |
|---|---|---|
| Produkte | Produkttypen, Child SKUs, Attribute, Attribute Sets, Websites, Kategorien, Preise, Sichtbarkeit und Bestandsbeziehungen. | Katalogdaten müssen das Enterprise-Verkaufsmodell unterstützen, nicht nur die Darstellung im Storefront. |
| Kunden | Einzelne Käufer, Kundengruppen, Unternehmensbenutzer, Adressen, Bestellhistorie und Kontoberechtigungen. | Kundendaten müssen gegebenenfalls sowohl Identität als auch Einkaufskontext erhalten. |
| Unternehmen | Unternehmensadministratoren, Benutzer, Rollen, Berechtigungen, Kredit, Angebote, Purchase Orders und Genehmigungsstatus. | B2B-Daten sollten eingegrenzt werden, bevor Kunden wie gewöhnliche Einzelkonten behandelt werden. |
| Shared Catalogs | Käuferspezifische Katalogsichtbarkeit und Preise über Kundengruppen oder Unternehmenszuordnung. | Das Vorhandensein eines Produkts bedeutet nicht automatisch, dass es für jeden Käufer sichtbar ist. |
| Storefront-Umfang | Websites, Stores, Store Views, Sprache, Währung, Inhalte, Konfiguration und Katalogzuordnung. | Daten für mehrere Marken, Regionen oder Sprachen dürfen nicht zusammengeführt werden. |
| Inhalte und Kampagnen | CMS Pages, CMS Blocks, geplante Aktualisierungen, Promotion-Zeitpunkte, Landing Pages und Kampagnen-Assets. | Eine rein statische Inhaltsmigration kann zeitabhängige kommerzielle Absichten verlieren. |
| Bestand | Sources, Stocks, Annahmen zur Verkaufbarkeit, Channel-Zuordnung und externe Bestandsverantwortung. | Mengen sollten im Zusammenhang mit der Auftragsabwicklungsstruktur geprüft werden, nicht nur nach SKU-Anzahl. |
| URLs | URL Keys, Rewrites, Redirects, lokalisierte Pfade, benutzerdefinierte Routes und besonders wertvolle Landing Pages. | SEO-Kontinuität hängt von Bedeutung und Umfang einer Route ab, nicht nur von der Übertragung einer Seite. |
Die praktische Migrationsfrage lautet, ob jeder Datensatz genügend Struktur besitzt, um innerhalb von Adobe Commerce weiter zu funktionieren. Auch ein grundsätzlich unterstützter Datensatz kann eine andere Zielbeziehung, eine andere Scope-Zuordnung, eine klare Verantwortungsentscheidung oder eine getrennte Implementierung benötigen, wenn er Enterprise-Geschäftsregeln trägt.
Produktdaten hängen von Produkttyp, Attributen und Governance-Regeln ab
Produktdaten müssen bei einer Adobe-Commerce-Migration sorgfältig interpretiert werden, weil sie Storefront-Funktion, Merchandising, Filterung, Suche, Preise, Bestand und Integrationsabläufe beeinflussen können. Die erste Bedeutungsebene ist der Produkttyp. Simple, configurable, grouped, virtual, bundle und downloadable Products funktionieren nicht gleich. Ein Quellprodukt mit Optionen muss möglicherweise als configurable Product mit zugeordneten einfachen Child Products aufgebaut werden. Ein Paket oder Kit aus dem Quellsystem muss geprüft werden, bevor es als bundle, grouped, individuell behandelt oder aus dem Standardumfang ausgeschlossen wird.
Configurable Products sind besonders wichtig. Das Parent Product bietet dem Käufer eine gemeinsame Produktdarstellung, während die Child Simple Products die tatsächlich kaufbaren Bedeutungen auf SKU-Ebene tragen. Größe, Farbe, Material, Packungsgröße oder technische Spezifikation können SKU-Identität, Preis, Bild, Bestand und Integrationsreferenzen beeinflussen. Werden diese Beziehungen abgeflacht, kann der Katalog vollständig aussehen, während Kaufprozess, Auftragsabwicklung, Reporting oder ERP-Synchronisierung nicht mehr korrekt funktionieren.
Attribute und Attribute Sets fügen eine weitere Governance-Ebene hinzu. Attribute können sichtbare Produktfelder, Suche, Layered Navigation, Vergleich, Import-/Export-Verhalten, Promotion-Bedingungen, administrative Pflege und Integrationslogik steuern. Attribute Sets gruppieren Produktfamilien in strukturierte Vorlagen. Ein benutzerdefiniertes Quellfeld sollte nicht automatisch in Beschreibungstext umgewandelt werden, wenn es Filterung, Preise, PIM-Synchronisierung, Suche, Reporting oder nachgelagerte Prozesse steuert.
| Produktstruktur | Was interpretiert werden muss | Warum dies in Adobe Commerce wichtig ist |
|---|---|---|
| Produkttyp | Simple, configurable, grouped, bundle, virtual, downloadable oder individuell behandelte Struktur. | Der Produkttyp steuert, wie Käufer Artikel auswählen und kaufen. |
| Child-SKU-Beziehung | Parent-Child-Zuordnung, Optionsbezeichnungen, Bilder, Preisunterschiede, Bestand und Kennungen. | Fehlerhafte Beziehungen können Produkte sichtbar, aber kommerziell unbrauchbar machen. |
| Attribute | Anzeigefelder, durchsuchbare Felder, filterbare Felder, Regel-Inputs, Integrations-IDs und Admin-Felder. | Attributentscheidungen beeinflussen Katalog-Governance und Produktsuche durch Käufer. |
| Attribute Sets | Vorlagen für Produktfamilien und erforderliche Felder. | Schlechte Attribute-Set-Planung erschwert die Katalogpflege nach der Migration. |
| Kategoriezuordnung | Navigation, Merchandising, Scope, Sichtbarkeit und URL-Funktion. | Eine falsche Kategoriebedeutung kann Auffindbarkeit, SEO und Käufervertrauen beeinträchtigen. |
| Produktbeziehungen | Related Products, Upsells, Cross-Sells, Zubehör, Ersatzprodukte und Kompatibilitätsreferenzen. | Der Verlust von Beziehungen kann Conversion und Verkaufsabläufe schwächen. |
Das Ziel besteht nicht darin, jedes Quellfeld exakt nachzubauen. Entscheidend ist, die kommerzielle Bedeutung des Katalogs in einer Form zu erhalten, die Adobe Commerce betreiben und verwalten kann, ohne den Zielkatalog zu einem Archiv von Feldern des Quellsystems zu machen.
Der Storefront-Umfang verändert die Bedeutung von Datensätzen
Der Storefront-Umfang in Adobe Commerce kann die Bedeutung nahezu jedes migrierten Datensatzes verändern. Eine Quellplattform kann Marken, Regionen, Sprachen, B2B-Portale, Retail-Channels, Großhandelsbereiche und internationale Storefronts über Kategorien, Domains, Kunden-Tags, Markets, Plugins oder benutzerdefinierte Felder darstellen. In Adobe Commerce müssen diese Unterschiede möglicherweise als Websites, Stores, Store Views, Kategoriestrukturen, Kundengruppen, Shared Catalogs, Konfigurationsregeln oder Inhaltsvarianten abgebildet werden.
Der Scope sollte vor dem detaillierten Mapping geplant werden. Ein Produktname kann global sein, während Beschreibungen je Store View abweichen. Eine CMS Page kann lokalisierte Versionen benötigen. Ein Produkt kann zu einer Website gehören, aber nicht zu einer anderen. Ein Kategoriepfad kann für einen Retail-Storefront passend sein, aber nicht für einen privaten B2B-Katalog. Ein Preis kann von Kundengruppe oder Shared-Catalog-Zugriff abhängen statt nur vom Produkt selbst.
Scope-Fehler bleiben in Datensatzanzahlen häufig unsichtbar. Die erwartete Anzahl an Produkten, Kategorien, Kunden oder Seiten kann vollständig übertragen werden, obwohl ein Storefront die falsche Sprache, den falschen Preis, die falsche Kategorie, Sichtbarkeit oder den falschen URL-Kontext erhält. Das Zielmodell benötigt deshalb für jede wichtige Marke, Region, Sprache, Website, jeden Store, jede Store View, jedes B2B-Segment und jeden privaten Katalogkontext eine eindeutige Zuordnung.
Kundendaten können individuelle Identität und Unternehmensberechtigungen enthalten
In Adobe Commerce können Kundendaten weit mehr als die Identität eines Einzelkontos darstellen. Dazu können Kundengruppen, Beziehungen zu Company Accounts, Unternehmensadministratoren, Unternehmensbenutzer, Berechtigungen, Quotes, Purchase Orders, Company Credit, Zahlungsmethoden, Versandmethodenregeln, rechtliche Adressdaten und Shared-Catalog-Zuordnungen gehören. Ein Kundendatensatz kann als individuelles Konto korrekt übertragen werden und dennoch seine Funktion verlieren, wenn der Käufer seine Unternehmensberechtigung oder seinen Katalogzugriff verliert.
Bei B2B-Migrationen sollte Kundenidentität von Einkaufskontrolle getrennt werden. Adobe Commerce verbindet Standard-Kundenkonten mit Company Accounts. Ein Company Account kann Administrator, Teams, Benutzer, Rollen, Berechtigungen und Genehmigungsbeziehungen enthalten. E-Mail-Adresse, Adresse und Bestellhistorie aus dem Quellsystem können für ein B2C-Konto genügen. Für B2B-Kontinuität können dagegen Unternehmensidentität, rechtliche Adresse, Administratorzuordnung, Organisationshierarchie, Kontostatus, Steuerreferenzen, Kreditkontext und externe Konto-IDs erforderlich sein.
| Kundenebene | Was geprüft werden sollte | Konsequenz für die Migration |
|---|---|---|
| Einzelkonto | E-Mail, Name, Adresse, Status, Passwortstrategie und Zuordnung zur Bestellhistorie. | Käufer brauchen eine wiedererkennbare Kontinuität ihrer Kundenkonten. |
| Kundengruppe | Rabatt, Steuer, Katalog, Preisgestaltung oder Storefront-Behandlung. | Die Gruppenzuordnung kann Käufererlebnis und Bestellgenauigkeit beeinflussen. |
| Company Account | Unternehmensadministrator, rechtliche Adresse, Unternehmensbenutzer, Hierarchie und Kontostatus. | Unternehmenseinkäufe können scheitern, wenn die Unternehmensstruktur nicht geplant ist. |
| Einkaufskontrollen | Quotes, Purchase Orders, Kredit, Zahlungsmethoden, Versandmethoden und Berechtigungen. | B2B-Abläufe benötigen möglicherweise zusätzliche Zielkonfiguration oder Implementierung über die migrierten Kundendatensätze hinaus. |
| Externe Kennungen | ERP-ID, CRM-ID, Händler-ID, Account-Manager-Referenz, Vertrags-ID oder Steuerreferenz. | Externe Systeme können von Kennungen abhängen, die in der Storefront-Prüfung nicht sichtbar sind. |
Adobe-Commerce-Unternehmensdaten sollten nicht wie eine gewöhnliche Liste von Kundenfeldern behandelt werden. Sie bilden eine Einkaufsstruktur. Der Umfang sollte übertragbare Identitäten und Beziehungen von Unternehmensberechtigungen, Einkaufskontrollen, Kreditverhalten und externen Integrationen trennen, die eine separate Zielimplementierung benötigen.
Shared Catalogs machen Produktzugriff käuferspezifisch
Shared Catalogs machen Produktzugriff und Preise in Adobe Commerce vom jeweiligen Käufer abhängig. Adobe Commerce kann einen öffentlichen Shared Catalog und benutzerdefinierte Shared Catalogs führen, die Company Accounts zugeordnet werden. Ein Produkt kann im primären Katalog existieren, ohne zu jedem Shared Catalog zu gehören. Ein individueller Preis kann für ein Unternehmen korrekt und für ein anderes falsch sein. Auch Kategorie-Berechtigungen können sich ändern, wenn Shared Catalog aktiviert ist.
Quellplattformen bilden diese Logik häufig anders ab, etwa durch Großhandelspreislisten, Kunden-Tags, Händlergruppen, ausgeblendete Kategorien, private Produktlisten, Vertragspreise, ERP-gesteuerte Regeln oder benutzerdefinierte Felder. Bei der Migration müssen diese Strukturen in das Zielmodell übertragen und interpretiert werden, nicht lediglich kopiert werden.
Für die Übertragung eines Shared-Catalog-Modells sollten vier Fragen beantwortet werden: Welche Unternehmen erhalten Zugriff? Welche Produkte gehören in welchen Katalog? Welche individuellen Preise gelten? Welche Kategorie-Berechtigungen oder Sichtbarkeitsregeln müssen in Adobe Commerce dargestellt werden? Preislisten, ausgeblendete Kategorien, Händler-Tags und ERP-Vertragsreferenzen aus dem Quellsystem sind Hinweise auf die beabsichtigte Beziehung, aber nicht automatisch gleichbedeutend mit einem Shared Catalog.
Bestellungen tragen kommerziellen, B2B- und Integrationskontext
Bei der Migration von Bestellungen nach Adobe Commerce sollte eine nutzbare Historie erhalten bleiben. Sie darf nicht den Eindruck erwecken, dass jeder Checkout-Mechanismus des Quellsystems dadurch zu einer aktiven Adobe-Commerce-Funktion wird. Historische Bestellungen können Positionen, Produkte, Mengen, Rabatte, Steuern, Versand, Rechnungsinformationen, Kundenreferenzen, Bestellstatus, Zahlungsreferenzen, Erstattungen, Rechnungen, Sendungen, Credit Memos, Purchase Orders, Quote-Referenzen, Unternehmenskontext und externe IDs enthalten.
Bei B2B- und Enterprise-Shops kann die Bestellhistorie zusätzliche Interpretation erfordern. Eine Quellbestellung kann zu einem Unternehmen gehören und nicht nur zu einem einzelnen Kunden. Ein historischer Rabatt kann einen Vertragspreis oder Shared-Catalog-Preis widerspiegeln. Eine Zahlungsmethode kann von Unternehmensregeln abhängen. Eine Purchase Order kann Genehmigungsbedeutung besitzen. Für Support-Teams kann eine ERP-Bestellnummer wichtiger sein als die Storefront-Bestellnummer.
| Bestellkontext | Was erhalten oder klassifiziert werden sollte | Warum es wichtig ist |
|---|---|---|
| Kunden- und Unternehmensbeziehung | Käuferkonto, Company Account, Administrator- oder Benutzerbeziehung und Gruppenkontext. | Support-Teams müssen erkennen können, wer die Bestellung unter welchem Konto aufgegeben hat. |
| Finanzdetails | Zwischensumme, Rabatte, Steuern, Versand, Erstattungen, Credit Memos, Rechnungen und Zahlungsreferenzen. | Die Historie muss für Service und Abstimmung lesbar bleiben. |
| B2B-Ablaufkontext | Quote, Purchase Order, Kontokredit, Genehmigung oder Vertragsreferenz. | Historische B2B-Bedeutung ist nicht immer gewöhnliche Bestelldatenstruktur. |
| Status der Auftragsabwicklung | Versand, Teilabwicklung, Stornierung, Rückgabe, Lagerreferenz oder ERP-Status. | Operative Teams müssen nachvollziehen können, was nach dem Kauf passiert ist. |
| Externe Kennungen | ERP-Bestell-ID, Buchhaltungs-ID, Marketplace-ID, CRM-Opportunity oder Lagerreferenz. | Die Kontinuität von Integrationen kann von Kennungen außerhalb der Standard-Bestellfelder abhängen. |
Das Zielmodell für Bestellungen sollte die unterschiedlichen Beziehungen von B2C- und B2B-Bestellungen, erstatteten oder gutgeschriebenen Bestellungen, rabatt- und steuerrelevanten Vorgängen, externen Referenzen sowie Unternehmens- und Kundengruppenkontext berücksichtigen. Diese Beziehungen entscheiden darüber, ob historische Bestellungen nach der Migration weiterhin verständlich sind.
Inhalte, Kampagnen und URLs müssen getrennt interpretiert werden
Die Inhaltsmigration zu Adobe Commerce kann CMS Pages, CMS Blocks, Kategorieinhalte, Produktbeschreibungen, Landing Pages, gegebenenfalls Blog Posts, Medien, Metadaten und Promotion-Assets umfassen. Bei Enterprise-Shops können Inhalte außerdem mit Kampagnenzeitpunkten, regionalen Storefronts, Merchandising-Kalendern, Brand Governance, rechtlicher Prüfung oder Genehmigungsabläufen verbunden sein.
Content Staging verändert die Interpretation von Inhalten, wenn zeitgesteuerte Änderungen relevant sind. Adobe Commerce kann Aktualisierungen für Produkte, Kategorien, Catalog Price Rules und Cart Price Rules, CMS Pages und CMS Blocks als kampagnenbezogene Änderungen einplanen. Eine Landing Page, ein Kategorie-Banner, eine Promotion oder eine geplante Preisänderung kann als Inhalt vorhanden sein und dennoch ihre kommerzielle zeitliche Bedeutung verlieren, wenn sie auf einen statischen Datensatz reduziert wird. Der Scope sollte daher Evergreen-Inhalte, zukünftige Kampagnen, aktuell geplante Änderungen und abgelaufenes Kampagnenmaterial voneinander trennen.
URLs müssen ähnlich differenziert werden. Product URL Keys, Category URL Keys, CMS-Pfade, URL Rewrites, lokalisierte Pfade, Redirects und benutzerdefinierte Landing-Page-Routes sollten nach ihrem geschäftlichen Wert geprüft werden. Die Seitenanzahl kann stimmen, während wertvolle Produktseiten, B2B-Einstiegspfade, Händlerportale, regionale URLs oder Kampagnenseiten ihre Kontinuität verlieren.
Daten aus Integrationen müssen vor dem Mapping ihrem Owner zugeordnet werden
Adobe-Commerce-Projekte hängen häufig von ERP-, PIM-, CRM-, OMS-, WMS-, Steuer-, Zahlungs-, Versand-, Marketplace-, Loyalty-, Subscription-, Analytics-, Such-, Personalisierungs- oder Marketing-Systemen ab. Diese Systeme können Felder und Kennungen verwalten, die bei einer reinen Storefront-Prüfung nicht offensichtlich sind.
Dazu gehören etwa ERP-Produkt-IDs, PIM-Produkt-IDs, Company-Account-IDs, Händler-IDs, Vertrags-IDs, Preislistenreferenzen, Lagercodes, Steuerbefreiungs-IDs, CRM-Kontoreferenzen, Marketplace-Item-IDs, Subscription-IDs und externe Bestellnummern. Werden solche Werte entfernt, umbenannt oder in ungeeignete Felder geschrieben, kann der migrierte Shop korrekt aussehen, während nachgelagerte Abläufe nicht mehr funktionieren.
Integrationsabhängige Daten sollten klassifiziert werden, bevor das endgültige Source-to-Target-Mapping festgelegt wird. Ein Wert kann in ein natives Attribut, ein von einer Extension verwaltetes Feld, einen systemübergreifenden Schlüssel, einen separaten Integrations-Payload oder eine ausgeschlossene Legacy-Struktur gehören. Die Entscheidung sollte sich daran orientieren, welches System den Wert künftig verwaltet und verwendet, nicht daran, an welcher Stelle er zufällig im Quellsystem gespeichert war.
Beziehungen in Adobe Commerce benötigen eindeutige Zuständigkeiten
Ein vollständiges Adobe-Commerce-Zielmodell weist der gesamten Beziehungskette klare Zuständigkeit und Bedeutung zu. Produktdatensätze unterstützen Katalog-Governance. Kunden- und Unternehmensdatensätze erhalten Einkaufsberechtigungen. Bestellungen behalten eine für Service nutzbare Historie. Inhalte tragen den richtigen Storefront- und Kampagnenkontext. URLs erhalten ihre Route-Bedeutung. Integrationsfelder bleiben zu den Systemen rückverfolgbar, die sie weiterhin verwenden.
Eine sinnvolle Datenprüfung stellt deshalb folgende Fragen:
- Können Produkte nach Produktfamilie, Attribute Set, Website und Storefront-Umfang gepflegt werden?
- Können B2B-Käufer auf den richtigen Katalog, Preis, Account, Quote, Purchase Order und Kreditkontext zugreifen?
- Können Support-Teams historische Bestellungen verstehen, ohne für die grundlegende Bedeutung in das Quellsystem zurückkehren zu müssen?
- Unterstützen Inhalte und URLs weiterhin Launch, SEO-Kontinuität und Kampagnenanforderungen?
- Können externe Systeme die migrierten Datensätze, von denen sie abhängen, weiterhin eindeutig erkennen?
Wenn diese Fragen aus dem Scope nicht beantwortet werden können, sind die Zielbeziehungen noch nicht ausreichend definiert, selbst wenn die Quelldatensätze verfügbar sind.
Fazit
Adobe Commerce verändert die Migrationsplanung, weil Daten häufig Enterprise-Betriebslogik tragen. Produkte sind nicht nur Artikel, sondern Produkttypen, Attribute, Attribute Sets, Websites, Store Views, Kategorien, Bestandsbeziehungen und Integrationsreferenzen. Kunden sind nicht nur Profile, sondern können Unternehmen, Benutzer, Administratoren, Kundengruppen, Käufer in Shared Catalogs und Teilnehmer an Genehmigungsprozessen sein. Inhalte, URLs, Bestellungen und Bestand können von Scope, Zeitplanung und externen Systemen abhängen.
Eine solide Adobe-Commerce-Migration behandelt Datenmodellarbeit als Übertragung geschäftlicher Bedeutung. Ziel ist eine Struktur, die Katalog-Governance, B2B-Einkauf, Storefront-Umfang, Inhaltskontinuität und Integrationsverantwortung unterstützt.
Häufige Fragen
Warum erfordert die Datenmigration zu Adobe Commerce mehr als reines Feld-Mapping?
Weil viele Adobe-Commerce-Datensätze operative Bedeutung tragen. Produkte, Kunden, Bestellungen, Inhalte, URLs und Bestand können B2B-Einkauf, Shared Catalogs, Storefront-Umfang, Attribut-Governance und Integrationsverantwortung beeinflussen.
Wie unterscheiden sich Shared Catalogs in Adobe Commerce von gewöhnlichen Kategorien?
Kategorien strukturieren Katalognavigation und Merchandising. Shared Catalogs können dagegen käuferspezifische Produktsichtbarkeit und Preise steuern, typischerweise in Verbindung mit Unternehmen oder Kundengruppen. Sie sollten als Zugriffs- und Preislogik geplant werden, nicht nur als Katalogstruktur.
Was macht Kundendaten in Adobe Commerce komplexer?
Kundendaten können Einzelkonten, Kundengruppen, Company Accounts, Unternehmensbenutzer, Administratoren, Rollen, Kredit, Quote-Berechtigungen, Purchase-Order-Berechtigungen und Shared-Catalog-Zuordnungen umfassen. Ein Kunde kann als Konto übertragen werden und dennoch seine B2B-Einkaufsbedeutung verlieren.
Sollten Content-Staging-Daten wie gewöhnliche CMS-Inhalte behandelt werden?
Nein. Zeitkritische Kampagnenänderungen, geplante Inhalte, Promotion-Seiten und launchbezogene Änderungen sollten getrennt geprüft werden. Ein Teil der Inhalte kann als stabiler CMS-Inhalt migriert werden, während Zeitplanung und Genehmigungsfunktion möglicherweise in Adobe Commerce konfiguriert oder manuell neu aufgebaut werden müssen.
Wann benötigen Adobe-Commerce-Daten eine getrennte Zielbehandlung?
Eine separate Migrationsbehandlung oder Zielimplementierung ist erforderlich, wenn der Scope nicht unterstützte Extension-Daten, benutzerdefinierte Datenbankstrukturen, nicht standardisierte Unternehmens- oder Katalogbeziehungen, Kennungen externer Systeme oder Funktionen umfasst, für die es in Adobe Commerce kein natives Ziel gibt.
Wie sollten externe Kennungen in Adobe Commerce dargestellt werden?
Eine externe Kennung sollte nur erhalten bleiben, wenn ein weitergenutzter ERP-, CRM-, PIM-, Auftragsabwicklungs-, Steuer- oder Reporting-Prozess davon abhängt. Danach ist zu entscheiden, ob der Wert in ein natives Feld, ein Extension-Feld, eine Integrationsreferenz oder einen dokumentierten systemübergreifenden Schlüssel gehört. Das Ergebnis sollte Mitarbeitern und verbundenen Systemen erlauben, den migrierten Datensatz eindeutig zuzuordnen, ohne die Kennung als Storefront-Inhalt offenzulegen oder mit der internen Adobe-Commerce-ID zu verwechseln.