Wenn osCMax als mögliche Zielplattform bewertet wird, erfordert die Migrationsplanung eine forensische Betrachtung der konkreten Quellinstanz. Die osCommerce-Abstammung der Plattform, gebündelte Contributions, spätere Änderungen und händlerspezifischer Code können dazu führen, dass zwei Shops mit demselben Plattformnamen materiell unterschiedlich aufgebaut sind. Fehler lassen sich deshalb nur zuverlässig vermeiden, wenn tatsächliche Datenbankstrukturen und geschäftliche Nutzung nachvollzogen werden, statt ein universelles Schema zu unterstellen.
Die wichtigsten Fehler entstehen, wenn osCMax als einheitliches osCommerce-ähnliches Zielschema behandelt wird. Abstammung, gebündelte Contributions, spätere Änderungen, Hosting-Entscheidungen und händlerspezifischer Code können einen Ziel-Build deutlich von einem anderen unterscheiden. Prävention beginnt deshalb mit der Prüfung der tatsächlichen Zielumgebung und damit, jede Anforderung des Quellshops einem bekannten Verantwortungsbereich im Ziel zuzuordnen.
Fehler 1: Annehmen, dass jeder osCMax-Shop ein einheitliches Standardschema verwendet
Was schiefgeht
osCMax-Shops spiegeln häufig eine konkrete Installationshistorie statt eines einzigen einheitlichen Datenmodells wider. Gebündelte Contributions, spätere Änderungen, Custom Tables und direkte Codeanpassungen können Products, Customers, Orders, Inhalte und Administration verändern. Die Bezeichnung osCMax beweist deshalb nicht, welche Felder oder Beziehungen im tatsächlichen Quellshop vorhanden sind.
Frühe Warnsignale
Dokumentation und Datenbankexport widersprechen sich, Tabellenpräfixe oder Spalten weichen von Erwartungen ab oder Mitarbeiter nutzen Admin-Oberflächen ohne erkennbares Gegenstück in Standardtabellen. Zwei als osCMax bezeichnete Shops erzeugen deutlich unterschiedliche Exporte.
| Nachweis | Mögliche Bedeutung | Migrationsrisiko |
|---|---|---|
| Unerwartete Tabelle oder Spalte | Gebündelte oder individuelle Contribution | Geschäftsdaten können ausgelassen werden |
| Geänderter Admin-Workflow | Anpassung auf Codeebene | Gespeicherte Werte können verborgene Bedeutung besitzen |
| Unterschiedliches Verhalten zweier Shops | Abweichende Installationshistorie | Ein Mapping kann nicht sicher für beide gelten |
Prävention
Inventarisieren Sie tatsächliche Datenbank, Dateistruktur, installierte Contributions und Geschäftsabläufe, bevor Mappings definiert werden. Verfolgen Sie jedes nicht standardisierte Feld bis zu Oberfläche, Report oder Prozess, der es verwendet. Wissen über die Plattformfamilie dient nur der Orientierung; der Live-Shop ist das autoritative Schema.
Beispiel für eine Empfehlung
Ein Product-Export enthält mehrere Preis- und Sichtbarkeitsspalten, die in einem einfachen osCommerce-Schema fehlen. Statt sie als Rauschen zu verwerfen, werden sie bis zum Customer-Group-Verhalten zurückverfolgt und nur jene Werte bewahrt, die weiterhin kommerzielle Bedeutung haben.
Bestehenskriterium
Jede im Umfang liegende Tabelle und jedes nicht standardisierte Feld ist nach Zweck klassifiziert, keine erforderliche Datensatzfamilie hängt von einer unbekannten Contribution ab und das Mapping folgt dem tatsächlichen Shop statt einer angenommenen osCMax-Vorlage.
Fehler 2: osCMax wie einen gewöhnlichen osCommerce-2.x-Shop behandeln
Was schiefgeht
osCMax hat osCommerce-Konzepte geerbt, historisch aber zusätzliche Contributions und Integrationsentscheidungen gebündelt. Ein gewöhnliches osCommerce-Mapping kann Felder, Beziehungen und Admin-Verhalten ignorieren, die osCMax ergänzt oder verändert hat. Der umgekehrte Fehler ist ebenfalls möglich: anzunehmen, dass jedes historische osCMax-Feature im konkreten Händler-Shop noch aktiv ist.
Frühe Warnsignale
Der Migrationsplan nennt nur Basis-Products, Customers, Orders, Categories und Attribute. Mitarbeiter erwähnen Gruppenpreise, Artikelinhalte, Template-Systeme, erweiterte Orders oder Reports, die im Mapping keinen Platz haben.
| Annahme | Warum sie scheitert | Erforderliche Reaktion |
|---|---|---|
| Basis-osCommerce-Tabellen reichen aus | Gebündelte Contributions können zusätzliche Bedeutung besitzen | osCMax-spezifische und individuelle Strukturen untersuchen |
| Jedes gebündelte Feature ist aktiv | Ungenutzte Contributions können Rückstände hinterlassen | Tatsächliche geschäftliche Nutzung bestätigen |
| Die Zielplattform kann altes Verhalten automatisch reproduzieren | Verhalten kann in Code statt Datensätzen liegen | Separaten Zielverantwortlichen festlegen |
Prävention
Trennen Sie geerbte osCommerce-Strukturen von osCMax-Erweiterungen und händlerspezifischen Änderungen. Leiten Sie den Umfang aus beobachteter Geschäftsnutzung statt einer historischen Feature-Liste ab. Bewahren Sie weiterhin benötigte Datenbeziehungen und legen Sie ungenutzte Contribution-Rückstände bewusst still.
Beispiel für eine Empfehlung
Ein Shop enthält Artikeltabellen und Customer-Preisstrukturen. Prüfen Sie, ob beide noch kundenbezogene oder betriebliche Prozesse unterstützen. Migrieren Sie weiterhin benötigte Inhalts- und Preisbedeutung, bauen Sie aufgegebene Module aber nicht nur deshalb nach, weil ihre Tabellen noch gefüllt sind.
Bestehenskriterium
Das Team kann Strukturen als geerbt, gebündelt, individuell angepasst, aktiv oder veraltet unterscheiden und jede fortbestehende Beziehung hat ein explizites Ziel, ohne pauschale Gleichsetzung mit Basis-osCommerce.
Fehler 3: Contribution-eigene Product-Felder verlieren
Was schiefgeht
Ein Product kann Werte enthalten, die durch gebündelte oder später installierte Contributions erzeugt wurden: zusätzliche Beschreibungen, Kennungen, Verfügbarkeitsfelder, Tabs, Versandinformationen, Mengenregeln oder Merchandising-Flags. Standard-Product-Exporte können diese Werte auslassen oder zu unstrukturierten Notizen abflachen.
Frühe Warnsignale
Die Storefront zeigt Product-Informationen, die in Standard-Product-Tabelle oder -Export fehlen. Reports und Integrationen verweisen auf Felder, die im Migrationsinventar nicht enthalten sind.
| Feldtyp | Wahrscheinlicher Eigentümer | Folge bei Nichtbeachtung |
|---|---|---|
| Zusätzliche Kennung | Integrations- oder Reporting-Contribution | Externe Abstimmung bricht |
| Zusätzlicher Inhalt oder Tab | Product-Inhalts-Contribution | Kundenrelevante Information verschwindet |
| Mengen- oder Versandfeld | Contribution für kommerzielle Regeln | Kauf- oder Fulfillment-Erwartungen verändern sich |
Prävention
Vergleichen Sie repräsentative Product-Seiten, Admin-Formulare, Datenbankzeilen und externe Exporte. Ordnen Sie jeden Contribution-eigenen Wert seiner Geschäftsfunktion zu. Stabile Kennungen und kundenrelevante Informationen werden bewahrt; aktives Verhalten erhält Zielkonfiguration oder -implementierung, statt ein gespeichertes Feld als selbst ausführende Logik zu behandeln.
Beispiel für eine Empfehlung
Ein Verpackungscode und eine Lieferantenreferenz erscheinen in einem individuellen Admin-Panel und versorgen einen Lagerreport. Beide Werte werden zusammen mit dem stabilen Quellschlüssel des Products erhalten, während die alte Reporting-Contribution durch einen zielseitig verantworteten Reporting-Pfad ersetzt wird.
Bestehenskriterium
Repräsentative Products behalten alle weiterhin benötigten kundenbezogenen und betrieblichen Werte, externe Reports können sie abstimmen und kein unbekanntes Contribution-Feld bleibt geschäftskritisch.
Fehler 4: Attribute, Optionspreise und Bestandsbedeutung abflachen
Was schiefgeht
Legacy-osCMax-Installationen können Käuferoptionen über Basisattribute sowie Contribution-spezifische Preis-, Bestands-, Bild- oder Modellergänzungen abbilden. Werden nur Options- und Wertbezeichnungen kopiert, können Auswahlmöglichkeiten korrekt aussehen, aber weder die erfüllte Einheit identifizieren noch Verfügbarkeit steuern.
Frühe Warnsignale
Alle Auswahlmöglichkeiten teilen dieselbe SKU oder denselben Bestand, Preispräfixe verschwinden, ungültige Kombinationen werden auswählbar oder Order Lines zeigen nicht mehr, welche Option gekauft wurde.
| Attributnachweis | Zu bewahrende Bedeutung | Risiko |
|---|---|---|
| Preispräfix oder Override | Kommerzielle Wirkung der Auswahl | Cart Total wird falsch |
| Bestand/Modell auf Optionsebene | Identität der verkaufbaren Einheit | Overselling oder unklarer Fulfillment-Fall |
| Bild- oder Gewichtsbeziehung | Auswirkung auf Darstellung/Fulfillment | Customer sieht oder erhält falschen Artikel |
Prävention
Klassifizieren Sie Attributdaten nach Wirkung und bestimmen Sie die Contribution, die Bestand oder Kennungen auf Optionsebene besitzt. Bewahren Sie gültige Auswahlbeziehungen und betriebliche Schlüssel statt freier Labels. Nutzt das Ziel Varianten oder Kombinationen, wird die verkaufbare Einheit bewusst in diese Struktur abgebildet.
Beispiel für eine Empfehlung
Ein T-Shirt verwendet Größen- und Farbattribute; eine installierte Contribution verwaltet den Bestand je Kombination. Das Parent Product bleibt für Merchandising erhalten, zusätzlich werden jede gültige verkaufbare Kombination und ihre Bestandskennung bewahrt.
Bestehenskriterium
Jede repräsentative Auswahl erzeugt den beabsichtigten Artikel, Preis, Bestand und eine verständliche Order Line; ungültige Kombinationen sind ausgeschlossen und betriebliche Kennungen erhalten.
Fehler 5: Customer Groups ohne ihre eigene Preisbedeutung kopieren
Was schiefgeht
Manche osCMax-Shops verwenden Group-Pricing-Contributions mit eigenen Preisbeziehungen. Werden Customer Groups nur als Bezeichnung migriert, während Product-Preise, Sichtbarkeit, Steuerbehandlung oder Rabattregeln verloren gehen, bleiben klassifizierte Konten zurück, die zu gewöhnlichen Retail-Bedingungen kaufen.
Frühe Warnsignale
Gruppenmitgliedschaft ist vorhanden, gruppenspezifische Product-Preise oder Einschränkungen fehlen jedoch. In der Datenbank existieren mehrere Preisspalten ohne dokumentierten Customer-Group-Eigentümer.
| Beziehung | Warnsignal | Auswirkung |
|---|---|---|
| Customer zu Gruppe | Gruppe wird zu reinem Text | Kontobehandlung wird nicht aktiviert |
| Gruppe zu Product-Preis | Nur Retail-Preis migriert | Großhandels- oder verhandelte Preise verschwinden |
| Gruppe zu Sichtbarkeit/Zugriff | Eingeschränkter Katalog wird öffentlich oder verborgen | Kommerzielle Grenzen scheitern |
Prävention
Bestimmen Sie jede aktive Customer Group und die konkreten Ergebnisse, die sie steuert. Bewahren Sie Mitgliedschaft und verknüpfte Product- oder Regelpreise getrennt. Veraltete Gruppen dürfen erst konsolidiert werden, nachdem bestätigt ist, dass sie keine Preise, Zugriffe oder Reporting-Beziehungen mehr besitzen.
Beispiel für eine Empfehlung
Eine Trade-Customer-Group erhält eine eigene Product-Preisliste. Bewahren Sie Customer-Mitgliedschaft und Product-to-Group-Preise und definieren Sie das Zielsystem, das sie anwendet. Das Wort „Trade“ allein auf dem Customer-Datensatz reicht nicht.
Bestehenskriterium
Repräsentative Group Customers erhalten die vorgesehenen Products und Konditionen, gewöhnliche Customers erben sie nicht und der Zieleigentümer für Preis- oder Zugriffsverhalten ist explizit.
Fehler 6: Article Manager und Informationsinhalte aus dem Umfang lassen
Was schiefgeht
osCMax-Installationen können neben Standard-Katalogdatensätzen Contributions für Artikel, Themen, FAQs, News oder Informationsseiten nutzen. Wird der Shop als reiner Product-Commerce betrachtet, können wertvolle Inhalte, Navigationsbeziehungen, interne Links und SEO-Einstiegsseiten fehlen.
Frühe Warnsignale
Kundenrelevante Seiten existieren im Quellshop, fehlen aber in Product- und Category-Exporten. Admin-Menüs enthalten Artikel- oder Themenverwaltung und Suchtraffic landet auf Nicht-Katalog-Routen.
| Inhaltsbeziehung | Warnsignal | Folge bei Nichtbeachtung |
|---|---|---|
| Artikel zu Thema | Seiten migrieren ohne Hierarchie | Navigation und Kontext verschwinden |
| Inhalt zu Product | Product-Links fehlen | Kaufberatung wird vom Product getrennt |
| Seite zu Route/Metadaten | URL und Metadaten haben kein Ziel | Such-Einstiegspfade gehen verloren |
Prävention
Inventarisieren Sie Inhaltstabellen, Themenhierarchien, Seitenbeziehungen, Sprachen, Medien, Metadaten und interne Links. Entscheiden Sie, welche Inhalte weiterhin relevant sind, und weisen Sie jeder Seite einen Zielinhaltstyp und eine Route zu. Aufgegebene News- oder FAQ-Inhalte sollten ohne fortbestehenden Zweck nicht neu aufgebaut werden.
Beispiel für eine Empfehlung
Ein technischer Ratgeber enthält nach Themen gruppierte Artikel, die von Product-Seiten verlinkt werden. Bewahren Sie nützliche Artikel, Themenbeziehungen und Product-Links; veraltete Inhalte werden mit bewusst gewählten Routenzielen stillgelegt.
Bestehenskriterium
Jede priorisierte Inhaltsseite ist vorhanden, lesbar, über die vorgesehene Navigation oder Product-Beziehung erreichbar und einer kohärenten Zielroute zugeordnet, ohne verwaiste Quelllinks.
Fehler 7: Templates und InfoBoxes mit migrierbaren Inhalten verwechseln
Was schiefgeht
Template-Systeme, InfoBoxes, Modulpositionen und geänderte PHP-Dateien steuern Darstellung getrennt vom zugrunde liegenden Product- oder Inhaltsdatensatz. Das Kopieren von Text und Bildern rekonstruiert das alte Layout nicht; das Kopieren von Template-Code in eine andere Architektur kann dagegen fragile oder unsichere Annahmen konservieren.
Frühe Warnsignale
Das Quelldesign hängt von benannten Template-Verzeichnissen, Box-Dateien, Platzierungseinstellungen oder direkten Codeänderungen ab. Inhaltsverantwortliche erwarten dieselbe Sidebar, denselben Checkout-Block oder dasselbe Kampagnenlayout allein deshalb, weil der Text migriert wurde.
| Quellkomponente | Was sie besitzt | Behandlung im Ziel |
|---|---|---|
| Template-Datei | Darstellung und Code | Neu gestalten oder neu implementieren |
| InfoBox-/Modulposition | Platzierung und Sichtbarkeit | Auf Ziel-Layoutkomponente abbilden |
| Inhaltsdatensatz | Text, Medien und Links | Migrieren, wenn weiterhin nützlich |
Prävention
Trennen Sie Inhalts-Assets von Layoutcode und Modulplatzierung. Wiederverwendbarer Text, Medien und Beziehungen werden bewahrt, die Darstellung wird mit unterstützten Zielkomponenten neu aufgebaut. Jede in Template-Code verborgene Geschäftsregel muss dokumentiert werden, bevor dieser Code stillgelegt wird.
Beispiel für eine Empfehlung
Eine „Latest News“-InfoBox liest Artikeldaten. Migrieren Sie Artikel und Datumswerte und erstellen Sie anschließend eine aktuelle News-Komponente, statt die alte Box-Datei zu verschieben und unveränderte Funktion zu erwarten.
Bestehenskriterium
Priorisierte Seiten enthalten die vorgesehenen Inhalte und Kaufsteuerungen in einem wartbaren Ziellayout; keine erforderliche Funktion hängt von kopiertem Legacy-Template- oder InfoBox-Code ab.
Fehler 8: Order Totals, Status und modul erzeugte Historie abflachen
Was schiefgeht
Order Totals, Zahlungs- und Versandmodule, individuelle Statushistorien, Kommentare und Contribution-Felder können erklären, wie eine osCMax-Order berechnet und bearbeitet wurde. Werden nur Header Total und aktueller Status übernommen, kann die Historie nicht mehr abgestimmt werden.
Frühe Warnsignale
Endsummen sind vorhanden, aber Rabatte, Steuern, Versand, Gebühren, Zahlungsreferenzen, Optionsauswahl oder Statuskommentare fehlen. Individuelle Order-Reports stimmen nicht mehr mit der migrierten Historie überein.
| Order-Nachweis | Verlustmuster | Folge |
|---|---|---|
| Total-Module | Komponenten werden zu einem Betrag zusammengeführt | Finance kann die Summe nicht erklären |
| Statushistorie/Kommentare | Nur finale Bezeichnung bleibt | Support verliert Transaktionschronologie |
| Modulreferenzen | Zahlungs-/Versand-IDs verschwinden | Externe Abstimmung bricht |
Prävention
Bewahren Sie Line Items, gewählte Attribute, Total-Komponenten, Adressen, Daten, Quell-Order-IDs, Statushistorie, Kommentare und aussagekräftige externe Referenzen. Historische Status dürfen für Lesbarkeit übersetzt werden, ohne zu behaupten, dass alte Modulworkflows im Ziel noch aktiv sind.
Beispiel für eine Empfehlung
Eine rabattierte Order enthält Versandversicherung und eine individuelle Zahlungsreferenz. Jede Total-Komponente und Referenz bleibt im historischen Datensatz, während Live-Zahlungs- und Versandverhalten separat konfiguriert werden.
Bestehenskriterium
Mitarbeiter können repräsentative Order Totals und Chronologie erklären, gekaufte Optionen erkennen, Quellreferenzen abstimmen und Ausnahmezustände verstehen, ohne den alten Shop zu öffnen.
Fehler 9: Custom Tables kopieren, ohne den nutzenden Prozess zu übertragen
Was schiefgeht
Jahrelange Contributions und individuelle Änderungen können Custom Tables, Bridge Tables, Flags und Logs hinterlassen. Sie vollständig zu kopieren bewahrt keine Bedeutung, wenn im Ziel kein Prozess sie liest; sie blind auszuschließen kann ERP-, Reporting-, Fulfillment- oder Customer-Service-Workflows brechen.
Frühe Warnsignale
Tabellen haben unklare Namen oder keine Admin-Oberfläche, werden aber von geplanten Exporten oder Reports abgefragt. Entwickler können die Speicherung erklären, aber nicht die Geschäftsentscheidung, die davon abhängt.
| Zustand individueller Daten | Richtige Frage | Unsicheres Ergebnis |
|---|---|---|
| Aktiver betrieblicher Wert | Welcher fortbestehende Prozess nutzt ihn? | Wert fehlt und Workflow bricht |
| Historische Referenz | Wer muss den Wert wie lange lesen können? | Nachweis wird unzugänglich |
| Verwaister Rückstand | Hängt noch ein Prozess davon ab? | Technischer Ballast wird unbegrenzt kopiert |
Prävention
Verfolgen Sie Lese- und Schreibpfade jeder individuellen Struktur. Bewahren Sie Werte nur, wenn ein fortbestehender Prozess, eine historische Verpflichtung oder ein Abstimmungsbedarf existiert. Überführen Sie den Wert in ein zielseitig verantwortetes Feld oder einen Integrationsvertrag; kopieren Sie nicht die ganze Legacy-Tabelle, wenn nur eine stabile Kennung erforderlich ist.
Beispiel für eine Empfehlung
Eine Custom Table ordnet Products einem Lagercode zu. Bewahren Sie Code und Product-Schlüssel im Zielintegrationsmodell, schließen Sie aber alte Processing Flags aus, die kein aktueller Lagerprozess mehr verwendet.
Bestehenskriterium
Jede individuelle Struktur ist als fortbestehend, historisch oder veraltet klassifiziert; fortbestehende Daten haben einen Zielconsumer und ausgeschlossener Rückstand besitzt keine undokumentierte Geschäftsabhängigkeit.
Fehler 10: Historische Contribution-Rückstände als aktuelle Anforderungen behandeln
Was schiefgeht
Legacy-Installationen können deaktivierte Module, aufgegebene Felder, veraltete Konfigurationszeilen und doppelte Contributions enthalten. Alles neu aufzubauen erhöht die Komplexität und kann widersprüchliche Daten oder veraltete Geschäftsregeln in das Ziel importieren.
Frühe Warnsignale
Die Datenbank enthält mehrere Felder für ähnliche Zwecke, Module sind deaktiviert, aber noch befüllt, oder niemand kann erklären, wann ein Wert zuletzt verwendet wurde. Anforderungen werden allein mit dem Vorhandensein einer Tabelle begründet.
| Rückstandssignal | Erforderliche Entscheidung | Ergebnis der Prävention |
|---|---|---|
| Deaktiviertes Modul mit Daten | Historischer Nachweis oder veraltet? | Nur begründete Datensätze behalten |
| Doppelte Contribution-Felder | Welche Quelle ist autoritativ? | Eine Bedeutung auswählen und normalisieren |
| Konfiguration ohne Verantwortlichen | Hängt noch ein Workflow davon ab? | Ausschließen statt neu aufbauen |
Prävention
Nutzen Sie geschäftliche Eigentümerschaft, Nutzungsnachweise, Zeitstempel, Reports und Prozessverfolgung, um aktive Anforderungen von Rückständen zu unterscheiden. Konflikte werden vor dem Mapping gelöst. Datensätze mit historischem Wert, aber ohne aktives Zielverhalten können archiviert werden; veraltete Konfiguration wird ausgeschlossen, wenn sie falsche Erwartungen erzeugen würde.
Beispiel für eine Empfehlung
Zwei Product-Felder enthalten ähnliche Manufacturer-Codes, aber nur eines erscheint in aktuellen Lagerexporten. Das aktive Feld wird bewahrt; das andere nur dann für historische Referenz erhalten, wenn es dafür einen Bedarf gibt. Es werden keine doppelten Zielfelder erzeugt.
Bestehenskriterium
Jeder migrierte nicht standardisierte Wert hat einen aktuellen oder dokumentierten historischen Zweck, doppelte Bedeutungen sind aufgelöst und das Ziel erbt keine deaktivierten Module oder unbeaufsichtigte Konfiguration als aktive Anforderungen.
Übergreifende Präventionsprioritäten
Die wichtigste Kontrolle ist eine Abhängigkeitskarte der Quelle, die Tabellen und Felder mit sichtbarem Storefront-Verhalten, Administration, Reports, Integrationen und historischen Verpflichtungen verbindet. Product-Attribute, Customer-Group-Preise, Artikelinhalte, Templates, Orders und individuelle Strukturen sollten als zusammenhängende Systeme statt isolierte Exporte geprüft werden.
Historische Dokumentation kann wahrscheinliche Abstammung erklären, doch der Live-Shop bestimmt die aktuelle Bedeutung. Nicht unterstützter oder inaktiver Code darf nicht allein deshalb zur Anforderung werden, weil er noch installiert ist. Ebenso darf ein nicht standardisiertes Feld erst ausgeschlossen werden, wenn sein Consumer und Geschäftszweck verstanden sind.
Fazit
Eine zuverlässige osCMax-Migration bewahrt aktive Commerce-Bedeutung, ohne jede Schicht historischer Rückstände nachzubauen. Sie trennt grundlegende osCommerce-Strukturen von gebündelten Contributions und Händleranpassungen, erhält betriebliche Kennungen und verständliche Historie, baut Darstellung und Live-Verhalten unter aktueller Zielverantwortung neu auf und schließt veralteten technischen Ballast bewusst aus.
Häufige Fragen
Warum können zwei osCMax-Shops unterschiedliche Mappings benötigen?
Gebündelte Contributions, spätere Installationen, direkte Codeänderungen und individuelle Datenbankstrukturen können sich unterscheiden. Der Live-Shop und nicht die Plattformbezeichnung definiert das autoritative Schema.
Soll osCMax exakt wie osCommerce gemappt werden?
Nein. osCMax hat osCommerce-Konzepte geerbt, kann aber zusätzliche Felder und Beziehungen enthalten. Wissen über Basis-osCommerce ist nützliche Orientierung, ersetzt aber keine Quellprüfung.
Wie sollten Contribution-eigene Product-Daten behandelt werden?
Verfolgen Sie jeden Wert bis zu seiner geschäftlichen Nutzung. Kundenrelevante Informationen, betriebliche Kennungen und fortbestehende Regeln werden bewahrt; Verhalten erhält einen Zieleigentümer, statt unerklärte Felder zu kopieren.
Warum sind osCMax-Attribute besonders riskant?
Preis-, Bestands-, Modell-, Bild- oder Gewichtsverhalten kann von installierten Contributions statt von Basisattributbezeichnungen besessen werden. Diese Wirkungen müssen mit der richtigen verkaufbaren Auswahl verbunden bleiben.
Sollten alte Templates und InfoBoxes migriert werden?
Bewahren Sie nützliche Inhalte und darin verborgene Geschäftsanforderungen, bauen Sie die Darstellung aber mit unterstützten Zielkomponenten neu auf. Legacy-Template- und Box-Code darf nicht als portabel vorausgesetzt werden.
Wann können osCMax-Daten sicher ausgeschlossen werden?
Wenn kein aktiver Prozess sie verwendet und sie keinen historischen, rechtlichen oder Abstimmungswert besitzen. Die Entscheidung sollte auf Eigentums- und Nutzungsnachweisen beruhen, nicht auf Vermutungen.