Bei der Bewertung von PrestaShop als mögliche Zielplattform entstehen besonders häufig Probleme, wenn Datensätze zwar vorhanden sind, ihre Shop-, Sprach-, Kombinations-, Modul- oder kaufmännischen Beziehungen im Ziel aber eine andere Bedeutung erhalten haben. Prävention muss deshalb der operativen Beziehung hinter jedem Datensatz folgen, statt sich auf Datensatzanzahlen zu verlassen. Die folgenden zehn Fehlerbilder konzentrieren sich auf wiederkehrende Muster, bei denen ein Katalog vollständig wirken kann, obwohl Kaufprozess, Produktsuche, Service oder Integrationen geschwächt wurden.
Fehler 1: Kombinationen werden auf gewöhnliche Produktfelder reduziert
Was schiefläuft
Ein Quellprodukt kann mit intaktem Basisdatensatz ankommen, während seine verkaufbare Variantenstruktur verloren geht. PrestaShop-Kombinationen tragen die kaufrelevanten Unterschiede zwischen einzelnen Auswahlmöglichkeiten. Merkmale beschreiben Produkte, während Anpassungsfelder Werte erfassen, die Käufer selbst eingeben. Werden diese drei Strukturen gleich behandelt, können doppelte Produkte, fehlende Variantenpreise, falsche Bestandszuständigkeit oder eine Storefront entstehen, die Informationen anzeigt, aber die gewünschte Kaufentscheidung nicht mehr korrekt abbildet.
Frühe Warnsignale
Das Warnsignal ist nicht eine niedrige Produktanzahl. Entscheidend ist die Abweichung zwischen dem, was Kunden auswählen können, und dem, was Mitarbeitende verwalten. Besonders riskant sind Produkte, deren Optionen SKU, Preis, Gewicht, Bild, Verfügbarkeit oder Bestand verändern.
| Signal | Wahrscheinliche Bedeutung | Unmittelbares Risiko |
|---|---|---|
| Jede Option wurde zu einem Merkmal | Beschreibende und verkaufbare Strukturen wurden vermischt | Das Produkt zeigt Auswahlmöglichkeiten, die den tatsächlich gekauften Artikel nicht steuern können. |
| Jede Kombination wurde zu einem separaten Produkt | Eltern-Kombinations-Beziehung wurde aufgelöst | Kategorien, SEO und Merchandising können fragmentieren. |
| Bestand existiert nur auf Ebene des Hauptprodukts | Kombinationsbestand wurde nicht erhalten | Verkaufbare Varianten können überverkauft werden oder fälschlich als nicht verfügbar erscheinen. |
Prävention
Klassifizieren Sie jede Quelloption vor der Zuordnung nach ihrer geschäftlichen Funktion. Eine Auswahl, die die gekaufte SKU verändert, gehört in die Kombinationslogik. Ein Wert für Vergleich oder Produktspezifikation gehört zu den Merkmalen. Vom Käufer eingegebener Text oder Dateien gehören zur Anpassung. Verwenden Sie repräsentative Produkte mit mehreren Optionsdimensionen, Preisänderungen, Bildern und Bestandslogik. Erhalten Sie stabile externe Kennungen, wenn ERP- oder Lagersysteme die Kombination und nicht nur das Hauptprodukt erkennen.
Beispiel
Bei einer Jacke in mehreren Größen und Farben sollte ein Produkt mit Kombinationen für die verkaufbaren Varianten erhalten bleiben. Kombinations-SKU, Preiswirkung, Bildbeziehung und Bestand sollten auf Variantenebene bestehen. „Wasserdichtigkeit“ bleibt dagegen ein Merkmal, während eine optionale Stickerei als Anpassung behandelt wird, statt für jeden Wert eigene Produkte zu erzeugen.
Pass-Bedingung
Ein Käufer kann jede erforderliche Auswahl treffen, die richtige SKU und der richtige Preis landen im Warenkorb, Kombinationsbestand verändert sich dort unabhängig, wo dies vorgesehen ist, und Mitarbeitende können jede verkaufbare Variante auf dieselbe operative Kennung zurückführen, die verbundene Systeme verwenden.
Fehler 2: Datensätze bleiben erhalten, aber ihre Multistore-Zuständigkeit geht verloren
Was schiefläuft
PrestaShop Multistore kann denselben Datensatz je nach Shop oder Shop-Gruppe unterschiedlich sichtbar, bepreist, übersetzt oder konfiguriert darstellen. Eine Migration, die Produkt-, Kategorie-, Kunden- oder CMS-Datensätze erhält, ihren Shop-Kontext aber verliert, kann den falschen Katalog veröffentlichen, regionale Inhalte zusammenführen oder gemeinsam genutzte Datensätze einem Shop zuordnen, in dem sie nie erscheinen sollten.
Frühe Warnsignale
Das Risiko ist besonders hoch, wenn Teams von „dem PrestaShop-Shop“ sprechen, obwohl tatsächlich mehrere Storefronts bestehen. Unterschiede bei Domain, Sprache, Währung, Katalog, Theme, Preisen oder operativer Verantwortung zeigen, dass der Shop-Kontext Teil der Datenbedeutung ist.
| Bereich | Multistore-Frage | Folge bei Missachtung |
|---|---|---|
| Produkte und Kategorien | Global gemeinsam oder selektiv zugeordnet? | Der falsche Shop kann Datensätze veröffentlichen oder verbergen. |
| Preise und Promotions | Gemeinsam oder shopspezifisch? | Regionale kaufmännische Regeln können zusammenfallen. |
| CMS und Übersetzungen | Gemeinsame Inhalte oder pro Shop lokalisiert? | Ein Markt kann Inhalte eines anderen überschreiben. |
Prävention
Erstellen Sie für jede Datensatzfamilie im Umfang eine Matrix zur Shop-Zuständigkeit. Trennen Sie tatsächlich gemeinsam genutzte Daten von Werten, die je Shop, Sprache oder Region variieren. Verwenden Sie eindeutige Shop-Kennungen, statt Zuständigkeit aus Domain oder Sprache abzuleiten. Wenn die Zielplattform Storefronts anders modelliert, definieren Sie für jeden shopspezifischen Wert ausdrücklich die Zielbeziehung, statt nur den gemeinsamen Datensatz zu kopieren.
Beispiel
Ein Händler betreibt einen französischen und einen belgischen Shop mit gemeinsamem Produktkatalog, aber unterschiedlichen Beschreibungen, Steuerdarstellungen und Promotions. Die gemeinsame Produktidentität sollte erhalten bleiben, während lokalisierte Inhalte und kaufmännische Werte den richtigen Ziel-Storefronts zugeordnet werden, statt einen Shop zur universellen Quelle zu machen.
Pass-Bedingung
Jede Ziel-Storefront zeigt nur die vorgesehenen Produkte, Kategorien, Inhalte, Sprachen und kaufmännischen Kontexte. Gemeinsam genutzte Datensätze bleiben dort gemeinsam, wo dies gewollt ist, und kein shopspezifischer Wert wird stillschweigend zum globalen Standard.
Fehler 3: Kundengruppen werden ohne ihre kaufmännische Bedeutung migriert
Was schiefläuft
Kundengruppen können Sichtbarkeit, Preise, Rabatte, Steuerdarstellung oder Zugriffsregeln beeinflussen. Werden nur Gruppennamen kopiert, aber die gesteuerten Beziehungen nicht erhalten, entstehen Kundenkonten, die im Back Office korrekt klassifiziert wirken, in der Storefront aber wie gewöhnliche Endkunden behandelt werden. Dieser Fehler bleibt leicht unentdeckt, wenn Reviewer nur Kundenprofile prüfen und nicht die tatsächlichen Kaufergebnisse pro Gruppe vergleichen.
Frühe Warnsignale
Gruppenbezeichnungen können vorhanden sein, während die zugehörigen kaufmännischen Ergebnisse fehlen. Besonders kritisch ist dies, wenn Quellgruppen B2B-, Großhandels-, Mitarbeiter-, Loyalty-, Steuer- oder Regionslogik kombinieren.
| Warnsignal | Was es nahelegt | Geschäftliche Folge |
|---|---|---|
| Gruppen existieren, aber alle Käufer sehen denselben Preis | Preisbeziehung wurde nicht abgebildet | Großhandels- oder Verhandlungspreise funktionieren nicht wie erwartet. |
| Eingeschränkte Produkte sind für alle sichtbar | Sichtbarkeitszuständigkeit ging verloren | Private Katalogregeln verschwinden. |
| Steuerdarstellung ist für alle Gruppen identisch | Gruppenabhängiger Steuerkontext wurde vereinheitlicht | Angezeigte und berechnete Summen können von Richtlinien abweichen. |
Prävention
Dokumentieren Sie das Ergebnis, das jede Quellgruppe steuert, nicht nur ihren Namen. Migrieren Sie die Kunden-Gruppen-Beziehung getrennt von der Zielkonfiguration, die dieser Gruppe Wirkung verleiht. Fassen Sie doppelte oder veraltete Gruppen bewusst zusammen. Wenn mehrere Quellgruppen in einem einzigen Tag oder Custom Field kodiert sind, klären Sie, ob das Ziel gleichwertige Mitgliedschaften unterstützt oder eine normalisierte Hierarchie benötigt.
Beispiel
Für eine Großhandelsgruppe sollten sowohl Kundenmitgliedschaft als auch die Zielverantwortung für Großhandelspreise, eingeschränkte Produkte und Steuerdarstellung definiert werden. Die Gruppe gilt nicht als erfolgreich migriert, nur weil im Kundendatensatz „Wholesale“ steht.
Pass-Bedingung
Repräsentative Kunden gelangen in den richtigen Kontokontext und erhalten die vorgesehene Produktsichtbarkeit, Preise, Rabatte und Steuerdarstellung ihrer Gruppe. Bewusste Unterschiede zum Quellsystem sind als Zielverhalten dokumentiert.
Fehler 4: Der Kategoriebaum bleibt erhalten, aber die Produktsuche verschlechtert sich
Was schiefläuft
Ein Kategorieimport kann Namen und Elternbeziehungen vollständig wiedergeben und trotzdem die Produktsuche verschlechtern. PrestaShop-Navigation, Facettenfilter, Merkmale, Merchandising und Theme-Verhalten können von mehr als dem Baum selbst abhängen. Leere Kategorien, Produkte in der falschen Standardkategorie oder Merkmale, die nicht mehr vollständig genug für Filterung sind, machen einen scheinbar vollständigen Katalog schwer nutzbar.
Frühe Warnsignale
Kategorieanzahlen sehen meist korrekt aus, selbst wenn die Produktsuche beschädigt ist. Warnsignale zeigen sich in Storefront-Pfaden, Produktplatzierung, Filtern und dem Verhalten der Standardkategorie.
| Prüfung | Fehlermuster | Warum das relevant ist |
|---|---|---|
| Standardkategorie | Produkt besitzt mehrere Zuordnungen, aber den falschen primären Kontext | Breadcrumbs und kanonisches Verhalten können sich verändern. |
| Merkmalsabdeckung | Merkmalswerte existieren nur für einen Teil einer Produktfamilie | Facettierte Navigation wird inkonsistent. |
| Kategorietiefe | Tiefe Zweige wurden zusammengeführt oder dupliziert | Kunden verlieren erwartete Browsing-Pfade. |
Prävention
Definieren Sie gewünschte Discovery-Ergebnisse für repräsentative Produktfamilien. Erhalten Sie alle benötigten Kategoriezuordnungen und bestimmen Sie die Standardkategorie dort ausdrücklich, wo PrestaShop-Verhalten davon abhängt. Normalisieren Sie Merkmalsnamen und -werte, bevor diese für Filterung verwendet werden. Veraltete Kategorien sollten nur zusammen mit einem klaren Redirect- oder Merchandising-Ziel eingestellt werden.
Beispiel
Bei einem Schuhkatalog sollte ein Laufschuh weiterhin unter Herren, Running und Sale erscheinen und zugleich die vorgesehene Standardkategorie behalten. Größen-, Untergrund- und Wasserschutzmerkmale müssen ausreichend vollständig sein, damit das Zielsystem sinnvoll filtern kann.
Pass-Bedingung
Prioritäre Produktfamilien sind über die erwarteten Kategoriepfade erreichbar, Breadcrumbs und Standardkontext sind schlüssig, Filter verwenden vollständige normalisierte Werte und eingestellte Zweige führen Kunden zu einem sinnvollen Ziel.
Fehler 5: Es wird angenommen, dass sprechende URLs die Routenidentität automatisch erhalten
Was schiefläuft
URL-Schlüssel, umgeschriebene Routen, Sprachpräfixe und CMS-Pfade aus dem Quellsystem erzeugen in einer neuen PrestaShop-Umgebung nicht automatisch dieselbe öffentliche Adresse. Ein Datensatz kann vorhanden sein, während seine wertvolle Route geändert wurde, mit einer anderen Route kollidiert oder im falschen Shop bzw. in der falschen Sprache auflöst. Das betrifft Kunden, Kampagnen, interne Links und Suchsichtbarkeit.
Frühe Warnsignale
Besonders deutliche Warnsignale sind doppelte Rewrite-Werte, unerklärte Sprachsuffixe, fehlender Shop-Kontext oder wichtige Seiten, deren Ziel nie ausdrücklich definiert wurde.
| Routentyp | Typische Migrationslücke | Erforderliche Entscheidung |
|---|---|---|
| Produkt- oder Kategorieroute | Alte Rewrite-Logik passt nicht zur Zielstruktur | Kanonisches Ziel wählen und Quellroute weiterleiten. |
| Mehrsprachige Route | Sprachspezifische Slugs werden auf einen Wert reduziert | Lokalisierte Zielrouten getrennt erhalten. |
| CMS- oder Kampagnenroute | Seite existiert unter neuem Pfad | Interne Links aktualisieren und historische Route umleiten. |
Prävention
Erstellen Sie ein Routenregister für prioritäre Produkte, Kategorien, CMS Pages und Kampagnenziele. Erfassen Sie Quell-URL, Sprache, Shop, vorgesehenes Ziel und Redirect-Verantwortlichen. Prüfen Sie Eindeutigkeit innerhalb des Ziel-Routing-Kontexts. Bedeutungsvolle Slugs sollten nach Möglichkeit erhalten werden, doch ein kohärentes kanonisches Ziel ist besser als mehrere konkurrierende Routen.
Beispiel
Eine französische und eine belgische Produkt-URL verwenden denselben übersetzten Namen, gehören aber zu unterschiedlichen Shops. Beide sollten dem korrekten Shop-und-Sprach-Ziel zugeordnet werden und eigene Redirects von den historischen Pfaden erhalten, statt nur die Route mit dem größten Traffic beizubehalten.
Pass-Bedingung
Jede prioritäre historische Route führt direkt oder über genau einen sinnvollen Redirect zum richtigen Produkt-, Kategorie- oder CMS-Ziel im vorgesehenen Shop und in der vorgesehenen Sprache, ohne Schleifen oder Kollisionen.
Fehler 6: Module, Overrides und Theme-Logik werden wie migrierte Daten behandelt
Was schiefläuft
PrestaShop-Module und Overrides können Felder erzeugen, Checkout-Verhalten verändern, Carrier oder Zahlungslogik ergänzen, Produktdarstellung beeinflussen oder Integrationskennungen speichern. Themes können bestimmen, wie Katalogstrukturen ausgegeben werden. Das Kopieren gewöhnlicher Datensätze stellt dieses Verhalten nicht wieder her. Umgekehrt kann das Kopieren von Modultabellen ohne Kenntnis des konsumierenden Moduls zu unbrauchbaren oder riskanten Daten führen.
Frühe Warnsignale
Das Risiko wird sichtbar, wenn geschäftskritische Ergebnisse nur mit Modulnamen beschrieben werden, benutzerdefinierte Tabellen keinen Eigentümer haben oder das Ziel-Theme andere Felder und Hooks erwartet.
| Abhängigkeit | Zu beantwortende Frage | Wahrscheinlicher Verantwortlicher |
|---|---|---|
| Modulgeneriertes Feld | Welcher aktuelle Prozess liest diesen Wert? | Weiterbestehendes Modul, Integration oder neu strukturierter Zielwert. |
| Override oder individueller Code | Welches Standardverhalten wird dadurch verändert? | Zielimplementierung statt Datensatzmigration. |
| Themespezifischer Inhalt | Handelt es sich um Daten oder Darstellungskonfiguration? | Ziel-Theme-/Content-Setup. |
Prävention
Inventarisieren Sie Module, Overrides, benutzerdefinierte Tabellen, Hooks und Theme-Abhängigkeiten nach ihrem geschäftlichen Ergebnis. Erhalten Sie einen Wert nur, wenn im Ziel ein tatsächlicher Verbraucher existiert. Trennen Sie Datensatzmigration vom Installieren, Konfigurieren, Ersetzen oder Neuaufbauen von Verhalten. Übernehmen Sie keine inaktiven Moduldaten nur deshalb, weil sie in der Datenbank existieren.
Beispiel
Speichert ein Modul eine Lieferantenreferenz, die von einem ERP-Export verwendet wird, sollte diese Referenz in einem Zielfeld oder Integrationsdatensatz erhalten werden, den der weiterbestehende ERP-Prozess lesen kann. Die Modultabelle selbst sollte nicht kopiert werden, wenn das Modul im Ziel nicht weiterverwendet wird.
Pass-Bedingung
Jedes geschäftskritische Modul oder jeder Override besitzt einen definierten Zielverantwortlichen, benötigte Daten bleiben für diesen Verbraucher lesbar und kein Storefront- oder Betriebsprozess wird allein deshalb als fortbestehend betrachtet, weil Standarddatensätze migriert wurden.
Fehler 7: Bestandszuständigkeit über Kombinationen und Standorte hinweg wird vereinheitlicht
Was schiefläuft
Bestand kann auf Produktebene korrekt erscheinen, während verkaufbare Kombinationen falsche Mengen oder Verfügbarkeiten besitzen. Externe Bestandssysteme, historische Advanced-Stock-Strukturen, Warehouse-Feeds oder shopspezifischer Bestand können zusätzliche Eigentumsebenen schaffen. Werden diese Werte vereinheitlicht, entstehen Überverkäufe, falsche Out-of-Stock-Zustände oder Zielmengen, die unmittelbar von einem verbundenen System überschrieben werden.
Frühe Warnsignale
Eine einzige Menge pro Produkt, fehlende Kombinationskennungen, unerklärte negative Bestände oder Abweichungen zwischen Store und externem System deuten eher auf ein Zuständigkeitsproblem als auf einen einfachen Importfehler hin.
| Bestandssignal | Wahrscheinliche Ursache | Präventionsfokus |
|---|---|---|
| Elternmenge entspricht der Summe aller Varianten | Variantenzuständigkeit wurde ignoriert | Kombinationsbestand oder externen Bestandsschlüssel erhalten. |
| Zielmenge ändert sich nach Synchronisation | Externes System bleibt führend | Eröffnungsbestand und Verantwortlichkeit nach der Migration definieren. |
| Ein Shop zeigt Bestand eines anderen Shops | Shop-Kontext wurde vereinheitlicht | Shop-/Standortbeziehung erhalten. |
Prävention
Definieren Sie das führende Bestandssystem für jede Produktfamilie und jeden Standort. Erhalten Sie Kombinations-SKUs und externe Kennungen. Legen Sie fest, ob die Migration einen Eröffnungsbestand, einen historischen Referenzwert oder einen dauerhaft weitergeführten Bestandswert liefert. Veraltete Bestandstabellen, die Verfügbarkeit nicht mehr steuern, sollten ausgeschlossen werden.
Beispiel
Bei einem Produkt mit größenabhängigen Kombinationen, dessen Bestand von einem Lagersystem geführt wird, sollte der Eröffnungsbestand pro Kombination migriert und die Warehouse-SKU erhalten werden. Nach dem Cutover sollte die Warehouse-Verbindung wieder führend werden, statt die Summe auf Produktebene dauerhaft als Bestand zu verwenden.
Pass-Bedingung
Die richtige verkaufbare Kombination ist im richtigen Shop oder Standort verfügbar, Bestandsänderungen erfolgen unter dem vorgesehenen Systemverantwortlichen und jeder Zielbestand kann über eine stabile Produkt- oder Kombinationskennung abgeglichen werden.
Fehler 8: Historische Bestellungen werden ohne ihren erklärenden Kontext erhalten
Was schiefläuft
Bestellsumme und Status reichen nicht aus, um zu erklären, was tatsächlich passiert ist. Historische Bestellungen können von Produktkombinationen, Kundengruppen, Steuern, Carriern, Rabatten, Rückerstattungen, Nachrichten und Statushistorien abhängen. Werden diese Beziehungen reduziert, sieht das Team zwar die Transaktion, kann aber den Betrag, die gekaufte Variante oder den Auftragsabwicklung- bzw. Rückerstattungsvorgang nicht mehr zuverlässig erklären.
Frühe Warnsignale
Bestellungen wirken in Listen vollständig, werden beim Öffnen aber mehrdeutig. Fehlende Optionsdetails auf Positionsebene, generische Status, fehlender Rabattkontext oder getrennte Kundendatensätze sind typische Hinweise.
| Bestellkontext | Folge, wenn er fehlt | Serviceauswirkung |
|---|---|---|
| Kombinations- oder Anpassungsdetail | Gekaufter Artikel lässt sich nicht eindeutig identifizieren | Rückgaben und Supportentscheidungen werden unsicher. |
| Statushistorie und Nachrichten | Operativer Ablauf geht verloren | Mitarbeitende können Auftragsabwicklung oder Stornierung nicht nachvollziehen. |
| Rabatt-, Steuer- und Versandpositionen | Gesamtsumme ist nicht abstimmbar | Finanzen und Kundenservice verlieren Vertrauen in die Historie. |
Prävention
Erhalten Sie Produktidentität und beschreibenden Kaufkontext auf Positionsebene, auch wenn das Ziel nicht jeden historischen Ablaufstatus exakt nachbilden kann. Ordnen Sie Status nach Bedeutung und nicht nur nach ähnlicher Bezeichnung zu. Halten Sie finanzielle Positionen unterscheidbar. Quell-Bestellnummern und externe Referenzen sollten erhalten bleiben, wenn andere Systeme sie für die Suche verwenden.
Beispiel
Bei einer erstatteten Bestellung mit Größen-/Farbkombination und Gutschein sollten gekaufte Kombinationsbeschreibung, ursprüngliche Beträge, Rabattposition, Rückerstattungskontext, Kundenbeziehung und Quellreferenz erhalten bleiben, statt alles als generische abgeschlossene Bestellung darzustellen.
Pass-Bedingung
Mitarbeitende können erkennen, was der Kunde gekauft hat, wie sich die Summe zusammensetzt, welche Statusfolge durchlaufen wurde und welcher Rückerstattungs- oder Auftragsabwicklung-Kontext relevant ist, ohne für gewöhnliche Supportfragen auf den stillgelegten Quellshop zurückgreifen zu müssen.
Fehler 9: Inkonsistente Lokalisierung wird in einen gemeinsamen Katalog übernommen
Was schiefläuft
Mehrsprachige Inhalte enthalten häufig unvollständige Übersetzungen, doppelte Slugs, Fallback-Texte, HTML-Abweichungen und modulgenerierte Felder mit uneinheitlicher Lokalisierung. Werden alle Werte unverändert übernommen, kann Quellsprache im falschen Shop erscheinen oder es können leere Storefront-Bereiche entstehen, obwohl das Ziel einen lokalisierungsspezifischen Wert erwartet.
Frühe Warnsignale
Produkte besitzen beispielsweise einen übersetzten Namen, aber keine übersetzte Beschreibung; Kategorie-Slugs kollidieren zwischen Sprachen; oder ein Shop verwendet kopierte Inhalte, die eigentlich getrennt bleiben sollten.
| Lokalisierungsproblem | Sichtbares Ergebnis | Kontrolle |
|---|---|---|
| Fehlender lokalisierter Wert | Leerer oder automatisch ersetzter Storefront-Inhalt | Genehmigte Fallback- oder Vervollständigungsregel definieren. |
| Gleicher Slug in widersprüchlichen Kontexten | Routenkollision oder falsches Ziel | Locale-/Shop-bewusste Routen vergeben. |
| Eingebettete Links zur Quelldomain | Kunden gelangen zurück zum alten Shop | Links auf Zieladressen umschreiben. |
Prävention
Prüfen Sie die Übersetzungsvollständigkeit nach wichtigen Datensatzfamilien und Locales. Normalisieren Sie Encoding und HTML. Legen Sie fest, wo Fallback zulässig ist und wo fehlende Inhalte bis zur Vervollständigung unveröffentlicht bleiben müssen. Behandeln Sie Links, Medienreferenzen und SEO-Felder als lokalisierte Beziehungen und nicht als gewöhnlichen Text.
Beispiel
Ein Produkt besitzt vollständige französische Inhalte, aber nur einen englischen Namen. Die französische Version sollte regulär veröffentlicht werden. Für Englisch gilt die genehmigte Fallback-Regel. Eine unvollständige englische Beschreibung darf dabei nicht versehentlich einen Link zur französischen Quelldomain übernehmen.
Pass-Bedingung
Jede veröffentlichte Locale zeigt die vorgesehene Sprache, Routen und Medien lösen im richtigen Shop-Kontext auf und fehlende Übersetzungen folgen einer bewussten Fallback- oder Veröffentlichungsregel statt zufälliger Vererbung.
Fehler 10: Externe Kennungen werden erhalten, ihre Verbraucher jedoch nicht
Was schiefläuft
Quelldatenbanken enthalten häufig ERP-IDs, Lieferantenschlüssel, Marketplace-IDs, alte Produktreferenzen und modulspezifische Lookup-Werte. Werden diese Zeichenfolgen in einem beliebigen Notizfeld gespeichert, bleibt zwar der Text erhalten, nicht aber seine Funktion. Werden sie weggelassen, kann der Abgleich scheitern. Werden sie dupliziert, können verbundene Systeme den falschen Datensatz aktualisieren.
Frühe Warnsignale
Teams können Kennungen aufzählen, aber nicht sagen, welches System sie verwendet, ob sie eindeutig sein müssen oder wie sie nach der Migration abgefragt werden.
| Kennung | Verbraucherfrage | Zielanforderung |
|---|---|---|
| ERP-Produkt- oder Kombinations-ID | Welcher Synchronisationsprozess nutzt sie? | Stabiles eindeutiges Feld, das der Integration zur Verfügung steht. |
| Marketplace-Listing-ID | Bleibt das Listing aktiv? | Weiterbestehende Channel-Beziehung oder bewusste Stilllegung. |
| Historische Bestellreferenz | Wer sucht danach? | Sichtbare und durchsuchbare historische Referenz. |
Prävention
Erstellen Sie einen Kennungsvertrag mit Quellfeld, Datensatzeigentümer, Zielort, Eindeutigkeitsregel, Format und konsumierendem System. Erhalten Sie nur aktive oder als Nachweis benötigte Kennungen. Produkt- und Kombinationsschlüssel müssen getrennt bleiben. Testen Sie Such- und Aktualisierungsverhalten über die weiterbestehende Integration oder den operativen Ablauf.
Beispiel
Wenn ein ERP Bestand anhand einer Kombinationsreferenz aktualisiert, muss diese Referenz an der verkaufbaren Zielkombination oder im Integrationsdatensatz liegen. Sie darf nicht nur am Hauptprodukt oder in einem Admin-Notizfeld gespeichert werden, das der Synchronisationsprozess nicht abfragen kann.
Pass-Bedingung
Jede erforderliche externe Kennung ist dort eindeutig, wo Eindeutigkeit erwartet wird, kann vom weiterbestehenden Verbraucher abgefragt werden, ist der richtigen Datensatzebene zugeordnet und unterstützt nachweislich Abgleich oder Integrationsverhalten.
Übergreifende Präventionsprioritäten
Die wiederkehrenden PrestaShop-Risiken lassen sich über drei miteinander verbundene Prüfpfade kontrollieren.
| Präventionspriorität | Was sie schützt | Evidenz vor der Freigabe |
|---|---|---|
| Bedeutung von Kombinationen und Bestand erhalten | Kombinationen, Attribute, Standorte und verkaufbaren Bestand | Repräsentative Produkte behalten die richtigen Auswahlmöglichkeiten, Kennungen, Bestandszuständigkeiten und Verfügbarkeiten. |
| Multistore- und kaufmännischen Kontext erhalten | Shop-Zuständigkeit, Kundengruppen, Lokalisierung, Kategorien und Preise | Datensätze erscheinen im richtigen Shop, in der richtigen Sprache, Währung, Gruppe und im richtigen Browse-Kontext. |
| Module und Integrationen von migrierten Datensätzen trennen | Overrides, Themes, externe Kennungen und operative Verbraucher | Jede nicht zum Kern gehörende Abhängigkeit besitzt einen Zielverantwortlichen, eine Implementierungsentscheidung und eine Validierungsmethode. |
Fazit
Ein zuverlässiges PrestaShop-Ergebnis entsteht aus ausdrücklich definierten Beziehungen: Produkte zu Kombinationen, Kategorien zur Produktsuche, Kunden zu Gruppen, Datensätze zu Shops und Sprachen sowie benutzerdefinierte Werte zu weiterbestehenden Modulen oder Integrationen. Werden diese Beziehungen anhand repräsentativer Geschäftsszenarien definiert und geprüft, kann die Migration nicht nur den Datenbankinhalt, sondern die operative Funktionsweise des Shops erhalten.
Häufige Fragen
Warum sind PrestaShop-Kombinationen ein wesentliches Migrationsrisiko?
Kombinationen können SKU-, Preis-, Bild-, Gewichts- und Bestandsunterschiede besitzen. Werden sie auf Merkmale oder separate Produkte reduziert, verändert sich die verkaufbare Struktur und damit möglicherweise Warenkorb- und Bestandsverhalten.
Benötigt Multistore separate Kopien jedes Datensatzes?
Nicht unbedingt. Manche Daten können gemeinsam genutzt werden, während andere Werte shopspezifisch sind. Die Migration sollte die beabsichtigte Zuständigkeit erhalten, statt alles zu duplizieren oder einen Shop als universell zu behandeln.
Sollte jede Modultabelle migriert werden?
Nein. Ein Moduldatensatz sollte nur erhalten werden, wenn eine weiterbestehende Zielkomponente oder ein operativer Prozess ihn tatsächlich benötigt. Inaktive oder verwaiste Moduldaten sollten nicht allein der Vollständigkeit halber kopiert werden.
Wie sollten Kundengruppen bewertet werden?
Bewerten Sie das kaufmännische Ergebnis jeder Gruppe, etwa Preise, Sichtbarkeit, Steuerdarstellung oder Zugriff, und nicht nur, ob die Gruppenbezeichnung vorhanden ist.
Wie lassen sich PrestaShop-URLs am sichersten erhalten?
Verwenden Sie ein Routenregister, das für prioritäre Produkte, Kategorien, CMS Pages und Kampagnen Quellpfad, Shop, Sprache, Zieladresse und Redirect-Verantwortung dokumentiert.
Was beweist, dass externe Kennungen korrekt erhalten wurden?
Das weiterbestehende ERP-, Lager-, Marketplace- oder Supportsystem kann über die erhaltene Kennung den vorgesehenen Zieldatensatz auf der richtigen Produkt-, Kombinations-, Kunden- oder Bestellebene finden und aktualisieren.