Wenn Magento Open Source als mögliche Zielplattform ausgewählt wird, sollte die Vorbereitung den Quellshop vor jedem Migrationslauf in ein dokumentiertes Modell für Katalog, Customers, Orders, Inhalte und Erweiterungen übersetzen. Die Plattform ist flexibel, doch genau diese Flexibilität macht es notwendig, Product-Typen, konfigurierbare Child-SKUs, Custom Options, Attribute, Attributsets, Store Views, Inventory Sources, historische Orders, von Erweiterungen verwaltete Daten und externe Identifikatoren sauber voneinander zu unterscheiden.
Für jeden Vorbereitungsbereich sollten Maßnahme, Verantwortlicher, Nachweis und Bedingung für Bereitschaft festgelegt werden. So wird der repräsentative Migrationstest zu einer kontrollierten Stichprobe der geplanten Magento-Struktur und nicht zum ersten Versuch, die Funktionsweise des Quellshops überhaupt zu verstehen.
Zielstruktur für Magento Open Source definieren
Erstellen Sie eine kompakte Zielstrukturübersicht für Websites, Stores, Store Views, Sprachen, Währungen, Katalogverantwortung, Customer Groups, Bestand, Inhalte und Integrationen.
| Vorbereitungsbereich | Zu dokumentierende Entscheidung | Verantwortlicher | Nachweis der Bereitschaft |
|---|---|---|---|
| Website- und Store-View-Geltungsbereich | Welche Marken, Regionen, Sprachen, Währungen, Domains und lokalisierten Werte getrennte Geltungsbereiche benötigen | Commerce-Verantwortlicher | Website-/Store-/Store-View-Matrix |
| Product-Architektur | Welche Quelldatensätze zu einfachen, konfigurierbaren, gruppierten, Bundle-, virtuellen oder Download-Products werden | Katalogverantwortlicher | Klassifizierung der Product-Familien |
| Attribut-Governance | Welche Felder Attribute, Attributsets, Custom Options, Inhalte oder externe Daten werden | Katalog- und Technikverantwortliche | Attributverzeichnis mit Beispielwerten |
| Bestandsverantwortung | Ob Magento, ERP, WMS, Lieferant oder Marketplace den Bestand führt | Inventory-Verantwortlicher | Source-/Stock-/System-of-Record-Matrix |
| Customer- und Order-Historie | Welche Customer Groups, Adressen, Status, Anpassungen und externen Referenzen verständlich bleiben müssen | Operations und Support | Repräsentatives Customer-/Order-Paket |
| Erweiterungsgrenzen | Welche Module und Custom Tables wichtige Datensätze erzeugen | Technischer Verantwortlicher | Abhängigkeitsregister |
Die Zielübersicht soll die Eigentümerschaft im Ziel festlegen, ohne zu einer vollständigen Magento-Implementierungsspezifikation zu werden.
Zugänge, Backups und Quelldaten-Nachweise vorbereiten
Sammeln Sie:
- Administratorzugang zur Quelle sowie Magento-Administratorzugang mit dem erforderlichen Berechtigungsniveau;
- Datenbank- und Medien-Backups, soweit verfügbar;
- aktuelle Exporte oder Berichte zu Products, Categories, Customers, Orders, Coupons, Bewertungen, CMS Pages, Blog Posts und Medien;
- Listen der Websites, Stores, Store Views, Sprachen, Währungen und Domains;
- Referenzen zu Product-Typen, Attributen, Attributsets, Custom Options und Categories;
- Berichte zu Inventory Sources, Stocks, Lagern und externen Bestandssystemen;
- Beispiele für Customer Groups, Steuern und Account-Status;
- Inventare zu Erweiterungen, Custom Modules, Cron Jobs, APIs und Integrationen;
- Listen zu URL Rewrites, Redirects, Sitemaps und wichtigen Routen;
- Screenshots oder Berichte, die ungewöhnliches Verhalten der Quelle erklären.
| Nachweis | Warum er benötigt wird | Bedingung für Bereitschaft |
|---|---|---|
| Datenbank-/Medien-Backup | Bewahrt Datensätze, die Standardexporte nicht liefern | Backup-Datum, Speicherort und Wiederherstellungsverantwortlicher sind dokumentiert |
| Attributverzeichnis | Erklärt Custom Fields und Unterschiede zwischen Product-Klassen | Jedes wichtige Attribut besitzt Zweck, Typ, Geltungsbereich und Beispielwerte |
| Erweiterungsinventar | Identifiziert Datensätze außerhalb des Magento-Kerns | Jedes kritische Modul besitzt fachlichen und technischen Verantwortlichen |
| URL-Inventar | Schützt Routenkontinuität | Wichtige Product-, Category- und Content-Pfade besitzen vorgesehene Ziele |
| Register externer IDs | Schützt Integrationskontinuität | Schlüssel sind der richtigen Product-, Customer-, Order- oder Bestandsebene zugeordnet |
Ein fehlender Erweiterungsexport, ein nicht zugänglicher Medienordner oder eine undokumentierte Custom Table muss als offener Vorbereitungspunkt sichtbar bleiben.
Product-Typen und verkäufliche Beziehungen vorbereiten
Wählen Sie Beispiele für jede Product-Struktur aus, die Katalogpflege oder Order-Historie wesentlich beeinflusst:
- einfache Products;
- konfigurierbare Products mit zugeordneten einfachen Products;
- gruppierte Products;
- Bundle Products;
- virtuelle und Download-Products;
- Products mit Custom Options;
- Products auf mehreren Websites oder mit Store-View-Werten;
- Products mit von Erweiterungen verwalteten Feldern, Custom Tables oder externen IDs.
| Verhalten in der Quelle | Vorbereitungsentscheidung für Magento | Erforderlicher Nachweis |
|---|---|---|
| Eine Auswahl erzeugt eine eigenständige SKU oder einen eigenen Bestandsdatensatz | Konfigurierbares Parent-Product und zugeordnete einfache Products definieren | Parent-/Child-IDs, SKUs, Attribute, Bestand, Preise und Bilder |
| Products werden gemeinsam vermarktet, aber unabhängig verkauft | Beziehung als gruppiertes Product definieren | Gruppenmitglieder und Mengen |
| Customer stellt ein Set zusammen | Bundle-Komponenten und Auswahlregeln definieren | Komponenten-Products, Mengen, Pricing und Bestandsverantwortung |
| Ein Wert verändert ein Product ohne eigenen Bestand | Custom Option oder einen anderen Eigentümer definieren | Optionstyp, Werte, Preiseffekt und historisches Order-Beispiel |
| Product ist digital oder wird nicht versendet | Download- oder virtuelle Product-Struktur definieren | Datei, Zugriff, Versandkontext und Order-Kontext |
| Quelle verwendet duplizierte Products für regionale Geltungsbereiche | Website-/Store-View-Eigentümerschaft oder bewusst getrennte Products definieren | Regionale Inhalte, Preise, URLs und Identifikatorbeispiele |
Normalisieren Sie doppelte SKUs, verwaiste Child-Products, inkonsistente Optionslabels, fehlende Parent-Beziehungen, veraltete Products und nicht unterstützte Kombinationen, bevor die Zuordnung finalisiert wird.
Attribute und Attributsets bereinigen
Magento-Attribute können Bearbeitung, Filterung, Suche, Vergleich, Product-Erstellung und Store-View-Inhalte beeinflussen. Bereiten Sie deshalb ein gesteuertes Feldinventar vor, statt jedes Quellfeld in ein übergroßes Attributset zu kopieren.
Dokumentieren Sie für jedes Feld:
- geschäftlichen Zweck;
- Datentyp und zulässige Werte;
- verwendende Product-Klassen;
- globalen, Website- oder Store-View-Geltungsbereich;
- ob Customers den Wert auswählen;
- ob Suche, Filterung, Vergleich oder Integration davon abhängen;
- ob das Feld einen Identifikator eines anderen Datensatzes enthält;
- ob es erhalten, normalisiert, zusammengeführt oder ausgeschlossen werden soll.
| Feldmuster | Vorgesehener Eigentümer in Magento | Nachweis der Bereitschaft |
|---|---|---|
| Variantenbestimmender Wert | Konfigurierbares Attribut und zugeordnete einfache Products | Kontrollierte Werte und Beispiele aus Product-Familien |
| Technische Spezifikation | Product-Attribut über ein Attributset | Typ, Geltungsbereich, zulässige Werte sowie Darstellungs-/Suchzweck |
| Vom Customer eingegebener Wert | Custom Option, Erweiterung oder Order-Line-Eigentümer | Storefront- und historisches Order-Beispiel |
| Reiner Integrationswert | Product- oder Child-SKU-Attribut, das ein externes System nutzt | Verantwortliches externes System und Eindeutigkeitsregel |
| Historischer Workaround der Quelle | Normalisiertes Zielattribut, Inhalt, Erweiterung oder Ausschluss | Entscheidungsprotokoll zum fortbestehenden Zweck |
Bereit ist dieser Bereich, wenn jede wesentliche Product-Klasse ein freigegebenes Attributset besitzt und kein wichtiges Feld undefiniert oder mehreren widersprüchlichen Eigentümern zugeordnet bleibt.
Categories, Inhalte, URLs und Store-View-Werte vorbereiten
Erstellen Sie ein Routen- und Inhaltsinventar für:
- Category-Hierarchie und Product-Zuordnungen;
- Categories, die nur interner Organisation oder Kampagnen dienen;
- Product- und Category-URL-Keys;
- CMS Pages, CMS Blocks, Page-Builder- oder Theme-verwaltete Inhalte;
- Blog Posts und von Erweiterungen verwaltete Inhalte;
- lokalisierte Product-, Category- und CMS-Werte;
- wichtige Backlinks, bezahlte Kampagnenrouten, Policy-Seiten und Landingpages;
- URL Rewrites, Redirects und interne Links.
| Quelldatensatz | Vorbereitungsfrage | Nachweis der Bereitschaft |
|---|---|---|
| Category | Ist sie dauerhafte Katalogstruktur, Navigation, Kampagnengruppierung oder interne Klassifizierung? | Category-Entscheidung und Beispiel zur Product-Zuordnung |
| Lokalisiertes Product oder Seite | Welche Store View besitzt den jeweiligen Wert? | Store-View-Wertematrix |
| CMS Page/Block | Handelt es sich um wiederverwendbaren Inhalt, Seiteninhalt oder Theme-Darstellung? | Inhaltsinventar und Zielverantwortung |
| Blog Post | Welche Erweiterung oder welches Content-System wird ihn besitzen? | Post-Liste, Medien, URLs und Zieleigentümer |
| Historische URL | Welches Ziel-Product, welche Category oder welcher Content-Datensatz erhält den Redirect? | Quell-/Ziel-Routenledger |
Der Bereich ist bereit, wenn jede wichtige öffentliche Route ein Ziel oder eine bewusste Stilllegungsentscheidung besitzt und jeder lokalisierte Wert einer Store View zugeordnet ist.
Customer Groups, Customers und historische Orders vorbereiten
Die Customer-Vorbereitung sollte registrierte Customers, Gäste, mehrere Adressen, Customer Groups, Steuerbehandlung, Account-Status, doppelte Identitäten, Custom Fields sowie externe CRM- oder ERP-Schlüssel umfassen.
Wählen Sie für Orders Beispiele mit:
- konfigurierbaren Products und Custom Options;
- gruppierten oder Bundle Products;
- Rabatten, Coupons, Steuern, Versand- und Zahlungslabels;
- Rechnungen, Sendungen, Gutschriften, Stornierungen und Kommentaren;
- Marketplace-, ERP-, Auftragsabwicklungs-, Buchhaltungs- oder CRM-Referenzen;
- jeder wichtigen Website, Währung oder Customer Group.
| Vorbereitungspunkt | Verantwortlicher | Erforderlicher Nachweis | Bedingung für Bereitschaft |
|---|---|---|---|
| Customer-Identität | Customer Operations | Beispiele für Duplikate, Gäste, Adressen und externe IDs | Regeln zum Zusammenführen und Getrennthalten sind dokumentiert |
| Customer Groups | Fachlicher Eigentümer | Gruppenliste und zugehöriger Pricing-/Tax-/Zugriffszweck | Jede Gruppe hat eine fortbestehende geschäftliche Bedeutung |
| Historische Orders | Support und Finance | Repräsentatives Order-Paket | Positionen, Summen, Status, Auftragsabwicklung, Erstattungen und Referenzen sind erklärt |
| Sensible Daten | Legal-/Data-Verantwortlicher | Freigegebene Feldliste | Nicht benötigte oder nicht unterstützte personenbezogene Daten sind ausgeschlossen |
Aktuelle Customer Groups oder Product-Preise dürfen historische Orders nicht neu interpretieren. Der Order-Datensatz sollte seine eigenen transaktionszeitbezogenen Nachweise bewahren.
Eigentümerschaft für Bestand und Auftragsabwicklung vorbereiten
Magento-Bestand kann Sources, Stocks, Website-Zuordnungen, Source-Mengen, verkaufbare Menge, Reservations, Backorders, Abholorte, Drop Shipper und externe Bestandssysteme umfassen.
Bereiten Sie Beispiele vor für:
- einfache und konfigurierbare Child-SKUs;
- Products mit einer oder mehreren Sources;
- Backorder-, Low-Stock-, Out-of-Stock- oder Preorder-ähnliche Datensätze;
- Lager-, Store-, Lieferanten- und Drop-Ship-Standorte;
- Products, die mit ERP, WMS, Marketplace oder Systemen für die Auftragsabwicklung synchronisiert werden;
- Bestand, der kurz vor dem Migrationsfenster aktualisiert werden muss.
| Bestandsfrage | Nachweis | Bedingung für Bereitschaft |
|---|---|---|
| Welches System besitzt die Menge? | System-of-Record-Matrix | Jede wichtige SKU besitzt genau eine festgelegte Bestandsautorität |
| Welcher Quellstandort entspricht welcher Magento Source? | Standortmatrix | Source-Codes in Quelle und Ziel sind dokumentiert |
| Welche Websites verwenden welchen Stock? | Website-/Stock-Beziehung | Eigentümerschaft je Verkaufskanal ist definiert |
| Welche Product-Ebene besitzt Bestand? | Parent-/Child-SKU-Beispiele | Verantwortung von konfigurierbarem Parent und Children ist klar |
| Welche Werte sind Eröffnungs-Snapshots? | Datierter Bestandsbericht | Snapshot-Datum und Verantwortlicher für Aktualisierung sind dokumentiert |
Bestand ist vorbereitet, wenn Menge, Standort, Product-Ebene, Website-Beziehung und Eigentümerschaft externer Systeme ausdrücklich geklärt sind.
Erweiterungen, Custom Modules und externe Systeme inventarisieren
Erstellen Sie ein Abhängigkeitsregister für jede Erweiterung, jedes Custom Module, jede modifizierte Tabelle, API, jeden geplanten Prozess und jedes externe System, das Product-, Customer-, Order-, Bestands-, Inhalts- oder URL-Funktionen verändert.
Dokumentieren Sie:
- Modul- oder Systemname;
- geschäftlichen Zweck;
- erweiterte Kerndatensätze;
- erzeugte Custom Fields, Tabellen, Status oder IDs;
- Verfügbarkeit von Export oder API;
- fachlichen und technischen Verantwortlichen;
- fortbestehenden Zieleigentümer oder Ersatz;
- zu archivierende oder auszuschließende Daten.
Zu den wichtigen Abhängigkeiten gehören Suche, Bewertungen, Loyalty, Subscriptions, Zahlung, Steuer, Versand, Marketplaces, ERP, PIM, WMS, CRM, Buchhaltung, Consent, Analyse sowie individuelle Checkout- oder Auftragsabwicklungslogik.
Das Register ist bereit, wenn jede wichtige Abhängigkeit einen benannten Zieleigentümer und stabilen Schlüssel besitzt. Datensätze aus Erweiterungen dürfen nicht als gewöhnliche Magento-Felder beschrieben werden, sofern sie nicht tatsächlich dem Kern der Plattform gehören.
Repräsentative Muster für den Migrationstest auswählen
| Muster | Zweck der Vorbereitung |
|---|---|
| Einfache und konfigurierbare Product-Familie | Product-Typ, Attribute, Child-SKUs, Medien und Bestand festlegen |
| Gruppiertes oder Bundle Product | Komponentenbeziehungen und Pricing-Eigentümerschaft sichtbar machen |
| Product mit Custom Options | Einmalige Customer-Eingaben und Darstellung in historischen Orders prüfen |
| Lokalisiertes Product oder Category | Website-, Store-View-, Content- und URL-Geltungsbereich prüfen |
| Customer mit Gruppe und externer ID | Identität, Segmentierung und Integrationsbeziehungen prüfen |
| Komplexe historische Order | Optionen, Summen, Sendungen, Gutschriften und Referenzen prüfen |
| SKU mit mehreren Inventory Sources | Source-, Stock-, Website- und externe Bestandseigentümerschaft prüfen |
| Von Erweiterung verwalteter Datensatz | Entscheidungen zu Custom Table und Zieleigentümer sichtbar machen |
Dokumentieren Sie für jedes Muster Quell-ID, gegebenenfalls Quell-URL, geschäftlichen Grund, vorgesehenen Magento-Eigentümer, zugehörige externe Identifikatoren, bekannte Ausschlüsse und verantwortlichen Reviewer. Das Musterledger ist bereit, wenn jeder ausgewählte Datensatz eine nachvollziehbare Quellerwartung und einen benannten Prüfer besitzt.
Magento-Open-Source-Bereitschaftsgate abschließen
| Bereitschaftsfrage | Erforderlicher Nachweis | Bedingung für Bereitschaft |
|---|---|---|
| Sind Zugänge und Quellarchive wiederherstellbar? | Zugangsprotokoll, Datenbank-Backup, Medien-Backup und Exporte | Benötigte Datensätze können unabhängig vom Live-Quellshop geprüft werden |
| Sind Product-Familien und Attributsets definiert? | Product- und Attributmatrix | Jedes wesentliche Katalogmuster besitzt eine vorgesehene Magento-Struktur |
| Sind Categories, Inhalte und URLs zugeordnet? | Content- und Routenledger | Wichtige Datensätze besitzen Ziele oder Stilllegungsentscheidungen |
| Sind Customer- und Order-Bedeutungen dokumentiert? | Customer-/Order-Nachweispaket | Identität, Status und historische Beziehungen sind erklärt |
| Ist Bestandsverantwortung eindeutig? | Source-/Stock-/System-of-Record-Matrix | Jede wichtige SKU besitzt eine festgelegte Mengenautorität |
| Sind Erweiterungen und externe Systeme inventarisiert? | Abhängigkeitsregister | Jede kritische Abhängigkeit besitzt einen fortbestehenden Eigentümer |
| Sind repräsentative Migrationsmuster ausgewählt? | Musterledger | Gewöhnliche und außergewöhnliche Strukturen sind abgedeckt |
| Sind offene Punkte kontrolliert? | Entscheidungslog | Jeder offene Punkt besitzt Verantwortlichen und Fälligkeit |
Das Vorbereitungsgate ist vollständig, wenn keine kritische Product-, Attribut-, Customer-, Order-, Bestands-, URL- oder Erweiterungsentscheidung auf undokumentierten Annahmen beruht.
Fazit
Die Vorbereitung für Magento Open Source sollte ein wiederherstellbares, plattformspezifisches Nachweispaket schaffen. Product-Typen, Attributsets, Categories, Store Views, Inventory Sources, Customer Groups, historische Orders, Erweiterungen, Inhalte, URLs und externe IDs benötigen jeweils klare Eigentümerschaft.
Wer diese Entscheidungen vor dem repräsentativen Migrationstest dokumentiert, sorgt dafür, dass die Musterdatensätze die vorgesehene Magento-Architektur abbilden, statt das Team zu zwingen, sie erst aus importierten Daten abzuleiten.
Häufige Fragen
Welcher Vorbereitungsdatensatz für Magento Open Source sollte zuerst erstellt werden?
Erstellen Sie zuerst die Zielstrukturübersicht für Websites, Store Views, Product-Typen, Attribute, Bestand, Customers, Orders, Inhalte und Integrationen. Sie bestimmt, welche Nachweise der restliche Check benötigt.
Warum sind Product-Muster wichtiger als Product-Anzahlen?
Anzahlen zeigen keine konfigurierbaren Child-Beziehungen, Bundle-Komponenten, Custom Options, lokalisierten Werte oder von Erweiterungen verwalteten Felder. Repräsentative Product-Familien machen die Strukturen sichtbar, die das Ziel unterstützen muss.
Sollte jedes Quellfeld zu einem Magento-Attribut werden?
Nein. Ein Wert kann zu einer Variante, Custom Option, einem Content-Feld, einer Erweiterung, einem externen System oder einem bewussten Ausschluss gehören. Ordnen Sie das Feld nach Geschäftszweck und künftigem Nutzer zu.
Wie sollten Attributsets vorbereitet werden?
Gruppieren Sie Products nach tatsächlichen Pflegeanforderungen, definieren Sie die benötigten Attribute je Gruppe, normalisieren Sie kontrollierte Werte, dokumentieren Sie Geltungsbereiche und entfernen Sie veraltete oder doppelte Felder.
Wann sollte Bestand getrennt von Katalogdaten vorbereitet werden?
Immer dann, wenn Bestand von Sources, Stocks, Websites, konfigurierbaren Child-SKUs, Backorders, Reservations oder einem externen ERP, WMS, Marketplace oder Lieferantenfeed abhängt.
Was sollte mit Daten aus Erweiterungen oder Custom Modules geschehen?
Identifizieren Sie Modul, Kerndatensatz, Geschäftszweck, Tabellen oder Felder, externe Identifikatoren und fortbestehenden Zieleigentümer. Wichtige Datensätze brauchen ein ausdrücklich definiertes Ziel; veraltete Datensätze können archiviert oder ausgeschlossen werden.