Wenn Gambio als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn Gambio als Zielplattform ausgewählt werden soll, muss die Vorbereitung zunächst klären, welche Kataloggeneration, Hosting-Umgebung, Module und Anpassungen der Quellshop tatsächlich verwendet. Aktuelle Product Options und Product Variants können in langjährig betriebenen Shops konzeptionell neben älteren Artikelattributen oder Artikeleigenschaften stehen. Products können außerdem von Sichtbarkeit nach Kundengruppe, gruppenspezifischen Preisen, Staffelpreisen, Categories, Inhalten, Modulen, externen Systemen und mehrsprachigen Feldern abhängen.
Jede Vorbereitungsmaßnahme sollte einen Verantwortlichen, einen konkreten Nachweis und eine eindeutige Freigabebedingung besitzen. Das Paket muss Quellnachweise von der Implementierung im Ziel trennen: Product- und Variantenbeziehungen, historische Orders, Content-Manager-Datensätze, URLs, externe Kennungen und moduleigene Daten gehören zur Migrationsbereitschaft; Live-Konfiguration für Zahlung, Versand, Steuern, E-Mail, Theme und Checkout bleibt dagegen Aufgabe der Zielumgebung.
Gambio-Umgebung, Zugriff und Wiederherstellungsweg bestätigen
Dokumentieren Sie, ob der Quellshop Gambio Cloud oder eine selbst gehostete Installation verwendet. Bestätigen Sie den Zugriff auf den Administrationsbereich sowie, soweit zutreffend, auf Hosting, Datenbank, Dateisystem, Product-Bilder, Download-Dateien, Content Manager, Module, geplante Prozesse und verbundene Systeme. Erfassen Sie die Gambio-Version, bei Self-Hosting die PHP-/Datenbankumgebung, das Theme, Sprachen, Währungen, aktive Module, GXModules, individuellen Code und Integrationen.
| Vorbereitungsmaßnahme | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Administrationszugriff bestätigen | Gambio-Administrator | Funktionsfähiges Konto und Rollenübersicht | Products, Optionen, Varianten, Customers, Orders, Inhalte und Module können geprüft werden. |
| Umgebungszugriff bestätigen | Infrastrukturverantwortlicher | Übersicht über Cloud-Management oder Hosting-/Datenbank-/Dateisystemzugriff | Es ist klar, welche Quellnachweise in der gewählten Betriebsumgebung verfügbar sind. |
| Wiederherstellbare Backups erstellen | Infrastrukturverantwortlicher | Backups von Datenbank, Dateien, Bildern, Downloads und Konfiguration einschließlich Wiederherstellungsverantwortlichem | Der Quellshop lässt sich wiederherstellen, ohne vom Live-System abhängig zu sein. |
| Versionen und Anpassungen erfassen | Technischer Verantwortlicher | Inventar von Gambio, gegebenenfalls PHP/Datenbank, Theme, Modulen, GXModules und individuellem Code | Versionsabhängige Strukturen und Änderungen sind dokumentiert. |
| Externe Systeme abbilden | Integrationsverantwortliche | Endpunkte und IDs für ERP/PIM/WMS/CRM/Marketplace/Buchhaltung/Zahlung/Auftragsabwicklung | Fortbestehende Datenhoheiten und Synchronisationsschlüssel sind bekannt. |
Bewahren Sie Kennungen für Products, aktuelle Varianten, ältere Attribute/Eigenschaften, Categories, Kundengruppen, Customers, Orders, Inhalte, Module und externe Systeme. Diese Kennungsübersicht ist besonders wichtig, wenn dieselbe sichtbare Auswahl je nach Gambio-Generation unterschiedlich gespeichert sein kann.
Products, Product-Typen und Category-Beziehungen klassifizieren
Bereiten Sie Products nach ihrem kommerziellen Verhalten vor und nicht nach bloßer Zeilenanzahl. Erfassen Sie Artikelnummer, Modell- oder Barcode-Kennungen, Product-Typ, Preis, Steuerklasse, Bestand, Abmessungen, Manufacturer, Categories, Bilder, Download-Dateien, Lieferstatus, Mengenregeln, mehrsprachige Beschreibungen, Metadaten und Sichtbarkeit.
| Product-Muster | Vorzubereitende Nachweise | Freigabebedingung |
|---|---|---|
| Standardmäßiger physischer Product | Product-ID, Artikel-/Modellnummer, Preis, Steuer, Bestand, Gewicht, Category, Manufacturer und Bilder | Ein Datensatz identifiziert den verkauften und ausgelieferten Artikel eindeutig. |
| Download-Product | Datei, Product-Verknüpfung, Zugriffsbeziehung, gegebenenfalls Limits/Ablauf und Beispiel einer abgeschlossenen Order | Datei und historischer Kaufnachweis sind wiederherstellbar. |
| Service oder nicht zu versendender Product | Product-Typ, Preis, Steuer, Verfügbarkeit und Order-Beispiel | Physische Bestands- und Versanddaten werden nicht erfunden. |
| Product in mehreren Categories | Product-zu-Category-Zuordnungen und priorisierte öffentliche Routen | Products werden nicht nur zur Reproduktion von Auffindbarkeitspfaden dupliziert. |
| Nach Kundengruppe eingeschränkter Product | Gruppensichtbarkeit, Product-ID, Preisbeziehungen und repräsentative Customers | Zugriff und kommerzieller Umfang sind über den Product-Status hinaus dokumentiert. |
| Medienreicher Product | Haupt- und Zusatzbilder, variantenspezifische Medien, Sortierung und Speicherpfad | Jedes Asset hat einen bekannten Product- oder Varianten-Eigentümer. |
Erfassen Sie inaktive, versteckte, ausgelaufene, nicht verfügbare und nachbestellbare Fälle sowie Mindestmengen- und Mengenstaffelregeln. Diese Zustände benötigen eine explizite Behandlung im Ziel.
Aktuelle Product Options und Varianten von Legacy-Strukturen trennen
Die aktuelle Gambio-Dokumentation unterscheidet Optionen, Product Options und Product Variants. Product Variants stehen für konkrete Kombinationen und können Product-Werte wie Kennungen, Bestand, Preis, Gewicht oder Bildbeziehungen überschreiben. Ältere Shops können für vergleichbare Storefront-Auswahlen Artikelattribute oder Artikeleigenschaften über andere Tabellen und Regeln verwenden.
| Quellstruktur | Vorzubereitende Nachweise | Freigabebedingung |
|---|---|---|
| Aktuelle Option | Options-ID, Werte, Übersetzungen, Sortierung und Product-Zuordnungen | Wiederverwendbare Auswahldefinitionen sind dokumentiert. |
| Product Option | Product, verknüpfte Optionswerte, Bildreferenzen, Pflichtstatus und Darstellungszweck | Auf Product-Ebene auswählbare Werte sind nachvollziehbar. |
| Product Variant | Varianten-ID, Optionskombination, Modell/EAN/GTIN, Preis, Bestand, Gewicht, Bildliste und Product-Verknüpfung | Jede verkaufsfähige Kombination besitzt eine vollständige Identität. |
| Legacy-Artikelattribut | Attributgruppe/-wert, Product-Verknüpfung, Preis-/Gewichtseffekt, Bestandsverhalten und Beispiele aus Order-Positionen | Legacy-Verhalten wird ohne Nachweis nicht als aktuelle Variante umgedeutet. |
| Legacy-Artikeleigenschaft | Eigenschaftsgruppen, Werte, Kombinationen, Bestand, Product-Verknüpfung und Kontext der Quellversion | Eigentum der Kombination und Datenherkunft sind eindeutig. |
| Käuferpersonalisierung | GX-Customizer oder Moduleigentümer, Felddefinition, Eingabewert und Referenz zur Order-Position | Einmalige Customer-Eingaben bleiben von wiederverwendbaren Variantendaten getrennt. |
Erstellen Sie für wichtige Optionsfamilien ein Auswahlregister. Notieren Sie, ob ein Wert verkaufsfähige Identität, Preis, Bestand, Gewicht, Medien, Auftragsabwicklung oder Filterung verändert oder lediglich die Product-Beschreibung ergänzt.
Customer Groups, Preise, Mengenregeln und Bestand vorbereiten
Gambio-Kundengruppen können Product- und Category-Zugriff, Inhaltssichtbarkeit, Product-Preise, Staffelpreise, steuerliche Behandlung, Rabatte und anderes kommerzielles Verhalten beeinflussen. Bestand kann einem Product oder einer Product Variant gehören, während externe Systeme weiterhin als maßgebliche Quelle fungieren können.
| Kommerzieller Bereich | Nachweis | Verantwortlicher | Freigabebedingung |
|---|---|---|---|
| Customer Group | Gruppen-ID, Name, Mitglieder, Sichtbarkeitszuordnungen, Preisfelder, Rabatt- oder Steuerverhalten | Commerce-Verantwortlicher | Gruppenbedeutung ist über die Bezeichnung hinaus dokumentiert. |
| Gruppenspezifischer Preis | Product/Variante, Gruppe, Währung, Betrag und Fallback-Verhalten | Preisverantwortlicher | Jeder Preis ist mit dem vorgesehenen Product und der richtigen Gruppe verbunden. |
| Staffelpreis | Product/Variante, Gruppe, Mengenschwellen, Preis und Zeitkontext | Preisverantwortlicher | Schwellenwerte und kommerzieller Geltungsbereich sind vollständig. |
| Mengenregel | Mindestmenge, Bestellschritt, Verpackungseinheit und Product-/Varianten-Eigentümer | Katalogverantwortlicher | Mengenbeschränkungen sind nicht in Notizen verborgen. |
| Bestand | Product-/Varianten-ID, Menge, Bestandsführungsmodus, Nachbestellstatus und externe Datenhoheit | Bestandsverantwortlicher | Die maßgebliche Menge der verkaufsfähigen Einheit ist bekannt. |
| Promotion oder Coupon | Code/Regel, Wert, Bedingungen, Zeiträume, Nutzung und historische Order-Referenzen | Marketingverantwortlicher | Historischer Rabattnachweis bleibt von der Live-Konfiguration im Ziel getrennt. |
Historische Order-Preise und Rabatte müssen als Snapshots erhalten bleiben. Sie dürfen nicht aus aktuellen Customer-Group-Einstellungen neu berechnet werden.
Customers, Adressen, Orders und Servicehistorie vorbereiten
Zur Customer-Vorbereitung gehören Identität, Kundengruppenzugehörigkeit, Adressen, Unternehmens- oder Steuerinformationen, Kontostatus, Einwilligungsnachweise, Reviews, gegebenenfalls Notizen, externe IDs und Authentifizierungsabhängigkeiten. Bei Orders müssen Product- oder Variantenpositionen, ausgewählte Werte, Adressen, Mengen, Preise, Steuern, Rabatte, Zahlungs- und Versandbezeichnungen, Status, Kommentare, Rechnungen, Lieferungen, Erstattungen, Widerrufe und externe Referenzen bewahrt werden.
| Datensatzbereich | Nachweis | Verantwortlicher | Freigabebedingung |
|---|---|---|---|
| Customer-Identität | Customer-ID, E-Mail, Gruppe, Status, Adressen, Sprache, Unternehmens-/Steuerfelder und externe ID | Customer-Datenverantwortlicher | Doppelte Konten und Gruppenzuordnungen sind bewusst aufgelöst. |
| Authentifizierung | Passwortverfahren, Social Login/SSO, MFA, Reset-Weg und Kommunikationsverantwortlicher | Sicherheitsverantwortlicher | Kontozugriff ist geplant, ohne Passwortportabilität zu unterstellen. |
| Order-Positionen | Product-/Varianten-IDs, Snapshot-Namen, Optionswerte, Menge, Preis, Steuer und Rabatt | Order-Datenverantwortlicher | Gekaufte Artikel bleiben unabhängig vom aktuellen Katalog nachvollziehbar. |
| Order-Status und Kommentare | Statushistorie, Zeitstempel, öffentliche/interne Kommentare und zuständiges Team | Operations-Verantwortlicher | Historische Prozessbedeutung ist dokumentiert. |
| Dokumente und After-Sales-Datensätze | Rechnung, Lieferdokument, Erstattung, Widerruf, Tracking und Zahlungsreferenzen | Finanz-/Supportverantwortliche | Historische Service- und Abstimmungsnachweise sind wiederherstellbar. |
| Externe IDs | ERP-, Marketplace-, Buchhaltungs-, Zahlungs- und Auftragsabwicklungsschlüssel | Integrationsverantwortliche | Systemübergreifende Datenherkunft bleibt nachvollziehbar. |
Nehmen Sie Gast- oder eingeschränkte Konten, Händlergruppen, mehrere Adressen, Orders mit aktuellen und älteren Optionsstrukturen, Staffelpreisfälle, Erstattungen, Widerrufe und extern abgewickelte Orders in die Vorbereitung auf.
Categories, Content-Manager-Datensätze, Rechtstexte und URLs vorbereiten
Gambio-Inhalte können in Product- oder Category-Beschreibungen, Product-Tabs, Content-Manager-Einträgen, Rechtstexten, Bannern, Teaser-Bereichen, Menüs, Themes, Sprachdateien oder Modulen liegen. Customer-Group-Zugriff kann außerdem für Products, Categories und Inhalte gelten.
| Storefront-Bereich | Vorzubereitende Nachweise | Freigabebedingung |
|---|---|---|
| Category-Hierarchie | Category-IDs, Parent-Beziehungen, Product-Zuordnungen, Gruppensichtbarkeit, Übersetzungen, Bilder und Metadaten | Kataloghierarchie und Zugriffsbereich sind vollständig. |
| Content-Manager-Datensatz | Content-ID, Typ, Sprache, Status, Gruppenzugriff, Route, Menü-/Footer-Platzierung und Medien | CMS-Inhalt bleibt von Theme-Präsentation getrennt. |
| Product-Tab oder zusätzliches Feld | Product-ID, Feld-/Tab-Definition, Sprache, Anzeigeposition und verwendendes Theme/Modul | Product-eigener Inhalt wird nicht in eine generische Seite umgewandelt. |
| Priorisierte URL | Eigentümer Product/Category/Inhalt, Sprache, Quellpfad, Metadaten und Zielabsicht | Jeder wichtige Pfad hat eine Entscheidung: erhalten, ändern, zusammenführen, einstellen oder weiterleiten. |
| Interner Link | Quellinhalt, verknüpftes Objekt, alter Pfad und Zielabsicht | Links können umgeschrieben werden, ohne den referenzierten Datensatz zu verlieren. |
| Theme- oder StyleEdit-Inhalt | Theme, Block, Platzierung, Quellinhalt und Verantwortlicher | Präsentationsabhängigkeiten sind von portablen Inhalten getrennt. |
Rechts- und Richtlinienseiten werden als Inhaltsdatensätze aufgenommen, während die aktuelle rechtliche Prüfung dem zuständigen Geschäftsverantwortlichen zugewiesen bleibt. Migrationsvorbereitung bewahrt Inhaltsidentität und Platzierungsnachweise; sie bestätigt nicht die rechtliche Aktualität.
Module, GXModules, benutzerdefinierte Tabellen und Integrationen inventarisieren
Erstellen Sie ein Eigentumsregister für Module, GXModules, Zahlungs- und Versandkomponenten, Marketplace-Connectoren, Product-Feeds, Suche, Loyalty, Reviews, Personalisierung, ERP/PIM/WMS/CRM-Integrationen, benutzerdefinierte Tabellen, veränderte Felder und direkte Datenbankänderungen.
| Abhängigkeit | Vorzubereitende Nachweise | Freigabebedingung |
|---|---|---|
| Modul oder GXModule | Name, Version, Status, Zweck, Konfigurationsverantwortlicher, Tabellen/Felder und betroffene Datensätze | Moduleigene Daten besitzen ein Ziel oder einen fortbestehenden Eigentümer. |
| Benutzerdefiniertes Feld/Tabelle | Schema, Schlüsselbeziehungen, Geschäftszweck und verwendender Code | Individuelle Datensätze können interpretiert und müssen nicht blind kopiert werden. |
| Theme-Anpassung | Theme-Version, StyleEdit-Einstellungen, Overrides, Skripte und betroffene Inhalte/Routen | Präsentation ist von portablen Datensätzen getrennt. |
| Externes System | Endpunkt, maßgebliche Entitäten, Synchronisationsrichtung, IDs und Cutover-Verantwortlicher | Konkurrierende führende Systeme werden vermieden. |
| API oder Feed | Ressourcen, Verantwortlicher für Zugangsdaten, Payload-Kennungen, Aktualisierungsrichtung und Fehlerverantwortlicher | Integrationsnachweise sind vollständig, ohne Geheimnisse in Dokumentation offenzulegen. |
| Generierte Daten | Cache, Logs, Sessions, Suchindizes, temporäre Exporte und aufgegebene Tabellen | Nicht maßgebliche Daten werden bewusst ausgeschlossen. |
Inaktive Module sollten im Register bleiben, wenn ihre Felder oder historischen Datensätze noch in Products, Customers, Orders oder Inhalten vorkommen.
Repräsentative Beispiele für den Migrationstest auswählen
Wählen Sie Beispiele, die die tatsächlich verwendete Gambio-Generation und das Betriebsmodell sichtbar machen. Erfassen Sie Quell-IDs, Artikelnummern, URLs, Optionsherkunft, Kundengruppen, Modulabhängigkeiten, externe Schlüssel und den Grund für die Auswahl jedes Beispiels.
| Beispiel | Vorzubereitende Nachweise | Zweck der Vorbereitung |
|---|---|---|
| Standard-Product | Preis, Steuer, Bestand, Category, Manufacturer, Medien, Gruppensichtbarkeit und Order | Definiert die gewöhnliche Product-Basis. |
| Aktuelle Product-Variant-Familie | Product, Optionen, Varianten, Kennungen, Bestand, Preis, Gewicht, Bilder und Orders | Repräsentiert das aktuelle Kombinationsmodell. |
| Product mit Legacy-Attributen/-Eigenschaften | Quellversion, Gruppen/Werte, Kombinationen, Preis-/Bestandsverhalten und Order-Positionen | Macht ältere Strukturen vor der Zuordnung sichtbar. |
| Customer-Group-Fall | Customer, Gruppe, eingeschränkter Product/Inhalt, Preis und relevante Order | Repräsentiert segmentiertes Commerce-Verhalten. |
| Komplexe Order | Variante oder Legacy-Auswahl, Rabatt, Steuer, Zahlung, Versand, Rechnung, Erstattung/Widerruf und externe IDs | Repräsentiert historische kommerzielle Nachweise. |
| Inhalts-/Routenfall | Content-Manager-Eintrag oder Product-/Category-Inhalt, Sprache, Gruppenzugriff, URL und Links | Repräsentiert Inhalts- und SEO-Eigentum. |
| Moduleigener Datensatz | Kernentität, Modultabelle/-feld, Konfigurationsverantwortlicher und Integrationsschlüssel | Macht Nicht-Kernumfang vor der Ausführung sichtbar. |
Das Gambio-Beispielpaket ist bereit, wenn jeder ausgewählte Datensatz ein Erwartungsblatt zur Quelle, Options- oder Variantenkontext, zugehörige Dateien und einen benannten Prüfer besitzt.
Abschließendes Bereitschafts-Gate für Gambio durchführen
| Bereitschaftsbereich | Bedingung für die Freigabe |
|---|---|
| Zugriff und Wiederherstellung | Administration, Cloud- oder Hosting-/Datenbank-/Dateizugriff, Bilder, Downloads, Backups und Wiederherstellungsverantwortung sind bestätigt. |
| Katalog | Products, aktuelle Varianten, Legacy-Attribute/-Eigenschaften, Categories, Manufacturers, Medien, Preise, Bestand und Kennungen sind nachvollziehbar. |
| Customers und Orders | Konten, Gruppen, Adressen, Orders, Positionen, Summen, Status, Dokumente, After-Sales-Datensätze und externe IDs besitzen Nachweise. |
| Inhalte und URLs | Content-Manager-Datensätze, Rechtstexte, Product-/Category-Inhalte, Themes, priorisierte Pfade, Links und Redirect-Entscheidungen sind dokumentiert. |
| Abhängigkeiten | Module, GXModules, benutzerdefinierte Felder/Tabellen, APIs, Feeds und externe Systeme haben benannte Verantwortliche. |
| Beispiele | Repräsentative Datensätze decken jedes wesentliche aktuelle, ältere, Customer-Group-, Order-, Inhalts- und Modulmuster ab. |
Der Gambio-Umfang ist bereit, wenn jeder wesentliche Datensatz auf Quellgeneration, Eigentümer, zugehörige Datensätze, Nachweisartefakt und vorgesehenes Ziel bzw. fortbestehendes System zurückgeführt werden kann.
Fazit
Eine belastbare Vorbereitung für Gambio benötigt abgestimmte Nachweise zu Betriebsumgebung, Products, aktuellen Optionen und Varianten, älteren Attributen oder Eigenschaften, Kundengruppen, Preisen, Bestand, Customers, Orders, Content-Manager-Datensätzen, URLs, Modulen und externen Systemen. Herkunft und Zuständigkeit müssen vor der Ausführung eindeutig sein.
Ein vollständiges Bereitschaftspaket sichert wiederherstellbare Quellnachweise, trennt aktuelle und ältere Katalogstrukturen, unterscheidet historische Transaktionen von Live-Konfiguration und weist jeder Inhalts- oder Modulabhängigkeit einen benannten Verantwortlichen zu.
Häufige Fragen
Was sollte für eine Gambio-Migration zuerst vorbereitet werden?
Bestätigen Sie zuerst, ob der Shop in Gambio Cloud oder selbst gehostet läuft, sichern Sie die verfügbaren Administrations- und Infrastrukturzugriffe, erstellen Sie wiederherstellbare Backups und dokumentieren Sie Gambio-Version, Theme, Module und Anpassungen.
Warum müssen aktuelle Varianten und ältere Attribute oder Eigenschaften getrennt werden?
Sie können ähnliche Storefront-Auswahlen über unterschiedliche Datensätze und Regeln erzeugen. Aktuelle Product Variants können Kennungen, Bestand, Preis, Gewicht und Bilder besitzen, während ältere Attribute oder Eigenschaften diese Beziehungen anders speichern.
Wie sollten Kundengruppen vorbereitet werden?
Dokumentieren Sie Gruppenzugehörigkeit gemeinsam mit Product-, Category- und Inhaltssichtbarkeit, gruppenspezifischen Preisen, Staffelpreisen, Rabatten und steuerlichem Verhalten. Nur den Gruppennamen zu erhalten bewahrt seine kommerzielle Bedeutung nicht.
Welche Gambio-Orders eignen sich als repräsentative Beispiele?
Nehmen Sie aktuelle Varianten, ältere Attribut-/Eigenschaftsauswahlen, Customer-Group-Preise, Gast- oder Händlerkonten, Rabatte, Steuern, Rechnungen, Lieferungen, Erstattungen oder Widerrufe sowie externe Integrationsreferenzen auf.
Wie sollten Content Manager und Theme-Inhalte getrennt werden?
Content-Manager-Einträge und Product-/Category-Inhalte sollten Datensatzidentität, Sprache, Zugriff, Route und Links behalten. StyleEdit, Theme-Blöcke und Template-Overrides gehören zur Präsentation und benötigen separate Zuständigkeit.
Was gehört in das Gambio-Modulregister?
Erfassen Sie jedes Modul, GXModule, benutzerdefinierte Feld oder Tabelle, jeden Feed, jede API-Verbindung und jede externe Integration, die Geschäftsdaten erzeugt oder konsumiert. Jeder Eintrag benötigt Eigentümer, betroffene Datensätze, Nachweise sowie eine Ziel- oder Retained-System-Entscheidung.