Wenn osCommerce 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 osCommerce als Zielplattform ausgewählt wird, beginnt die Vorbereitung mit der Versionslinie, denn aktuelles osCommerce v4 und langjährig betriebene Legacy-Installationen können deutlich unterschiedliche Katalog-, Erweiterungs-, Inhalts- und Datenbankstrukturen verwenden. Ein als osCommerce bezeichneter Shop kann aktuelles v4, eine ältere 2.x-Version, ein Fork oder eine stark veränderte Codebasis mit Community-Erweiterungen und direkten Schemaänderungen sein.
Ziel der Vorbereitung ist, das tatsächliche Quellmodell zu bestimmen, bevor Feld-Mappings gewählt werden. Jeder Bereich sollte Maßnahme, Verantwortlichen, Nachweis und Bereitschaftsbedingung benennen. Aktuelle v4-Beziehungen wie Vertriebskanäle, Kundengruppen, Attribute, Eigenschaften und CMS-Datensätze dürfen in einer Legacy-Quelle nicht in derselben Form vorausgesetzt werden. Umgekehrt darf eine Legacy-Erweiterungstabelle nicht nur deshalb als native v4-Daten behandelt werden, weil eine moderne Funktion ähnlich heißt.
Versionslinie, Zugriff und technische Verantwortung der Quelle klären
Dokumentieren Sie Plattformname, Version, Branch oder Fork, Datenbankpräfix, Hosting-Umgebung, aktive Front Ends oder Storefronts, Sprachen, Währungen, Erweiterungen, veränderte Dateien, eigene Tabellen und externe Synchronisationen der Quelle. Hat ein älterer Shop mehrere Upgrades durchlaufen, sollten Entwicklernotizen oder Schema-Nachweise erhalten bleiben, die erklären, welche Tabellen das aktuelle Verhalten tatsächlich steuern.
Bereiten Sie den für den gewählten Migrationspfad erforderlichen Zugriff auf die Quelle vor. Der technische Verantwortliche sollte bestätigen, dass die Verbindung die richtige Datenbank und den richtigen Dateibaum erreicht und dass verfügbare Backups denselben Shop-Zustand repräsentieren.
| Maßnahme | Verantwortlicher | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Quellgeneration und Code-Linie bestimmen | Technischer Verantwortlicher | Versionsnachweis, Repository- oder Paketnotiz, Fork-Historie | Die Quelle ist als aktuelles v4, Legacy-osCommerce, Fork oder individuelle Ableitung klassifiziert. |
| Datenbank- und Dateizugriff bestätigen | Hosting- oder Datenbankverantwortlicher | Datenbankname/-präfix, Verbindungsstatus, Document-Root-Hinweis | Die erforderliche Quellverbindung erreicht die vorgesehene Installation. |
| Erweiterungen und Core-Anpassungen inventarisieren | Entwickler oder Agentur | Erweiterungsliste, Nachweis veränderter Dateien, Liste eigener Tabellen | Native, erweiterungseigene und individuelle Datensätze lassen sich trennen. |
| Front Ends, Sprachen, Währungen und Steuerkontext dokumentieren | Commerce-Verantwortlicher | Einstellungsnachweis und Umfangsmatrix | Shopweiter Kontext, der Product- oder Order-Bedeutung verändert, ist dokumentiert. |
| Externe Systeme und Importe identifizieren | Integrationsverantwortlicher | ERP-/PIM-/WMS-/CRM-Liste, Feed-Zeitplan, Schlüsselfelder | Werte, die außerhalb von osCommerce gepflegt werden, haben eine benannte Systemhoheit. |
Sobald die Nachweise zusammengestellt sind, sollten nicht dokumentierte strukturelle Änderungen eingefroren werden. Der normale Handel kann weiterlaufen, aber neue Erweiterungen, Schemaänderungen, Product-Modelländerungen oder Routenumschreibungen gehören in das Projekt-Änderungsprotokoll.
Products, Categories, Marken, Lieferanten und Front-End-Umfang vorbereiten
Aktuelles osCommerce v4 kann Products mit Categories, Marken, Lieferanten, Vertriebskanälen oder Front Ends, Kundengruppen, mehrsprachigen Beschreibungen, Bestandsmodi, Bildern, Kennungen, Preisen, SEO-Feldern und Merchandising-Beziehungen verbinden. Legacy-Shops können dafür einfachere Core-Tabellen plus Erweiterungen nutzen.
Erstellen Sie ein Product-Inventar mit Quell-Product-ID, SKU oder Modell, weiteren Kennungen, Status, Basispreis, Steuerklasse, Bestandsverhalten, Gewicht, virtuellem/herunterladbarem Status, Category-Zuweisungen, Marke oder Hersteller, Lieferant, Bildern, Sprachwerten, Vertriebskanalumfang, Kundengruppenumfang sowie aktiven Promotion- oder Mengenpreisbeziehungen.
| Muster in der Quelle | Vorbereitungsmaßnahme | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Product mehreren Categories zugewiesen | Alle Category-Beziehungen und den primären Merchandising-Kontext dokumentieren | Product-zu-Category-Export | Gemeinsame Platzierung ist sichtbar, ohne Products zu duplizieren. |
| Product nur in ausgewählten Front Ends verfügbar | Kanal-/Front-End-Zuweisungen und Einschränkungen dokumentieren | Umfangsmatrix nach Product und Category | Kanalverfügbarkeit ist explizit. |
| Marken- oder Lieferantenbeziehung | Öffentliche Markenidentität von Beschaffungsverantwortung trennen | Marken-, Lieferanten- und Product-Verknüpfungen | Ähnliche Bezeichnungen werden nicht in ein fachlich falsches Feld zusammengeführt. |
| Echter, unbegrenzter, verborgener oder Preorder-Bestand | Menge, Bestandsmodus und Verhalten bei Nichtverfügbarkeit dokumentieren | Repräsentative Product-Einstellungen | Verfügbarkeitsbedeutung wird nicht auf eine numerische Menge reduziert. |
| Virtuelles oder herunterladbares Product | Datei, Ablauf, Download-Limits, Versandbedeutung und Quellpfad dokumentieren | Product-/Dateimanifest | Digitale Lieferbeziehungen und Originaldateien sind verfügbar. |
| Gruppen- oder Mengenpreis | Product, Kundengruppe, Schwelle, Währung und Betrag dokumentieren | Inventar der Preisbeziehungen | Bedingte Preise werden nicht durch den Basispreis ersetzt. |
Bei Legacy-Shops sollte vermerkt werden, welche Werte aus Core-Product-Tabellen und welche aus Erweiterungsspalten oder separaten Tabellen stammen. Jede Bereinigung, die Product-Identität oder Kanalumfang verändert, sollte vom Business-Verantwortlichen freigegeben werden.
Attribute, Eigenschaften und Beziehungen konfigurierbarer Products trennen
Aktuelles v4 unterscheidet Attribute von Eigenschaften. Attribute können auswählbare Werte, wiederverwendbare Vorlagen, Preis- oder Gewichtseffekte, virtuelle Dateien und Bestandsbeziehungen darstellen. Eigenschaften beschreiben strukturierte Merkmale für Darstellung, Filterung, Suche, Vergleich, Bereiche, Symbole oder Product Groups. Legacy-osCommerce-Attribute können mehrere dieser Bedeutungen vermischen.
Bereiten Sie Nachweise vor, die jeden Quellwert nach Funktion statt nur nach Namen klassifizieren.
| Geschäftliche Bedeutung | Vorbereitungsmaßnahme | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Auswählbare Käuferoption | Attribut, Werte, Vorlage, Product-Zuweisung und Preis-/Gewichtseffekte dokumentieren | Attribut- und Zuweisungsexport | Kaufoption und kommerzielle Wirkung sind explizit. |
| Kombination mit eigener SKU oder eigenem Bestand | Konfigurierbare oder erweiterungseigene Kombinationsdatensätze identifizieren | Kombinationstabelle und Product-Schlüssel | Eigenständige verkaufbare Identität bleibt im Quellmodell erhalten. |
| Technische Spezifikation | Eigenschaftskategorie, Eigenschaft, Typ, Einheit, Werte und Product-Verknüpfungen dokumentieren | Eigenschaftsinventar | Beschreibende Daten sind von Käuferoptionen getrennt. |
| Filter- oder Vergleichswert | Darstellungs-/Filter-/Suchverhalten und Taxonomie dokumentieren | Aktive Discovery-Feldmatrix | Für Product-Discovery erforderliche Werte sind identifiziert. |
| Texteingabe oder Personalisierung | Feldeigentümer und repräsentative Order-Positionen identifizieren | Product- und Order-Beispiele | Kaufspezifische Eingabe wird nicht als wiederverwendbare Metadaten behandelt. |
| Herunterladbares Attribut | Datei, Limits, Product und Attributbeziehung dokumentieren | Datei- und Attributmanifest | Datei und Nachweis des digitalen Anspruchs sind vollständig. |
Nicht jedes Legacy-Attribut darf automatisch zu einem aktuellen v4-Attribut werden. Manche Werte gehören zu Eigenschaften, Beziehungen konfigurierbarer Products, Custom Fields oder Strukturen einer Erweiterung.
Kundengruppen, Konten, Adressen und kommerziellen Kontext dokumentieren
Aktuelle v4-Kundengruppen können Product- und Category-Sichtbarkeit, Steueranwendung, kumulative Rabatte sowie Standardwerte für Gäste oder neu registrierte Nutzer steuern. Erweiterungen können Wholesale-, B2B-, Kredit-, Loyalty- oder Freigabedatensätze ergänzen. Legacy-Shops können dieselben Zusammenhänge anders abbilden.
Bereiten Sie Customer-Nachweise vor, die Identität, Adressbuchdatensätze, Gaststatus, Kundengruppenmitgliedschaft, Steuer- oder Handelsstatus, Bewertungen, externe Kennungen sowie erweiterungseigene Salden oder Berechtigungen voneinander trennen.
| Datensatzbereich | Verantwortlicher | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Customer-Identität | Customer-Service- oder CRM-Verantwortlicher | Duplikat- und Ausnahmeliste | Jedes beibehaltene Konto hat eine klare Identitätsentscheidung. |
| Kundengruppen | Commerce-Verantwortlicher | Gruppenmatrix für Sichtbarkeit, Steuern und Rabatte | Gruppenbedeutung ist über die Bezeichnung hinaus dokumentiert. |
| Adressen | Customer-Datenverantwortlicher | Wiederverwendbare Adressen und Order-Zeitpunkt-Beispiele | Kontodatensätze und historische Momentaufnahmen sind getrennt. |
| Wholesale- oder B2B-Erweiterungen | Business-Verantwortlicher und Entwickler | Unternehmens-, Rollen-, Freigabe-, Preis- oder Kreditdatensätze | Erweiterungseigene kommerzielle Beziehungen haben eine Zielentscheidung. |
| Bewertungen und Aktivität | Content- oder Commerce-Verantwortlicher | Repräsentative Customer-zu-Product-Beziehungen | Von Customers erzeugte Datensätze behalten den richtigen Eigentümer. |
| Externe Customer-Schlüssel | Integrationsverantwortlicher | CRM-/ERP-Kennungsmatrix | Fortbestehende Systeme können dasselbe Konto wiederfinden. |
Die Portabilität von Passwörtern sollte als Eigenschaft der Quelle dokumentiert und nicht aus einer vorhandenen E-Mail-Adresse abgeleitet werden. Erfassen Sie Authentifizierungsschema und Abhängigkeit des Kontozugriffs, ohne diese Checkliste in Kommunikationsplanung für Customers umzuwandeln.
Orders und historische Geschäftsnachweise vorbereiten
Die Order-Vorbereitung sollte historische Transaktionen interpretierbar machen. Aktuelle v4-Orders können Vertriebskanalkontext, Product- und Attributmomentaufnahmen, Adressen, Summen, Status, Kommentare, Zahlungs- und Versandbezeichnungen, Tracking, Erstattungen, Rückgaben, Rechnungen und externe Referenzen enthalten. Legacy-Module können zusätzliche Order-Total-Zeilen oder Transaktionstabellen erzeugen.
Wählen Sie Orders aus, die die tatsächliche Komplexität des Shops repräsentieren, und bestimmen Sie, welche Datensätze oder Erweiterungen jeden historischen Wert besitzen.
| Order-Nachweis | Vorbereitungsmaßnahme | Bereitschaftsbedingung |
|---|---|---|
| Product- und Attributpositionen | Momentaufnahme von Namen, SKUs, gewählten Werten, Mengen und Preisen dokumentieren | Der gekaufte Artikel bleibt unabhängig vom aktuellen Katalog verständlich. |
| Rechnungs- und Lieferadressen | Order-Zeitpunkt-Momentaufnahmen getrennt von Customer-Adressen erhalten | Historische Transaktionsadressen sind vollständig. |
| Steuern, Versand, Rabatte, Gebühren und Gutschriften | Jede relevante Order-Total-Zeile und ihren Moduleigentümer inventarisieren | Endsumme lässt sich erklären, ohne stillgelegten Code wiederherzustellen. |
| Zahlungs- und Versandreferenzen | Bezeichnungen, Transaktions-IDs, Tracking und Modulverantwortung dokumentieren | Historische Referenzen sind verfügbar, ohne sie als aktive Konfiguration zu behandeln. |
| Status und Kommentare | Statusbedeutung, Reihenfolge, Datum und Sichtbarkeit dokumentieren | Mitarbeitende können den historischen Ablauf interpretieren. |
| Erstattungen, Rückgaben und externe IDs | Verbundene Entitäten und Abstimmungsschlüssel dokumentieren | After-Sales- und externe Systembeziehungen bleiben nachvollziehbar. |
Alte Orders dürfen nicht aus aktuellen Product-, Kundengruppen-, Steuer- oder Versandeinstellungen neu berechnet werden. Das Nachweispaket sollte die ursprüngliche Transaktion so erhalten, wie sie aufgezeichnet wurde.
Apps, Legacy-Erweiterungen, eigene Tabellen und Integrationen inventarisieren
Aktuelle v4-Apps und Legacy-Erweiterungen können Katalogfelder, Kundengruppen, Order-Summen, SEO-Daten, Zahlungsreferenzen, Marketplace-Angebote, Berichte oder Zuordnungen externer Systeme besitzen. Eine reine Erweiterungsliste reicht nicht; die Vorbereitung muss bestimmen, welche Datensätze jede Komponente erzeugt oder verändert.
| Abhängigkeitsmuster | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|
| Aktuelle v4-App | App-Name, Version, betroffene Entitäten, Felder/Tabellen und repräsentative IDs | Aktive App-Daten haben einen expliziten Eigentümer. |
| Legacy-Erweiterung | Paketname, veränderte Core-Dateien, SQL-Änderungen und verbundene Datensätze | Erweiterungsdaten lassen sich von Core-osCommerce-Datensätzen trennen. |
| Eigene Tabelle oder eigenes Feld | Schema, Geschäftsbedeutung, Parent-Schlüssel und Nutzer | Jeder aktive individuelle Wert hat eine Zielentscheidung. |
| Marketplace- oder Vertriebskanal-Connector | Listing-, Angebots-, Kanal- und externe IDs | Kanonische Product-Identität ist von Kanaldarstellung getrennt. |
| ERP-/PIM-/WMS-/CRM-Integration | Systemhoheit, Synchronisationsrichtung und stabile Schlüssel | Fortbestehende Systeme können Zielentitäten wieder verbinden. |
| Aufgegebene Komponente | Nachweis der letzten Nutzung und Bestätigung des Verantwortlichen | Veraltete technische Reste sind für Archivierung oder Ausschluss markiert. |
CMS-Inhalte, Medien, SEO und Routen-Nachweise vorbereiten
Aktuelles v4 kann CMS-Inhalte, Themes, Front Ends, Product- und Category-Beschreibungen, Medien und SEO-Einstellungen verwalten. Legacy-Shops können Erweiterungen für Informationsseiten, statische Dateien, Template-Boxen, Sprachdateien oder SEO-Module verwenden. Bereiten Sie Inhalte nach Eigentümer vor, statt jede sichtbare Seite als dieselbe CMS-Entität zu behandeln.
Erstellen Sie ein Routeninventar für priorisierte Products, Categories, Marken, CMS Pages, Informationsseiten, Front-End-spezifische Inhalte und Erweiterungsendpunkte. Dokumentieren Sie Quellpfad, Eigentümerobjekt, Sprache, Front End, Metadaten, gegebenenfalls Canonical-Einstellung, Geschäftsbedeutung und vorgesehene Behandlung.
Sichern Sie Originalbilder, Downloads, Dokumente, Theme-Assets und Inhaltsdateien. Dokumentieren Sie Attachment-Beziehungen und externe URLs. Ein Datenbank-Dump kann Dateinamen enthalten, ohne die Originaldateien selbst zu sichern.
Backup- und Eingabebereitschaftspaket erstellen
Erstellen Sie ein wiederherstellbares Paket, das an einen eindeutigen Quellzustand gebunden ist.
| Paketbestandteil | Verantwortlicher | Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Datenbank-Backup | Datenbankadministrator | Zeitgestempelter Dump, Präfix und Hinweis zur Quellgeneration | Das vollständige vorgesehene Schema ist enthalten. |
| Dateien und Medien | Hosting- oder Technikverantwortlicher | Dateiarchiv oder zugänglicher Quellbaum | Originalmedien, Downloads, Erweiterungen und individueller Code sind verfügbar. |
| Versionsliniennachweis | Technischer Verantwortlicher | Versions-/Fork-Historie und Upgrade-Notizen | Legacy- und aktuelle Strukturen lassen sich korrekt interpretieren. |
| Zugriffsregister | Projektverantwortlicher | Zugriffsverantwortlicher und Verbindungsstatus | Erforderliche Zugriffe sind verfügbar, ohne Zugangsdaten zu veröffentlichen. |
| Änderungsprotokoll | Shop-Administrator | Strukturelle Änderungen nach dem Nachweis-Stichtag | Späte Änderungen können bewusst übernommen werden. |
Repräsentative Teststichproben für die Migration auswählen
Erstellen Sie ein Stichprobenmanifest mit Quell-IDs, Verantwortlichen, geschäftlichem Grund, verbundenen Dateien und erwarteten Quellbeziehungen. Die Auswahl sollte sowohl aktuelle v4-Strukturen als auch Legacy-spezifische Strukturen sichtbar machen, sofern beide existieren. Das osCommerce-Stichprobenmanifest ist bereit, wenn jede Quellerwartung, Abhängigkeit von der Versionslinie, verknüpfte Datei und Kennung vollständig dokumentiert und einer prüfenden Person zugeordnet ist.
Mindestens enthalten sein sollten:
- ein einfaches Product und ein Product mit mehreren Category- oder Front-End-Zuweisungen;
- Products mit Attributen, Eigenschaften, konfigurierbaren Kombinationen, Downloads, Lieferanten und Gruppenpreisen;
- Customers aus relevanten Gruppen, Gasttransaktionen sowie Wholesale- oder erweiterungseigene Konten;
- Orders mit Attributen, mehreren Summen, Erstattungen, Tracking, Kommentaren und externen Referenzen;
- priorisierte CMS-, Product-, Category-, Marken- und erweiterungseigene Routen;
- ein aktueller App- oder Legacy-Erweiterungsdatensatz mit geschäftlichen Daten;
- ein Datensatz, dessen Bedeutung sich zwischen Quellgeneration und aktuellem v4 unterscheidet.
Abschließendes osCommerce-Bereitschaftstor anwenden
| Bereitschaftsfrage | Erforderliches Ergebnis |
|---|---|
| Ist die Quelllinie bestätigt? | Version, Branch oder Fork, Datenbank, Front Ends, Erweiterungen und Anpassungen sind dokumentiert. |
| Ist der Katalogumfang vollständig? | Products, Categories, Marken, Lieferanten, Kanäle, Bestand, Preise und Medien haben Eigentümer. |
| Sind Attribute und Eigenschaften klassifiziert? | Auswählbare, beschreibende, konfigurierbare und individuelle Beziehungen sind getrennt. |
| Sind Customers und Orders interpretierbar? | Gruppen, Adressen, Summen, Status und externe Referenzen sind dokumentiert. |
| Sind Apps und individuelle Daten klassifiziert? | Aktive erweiterungseigene Datensätze haben explizite Zielentscheidungen. |
| Sind Inhalte und Routen inventarisiert? | CMS, Legacy-Inhalte, Medien und wichtige URLs sind ihren Eigentümerobjekten zugeordnet. |
| Sind Backup, Zugriff und Stichproben bereit? | Das Quellpaket ist wiederherstellbar und repräsentative IDs sind aufgelistet. |
Die Vorbereitung bleibt offen, solange eine kritische Legacy-Tabelle, Kanalzuweisung, Kundengruppenregel, ein Order-Total-Modul oder eine externe Kennung noch keinen Eigentümer und keine Zielentscheidung hat.
Fazit
Die Vorbereitung auf osCommerce ist ebenso eine Arbeit an der Versionslinie wie eine Dateninventur. Aktuelle v4-Products, Front Ends, Kundengruppen, Attribute, Eigenschaften, CMS-Inhalte und Apps müssen von Legacy-Tabellen, Community-Erweiterungen und verändertem Code getrennt werden.
Ein kontrolliertes Quellpaket macht diese Grenzen explizit und stellt repräsentative Datensätze für die Migrationskonfiguration bereit.
Häufige Fragen
Warum muss die osCommerce-Version oder der Fork der Quelle zuerst bestätigt werden?
Aktuelles v4 und Legacy-osCommerce-Installationen können Katalog-, Customer-, Order-, Inhalts- und Erweiterungsdaten unterschiedlich speichern und interpretieren. Die Versionslinie bestimmt, welche Beziehungen und Tabellen die Quelldatensätze tatsächlich besitzen.
Was unterscheidet die Vorbereitung von Attributen und Eigenschaften?
Attribute stehen meist für auswählbare oder konfigurierbare Product-Werte und können Preis, Gewicht, Bestand oder Downloads beeinflussen. Eigenschaften beschreiben strukturierte Merkmale für Darstellung, Filter, Suche oder Vergleich.
Wie sollten Vertriebskanal- oder Front-End-Zuweisungen dokumentiert werden?
Dokumentieren Sie, welche Products, Categories, Inhalte, Sprachen und URLs zu jedem Front End gehören. Gemeinsame und kanalspezifische Datensätze sollten in einer Umfangsmatrix sichtbar sein.
Sollten Tabellen aus Legacy-Erweiterungen in aktuelle osCommerce-v4-Felder kopiert werden?
Nicht automatisch. Identifizieren Sie zuerst Erweiterung, geschäftliche Bedeutung, Parent-Datensatz und fortbestehenden Nutzer. Eine moderne Funktion mit ähnlicher Bezeichnung verwendet möglicherweise nicht dasselbe Schema oder Verhalten.
Welche Orders gehören in eine osCommerce-Stichprobe?
Nehmen Sie Gast- und registrierte Orders, mehrere Status, Attributauswahl, Rabatte, Steuern, Versand, Zahlungsreferenzen, Erstattungen, Kommentare, Tracking sowie von Erweiterungen erzeugte Summen oder externe IDs auf.
Enthält das Datenbank-Backup auch osCommerce-Bilder, Downloads und Erweiterungsdateien?
Nein. Sichern Sie den relevanten Dateibaum zusätzlich zur Datenbank, damit Medien, herunterladbare Dateien, Themes, Apps, Legacy-Erweiterungen und individueller Code verfügbar bleiben.