Wenn PrestaShop als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn PrestaShop als Zielplattform ausgewählt werden soll, muss die Vorbereitung sowohl die Commerce-Datensätze als auch den Shop-Kontext dokumentieren, in dem diese Datensätze funktionieren. Produkte können von Kombinationen, Attributen, Merkmalen, Anpassungsfeldern, Lieferanten, Herstellern, Kategorien, Bildern, Bestand, Kundengruppen, Sprachen, Währungen und Multistore-Zuordnungen abhängen. Auch Kunden und Bestellungen können sich je nach Shop, Gruppe, Carrier, Modul, Währung, Steuerlogik oder historischem Status unterschiedlich verhalten.
Jede Vorbereitungsaufgabe sollte einen Verantwortlichen, einen konkreten Nachweis und eine eindeutige Freigabebedingung besitzen. Das Paket muss außerdem Quellnachweise und Zielkonfiguration voneinander trennen: Historische Bestellungen, Produktkombinationen, Kundengruppen, Shop-Zuordnungen, URLs und modulverwaltete Daten gehören zur Migrationsbereitschaft. Aktive Carrier-, Zahlungs-, Steuer-, Theme-, E-Mail- und Checkout-Konfiguration bleibt dagegen Teil der Implementierung im Zielsystem.
Back Office, Hosting, Datenbank, Dateien und Backups absichern
Bestätigen Sie den Zugang zum PrestaShop Back Office, Hosting, zur Datenbank, zum Dateisystem, zu Bildverzeichnissen, herunterladbaren Dateien, Cronjobs, Webservice-Einstellungen, Modulverwaltung und verbundenen Diensten. Dokumentieren Sie PrestaShop-Version, PHP- und Datenbankumgebung, Datenbankpräfix, aktives Theme, Sprachen, Währungen, Shops, Module, Overrides und individuellen Code.
| Vorbereitungsmaßnahme | Verantwortlich | Nachweis | Freigabebedingung |
|---|---|---|---|
| Administrativen Zugriff bestätigen | PrestaShop-Administrator | Funktionierendes Konto und Berechtigungsübersicht | Produkte, Kombinationen, Kunden, Bestellungen, Shops, Module und Konfiguration können geprüft werden. |
| Wiederherstellbare Backups erstellen | Infrastrukturverantwortung | Datenbank-Dump, Dateisystem-/Bildarchiv, Download-Dateiarchiv und benannter Restore-Verantwortlicher | Der Quellshop kann unabhängig von der Live-Umgebung wiederhergestellt werden. |
| Technische Umgebung dokumentieren | Technische Verantwortung | Inventar zu PrestaShop, PHP, Datenbank, Theme, Modulen, Overrides und Deployment | Versionsabhängige Daten und Anpassungen sind dokumentiert. |
| Webservice- und Integrationszugänge erfassen | Integrationsverantwortliche | Webservice-Schlüssel, freigegebene Ressourcen, externe Endpunkte und Kennungszuordnungen | Weiterbestehende Systeme und verfügbare Quellschnittstellen sind bekannt. |
| Quellkennungen erhalten | Datenverantwortung | IDs für Shops, Produkte, Kombinationen, Kunden, Bestellungen, Adressen, Kategorien, Module und externe Systeme | Tabellen- und systemübergreifende Beziehungen können abgeglichen werden. |
Löschen Sie inaktive Module, Overrides oder alte Felder nicht, bevor deren Datenzuständigkeit geprüft wurde. Auch eine inaktive Komponente kann weiterhin historische Produkt-, Kunden- oder Bestelldaten besitzen.
Multistore-, Shop-Gruppen-, Sprach- und Währungsumfang definieren
PrestaShop Multistore kann Daten und Einstellungen global, auf Shop-Gruppen-Ebene oder für einen einzelnen Shop verwalten. Je nach Gruppenkonfiguration können Shops Kunden oder Bestellungen gemeinsam nutzen. Produkte, Kategorien, Preise, Sprachen, Carrier, Module und URLs können dagegen kontextabhängig variieren.
| Umfangsbereich | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|
| Shop-Baum | Shop-Gruppen-IDs, Shop-IDs, Namen, Status, Standardshop, Domains und physische URI | Jeder Storefront-Kontext ist genau einmal dokumentiert. |
| Einstellungen für gemeinsam genutzte Daten | Customer Sharing, Order Sharing, Quantity Sharing und Regeln auf Gruppenebene | Gemeinsame Identitäten sind von duplizierten Datensätzen getrennt. |
| Produkt-/Shop-Zuordnungen | Produkt- und Kategorieverfügbarkeit, shopspezifischer Status, Preis, Text und Bilder | Produktpräsenz wird nicht allein aus dem Standardshop abgeleitet. |
| Sprache und Währung | Shop-Zuordnungen, Übersetzungen, Standardsprache, Währung, Wechselkurskontext und Fallbacks | Lokalisierte Datensätze bleiben dem vorgesehenen Shop zugeordnet. |
| URL-Kontext | Domain, Subdomain oder Pfad, SSL-Domain, physische URI, virtuelle URI und Haupt-URL | Jeder öffentliche Shop besitzt eine vollständige Routenidentität. |
Dokumentieren Sie, welche Shops getrennt bleiben, welche konsolidiert werden und welche historischen Shop-Kennungen auf Kunden oder Bestellungen erhalten bleiben müssen. Diese Entscheidung sollte vor der Normalisierung doppelter Produkte oder Kunden feststehen.
Produkte, Kombinationen, Attribute und Merkmale vorbereiten
PrestaShop trennt Produkte von Kombinationen. Attribute und Attributwerte erzeugen Kombinationen, während Merkmale Eigenschaften beschreiben, die keine Variante erzeugen. Kombinationsdatensätze können Referenzen, Lieferantenreferenzen, Barcodes, Preis- und Gewichtsänderungen, Mengen, Mindestmengen, Verfügbarkeitsdaten, Bilder und den Status der Standardkombination besitzen.
| Katalogmuster | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|
| Einfaches Produkt | Produkt-ID, Referenz, Typ, Preis, Steuergruppe, Bestand, Kategorie, Hersteller, Lieferant, Bilder und Shop-Zuordnungen | Das Produkt kann ohne versteckte Kombinationsdaten interpretiert werden. |
| Produkt mit Kombinationen | Produkt-ID, Kombinations-IDs, Attributwerte, Referenzen, Preise, Gewichte, Bestand, Bilder und Standardkombination | Jede verkaufbare Kombination ist unabhängig nachvollziehbar. |
| Produktmerkmal | Merkmal, Wert, Sprache, Produktzuordnung sowie Nutzung für Filterung oder Vergleich | Beschreibende Informationen sind von kaufbaren Auswahlmöglichkeiten getrennt. |
| Pack oder virtuelles Produkt | Komponenten-/Dateibeziehungen, Mengen, Zugriffsregeln und Bestellbeispiele | Nicht einfache Produktlogik ist vollständig belegt. |
| Lieferanten-/Herstellerbeziehung | IDs, Referenzen, Produktverknüpfungen, Einkaufskontext und externe Schlüssel | Marken- und Beschaffungszuständigkeit bleiben getrennt. |
| Multistore-Produkt | Shop-Zuordnungen, shopspezifische Werte, Kategorien, Preise und Status | Shop-Kontext bleibt erhalten und wird nicht vereinheitlicht. |
Nehmen Sie auch inaktive, nur online verfügbare, nicht verfügbare, eingestellte, ausverkaufte, vorbestellbare sowie durch Mindestmenge oder Datum begrenzte Fälle auf. Diese Zustände brauchen eine ausdrückliche Zielentscheidung und sollten nicht automatisch normalisiert werden.
Anpassungen, spezifische Preise, Bestand und Kundengruppen vorbereiten
Anpassungsfelder können Text- oder Dateieingaben erfassen und zunächst einem Produkt sowie später einer Bestellposition zugeordnet bleiben. Spezifische Preise können von Produkt, Kombination, Shop, Währung, Land, Kundengruppe, Kunde, Menge und Zeitraum abhängen. Bestand kann einem Produkt oder einer Kombination gehören und gegebenenfalls zwischen Shops geteilt werden.
| Kaufmännische Struktur | Nachweis | Freigabebedingung |
|---|---|---|
| Anpassungsfeld | Feld-ID, Produkt, Typ, Pflichtstatus, Bezeichnung, Speicherort hochgeladener Datei und Beispiel-Bestellposition | Vom Käufer eingegebene Daten bleiben von wiederverwendbaren Produktattributen getrennt. |
| Spezifischer Preis | Produkt/Kombination, Shop, Währung, Land, Gruppe, Kunde, Menge, Datum, Reduktionstyp und Priorität | Jeder bedingte Preis besitzt vollständigen Kontext. |
| Kundengruppe | Gruppen-ID, Mitglieder, Nutzung als Standardgruppe, Preisdarstellung, Reduktion, Kategoriezugriff und Shop-Zuordnung | Die Bedeutung der Gruppe ist über ihren Namen hinaus dokumentiert. |
| Bestand | Produkt-/Kombinations-ID, Shop- oder geteilter Mengenkontext, reservierter Zustand sofern verfügbar und externes führendes System | Verkaufbare Einheit und Shop-Kontext jeder Menge sind bekannt. |
| Cart Rule | Code, Bedingungen, Aktionen, Einschränkungen, Zeiträume, Nutzung und historische Bestellreferenzen | Historische Rabattnachweise sind von zukünftiger Promotionskonfiguration getrennt. |
Historische Bestellpreise und Rabatte bleiben Snapshots. Sie sollten nicht aus aktuellen spezifischen Preisen, Gruppen oder Cart Rules neu berechnet werden.
Kategorien, CMS Pages, sprechende URLs und Navigationspfade vorbereiten
PrestaShop-Kategorien können Eltern-Kind-Hierarchie, Shop-Zuordnung, lokalisierte Namen und Beschreibungen, Bilder, Metadaten, sprechende URLs, Gruppenzugriff und Produktmitgliedschaften enthalten. CMS Pages und CMS-Kategorien können rechtliche, Service- oder redaktionelle Inhalte bereitstellen. Navigationsmodule und Theme-Strukturen können zusätzliche Wege für die Produktsuche schaffen.
| Storefront-Bereich | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|
| Kategoriehierarchie | Kategorie-IDs, Eltern, Shop-Zuordnungen, Zugriffsgruppen, Produktmitgliedschaften und Übersetzungen | Taxonomie und Zugriffsbereich sind vollständig. |
| Produkt- und Kategorie-URLs | Sprechende URL, Shop, Sprache, kanonische Absicht, Metadaten und Priorität | Hochwertige Routen besitzen ausdrücklich definierte Zielentscheidungen. |
| CMS-Inhalte | CMS-Page-/Kategorie-IDs, Sprache, Shop-Zuordnung, Status, Route und Menübeziehung | CMS-Inhalte bleiben von der Theme-Darstellung getrennt. |
| Navigation | Menümodul, Links, Hierarchie, Shop-/Sprachkontext und Zielobjekt | Kundenpfade werden nicht allein aus Kategorien abgeleitet. |
| Interne Links und Redirects | Quellseite, verlinktes Objekt, alter Pfad und Zielabsicht | Links können umgeschrieben und prioritäre Pfade erhalten werden. |
Sammeln Sie prioritäre URLs aus Webanalyse, Suchdaten, Backlinks, Kampagnen, Kunden-E-Mails und interner Navigation. Eine Sitemap allein zeigt nicht jede Route, die kaufmännischen Wert besitzt.
Kunden, Adressen, Bestellungen und historische Dokumente vorbereiten
Die Kundenvorbereitung sollte Kontenidentität, Standard- und Zusatzgruppen, Shop-Kontext, Sprache, Adressen, Consent, Unternehmens- oder Steuerinformationen, externe IDs und Authentifizierungsabhängigkeiten umfassen. Für Bestellungen sollten Kunden- oder Gastkontext, Warenkorb, Währung, Shop, Carrier, Zahlungsmodul, Adressen, Produkt- und Kombinationspositionen, Anpassungen, Summen, Status, Rechnungen, Lieferscheine, Nachrichten, Rückerstattungen und externe Referenzen erhalten bleiben.
| Datensatzbereich | Nachweis | Freigabebedingung |
|---|---|---|
| Kundenkonto | Kunden-ID, E-Mail, Shop, Standard-/Zusatzgruppen, Sprache, Status, Adressen, Consent und externe ID | Doppelte und gemeinsam genutzte Konten werden bewusst aufgelöst. |
| Authentifizierung | Passwortverfahren, SSO/Social Login, Reset-Pfad und Verantwortlicher für Kundenkommunikation | Kontozugriff ist geplant, ohne Passwortportabilität vorauszusetzen. |
| Bestellpositionen | Produkt-/Kombinationsreferenzen, Snapshot-Bezeichnungen, Anpassungen, Menge, Preis, Steuer und Rabatt | Gekaufte Artikel bleiben unabhängig vom aktuellen Katalog verständlich. |
| Bestellsummen und Status | Währung, Zwischensumme, Versand, Rabatte, Steuern, Endsumme, aktueller Status und Historie | Historische kaufmännische Bedeutung kann abgeglichen werden. |
| Dokumente und After-Sales-Datensätze | Rechnung, Lieferschein, Gutschrift, Rückgabe, Nachricht, Zahlung, Carrier und Tracking-Referenzen | Nachweise für Kundenservice und Finanzen sind wiederherstellbar. |
| Externe IDs | ERP-, Marketplace-, Buchhaltungs-, Zahlungs- und Auftragsabwicklung-Schlüssel | Systemübergreifende Herkunft bleibt nachvollziehbar. |
Wählen Sie Gast-, registrierte, Multi-Group-, Multistore-, Kombinations-, personalisierte, rabattierte, erstattete, zurückgesendete und teilweise versandte Bestellungen als repräsentative Fälle aus.
Module, Overrides, Themes und benutzerdefinierte Tabellen inventarisieren
Erstellen Sie ein Zuständigkeitsregister für Module, Overrides, Themes, individuelle Controller, benutzerdefinierte Tabellen, direkte Datenbankänderungen, Webservice-Integrationen, Feeds, Marketplaces, Suche, Loyalty, Zahlung, Versand, Abonnements sowie ERP-/PIM-/WMS-/CRM-Verbindungen.
| Abhängigkeit | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|
| Modul | Name, Version, Status, Zweck, Konfigurationsverantwortlicher, Tabellen/Felder, Hooks und betroffene Datensätze | Moduldaten haben ein Ziel oder einen weiterbestehenden Eigentümer. |
| Override oder individueller Code | Klassen-/Controller-Override, geändertes Verhalten, Datenbankauswirkung und verantwortlicher Entwickler | Geschäftslogik ist unabhängig von der alten Implementierung dokumentiert. |
| Theme | Theme-Version, Templates, Modulpositionen, eingebettete Inhalte, individuelle Skripte und Routenabhängigkeiten | Darstellung ist von portierbaren Inhalten und Datensätzen getrennt. |
| Benutzerdefinierte Tabelle oder Spalte | Schema, Schlüssel, referenzierte Kerndatensätze und konsumierender Prozess | Individuelle Datensätze können interpretiert statt blind kopiert werden. |
| Externes System | Endpunkt, führende Entitäten, Synchronisationsrichtung, IDs und Cutover-Verantwortlicher | Konkurrierende führende Systeme werden vermieden. |
| Generierte Daten | Cache, Index, Logs, Sessions, temporäre Exporte und verwaiste Tabellen | Nicht maßgebliche Daten werden bewusst ausgeschlossen. |
Existiert dieselbe Funktion in mehreren Shops, dokumentieren Sie, ob die zugrunde liegenden Moduldaten gemeinsam genutzt, dupliziert oder kontextspezifisch sind.
Repräsentative Migrationstestmuster auswählen
Wählen Sie Quell-Datensätze, die die tatsächliche Komplexität des Shops sichtbar machen. Dokumentieren Sie IDs, Shop-Kontext, Sprache, URLs, Kombinationsreferenzen, Kundengruppen, Modulabhängigkeiten und den Grund für die Auswahl jedes Musters.
| Testmuster | Vorzubereitender Nachweis | Zweck der Vorbereitung |
|---|---|---|
| Einfaches Produkt | Preis, Steuer, Bestand, Kategorie, Hersteller/Lieferant, Bilder, Shop und Bestellung | Definiert die normale Produktbaseline. |
| Kombinationsreiches Produkt | Attribute, Kombinationen, Referenzen, Bestand, Bilder, Preis-/Gewichtsänderungen und Standardkombination | Repräsentiert verkaufbare Variantenstruktur. |
| Produkt mit Merkmalen/Anpassung | Merkmale, Kundeneingabefelder/-dateien und passende Bestellpositionen | Trennt beschreibende Daten von käuferseitigen Eingaben. |
| Multistore-Fall | Produkt, Kategorie, Kunde oder Preis mit All-Shops-, Gruppen- und Shop-Kontext | Repräsentiert gemeinsame und shopspezifische Zuständigkeit. |
| Kundengruppen-Fall | Kunde, Gruppen, spezifischer Preis, Kategoriezugriff und relevante Bestellung | Repräsentiert segmentierten Commerce. |
| Komplexe Bestellung | Kombination, Anpassung, Rabatt, Steuer, Carrier, Zahlung, Rechnung, Rückgabe und externe IDs | Repräsentiert historische Transaktionsnachweise. |
| Modulgesteuerter Datensatz | Kerndatensatz, Modultabellen/-felder, Hooks und externer Schlüssel | Macht nicht zum Kern gehörenden Umfang vor der Ausführung sichtbar. |
Das PrestaShop-Testpaket ist bereit, wenn jeder ausgewählte Datensatz ein Erwartungsblatt für die Quelle, Shop- und Sprachkontext, zugehörige Dateien und einen namentlich benannten Reviewer besitzt.
Abschließendes PrestaShop-Bereitschaftsprüfung durchführen
| Prüfbereich | Freigabebedingung |
|---|---|
| Zugriff und Wiederherstellung | Back Office, Hosting, Datenbank, Dateien, Bilder, Downloads, Zugangsdaten, Backups und Restore-Verantwortung sind bestätigt. |
| Multistore | Shops, Gruppen, Domains, Shared-Data-Einstellungen, Sprachen, Währungen und shopspezifische Werte sind dokumentiert. |
| Katalog | Produkte, Kombinationen, Attribute, Merkmale, Anpassungen, Kategorien, Lieferanten, Hersteller, Bestand, Preise und Kennungen sind nachvollziehbar. |
| Kunden und Bestellungen | Konten, Gruppen, Adressen, Warenkörbe, Bestellungen, Positionen, Summen, Status, Dokumente, Nachrichten, Rückgaben und externe IDs besitzen Nachweise. |
| Inhalte und URLs | CMS-Inhalte, Navigation, sprechende URLs, Metadaten, interne Links und Redirect-Entscheidungen sind dokumentiert. |
| Abhängigkeiten | Module, Overrides, Themes, benutzerdefinierte Tabellen, Webservice-Integrationen und externe Systeme haben benannte Verantwortliche. |
| Testmuster | Repräsentative Datensätze decken jedes wesentliche Produkt-, Shop-, Kunden-, Bestell-, Inhalts- und Modulmuster ab. |
Der PrestaShop-Umfang ist bereit, wenn jeder wesentliche Datensatz auf seinen Shop-Kontext, Quellverantwortlichen, zugehörige Datensätze, Nachweis und das vorgesehene Ziel oder weiterbestehende System zurückgeführt werden kann.
Fazit
Die Vorbereitung einer PrestaShop-Migration erfordert koordinierte Nachweise für Produkte, Kombinationen, Attribute, Merkmale, Anpassungen, Multistore-Geltungsbereiche, Kundengruppen, Kunden, Bestellungen, CMS-Inhalte, sprechende URLs, Module, Overrides und externe Systeme. Die Checkliste sollte diese Beziehungen vor der Ausführung ausdrücklich sichtbar machen, statt sich auf Exporte aus dem Standardshop zu verlassen.
Ein vollständiges Vorbereitungspaket bewahrt wiederherstellbare Quellnachweise, löst gemeinsame und shopspezifische Datensätze bewusst auf, trennt historische Commerce-Daten von aktiver Zielkonfiguration und weist jeder Modul- oder Custom-Abhängigkeit einen klaren Verantwortlichen zu.
Häufige Fragen
Was sollte für eine PrestaShop-Migration zuerst vorbereitet werden?
Bestätigen Sie den Zugang zu Back Office, Hosting, Datenbank, Dateisystem, Bildern und Modulen, erstellen Sie wiederherstellbare Backups und dokumentieren Sie PrestaShop-Version und Multistore-Struktur. Die Katalogvorbereitung sollte erst beginnen, wenn die Quelle zuverlässig geprüft und wiederhergestellt werden kann.
Warum müssen Produkte und Kombinationen getrennt vorbereitet werden?
Ein Produkt enthält gemeinsam genutzte Kataloginformationen, während Kombinationen eigene Referenzen, Barcodes, Preis- und Gewichtsänderungen, Bestand, Bilder, Mindestmengen und Optionswerte besitzen können. Jede tatsächlich verkaufbare Kombination muss unabhängig nachvollziehbar sein.
Wie unterscheiden sich PrestaShop-Merkmale von Attributen?
Attribute erzeugen Produktkombinationen, die Kunden auswählen können. Merkmale beschreiben dagegen Eigenschaften, die über Kombinationen hinweg stabil bleiben. Werden beide vermischt, können falsche Varianten entstehen oder Informationen für Filterung und Vergleich verloren gehen.
Warum ist der Multistore-Kontext unverzichtbar?
Produkte, Kategorien, Kunden, Preise, Sprachen, Module und URLs können für alle Shops gemeinsam, auf Shop-Gruppen-Ebene oder für einen einzelnen Shop gelten. Dieselbe Quell-ID kann deshalb je nach Kontext eine unterschiedliche geschäftliche Bedeutung haben.
Welche PrestaShop-Bestellungen eignen sich als repräsentative Testmuster?
Nehmen Sie Gast- und registrierte Kunden, Kombinationen, Personalisierungstext oder -dateien, kundengruppenabhängige Preise, Rabatte, mehrere Steuern, Rechnungen, Rückgaben, Gutschriften, Zahlungs- und Carrier-Referenzen sowie IDs externer Systeme auf.
Was gehört in das Register für PrestaShop-Module und Overrides?
Erfassen Sie jedes Modul, jeden Override, jede benutzerdefinierte Tabelle, Theme-Abhängigkeit, Webservice-Integration und externe Verbindung, die Geschäftsdaten erzeugt oder nutzt. Jeder Eintrag benötigt einen Verantwortlichen, betroffene Datensätze, Nachweise sowie eine Ziel- oder Retained-System-Entscheidung.