Wenn OpenCart 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 OpenCart als Zielplattform ausgewählt werden soll, muss die Vorbereitung den Quellshop verständlich machen, bevor die Migrationskonfiguration endgültig festgelegt wird. Die sichtbare Shopoberfläche kann einfach wirken, während wichtige Beziehungen über Products, wiederverwendbare Optionen, Attribute, Filter, Categories, Hersteller, Kundengruppen, Rabatte, Sonderpreise, mehrere Stores, SEO-Keywords, Erweiterungen, Themes und individuelle Datenbankfelder verteilt sind.
Ziel der Vorbereitung ist, diese verteilte Struktur in kontrollierte Quelldaten und belastbare Nachweise zu überführen. Für jeden wichtigen Bereich sollten die auszuführende Aufgabe, die fachlich verantwortliche Person, der benötigte Nachweis und das Bestehenskriterium feststehen. So wird verhindert, dass ein Product-Export fälschlich als vollständiges Abbild des Shops gilt, obwohl Kaufentscheidungen, Navigationsregeln, historische Order-Beziehungen oder erweiterungseigene Werte an anderer Stelle liegen.
Quellzugriff herstellen und die OpenCart-Umgebung dokumentieren
Beginnen Sie mit Nachweisen zur tatsächlich verwendeten OpenCart-Installation. Halten Sie OpenCart-Version, aktive Store- oder Multi-Store-Struktur, Datenbank, Document Root, Admin-Pfad, aktive Sprachen und Währungen, aktuelles Theme sowie das eingesetzte Erweiterungs- und Modifikationssystem fest. Langjährig betriebene Shops können Marketplace-Erweiterungen, OCMOD- oder VQMod-Änderungen, bearbeitete Theme-Dateien, individuelle Tabellen oder direkte Core-Modifikationen enthalten.
Die Zugriffsplanung muss zum tatsächlich vorgesehenen Verbindungspfad passen. Datenbankzugriff, Admin-Zugang, Hosting-Zugriff, API-Zugang oder ein Dateipaket sind nicht automatisch austauschbar. Bereiten Sie deshalb den verfügbaren und für den konkreten Shop geeigneten Quellzugriff einschließlich unterstützender Nachweise vor und halten Sie die zuständige Person erreichbar, falls Berechtigungen oder Netzwerkregeln geklärt werden müssen.
| Aufgabe | Verantwortlich | Nachweis | Bereit, wenn |
|---|---|---|---|
| Exakte OpenCart-Version und aktive Store-IDs erfassen | Store-Administrator | Versionsnachweis, Store-Liste, Umgebungsnotiz | Jede aktive Store-Instanz und Quellversion ist identifiziert. |
| Quellzugriff bestätigen | Hosting- oder Technikverantwortlicher | Verfügbare Zugangsdaten, Allowlist-Informationen, Zugriffstest | Die benötigte Verbindung erreicht die vorgesehene Installation. |
| Theme- und Modifikationsschichten erfassen | Entwickler oder Agentur | Theme-Name, OCMOD-/VQMod-Listen, Liste veränderter Dateien | Native Datensätze und codeabhängiges Verhalten lassen sich unterscheiden. |
| Sprachen, Währungen, Steuerkonfiguration und Maßeinheiten dokumentieren | Commerce-Verantwortlicher | Settings-Export oder Screenshots | Shopweite Werte, die Product- und Order-Bedeutung beeinflussen, sind dokumentiert. |
| Geplante Imports oder Synchronisationen identifizieren | Integrationsverantwortlicher | Feed-Zeitplan, Liste externer Systeme, letzte Läufe | Bekannt ist, welche Werte sich während der Vorbereitung noch ändern können. |
Legen Sie einen Stichtag für unkontrollierte Strukturänderungen fest. Der laufende Handel kann weitergehen, doch neue Erweiterungen, Schemaänderungen, große Katalogumbauten oder URL-Umschreibungen sollten ab diesem Zeitpunkt dokumentiert werden.
Products, Optionen, Attribute und Filter als getrennte Nachweisgruppen vorbereiten
OpenCart trennt Product-Datensätze von Optionen, Attributen und Filtern. Optionen erfassen auswählbare oder vom Customer eingegebene Werte und können Preis, Gewicht, Punkte, Menge oder Pflichtstatus beeinflussen. Attribute beschreiben Products. Filter unterstützen die Produktsuche über Product- und Category-Beziehungen. Werden alle vier Bereiche in einer einzigen Tabelle zusammengeführt, geht leicht verloren, ob ein Wert Kaufentscheidung, Spezifikation oder Navigationshilfe ist.
Erstellen Sie eine Product-Inventur mit Modell, SKU beziehungsweise anderen Identifiern, Status, Menge, Bestandsstatus, Preis, Steuerklasse, Gewicht, Abmessungen, Hersteller, Categories, Bildern, Downloads, verwandten Products, Sonderpreisen, Rabatten, Rewards, Optionen, Attributen und Filtern, soweit diese verwendet werden. Die Inventur muss nicht jede Datenbankspalte wiedergeben, aber die Beziehungen sichtbar machen, die einfache von komplexen Products unterscheiden.
| Quellmuster | Vorbereitung | Erforderlicher Nachweis | Bereit, wenn |
|---|---|---|---|
| Pflicht- oder preisverändernde Option | Optionstyp, Werte, Pflichtstatus und Anpassungen erfassen | Product-IDs und repräsentative Optionszuordnungen | Die kommerzielle Wirkung der Option ist explizit. |
| Text-, Textarea-, Datei-, Datums- oder Zeiteingabe | Customer-Eingaben von wiederverwendbaren Optionswerten trennen | Product-Liste und Beispiel-Orders mit dieser Eingabe | Kaufbezogene Eingabe wird nicht mit einer Variante verwechselt. |
| Technische Spezifikation | Attributgruppe, Attribut, Sprachwert und Product-Zuordnung erfassen | Attributexport oder strukturierte Stichprobe | Beschreibende Daten sind von auswählbaren Werten getrennt. |
| Filter der Shopoberfläche | Filtergruppe, Wert, Product- und Category-Zuordnung erfassen | Aktive Filtermatrix | Nur tatsächlich für die Produktsuche verwendete Filter werden weitergeführt. |
| Product mit mehreren Bildern oder Downloads | Reihenfolge und Dateiverfügbarkeit erfassen | Medienliste, Pfade und repräsentative Product-IDs | Dateien und Product-Beziehungen sind verfügbar. |
| Sonderpreis oder Kundengruppenrabatt | Product, Kundengruppe, Betrag/Prozent, Mengenschwelle und Zeitraum erfassen | Pricing-Regelinventur | Bedingte Preislogik ist vollständig und nicht auf den Basispreis reduziert. |
Bereinigen Sie nur eindeutige Quelldefekte. Doppelte Optionslabels, inkonsistente Groß-/Kleinschreibung, ungenutzte Filter oder leere Identifier können markiert werden. Werte sollten jedoch nicht allein wegen ähnlicher Schreibweise zusammengeführt werden. Jede Änderung, die Customer-Bedeutung verändert, benötigt fachliche Freigabe.
Categories, Hersteller, Stores und Navigationsbeziehungen dokumentieren
OpenCart-Categories können hierarchisch aufgebaut sein, mehrsprachigen Inhalte tragen, mit Filtern verbunden und bestimmten Stores zugeordnet werden. Products können mehreren Categories und Stores angehören. Hersteller können reine Product-Felder oder öffentliche Marken-Landingpages sein. Diese Beziehungen sollten getrennt von der eigentlichen Menüpräsentation dokumentiert werden.
Bereiten Sie die aktive Category-Struktur mit Parent-IDs, Store-Zuordnung, Status, Sortierung, Bildern, Beschreibungen, Metadaten, Filtern und aktuellen URLs vor. Markieren Sie veraltete, versteckte, nur zur Navigation duplizierte oder ausschließlich für historische Links erhaltene Categories. Für Hersteller sollte dokumentiert werden, welche öffentliche Routen, brauchbaren Beschreibungen, Bilder oder Suchrelevanz besitzen.
Bei Multi-Store-Installationen ist zusätzlich eine Scope-Matrix nötig. Ein Product oder eine Category im Standard-Store gehört nicht automatisch zu jedem weiteren Store. Auch Sprache, Theme, Domain, Informationsseiten und Settings können abweichen. Die Nachweise müssen zeigen, welche Datensätze geteilt, dupliziert oder Store-spezifisch sind.
| Navigationsbereich | Verantwortlich | Nachweis | Bereit, wenn |
|---|---|---|---|
| Category-Hierarchie | Katalogverantwortlicher | Parent-Child-Export und aktive Category-Liste | Jede erhaltene Category besitzt bekannten Parent und Geschäftszweck. |
| Product-to-Category-Zuordnung | Merchandising | Repräsentative Multi-Category-Products und Zuordnungsexport | Gemeinsame Product-Platzierung ist sichtbar, ohne Products zu duplizieren. |
| Herstellerseiten | Brand- oder SEO-Verantwortlicher | Herstellerliste, Routeninventur, Sichtbarkeitsnotizen | Öffentliche Marken sind von rein internen Herstellerwerten getrennt. |
| Store-Zuordnung | Multi-Store-Verantwortlicher | Scope-Matrix für Products, Categories, Informationsseiten und Domains | Jeder Datensatz besitzt einen vorgesehenen Store-Scope. |
| Filter und Navigation | Merchandising | Filter-to-Category-Matrix und Menü-Screenshots | Katalogklassifikation ist von Menüpräsentation getrennt. |
Customers, Kundengruppen, Adressen und Order-Historie vorbereiten
Bei Customers müssen Kontenidentität, Adressbuch, Kundengruppen, Freigabestatus, Marketingpräferenzen, Rewards, individuelle Felder und externe Identifier getrennt betrachtet werden. Eine Kundengruppe kann Rabatte, Product-Prices, Steuerverhalten, Zahlungszugang oder Freigabeprozesse steuern. Deshalb muss ihre Geschäftswirkung dokumentiert werden und nicht nur ihr Name.
Für Orders sollte die historische Nachweisfunktion erhalten bleiben. Erstellen Sie eine Statusinventur und wählen Sie Orders aus, die Gast- und registrierten Kaufabschluss, verschiedene Kundengruppen, Optionen, Rabatte, Coupons, Rewards, Steuern, Versand, Zahlungsbezeichnungen, gegebenenfalls Rückerstattungen oder Retouren sowie erweiterungseigene Summen abdecken. Halten Sie fest, welche historischen Werte Mitarbeitende für Suche, Customer-Konto, Buchhaltung oder Integrationen benötigen.
| Bereich | Vorbereitung | Nachweis | Bereit, wenn |
|---|---|---|---|
| Customer-Konten | Doppelte E-Mails, Freigabestatus, individuelle Felder und externe Schlüssel identifizieren | Customer-Übersicht und Ausnahmeliste | Für Identitätsausnahmen gibt es Verantwortlichen und Entscheidung. |
| Kundengruppen | Jede aktive kommerzielle oder zugriffsbezogene Wirkung erfassen | Group-to-Rule-Matrix | Gruppenbedeutung ist über das Label hinaus dokumentiert. |
| Adressen | Wiederverwendbare Customer-Adressen von Order-Snapshots trennen | Customer- und Order-Adressstichproben | Aktuelle Kontodaten und historische Nachweise werden nicht vermischt. |
| Order-Status | Status nach betrieblicher Bedeutung dokumentieren | Statusliste mit Beispiel-Orders | Historische Zustände sind ohne Farbe oder Label allein interpretierbar. |
| Order-Summen | Zwischensumme, Steuer, Versand, Coupon, Reward, Gebühr, Guthaben und Erweiterungszeilen inventarisieren | Repräsentative Orders | Jede wesentliche Anpassung hat bekannten Ursprung. |
| Externe Referenzen | ERP-, Marktplatz-, Zahlungs-, Versand- oder Buchhaltungs-IDs erfassen | Identifier-Matrix | Fortbestehende Systeme können denselben Customer oder dieselbe Order finden. |
Historische Orders sollten nicht nur zur Vereinheitlichung nachträglich verändert werden. Ungewöhnliche Labels oder Beträge können wichtige Originalnachweise sein. Bekannte Anomalien sollten separat dokumentiert werden.
Erweiterungen, Modifikationen, Themes und individuelle Daten inventarisieren
OpenCart-Erweiterungen können Felder, Tabellen, Optionsverhalten, Order-Summen, Feeds, Marktplatz-Listings, Schritte beim Kaufabschluss, Zahlungsdaten, Versandreferenzen, Auswertungen, SEO-Logik oder administrative Prozesse ergänzen. Themes können individuelle Felder lesen oder die Darstellung von Optionen, Filtern und Inhalte verändern. Eine reine Liste von Erweiterungsnamen reicht deshalb nicht aus; dokumentiert werden müssen die Geschäftsdaten und Ergebnisse, für die jede Erweiterung verantwortlich ist.
Erstellen Sie ein Erweiterungsregister mit Status, Anbieter, Version, Zweck, Speicherort soweit bekannt, betroffenen Entitäten, individuellen Feldern oder Tabellen, externen Abhängigkeiten und einer verantwortlichen Person. Trennen Sie aktive Geschäftsdaten von Konfiguration und technischem Altbestand.
| Wirkung einer Erweiterung | Vorzubereitender Nachweis | Bereitschaftsentscheidung |
|---|---|---|
| Product- oder Optionsfelder | Feldnamen, Beispiel-Products, Tabellen- oder Exportquelle | Jeder aktive Wert besitzt einen Zieleigentümer oder bewussten Ausschluss. |
| Order-Summen oder Logik beim Kaufabschluss | Beispiel-Orders, Summenlabels, Konfigurationsübersicht | Historische Werte sind von künftiger Konfiguration des Kaufabschlusses getrennt. |
| Marktplatz- oder Feed-Integration | Listing-IDs, Vertriebskanal-Categories, Synchronisationsschlüssel | Kanonische Product-Identität und Vertriebskanal-Datensätze sind unterscheidbar. |
| SEO- oder URL-Modifikation | Aktuelle Routenbeispiele, Redirect-Tabellen, Rewrite-Konfiguration | Wichtige Quellpfade können rekonstruiert werden. |
| Theme-abhängiger Inhalte | Screenshots, Template-Pfade, Block- oder Modulzuordnungen | Inhalte ist von Darstellungs-Code getrennt. |
| Veraltete Erweiterung | Letzte Nutzung und Bestätigung des Datenverantwortlichen | Alte Records sind für Archiv oder Ausschluss markiert. |
Inhalte, SEO-Keywords, Medien und Routennachweise vorbereiten
OpenCart kann SEO-Keywords Products, Categories, Herstellern und Informationsseiten zuordnen. Erstellen Sie eine Routeninventur mit Quellobjekt, Store- und Sprach-Scope, aktuellem Pfad, SEO-Keyword, Traffic- oder Geschäftswert und geplanter Behandlung. Markieren Sie doppelte Keywords, fehlende Keywords bei wichtigen Datensätzen, erweiterungserzeugte Routen und Pfade, die Server-Rewrite-Konfiguration benötigen.
Die Inhaltsinventur sollte Informationsseiten, Product- und Category-Beschreibungen, Herstellerinhalte, Banner, Layouts, Module und relevante Mediendateien umfassen. Ordnen Sie jedes Element als migrierbaren Inhaltsdatensatz, Aufgabe für Zielkonfiguration, Theme-Asset, externe Ressource oder veraltetes Material ein.
Sichern Sie Originalbilder und Downloads inklusive Pfad. Ein Datenbankexport enthält häufig nur Dateireferenzen, nicht die Dateien selbst. Identifizieren Sie fehlende Dateien, externe URLs, Unterschiede in Groß-/Kleinschreibung und generierte Thumbnails, die nicht als Originalquelle erhalten werden müssen.
Backup- und Input-Vorbereitungspaket erstellen
Vor struktureller Bereinigung oder Migrationsausführung sollte eine wiederherstellbare Quellkopie entstehen. Bei einem selbst gehosteten OpenCart-Shop umfasst sie typischerweise Datenbank-Backup, relevante Dateien, Umgebungsinformationen, Konfigurationsreferenzen und einen Nachweis, dass Datenbank und Dateistand zusammengehören.
| Paketbestandteil | Verantwortlich | Nachweis | Bereit, wenn |
|---|---|---|---|
| Datenbank-Backup | Hosting- oder Datenbankadministrator | Zeitgestempelter Dump und Restore-Hinweis | Dump ist vollständig und gehört zur richtigen Datenbank. |
| Dateien und Medien | Hosting- oder Technikverantwortlicher | Archiv oder erreichbarer Dateibaum | Originalbilder, Downloads, Erweiterungen und Theme-Dateien sind verfügbar. |
| Umgebungsdokumentation | Technikverantwortlicher | PHP-, Datenbank-, Webserver- und Erweiterungsinformationen | Versionsabhängiges Verhalten kann eingeordnet werden. |
| Zugriffsregister | Projektverantwortlicher | Besitzer und Status jedes Zugriffs | Erforderliche Zugriffe sind verfügbar, ohne Credentials in Planungsdokumente aufzunehmen. |
| Änderungsprotokoll | Store-Administrator | Änderungen nach dem Nachweisstichtag | Späte Strukturänderungen können gezielt berücksichtigt werden. |
Repräsentative Migrationsstichproben auswählen
Die Stichprobe sollte gerade die Beziehungen sichtbar machen, die den OpenCart-Shop prägen. Erstellen Sie ein kompaktes Manifest mit Quell-IDs, Geschäftszweck, zugehörigen Dateien und erwarteter Quellstruktur. Es ist bereit, wenn jeder ausgewählte Datensatz vollständige Quelldaten und einen benannten Reviewer besitzt.
Mindestens enthalten sein sollten:
- ein einfaches Product sowie ein inaktives oder archiviertes Product;
- Products mit Pflicht-, preisverändernden, Text-, Datei-, Datums- oder bestandsrelevanten Optionen, sofern vorhanden;
- Products mit Attributen, Filtern, mehreren Categories, Herstellern, mehreren Bildern, Downloads, Sonderpreisen und Kundengruppenrabatten;
- Customers aus relevanten Kundengruppen, eine Gast-Order und eine Order eines registrierten Customers;
- Orders mit Optionswerten, Coupons, Rewards, Steuern, Versand, Zahlungsreferenzen, ungewöhnlichen Summen und externen IDs;
- je eine wichtige Route für jeden öffentlich relevanten Objekttyp;
- einen aktiven erweiterungseigenen Datensatz und ein Theme-abhängiges Inhaltsbeispiel.
Abschließendes OpenCart-Bereitschaftsprüfung anwenden
Der Quellshop ist für den nächsten Migrationsschritt bereit, wenn seine Struktur ohne undokumentierte Annahmen erklärt werden kann.
| Bereitschaftsfrage | Erforderliches Ergebnis |
|---|---|
| Sind exakte Installation und Store-Scope bekannt? | Version, Stores, Sprachen, Währungen, Theme und Modifikationsschichten sind dokumentiert. |
| Sind Product-Beziehungen vollständig? | Optionen, Attribute, Filter, Categories, Medien, Pricing-Regeln und Identifier sind erfasst. |
| Sind Customers und Orders interpretierbar? | Gruppenlogik, Adressen, Status, Summen und externe Referenzen haben klare Verantwortliche. |
| Sind Erweiterungen und individuelle Daten klassifiziert? | Jede aktive Abhängigkeit besitzt Geschäftszweck und Zielentscheidung. |
| Sind Inhalte und URLs inventarisiert? | Wichtige Routen, Informationsseiten, Medien und Rewrite-Abhängigkeiten sind dokumentiert. |
| Sind Backups und Zugriffe bereit? | Das Quellpaket ist wiederherstellbar und die erforderliche Verbindung verfügbar. |
| Ist die Stichprobe repräsentativ? | Komplexe und gewöhnliche Records sind mit Quell-IDs und erwarteten Beziehungen dokumentiert. |
Offene Punkte gehören mit Verantwortlichem und Termin in ein Entscheidungsprotokoll. Die Vorbereitung ist nicht abgeschlossen, wenn ein kritisches Feld, eine Erweiterungstabelle, eine Store-Zuordnung oder ein externer Identifier noch lediglich als „unbekannt“ beschrieben wird.
Fazit
Die Vorbereitung auf OpenCart als Zielplattform ist am stärksten, wenn der Quellshop als zusammenhängender Katalog- und Betriebsdatensatz verstanden wird und nicht als flacher Product-Export. Optionen, Attribute, Filter, Categories, Stores, Kundengruppen, Order-Summen, Erweiterungen, Themes, Medien und SEO-Keywords benötigen jeweils klare Verantwortlichkeit und geeignete Nachweise.
Ein kontrolliertes Quellpaket, ein Manifest repräsentativer Stichproben und ein explizites Bereitschaftsprüfung schaffen die belastbare Grundlage für die eigentliche Migrationskonfiguration.
Häufige Fragen
Warum sollten OpenCart-Optionen, Attribute und Filter getrennt vorbereitet werden?
Sie erfüllen unterschiedliche Funktionen. Optionen erfassen Kaufentscheidungen oder Customer-Eingaben, Attribute beschreiben Products und Filter unterstützen die Produktsuche. Werden sie zusammengeführt, können falsche Variantenstrukturen entstehen oder wichtige Spezifikationen und Navigationsbeziehungen verloren gehen.
Was sollte bei einer OpenCart-Multi-Store-Installation dokumentiert werden?
Dokumentieren Sie jede Store-ID, Domain, Sprache, Währung, Theme, Settings, Product- und Category-Zuordnung, Informationsseiten und wichtige URLs. Geteilte und Store-spezifische Datensätze müssen klar unterscheidbar sein.
Enthält ein Datenbank-Backup auch OpenCart-Bilder und Downloads?
Nein. Die Datenbank speichert gewöhnlich Dateireferenzen, während Originalbilder, Downloads, Theme-Assets und Erweiterungsdateien im Dateisystem liegen. Bereiten Sie Datenbank und Dateien gemeinsam vor.
Wie sollten erweiterungseigene OpenCart-Daten vorbereitet werden?
Erfassen Sie Erweiterung, betroffene Entitäten, individuelle Felder oder Tabellen, repräsentative Quelldatensätze, externe Abhängigkeiten und fortbestehenden Geschäftszweck. Aktive Werte benötigen einen expliziten Eigentümer; veraltete Records können für Archiv oder Ausschluss markiert werden.
Welche OpenCart-Datensätze gehören in die repräsentative Stichprobe?
Verwenden Sie gewöhnliche und komplexe Products, verschiedene Optionstypen, Attribute und Filter, Multi-Category-Beziehungen, Kundengruppen, aussagekräftige Orders, wichtige Routen und aktive erweiterungseigene Records. Das Manifest sollte Quell-IDs und erwartete Beziehungen enthalten.
Sollten doppelte SEO-Keywords bereits während der Vorbereitung geändert werden?
Markieren Sie sie zunächst und weisen Sie einen Verantwortlichen zu. Ändern Sie sie nur über eine freigegebene URL-Entscheidung mit dokumentiertem Ziel und Redirect-Beziehung, weil ein scheinbar doppeltes Keyword weiterhin Traffic- oder Integrationsbedeutung besitzen kann.