Wenn osCMax als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Die Vorbereitung beginnt mit den Anforderungen des Quellshops, die erhalten bleiben müssen: Products und verkaufbare Kombinationen, Customers und Account-Beziehungen, Orders und ihre historische Bedeutung, Inhalte, Kennungen, Preise, Versand- und Zahlungskontext sowie Abhängigkeiten von externen Systemen. Für jede Anforderung muss feststehen, wo sie in osCMax dargestellt wird, welche Zielkonfiguration nötig ist, welche Nachweise gesammelt werden müssen und was neu gestaltet oder stillgelegt werden sollte.
Versionslinie, Shop-Historie und Quellzugriff erfassen
Dokumentieren Sie alle verfügbaren Hinweise auf die Abstammung der osCMax-Installation: angezeigte Version, Release-Paket oder Repository-Historie, Upgrade-Notizen, Änderungen am Datenbankschema, modifizierte Dateien, installierte Contributions, Template-Paket, Hosting-Umgebung und externe Integrationen. Widersprechen sich Nachweise, dokumentieren Sie die Unsicherheit statt automatisch die neuer wirkende Bezeichnung auszuwählen.
| Aktion | Verantwortlicher | Nachweis | Freigabebedingung |
|---|---|---|---|
| Versions- und Paketnachweise erfassen | Technischer Verantwortlicher | Admin-Footer, Paketdateien, Changelog, Versionswerte in der Datenbank | Bekannte und widersprüchliche Versionsindikatoren sind dokumentiert. |
| Upgrade- und Wartungshistorie erfassen | Entwickler, Agentur oder Händler | Deployment-Notizen, Backup-Daten, Patch-Historie | Wesentliche Schema- oder Codeübergänge sind identifizierbar. |
| Datenbank- und Dateizugriff bestätigen | Hosting-Verantwortlicher | Zugriffsstatus, Datenbankname, Document Root, Archivverfügbarkeit | Die tatsächlich aktive Installation kann untersucht und gesichert werden. |
| Template- und Sprachebenen identifizieren | Storefront-Verantwortlicher | Template-Name, Sprachverzeichnisse, Overrides, Screenshots | Inhalts- und Darstellungsdateien lassen sich von Datenbankdatensätzen trennen. |
| Geplante Jobs und externe Systeme identifizieren | Integrationsverantwortlicher | Cron-Liste, Exporte, Importe, ERP-/Buchhaltungs-/Versandreferenzen | Datenänderungen außerhalb des Admin-Bereichs sind bekannt. |
Während die Nachweise zusammengestellt werden, sollten undokumentierte Code- und Schemaänderungen eingefroren werden. Der Verkauf kann weiterlaufen, doch späte Product-Importe, neue Contributions, Feldänderungen oder Template-Wechsel gehören in ein Änderungsprotokoll.
Core-Commerce-Datensätze von Paket- und Contribution-Daten trennen
Beginnen Sie mit dem von osCommerce abgeleiteten Kern: Products, Product-Beschreibungen, Categories, Manufacturers, Attribute, Customers, Address Books, Orders, Order Products, Order Totals, Status, Reviews, Specials und weitere Standardbeziehungen der tatsächlichen Installation. Erfassen Sie anschließend zusätzliche Felder und Tabellen, die durch das osCMax-Paket, Contributions oder individuelle Entwicklung entstanden sind.
Ein vertrauter Tabellenname beweist nicht, dass jede Spalte zum Core gehört. Erstellen Sie ein Schema- und Eigentumsinventar, das Tabelle, Feld oder Datenkategorie, zugehörige Core-ID, bekannte erzeugende Contribution oder Modifikation, Geschäftszweck, aktuelle Nutzung und Zielentscheidung dokumentiert.
| Quellebene | Vorbereitungsnachweis | Freigabebedingung |
|---|---|---|
| Core-Product- und Category-Datensätze | Exporte für Product, Category, Manufacturer, Attribute, Preis, Bestand und Bilder | Grundlegende Katalogbeziehungen sind vollständig. |
| Durch das Paket ergänzte Felder | Schema-Diff, Admin-Screenshots, repräsentative Datensätze | Paketwerte sind von Core-Feldern getrennt. |
| Contribution-Tabelle | Tabellendefinition, Schlüsselbeziehungen, Modulname, Beispiel-IDs | Geschäftsdatenkategorie und Parent-Datensätze der Tabelle sind bekannt. |
| Direkte Core-Modifikation | Liste geänderter Dateien und betroffener Datenbankfelder | Geschäftliche Bedeutung ist unabhängig vom alten Code dokumentiert. |
| Feld eines externen Systems | Kennungszuordnung und aktueller Systemeigentümer | Stabile systemübergreifende Schlüssel bleiben nachverfolgbar. |
| Veraltete Tabelle oder Spalte | Nachweis letzter Nutzung und Händlerentscheidung | Technischer Altbestand ist für Archivierung oder Ausschluss markiert. |
Bereiten Sie eine Migration nicht allein anhand einer allgemeinen osCommerce-Tabellenliste vor. Das Live-Schema und der aktive Code bestimmen den tatsächlichen Quellshop.
Products, Attribute, Kombinationsbestand, Bilder und Preise vorbereiten
Legacy-Product-Optionen und Attribute können durch Contributions erweitert sein, die Bestand je Kombination, eigene SKUs, zusätzliche Bilder, individuelle Felder, Mengenrabatte, Preise je Customer Group, Downloads, Bundles oder Product-Konfiguratoren hinzufügen. Dokumentieren Sie das Geschäftsverhalten jeder Struktur, statt jede Option als einfaches Product-Attribut zu behandeln.
| Quellmuster | Aktion | Nachweis | Freigabebedingung |
|---|---|---|---|
| Standardattribut | Option, Wert, Product-Zuordnung und Preis- oder Gewichtseffekt erfassen | Attribute-Export und repräsentative Product-IDs | Bedeutung der Kaufauswahl ist eindeutig. |
| SKU oder Bestand auf Kombinationsebene | Contribution-Tabelle und Kombinationsschlüssel bestimmen | Kombinationsmatrix mit Menge und SKU | Verkaufbare Kombinationen lassen sich vom Parent Product unterscheiden. |
| Mehrere oder attributspezifische Bilder | Bilddateien, Reihenfolge und Product-/Optionsbeziehung erfassen | Medienmanifest und Dateipfade | Original-Assets und Zuordnungsbedeutung sind verfügbar. |
| Zusätzliches Product-Feld | Eigentümer, Typ, Anzeigezweck und externen Consumer dokumentieren | Schema-Zeile und Beispiel-Products | Aktive Werte haben einen Zieleigentümer. |
| Mengen- oder Customer-spezifischer Preis | Product, Gruppe oder Schwellenwert, Währung, Datumsbereich und Betrag erfassen | Preisinventar | Bedingte Preise werden nicht auf den Basispreis reduziert. |
| Downloadable Product | Datei, Zugriffsbeziehung sowie gegebenenfalls Ablauf oder Limit erfassen | Product- und historische Order-Beispiele | Nachweise zur digitalen Auslieferung sind vollständig. |
Der Katalogverantwortliche sollte jede Bereinigung doppelter Attribute, Bildnamen, SKUs oder Preise freigeben. Scheinbare Duplikate können Contribution-Verhalten oder externe Systemschlüssel widerspiegeln.
Customers, Address Books, Gruppen und Kontoerweiterungen vorbereiten
Die Customer-Vorbereitung sollte Kontoidentität, Address-Book-Einträge, Standardadressbeziehungen, Gruppen- oder Großhandelsklassifikation, Steuerkennungen, Freigabestatus, Loyalty- oder Credit-Datensätze, Referral-Werte, individuelle Felder und gegebenenfalls externe CRM- oder Buchhaltungs-IDs umfassen.
Erstellen Sie ein Ledger für Customer-Erweiterungen. Dokumentieren Sie für jedes zusätzliche Feld oder jede Tabelle den zugehörigen Customer-Schlüssel, Geschäftszweck, aktuellen oder historischen Status, Datenschutzverantwortlichen und die Frage, ob ein anderes System weiterhin autoritativ ist.
| Customer-Bereich | Nachweis | Freigabebedingung |
|---|---|---|
| Customer-Konto | Identität, Status, E-Mail-Ausnahmen, Daten und externe IDs | Doppelte oder widersprüchliche Identitäten haben eine festgelegte Behandlung. |
| Address Book | Adresszeilen und Standardadressverknüpfungen | Wiederverwendbare Adressen bleiben von Order-Snapshots getrennt. |
| Großhandels- oder Händlergruppe | Gruppenzuordnung plus Preis-, Steuer-, Zugriffs- oder Zahlungseffekte | Kommerzielle Bedeutung ist über die Bezeichnung hinaus dokumentiert. |
| Loyalty-, Credit- oder Reward-Contribution | Saldo, Transaktionshistorie und Parent-Customer-ID | Aktueller Saldo und historischer Nachweis können getrennt werden. |
| Individuelle Profilfelder | Schema, Feldtyp, Datenschutzzweck, Beispielwerte | Jedes aktive Feld hat einen Verantwortlichen. |
Orders, Order Totals, Statushistorie und Erweiterungsdatensätze vorbereiten
Orders enthalten in einem osCMax-Shop oft die wichtigsten historischen Nachweise. Bereiten Sie Order Header, Customer- oder Guest-Daten, Billing- und Shipping-Snapshots, Product Lines, Modell- oder SKU-Werte, gewählte Attribute, Mengen, Preise, Steuern, Rabatte, Versand, Zahlungsbezeichnungen, Status, Kommentare und externe Referenzen vor.
Order-Total-Module benötigen besondere Aufmerksamkeit. Trennen Sie Zwischensumme, Steuer, Versand, Coupon, Geschenkgutschein, Zuschlag, Kleinauftragsgebühr, Credit, Rabatt und weitere durch Contributions erzeugte Zeilen. Bewahren Sie Bezeichnung, Betrag, Sortierreihenfolge und Beziehung zur Endsumme.
| Order-Nachweis | Verantwortlicher | Freigabebedingung |
|---|---|---|
| Product- und Attributzeilen | Commerce-Verantwortlicher | Gekaufter Artikel und gewählte Werte sind ohne Live-Katalog verständlich. |
| Adress-Snapshots | Customer-Service-Verantwortlicher | Historische Adressen werden nicht durch aktuelle Customer-Daten überschrieben. |
| Order Totals | Finance- oder Commerce-Verantwortlicher | Jeder wesentliche Betrag hat eine bekannte Modul- oder Geschäftsbedeutung. |
| Status und Kommentare | Operations-Verantwortlicher | Historische Statusfolge und Notizen sind interpretierbar. |
| Zahlungs- und Versandreferenzen | Finance- oder Fulfillment-Verantwortlicher | Transaktion, Carrier, Tracking und Methodenbezeichnungen sind dokumentiert. |
| Returns, Vouchers, Credits oder After-Sales-Erweiterungen | Customer-Service-Verantwortlicher | Zugehörige Datensätze und Restwerte sind mit der Order verknüpft. |
| Export- oder Abstimmungs-IDs | Integrationsverantwortlicher | Buchhaltung, ERP, Marketplace oder Lager können die Transaktion finden. |
Aktuelle Zahlungs- oder Versandkonfiguration darf historische Bezeichnungen und Referenzen nicht ersetzen.
Contribution- und Anpassungsinventar erstellen
Das Contribution-Ledger ist das zentrale Vorbereitungsartefakt für osCMax. Gruppieren Sie Contributions nach Geschäftswirkung und nicht nur nach Installationsname.
| Contribution-Bereich | Vorzubereitende Nachweise | Freigabebedingung |
|---|---|---|
| Katalog und Preise | Zusätzliche Tabellen/Felder, repräsentative Products, Admin-Screens | Aktive Product- und Preisdaten haben Verantwortliche. |
| Customers und Zugriff | Gruppen, Freigaben, Steuerfelder, Loyalty, Credit, eingeschränkte Inhalte | Konto-Verhalten lässt sich in getrennte Beziehungen auflösen. |
| Checkout und Order Totals | Konfigurationsübersicht und repräsentative Orders | Historische Beträge sind von künftigem Verhalten getrennt. |
| Zahlung und Versand | Transaktions- oder Shipment-Referenzen, Statusfelder | Historische Nachweise bleiben ohne alte Zugangsdaten oder alten Code erhalten. |
| Reporting und Exporte | Exportflags, Batch-IDs, Schlüssel externer Systeme | Fortbestehende betriebliche Referenzen sind bekannt. |
| SEO und Inhalte | Routentabellen, Metadaten, Seiten, Redirects | Öffentliche Pfade und Inhaltseigentümer sind eindeutig. |
| Template und Interface | Template-Dateien, Boxen, Spracheinträge, Screenshots | Geschäftsinhalte sind von Darstellung getrennt. |
| Individueller Code | Liste geänderter Dateien, Schemaänderungen, Workflow-Verantwortlicher | Geschäftsregel ist unabhängig von der Implementierung dokumentiert. |
Klassifizieren Sie jedes Element als aktiv-erforderlich, aktiv-ersetzbar, nur historisch, inaktiv mit zu bewahrenden Daten, veraltet oder unbekannt. Unbekannte geschäftskritische Elemente blockieren die Migrationsbereitschaft.
Inhalte, Templates, Sprachdateien, Medien und URLs vorbereiten
Storefront-Inhalte können in Product- oder Category-Beschreibungen, Informationsseiten-Contributions, statischen Dateien, Template-Boxen, Sprachdateien, Bannern, Buttons, Bildern oder individuellen Modulen liegen. Inventarisieren Sie Inhalte nach Eigentümer und Route.
Bereiten Sie vor:
- aktive Richtlinien-, Informations-, Kontakt- und Serviceseiten;
- Product- und Category-Beschreibungen und Bilder;
- Template-Boxen mit geschäftlichen Inhalten;
- Texte aus Sprachdateien, die für Kunden weiterhin sichtbar sein müssen;
- Menüs und Navigationsziele;
- wichtige Product-, Category-, Manufacturer- und Inhalts-URLs;
- Redirects oder Rewrite-Regeln aus Contributions oder Serverkonfiguration;
- Originalbilder, Download-Dateien und nicht generierte Medien-Assets.
Ein Screenshot belegt die Darstellung, aber nicht den zugrunde liegenden Datensatz. Verknüpfen Sie Screenshots deshalb möglichst mit Dateipfaden, Datenbankschlüsseln oder Inhaltsquellen.
Hosting-, Runtime-, Sicherheits- und Backup-Nachweise vorbereiten
Legacy-Hostingbedingungen können bestimmen, ob Quelldaten und Dateien zugänglich sind. Dokumentieren Sie PHP- und Datenbankversionen, Zeichensatz oder Collation, Webserver-Konfiguration, geplante Jobs, Speicherpfade, Berechtigungen und bekannte Sicherheits- oder Wartungsbeschränkungen. Diese Angaben dienen der Quellinterpretation und sind keine Vorgabe, die alte Umgebung auf der Zielplattform zu reproduzieren.
Erstellen Sie einen wiederherstellbaren Backup-Satz aus Datenbank und relevantem Dateibaum desselben Shop-Zustands. Dazu gehören Templates, Sprachdateien, Bilder, Downloads, Contribution-Code, Konfigurationsreferenzen und individuelle Skripte. Dokumentieren Sie Verschlüsselung, Kompression, Größe, Zeitstempel und Zugriffsverantwortlichen.
| Backup-Bereich | Nachweis | Freigabebedingung |
|---|---|---|
| Datenbank | Vollständiger Dump und Hinweis zur Wiederherstellbarkeit | Core- und Contribution-Tabellen sind enthalten. |
| Dateien | Quellarchiv oder zugänglicher Dateibaum | Templates, Contributions, Bilder, Downloads und individueller Code sind verfügbar. |
| Umgebung | Runtime- und Servernotizen | Versionsabhängige Parsing-Probleme können antizipiert werden. |
| Sicherheit | Credential-Verantwortlicher, Zugriffsbeschränkungen, Umgang mit sensiblen Daten | Zugriff kann über den vorgesehenen Prozess sicher bereitgestellt werden. |
| Änderungsprotokoll | Späte Änderungen nach dem Backup | Neue Orders oder strukturelle Änderungen sind sichtbar. |
Repräsentative Beispiele für den Migrationstest auswählen
Erstellen Sie ein Stichprobenmanifest mit Quell-IDs, zugehörigen Tabellen, Dateien, Contribution-Eigentümer und erwarteter Quellbedeutung. Berücksichtigen Sie gewöhnliche Datensätze und die Fälle, die Schemaabweichungen am ehesten sichtbar machen.
Nehmen Sie auf:
- ein einfaches Product und ein Product mit Standardattributen;
- ein Product mit Bestand oder SKU auf Kombinationsebene, sofern verwendet;
- ein Product mit mehreren oder Contribution-eigenen Bildern, Downloads, Sonderpreisen oder individuellen Feldern;
- Customers mit mehreren Adressen, Großhandels-/Händlerklassifikation, individuellen Feldern, Loyalty, Credit oder externen IDs;
- Guest- und registrierte Orders mit Attributen, mehreren Order-Total-Zeilen, ungewöhnlichen Status, Zahlungs-/Versandreferenzen, Refunds, Vouchers oder Export-IDs;
- wichtige Inhalts- und Routenbeispiele;
- eine aktive Contribution-eigene Datenkategorie, einen Custom-Table-Datensatz und eine Beziehung zu einem externen System;
- einen zur Stilllegung vorgesehenen Datensatz mit dokumentierter Begründung, warum er nicht zum aktiven Zielumfang gehört.
Finales osCMax-Migrationsbereitschaft-Gate anwenden
| Migrationsbereitschaft-Frage | Erforderliches Ergebnis |
|---|---|
| Ist die Installationshistorie dokumentiert? | Versionsindikatoren, Historie, Paketnachweise und Konflikte sind erfasst. |
| Sind Core- und erweiterte Schemas getrennt? | Core-Tabellen, Paketerweiterungen, Contributions und individuelle Felder haben Verantwortliche. |
| Ist die Katalogkomplexität abgebildet? | Attribute, Kombinationsbestand, Bilder, Preise, Downloads und Kennungen sind dokumentiert. |
| Sind Customers und Orders interpretierbar? | Gruppen, Adressen, Totals, Status, After-Sales-Datensätze und externe IDs sind vollständig. |
| Sind Contributions klassifiziert? | Aktive, historische, veraltete und unbekannte Elemente haben explizite Entscheidungen. |
| Sind Inhalte und Storefront-Assets inventarisiert? | Seiten, Sprachtexte, Templates, Medien, URLs und Redirects sind nachvollziehbar. |
| Ist das Backup wiederherstellbar? | Datenbank, Dateien und Umgebungsnotizen entsprechen demselben Shop-Zustand. |
| Ist die Stichprobe repräsentativ? | Core-, Contribution-, Custom-Table-, historische und Stilllegungsfälle sind enthalten. |
Die Vorbereitung bleibt offen, solange eine geschäftskritische Contribution, Custom Table, Order-Total-Zeile oder externe Kennung keinen Verantwortlichen hat.
Fazit
Wenn osCMax als Zielplattform ausgewählt wird, hängt die Vorbereitung von den Nachweisen aus der tatsächlichen Quellinstallation ab. Core-Commerce-Datensätze, Paketerweiterungen, Contributions, Custom Tables, Templates, Sprachdateien, Order Totals und Schlüssel externer Systeme müssen getrennt werden, bevor die Migrationskonfiguration den Shop zuverlässig abbilden kann.
Ein wiederherstellbares Quellpaket, ein Ledger zur Contribution-Eigentümerschaft und ein repräsentatives Stichprobenmanifest bilden eine kontrollierte Migrationsbereitschaft-Grundlage für die Migrationskonfiguration.
Häufige Fragen
Warum reicht ein generisches osCommerce-Schema für die osCMax-Vorbereitung nicht aus?
osCMax-Installationen enthalten häufig Paketerweiterungen, Contributions, individuelle Felder, geänderte Core-Dateien und Custom Tables. Das Live-Schema und der aktive Code bestimmen, welche Datensätze vorhanden sind und was sie bedeuten.
Was sollte für jede osCMax-Contribution dokumentiert werden?
Dokumentieren Sie Geschäftszweck, Status, betroffene Core-Datenkategorien, Tabellen oder Felder, repräsentative Quell-IDs, externe Abhängigkeiten und die Einstufung der Datensätze als aktiv, historisch, ersetzbar, veraltet oder unbekannt.
Warum brauchen osCMax-Order-Totals ein eigenes Inventar?
Order-Total-Module können Versand-, Steuer-, Coupon-, Voucher-, Zuschlags-, Rabatt-, Gebühren-, Credit- und weitere Zeilen erzeugen. Bezeichnung, Betrag, Reihenfolge und Modulverantwortung erklären die historische Endsumme.
Sollten veraltete osCMax-Module und Tabellen einbezogen werden?
Sie sollten dokumentiert und anschließend für Archivierung oder Ausschluss markiert werden, wenn kein aktiver oder historischer Workflow mehr davon abhängt. Veralteter technischer Ballast sollte nicht in ein generisches Zielfeld gezwungen werden.
Was gehört in das osCMax-Quellbackup?
Bereiten Sie Datenbank und relevante Dateien desselben Shop-Zustands vor, einschließlich Templates, Contributions, Sprachdateien, Bilder, Downloads, Konfigurationsreferenzen und individuelle Skripte sowie Umgebungsnotizen.
Wie sollten repräsentative osCMax-Beispiele ausgewählt werden?
Nutzen Sie Core- und Contribution-geprägte Products, Customers mit Kontoerweiterungen, Orders mit mehreren Total-Zeilen, Inhalts- und Routenbeispiele, Custom-Table-Datensätze, externe Kennungen und mindestens einen bewusst stillzulegenden Fall.