Langjährig betriebene Zen-Cart-Stores verbinden häufig gewachsene Katalogdaten mit Attributen, verknüpften Category-Zuordnungen, Templates, Overrides, Plugins und direkten historischen Anpassungen. Diese Ebenen sind nicht austauschbar. Eine Migration kann Products und Customers korrekt übertragen und trotzdem Attributpreise, plugin-eigene Datensätze, Content Routes oder individuelle Abläufe verlieren, auf die Mitarbeitende angewiesen sind. Die folgenden zehn typischen Fehler machen diese wiederkehrenden Muster als konkrete Warnsignale, Kontrollen, Beispiele und Abnahmekriterien sichtbar, wenn Zen Cart als Zielplattform in Betracht gezogen wird.
Fehler 1: Attributwerte wie einfache Variantenbezeichnungen behandeln
Was schiefläuft
Zen-Cart-Attribute können auswählbare Optionen, Text, Dateien, Downloads, reine Anzeigewerte, Preis- oder Gewichtsaufschläge sowie Pflichtauswahlen abbilden. Werden sie bei der Migration auf einfache Name-Wert-Paare reduziert, gehen genau die Regeln verloren, die ein Product korrekt kaufbar machen. Dadurch können sich Preis, Gewicht, Bestandserwartungen oder Personalisierungsabläufe verändern.
Frühe Warnsignale
Besonders riskant sind Products mit gemischten Optionentypen, Pflichtabfragen, attributbasierter Preislogik, Texteingaben, Datei-Uploads oder Download-Attributen.
| Attributverhalten | Fehler bei Vereinfachung | Kontrolle |
|---|---|---|
| Erforderlicher auswählbarer Wert | Ein Standardwert kann unbeabsichtigt gekauft werden | Pflicht- und Standardverhalten erhalten |
| Preis- oder Gewichtsmodifikator | Warenkorbwert oder Versandberechnung ändern sich | Typ und Wert des Modifikators erhalten |
| Text-/Datei-/Download-Eingabe | Personalisierungs- oder Auslieferungskontext geht verloren | Unterstütztes Zielverhalten zuordnen |
Prävention
Erfassen Sie Attribute nach Optionentyp und betrieblicher Wirkung. Trennen Sie beschreibende Werte von Kaufsteuerungen. Pflichtkennzeichen, Sortierreihenfolge, Preis- und Gewichtsmodifikatoren, Standardauswahlen und Download-Beziehungen müssen erhalten bleiben, wenn sie die Transaktion beeinflussen. Falls die Zielplattform echte Varianten anders modelliert, definieren Sie die Beziehung zum verkaufbaren Datensatz, statt nur Bezeichnungen zu kopieren.
Empfehlungsbeispiel
Bei einer personalisierten Plakette sollten Größen-Dropdown, Gravur-Textfeld, einmalige Einrichtungsgebühr und Pflichtauswahl erhalten bleiben. Wandeln Sie nicht alle Werte in gewöhnliche Product-Spezifikationen um.
Abnahmekriterium
Käufer müssen die vorgesehenen Auswahlen treffen, der korrekte Preis und das richtige Gewicht müssen in den Warenkorb gelangen, Personalisierungswerte müssen mit der Order verknüpft bleiben und Download- oder dateibasierte Optionen müssen der vorgesehenen Zugriffsregel folgen.
Fehler 2: Verknüpfte Products als doppelte Products migrieren
Was schiefläuft
Zen Cart kann ein einzelnes Product über verknüpfte Beziehungen in mehreren Categories anzeigen. Wird jede Category-Platzierung als eigenes Product behandelt, entstehen doppelte SKUs, aufgesplitteter Bestand, konkurrierende URLs und unklare Order- oder Integrationenreferenzen. Wird dagegen nur eine Category als maßgeblich betrachtet, können wichtige Auffindbarkeitspfade verloren gehen.
Frühe Warnsignale
Identische Products erscheinen unter mehreren Quell-Category-IDs, teilen sich eine übergeordnete Product-Identität oder greifen auf denselben Bestand zu.
| Signal | Richtige Interpretation | Fehler bei falscher Zuordnung |
|---|---|---|
| Dieselbe Product-ID in mehreren Categories | Ein Product mit mehreren Platzierungen | Doppelte Products und Bestände |
| Eine verknüpfte Category wird entfernt | Ein Auffindbarkeitspfad entfällt, nicht die Product-Identität | Unerwartete Product-Löschung |
| Unterschiedliche URLs führen zum selben Product | Mehrere Routen zu einem Datensatz | SEO-Duplikate, wenn separate Seiten erzeugt werden |
Prävention
Identifizieren Sie das Master-Product und erhalten Sie mehrere Category-Zuordnungen. Es sollte genau eine operative SKU- und Bestandsinstanz geben. Legen Sie eine kanonische Zielroute fest und leiten Sie veraltete Pfade weiter, wenn die Zielplattform nicht jede verknüpfte Route reproduziert. Entfernen Sie echte Dubletten erst, nachdem bestätigt wurde, dass es sich nicht um absichtlich getrennte Datensätze handelt.
Empfehlungsbeispiel
Eine Kamera erscheint unter Elektronik, Kameras und Sale. Migrieren Sie ein Product mit drei Category-Beziehungen und einem Bestand, statt drei Products mit derselben SKU anzulegen.
Abnahmekriterium
Das Product bleibt ein einzelner operativer Datensatz, erscheint an allen vorgesehenen Auffindbarkeitsstellen, besitzt eine eindeutige Bestands- und Identifikatorbeziehung und erzeugt keine konkurrierenden kanonischen Zielseiten.
Fehler 3: Template-Dateien kopieren, ohne Overrides zu verstehen
Was schiefläuft
Mit den Template- und Override-Systemen von Zen Cart können angepasste Dateien Standardverhalten oder Darstellung ersetzen. Wer nur den aktiven Template-Ordner kopiert, übersieht möglicherweise geerbte Standarddateien. Wer dagegen die gesamte Quell-Codebasis übernimmt, kann veraltete Core-Anpassungen und versionsabhängige Annahmen mitschleppen. Migrierte Daten reproduzieren kein Template-Verhalten.
Frühe Warnsignale
Der Store enthält geänderte Core-Dateien, mehrere inaktive Templates, angepasste Sprachdateien oder Overrides, deren geschäftlicher Zweck nicht dokumentiert ist.
| Anpassung | Risiko | Erforderliche Entscheidung |
|---|---|---|
| Template-Override | Kann von alter Standard-Dateistruktur abhängen | Für Zielversion neu aufsetzen oder neu gestalten |
| Core-Dateiänderung | Kann verloren gehen oder Upgrades blockieren | Wenn möglich durch unterstützten Erweiterungspunkt ersetzen |
| Sprach-Override | Kann wichtige Labels oder Richtlinientexte enthalten | Inhalt am korrekten Zielort erhalten |
Prävention
Trennen Sie die Datenmigration von der Implementierung des Ziel-Themes. Inventarisieren Sie aktive Template-Dateien, Overrides, Sprachänderungen, standortspezifische Einstellungen und direkte Core-Anpassungen. Erhalten Sie das geschäftliche Ergebnis, nicht jede historische Datei. Vergleichen Sie notwendige Overrides mit den Standarddateien der Zielversion und verwenden Sie nach Möglichkeit unterstützte Override- oder Plugin-Mechanismen.
Empfehlungsbeispiel
Eine angepasste Product-Seite zeigt über eine alte Core-Änderung ein Lieferantenfeld an. Erhalten Sie den Lieferantenwert als Daten und implementieren Sie seine Darstellung anschließend über einen aktuellen Template- oder Plugin-Mechanismus, statt die alte bearbeitete Core-Datei zu kopieren.
Abnahmekriterium
Priorisierte Storefront-Seiten zeigen unter dem Ziel-Template die vorgesehenen Informationen und Steuerungen, benötigte Sprachinhalte sind vorhanden und die Implementierung hängt nicht von undokumentierten Core-Änderungen einer alten Quellversion ab.
Fehler 4: Annehmen, dass Plugins zusammen mit ihren Datenbanktabellen mitwandern
Was schiefläuft
Zen-Cart-Plugins können Code, Konfiguration, Datenbanktabellen, Observer, Admin-Seiten und Storefront-Verhalten hinzufügen. Das Kopieren von Plugin-Tabellen ohne kompatiblen Code hinterlässt unbrauchbare Daten. Umgekehrt kann die Installation eines Plugins ohne seine aktiven Datensätze den Betriebszustand zurücksetzen. Manche Plugins ändern zudem Core- oder Template-Dateien auf eine Weise, die bei einer reinen Datenbankanalyse nicht sichtbar ist.
Frühe Warnsignale
Benutzerdefinierte Tabellen haben unklare Namen, Mitarbeitende sind auf eine von einem Plugin bereitgestellte Admin-Oberfläche angewiesen oder ein kritischer Prozess wird intern nur über den Marketplace-Namen des Plugins bezeichnet.
| Plugin-Abhängigkeit | Frage | Ergebnis |
|---|---|---|
| Erzeugt persistente Datensätze | Kann das Ziel-Plugin dasselbe Schema lesen? | Aktive Daten zuordnen oder transformieren |
| Verändert Checkout oder Totals | Welche Geschäftsregel muss bestehen bleiben? | Verhalten neu konfigurieren oder ersetzen |
| Fügt Admin-/Berichtsfelder hinzu | Wer nutzt den Wert? | Nur bei fortbestehender Nutzung erhalten |
Prävention
Inventarisieren Sie Plugins nach geschäftlichem Ergebnis, Versionskompatibilität, geänderten Dateien, angelegten Tabellen und aktiven Datensätzen. Erhalten Sie Daten nur, wenn auf der Zielseite ein tatsächlicher Verbraucher existiert. Installieren oder ersetzen Sie Verhalten getrennt von der Übertragung von Datensätzen. Schließen Sie aufgegebene Plugin-Tabellen aus und dokumentieren Sie bewusst stillgelegte Funktionen.
Empfehlungsbeispiel
Ein Plugin ergänzt Orders um ein ERP-Exportkennzeichen. Erhalten Sie dieses Kennzeichen und seine Order-Beziehung, wenn der ERP-Prozess weitergeführt wird. Kopieren Sie jedoch keine nicht mehr benötigten Plugin-Tabellen, wenn eine neue Integration das Plugin ersetzt.
Abnahmekriterium
Jedes geschäftskritische Plugin-Ergebnis hat auf der Zielseite einen klaren Eigentümer, erforderliche Datensätze bleiben für diesen Eigentümer lesbar und Zahlungs-, Versand-, Checkout-, Berichts- oder Integrationenverhalten wird nicht allein deshalb als fortbestehend angenommen, weil eine Tabelle kopiert wurde.
Fehler 5: Zugriffsberechtigungen für Download-Products verlieren
Was schiefläuft
Download-Products können in Zen Cart über Attribute abgebildet sein und von Dateinamen, Order-Kontext und Auslieferungskonfiguration abhängen. Product und Order können korrekt migriert werden, während der Customer trotzdem den Zugriff verliert, eine Datei auf einen abgeschalteten Server verweist oder Nichtkäufer Zugriff erhalten, weil die Berechtigungsbeziehung nicht erhalten wurde.
Frühe Warnsignale
Download-Dateinamen liegen außerhalb gewöhnlicher Product-Felder, historische Orders zeigen das gekaufte Attribut nicht eindeutig oder Dateipfade verweisen auf Verzeichnisse des Quellservers.
| Beziehung | Fehler | Prävention |
|---|---|---|
| Product–Attribut–Datei | Download ist von der gekauften Auswahl getrennt | Asset-Beziehung erhalten oder neu aufbauen |
| Order–Customer-Berechtigung | Käufer kann Zugriffsrecht nicht mehr nachweisen | Historischen Kaufkontext erhalten |
| Dateispeicherpfad | Asset verschwindet nach Abschaltung der Quelle | In sicher verwalteten Zielspeicher verschieben |
Prävention
Identifizieren Sie jedes Download-Product und das Attribut oder die Regel, die den Zugriff gewährt. Verschieben Sie aktive Dateien in einen sicheren Zielspeicher. Erhalten Sie die gekaufte Optionenausprägung und den historischen Order-Nachweis. Konfigurieren Sie Regeln für die aktive Auslieferung ausdrücklich neu, statt sich auf Quell-Dateipfade oder alte Statusannahmen zu verlassen.
Empfehlungsbeispiel
Ein Kurs-Product enthält einen PDF-Download über ein auswählbares Attribut. Erhalten Sie Product, gekauftes Attribut, Customer Order und Dateibeziehung und konfigurieren Sie anschließend die Zugriffsregel des Ziels so, dass die Datei nur unter den vorgesehenen Bedingungen freigegeben wird.
Abnahmekriterium
Berechtigte Customers können auf die richtige Datei zugreifen, unberechtigte Nutzer nicht. Historische Orders erklären die Berechtigung und kein Download hängt vom stillgelegten Quellserver ab.
Fehler 6: Coupons, Gift Certificates und Order Totals zu stark vereinfachen
Was schiefläuft
Zen-Cart-Order-Totals können Coupons, Gift Certificates, Versand, Steuern, Rabatte und weitere Module enthalten. Wird nur der Endbetrag erhalten, fehlen die Bestandteile, die eine Customer-Belastung oder ein verbleibendes Guthaben erklären. Werden historische Certificates ohne klare Eigentümerschaft erneut als aktive Guthaben angelegt, kann außerdem eine doppelte Verbindlichkeit entstehen.
Frühe Warnsignale
Historische Orders weisen unerklärte Differenzen zwischen Zwischensumme und Endbetrag auf oder Gift-Certificate-Codes und Guthaben werden wie gewöhnliche Coupons behandelt.
| Kommerzielles Element | Migrationsrisiko | Kontrolle |
|---|---|---|
| Coupon-Rabatt | Grund des Rabatts geht verloren | Historische Position und Code bei Bedarf erhalten |
| Gift Certificate | Historische Nutzung wird zu neuer aktiver Verbindlichkeit | Eingelöste Historie vom Eröffnungsguthaben trennen |
| Versand-/Steuer-/Order-Total-Modul | Endbetrag ist nicht mehr nachvollziehbar | Finanzielle Komponenten getrennt erkennbar halten |
Prävention
Erhalten Sie historische Finanznachweise getrennt von aktiver Ziel-Promotion-Konfiguration. Entscheiden Sie, ob Gift-Certificate-Guthaben als Eröffnungsverbindlichkeit, eingelöste Historie oder stillgelegter Datensatz behandelt werden. Ordnen Sie Order-Total-Komponenten nach ihrer Bedeutung zu. Erzeugen Sie nicht allein aufgrund historischer Codes neue aktive Codes.
Empfehlungsbeispiel
Bei einer Order, die teilweise mit einem Gift Certificate und teilweise per Karte bezahlt wurde, sollten die Certificate-Anwendung und die übrigen finanziellen Komponenten erhalten bleiben. Migrieren Sie nur das verifizierte noch offene Certificate-Guthaben als aktive Verbindlichkeit.
Abnahmekriterium
Mitarbeitende können historische Totals nachvollziehen, aktive Guthaben entsprechen den bestätigten Verbindlichkeiten, eingelöste oder abgelaufene Instrumente werden nicht wiederverwendbar und Customers erhalten die vorgesehene aktuelle kommerzielle Behandlung.
Fehler 7: Product-Type- und Category-Beschränkungen verlieren
Was schiefläuft
Zen Cart unterstützt unterschiedliche Product Types und kann Categories auf einen Product Type beschränken. Werden alle Products als ein generischer Datensatz behandelt, können Felder oder Storefront-Verhalten verloren gehen, die für Downloads, Dokumente, Musik oder andere typspezifische Strukturen relevant sind. Werden Category-Beschränkungen ignoriert, können Datensätze entstehen, die sich in der Zielverwaltung nicht konsistent pflegen lassen.
Frühe Warnsignale
Quell-Products nutzen typspezifische Felder, Categories enthalten bewusst nur einen Product Type oder der Zielimport setzt bei jedem Datensatz denselben Standardtyp ein.
| Signal | Bedeutung | Risiko |
|---|---|---|
| Typspezifische Felder sind befüllt | Product-Verhalten reicht über allgemeine Katalogdaten hinaus | Wichtige Metadaten oder Kaufverhalten gehen verloren |
| Category akzeptiert nur einen Product Type | Admin-Struktur erzwingt eine Beziehung | Importiertes Product wird ungültig oder schwer pflegbar |
| Ziel besitzt ein anderes Typsystem | Direkte Typübernahme ist nicht möglich | Bedeutung muss in das Zielmodell übertragen werden |
Prävention
Inventarisieren Sie Product Types und bestimmen Sie die geschäftliche Funktion ihrer typspezifischen Felder. Ordnen Sie jedes Product einem gleichwertigen Zieltyp oder einem bewusst neu strukturierten Modell zu. Erhalten Sie Category-Beziehungen, ohne nicht unterstützte Typbeschränkungen zu erzwingen. Stellen Sie veraltete Product Types erst still, nachdem deren aktive Products ein gültiges Zielmodell erhalten haben.
Empfehlungsbeispiel
Ein Download-Product und ein Dokument-Product teilen sich eine Category, nutzen aber unterschiedliche typspezifische Daten. Erhalten Sie ihre kommerzielle Bedeutung über passende Ziel-Product-Modelle, statt beide als gewöhnliche physische Products zu importieren.
Abnahmekriterium
Jedes aktive Product behält die Felder und das Kaufverhalten, die seinem kommerziellen Zweck entsprechen. Category-Zuordnungen bleiben wartbar und kein Product fällt unbemerkt auf einen ungeeigneten generischen Typ zurück.
Fehler 8: Gesamtbestand erhalten, aber Verfügbarkeit auf Attributebene verlieren
Was schiefläuft
Der Bestand eines Basis-Products kann korrekt aussehen, obwohl einzelne Attributkombinationen unterschiedliche Verfügbarkeiten oder plugin-gesteuerte Bestände besitzen. Wer nur die Product-Gesamtmenge kopiert, kann nicht verfügbare Auswahlkombinationen verkaufbar machen oder verfügbare Kombinationen ausblenden. Externe Bestandsfeeds können den importierten Wert anschließend überschreiben, wenn Identifikatoren nicht übereinstimmen.
Frühe Warnsignale
Mitarbeitende verwalten Bestand nach Optionenkombination, verwenden ein Plugin für Variantenbestand oder verlassen sich auf externe SKU-Werte, die nicht am Basis-Product gespeichert sind.
| Bestandsmodell | Fehler bei Vereinfachung | Erforderlicher Eigentümer |
|---|---|---|
| Menge am Basis-Product | Alle Auswahlmöglichkeiten teilen unbeabsichtigt denselben Bestand | Ziel-Product oder Bestandssystem |
| Attribut-/Variantenbestand | Nicht verfügbare Kombination wird kaufbar | Beziehung der verkaufbaren Kombination |
| Externer Bestandsfeed | Importierter Bestand wird sofort ersetzt | Fortbestehende Integration mit stabilem Schlüssel |
Prävention
Bestimmen Sie, ob Bestand dem Basis-Product, einer Attributkombination, einem Plugin-Datensatz oder einem externen System gehört. Erhalten Sie die Identifikatoren, die der maßgebliche Eigentümer verwendet. Definieren Sie, ob die migrierte Menge als Anfangsbestand oder als fortlaufend verwalteter Wert dient. Addieren Sie Bestand nicht aus mehrfach verknüpften Product-Platzierungen.
Empfehlungsbeispiel
Ein T-Shirt besitzt über ein Plugin getrennte Bestände für jede Größen- und Farbkombination. Ordnen Sie jede verkaufbare Kombination dem Ziel-Bestandseigentümer zu und erhalten Sie ihre SKU, statt die Summe dem übergeordneten Product zuzuweisen.
Abnahmekriterium
Jede verkaufbare Auswahl zeigt die richtige Verfügbarkeit, genau ein maßgebliches System steuert fortlaufende Änderungen und die Abstimmung kann Zielbestand zum korrekten Product- oder Kombinationsidentifikator zurückverfolgen.
Fehler 9: EZ-Pages, interne Links und Storefront-Routen beschädigen
Was schiefläuft
Zen-Cart-Inhalte können EZ-Pages, Category-Inhalte, Product-Beschreibungen, Sidebox-Links und template-definierte Navigation umfassen. Wird Text ohne seinen Routen-, Link- oder Platzierungskontext übertragen, entstehen verwaiste Seiten, Links zur alten Domain oder eine Navigation, über die wichtige Richtlinien- und Kampagneninhalte nicht mehr auffindbar sind.
Frühe Warnsignale
Inhalte enthalten absolute Quell-URLs, EZ-Pages werden über numerische IDs referenziert oder die Sidebox-Platzierung wird fälschlich als Bestandteil des Seitendatensatzes behandelt.
| Content-Beziehung | Häufiger Fehler | Prävention |
|---|---|---|
| EZ-Page-Route | Zielseite erhält einen anderen Pfad | Zielroute festlegen und Weiterleitung einrichten |
| Interner Link | Quelldomain bleibt eingebettet | Auf Zieladresse umschreiben |
| Sidebox-/Navigationsplatzierung | Seite existiert, ist aber nicht auffindbar | Navigationsverantwortung im Ziel neu aufbauen |
Prävention
Inventarisieren Sie wichtige Content Routes und interne Links. Trennen Sie Seiteninhalt von Template- oder Sidebox-Platzierung. Ordnen Sie jede historische Route einem Ziel zu und schreiben Sie eingebettete Links sowie Medienreferenzen um. Erhalten Sie Veröffentlichungsstatus und Sprache bewusst.
Empfehlungsbeispiel
Eine EZ-Page mit Rückgaberichtlinie ist über eine Sidebox und mehrere Product-Beschreibungen verlinkt. Erstellen Sie eine zentrale Zielseite für die Richtlinie, leiten Sie die alte Route weiter, aktualisieren Sie eingebettete Links und bauen Sie die Navigationsplatzierung ausdrücklich neu auf.
Abnahmekriterium
Priorisierte Inhalte sind über die vorgesehene Navigation erreichbar, historische Routen führen zum richtigen Ziel und kein kundensichtbarer Link oder keine Medienreferenz verweist zurück auf den stillgelegten Quellshop.
Fehler 10: Legacy-Core-Anpassungen in eine neue Version übernehmen
Was schiefläuft
Langjährig betriebene Zen-Cart-Stores können direkte Core-Änderungen, alte Sprachdatei-Anpassungen, Datenbankänderungen und versionsabhängige Plugins enthalten. Wird die Quellinstallation als Blaupause für die Zielinstallation behandelt, können veralteter Code und nicht mehr gültige Annahmen erneut eingebaut werden und sichere, wartbare Upgrades verhindern. Wird die Migration dagegen ausschließlich als Datenübertragung betrachtet, können geschäftskritische Werte aus diesen Anpassungen verloren gehen.
Frühe Warnsignale
Niemand kann Core-Dateien zuverlässig von geänderten Dateien unterscheiden, die Upgrade-Historie ist unvollständig oder benutzerdefinierte Datenbankspalten haben keinen dokumentierten Verbraucher.
| Legacy-Artefakt | Gefahr | Bevorzugte Behandlung |
|---|---|---|
| Direkte Core-Änderung | Bricht Kompatibilität und Upgrades | Ergebnis über unterstützten Mechanismus neu implementieren |
| Benutzerdefinierte Datenbankspalte | Wert kann betrieblich kritisch sein | Nur mit benanntem Zielverbraucher erhalten |
| Altes Plugin/Konfiguration | Kann inkompatibel oder aufgegeben sein | Bewusst ersetzen, aktualisieren oder stilllegen |
Prävention
Vergleichen Sie die Quellinstallation nach Möglichkeit mit einer sauberen Version. Dokumentieren Sie geänderte Dateien, benutzerdefinierte Spalten, Plugins und deren geschäftliche Ergebnisse. Überführen Sie aktive Daten in zielseitig verantwortete Strukturen und bauen Sie nur Verhalten neu auf, das weiterhin benötigt wird. Kopieren Sie keine alte Codebasis als Abkürzung, um undokumentierte Logik zu bewahren.
Empfehlungsbeispiel
Eine alte Core-Änderung schreibt eine Vertriebsmitarbeiter-ID an Customers. Erhalten Sie diese ID in einem Zielfeld, das von der aktuellen CRM-Integration verwendet wird, und ersetzen Sie die alte Änderung anschließend durch einen wartbaren Erweiterungspunkt.
Abnahmekriterium
Der Ziel-Store bewahrt erforderliche Geschäftsdaten und notwendiges Verhalten, ohne von unerklärten Legacy-Core-Änderungen abzuhängen. Für jede Anpassung ist nachvollziehbar, wo ihre künftige Verantwortung liegt.
Übergreifende Präventionsprioritäten
Die wiederkehrenden Zen-Cart-Risiken lassen sich über drei miteinander verbundene Prüfpfade kontrollieren.
| Präventionspriorität | Was sie schützt | Nachweis vor Freigabe |
|---|---|---|
| Katalogbeziehungen erhalten | Attribute, verknüpfte Products, Product Types, Category-Beschränkungen, Bestand und Downloads | Repräsentative Products behalten vorgesehene Auswahl, Platzierung, Verfügbarkeit und Berechtigungsverhalten. |
| Legacy-Implementierungsebenen klassifizieren | Templates, Overrides, Plugins, Core-Anpassungen und Dateisystemabhängigkeiten | Für jede Abhängigkeit liegt eine Entscheidung zu behalten, ersetzen, neu aufbauen, ausschließen oder separat implementieren vor. |
| Kommerzielle und Routen-Kontinuität sichern | Coupons, Gift Certificates, Order Totals, EZ-Pages, interne Links und Storefront-Routen | Historische Werte bleiben nachvollziehbar und wichtige Customer-Pfade führen zu relevanten Zielen. |
Fazit
Eine erfolgreiche Migration zu Zen Cart erhält die kommerzielle und betriebliche Bedeutung des Stores, ohne unnötigen Legacy-Code in die Zielimplementierung mitzunehmen. Attribute bleiben korrekt kaufbar, verknüpfte Products bleiben ein Datensatz, aktive Plugins und benutzerdefinierte Felder haben klar definierte Eigentümer und Content, Downloads, Orders sowie Bestand bleiben in einer wartbaren Zielarchitektur nutzbar.
Häufige Fragen
Warum sind Zen-Cart-Attribute komplexer als gewöhnliche Varianten?
Sie können auswählbare Optionen, Text, Dateien, Downloads, reine Anzeigewerte sowie Preis- oder Gewichtsmodifikatoren darstellen. Optionentyp und Transaktionswirkung müssen erhalten bleiben.
Sollten verknüpfte Products mehrfach importiert werden?
Nein. Ein verknüpftes Product bleibt normalerweise ein einzelnes Product mit mehreren Category-Beziehungen. Eine Duplizierung würde SKU-, Bestands- und SEO-Verantwortung aufteilen.
Kann das vorhandene Zen-Cart-Template einfach kopiert werden?
Nicht pauschal und nicht ohne Prüfung. Aktive Overrides und Sprachänderungen sollten gegen die Zielversion geprüft werden; erforderliche Ergebnisse müssen über wartbare Zielmechanismen neu aufgebaut werden.
Wie sollten Plugin-Daten behandelt werden?
Erhalten Sie aktive, vom Plugin erzeugte Daten nur dann, wenn eine kompatible oder ersetzende Zielkomponente sie lesen kann. Plugin-Installation und -Konfiguration sind von der Migration der Datensätze getrennte Aufgaben.
Was ist für Download-Products erforderlich?
Product, Attribut- oder Dateibeziehung, sicheres Ziel-Asset, Customer-Order-Kontext und Zugriffsbedingung müssen miteinander verbunden bleiben.
Wie sollten Legacy-Core-Anpassungen behandelt werden?
Dokumentieren Sie das geschäftliche Ergebnis und die von ihnen erzeugten Daten, erhalten Sie aktive Werte in zielseitig verantworteten Strukturen und ersetzen Sie direkte Core-Änderungen nach Möglichkeit durch wartbare Zielmechanismen.