Von PrestaShop zu einem eigenen Shop wechseln

Was PrestaShop ist, und wer es hinter sich lässt

PrestaShop ist eine quelloffene Shopsoftware, geschrieben in PHP. Du lädst sie herunter, spielst sie auf deinem eigenen Server ein, und sie arbeitet auf einer MySQL oder MariaDB Datenbank, die dir gehört.¹ Der Kern liegt unter der Lizenz OSL 3.0, die mitgelieferten Module und das Classic Theme unter AFL 3.0, deshalb kann niemand deinen Shop abschalten oder sich einen Teil deines Umsatzes nehmen.² In Europa ist PrestaShop seit Jahren stark vertreten, vor allem in Frankreich, Spanien, Italien und auch bei uns in Deutschland, und für einen schlanken Shop mit gewöhnlichem Katalog ist es eine solide, leistungsfähige Plattform. Trifft das auf dich zu, will dieser Artikel dir das Weggehen nicht einreden.

Der Shop, der aus PrestaShop herauswächst, verlässt es selten, weil die Software nicht verkaufen könnte. Er verlässt es wegen des Gewichts, das sich über die Jahre angesammelt hat. Ein realer PrestaShop Shop fährt fast immer einen Turm aus Modulen, einige davon kostenpflichtig, und jedes muss mit den übrigen und mit dem Kern kompatibel bleiben. Die großen Versionswechsel waren jedes Mal hart: Der Übergang von 1.6 auf 1.7 hat die Theme Architektur neu aufgesetzt und das Back Office schrittweise auf Symfony gehoben, und ein Theme aus 1.6 lief unter 1.7 nicht mehr.³ Der Übergang von PrestaShop 8 auf PrestaShop 9, erschienen am 10. Juni 2025, hob das Framework von Symfony 4.4 auf Symfony 6.4, ließ ältere PHP Versionen fallen, entfernte die alte Produktseite und änderte, wie Produkt URLs gebaut werden, und das Projekt selbst warnt, dass Module und Themes dafür angepasst werden müssen.⁴ Das ist kein Skandal. Es ist der ehrliche Preis dafür, eine ausgereifte PHP Anwendung zu besitzen, die eine ganze Kette aus Dritten mitpflegen muss.

Wer wechselt, hat also nichts gegen den Onlinehandel. Er hat die Pflege satt: die Modullizenzen, die alle zueinander passen müssen, das Upgrade Projekt, das alle paar Jahre fällig wird, die laufende Sorge um Hosting und Sicherheit, und den kleiner werdenden Kreis an Entwicklern, die eine alternde Installation überhaupt noch anfassen wollen. Was gesucht wird, ist stattdessen eine einzige, getestete Anwendung unter eigener Kontrolle, und genau dafür steht ein maßgeschneiderter Solidus Shop.

Dieser Artikel zeigt die ehrliche Gestalt dieses Umzugs. Die tiefen, plattformunabhängigen Einzelheiten habe ich in einer Reihe von Begleittexten behandelt, angefangen bei was sich überträgt und was nicht, und ich verweise darauf, statt sie noch einmal auszubreiten. Hier bleibe ich dicht an PrestaShop: was es sauber herausrückt, was es einbehält, wie Export und API tatsächlich arbeiten, und die Fallen, die gerade für PrestaShop kennzeichnend sind.

Was dir gehört, und was zurückbleibt

Die größte Stärke von PrestaShop als Plattform, die man verlässt, deckt sich mit der von WooCommerce: Weil du selbst hostest, liegen die Daten bereits bei dir. Die Datenbank gehört dir, die Dateien gehören dir, und nichts verbirgt sich hinter einem Exportwerkzeug des Anbieters, das sich drosseln oder abschalten ließe. Der reine Zugriff auf deine Datensätze ist damit ausgezeichnet. Das Problem ist nie, die Daten herauszuholen. Es ist, dass ein Teil davon in Modulen, Overrides und Formaten festsitzt, die nicht mitreisen, und dass einige wenige Dinge aus Gründen, an denen keine Plattform etwas ändert, überhaupt nicht umziehen.

So sieht die ehrliche Aufteilung für einen typischen PrestaShop Shop aus.

Das Muster ist dasselbe, dem jede ehrliche Migration folgt. Die Hauptwörter wandern gut. Die Tätigkeitswörter, also das Verhalten, das in Modulen und im Theme steckte, werden neu gebaut. Wem jeder dieser Datensätze rechtlich gehört, und warum das bei der Übergabe entscheidend wird, steht in wem gehören eigentlich deine Geschäftsdaten.

Der Export und die API, im Detail

PrestaShop bietet dir drei ehrliche Wege, Daten herauszuholen, und eine echte Migration setzt alle drei ein.

Die CSV Import und Exportwerkzeuge. Unter den erweiterten Parametern steckt ein eingebautes Importwerkzeug, das CSV Dateien für eine feste Menge an Entitäten liest: Kategorien, Produkte, Kombinationen, Kunden, Adressen, Marken, Lieferanten, Aliasse, Shop Kontakte, und Bestellungen an Lieferanten, sobald die erweiterte Lagerverwaltung aktiv ist.⁵ Es ist ein wirklich brauchbares Werkzeug, und schon an der Form, die es verlangt, lässt sich viel über das Datenmodell ablesen. Es hat auch Tücken, die man kennen sollte, bevor man sich darauf stützt. Das Trennzeichen ist ein Semikolon, also stört jedes Semikolon in deinem Text den Parser. Jede Zeile braucht gleich viele Spalten. Kategorien müssen vor den Produkten vorhanden sein, die auf sie verweisen, deshalb importierst du Kategorien zuerst über ihre ID. Jeder Import deckt genau eine Sprache ab, also gehören mehrsprachige Daten in je eine Datei pro Sprache. Bild URLs müssen absolut und erreichbar sein. Und es gibt die Option, vor dem Import alles zu löschen, die genau das macht.⁵ Fürs Herausholen exportiert die Produktliste im Katalog nach CSV, und was die Oberflächen nicht abdecken, holst du aus der Datenbank.

Die Webservice API. PrestaShop liefert einen Webservice im REST Stil mit, in der Voreinstellung abgeschaltet. Du aktivierst ihn unter den erweiterten Parametern auf der Webservice Seite und legst dort einen Schlüssel an, und derselbe Schlüssel lässt sich auf nur lesend stellen oder je Methode und je Ressource mit Rechten versehen, sodass du Kunden und Bestellungen zum Lesen öffnest, ohne irgendwo Schreibrechte zu vergeben.⁶ Die Authentifizierung läuft über HTTP Basic mit dem Schlüssel als Benutzernamen und ohne Passwort, der Schlüssel ist damit das ganze Geheimnis und will wie eines gehütet werden. Die Doku rät, ihn in einem Authorization Header zu übergeben statt in der URL.⁷ Der Endpunkt sitzt unter /api/ im Wurzelverzeichnis der Installation und setzt aktives URL Rewriting am Webserver voraus. Der Aufruf der Wurzel listet die Ressourcen auf, die dein Schlüssel erreicht, unter ihnen customers, addresses, orders und order_histories.⁷ Ein Detail ist für ein Migrationsskript wichtig: Der Webservice sprach historisch XML, und du schaltest die Ausgabe mit dem Parameter output_format=JSON oder dem Header Output-Format auf JSON um, doch seit PrestaShop 8.1 gibt der Webservice nur noch JSON aus und kann JSON beim Schreiben nach wie vor nicht lesen.⁷ PrestaShop 9 ergänzt eine eigene, neuere Admin API auf Basis von API Platform mit OAuth2 Token, die die Richtung weist, vom Projekt aber noch als in Arbeit bezeichnet wird.⁸ Eine Ratenbegrenzung durch die Plattform, wie sie ein gehosteter Anbieter verhängt, existiert nicht: Die Grenze ist dein eigener Server, was praktisch bedeutet, dass du große Ressourcen seitenweise und außerhalb der Stoßzeiten abrufst.

Direkter Datenbankzugriff. Weil der komplette Shop in deinem eigenen MySQL liegt, ist der vollständigste und zuverlässigste Export schlicht das Lesen der Datenbank. Für eine Migration nehme ich die Datenbank als die Quelle der Wahrheit und den Webservice als Komfort, denn die Datenbank enthält alles, auch die Modultabellen, die die API nie preisgibt. Das ist der leise Vorteil einer selbst gehosteten Plattform, und der Grund, warum PrestaShop sauberer übergibt als jeder gehostete Mitbewerber.

Passwörter, und warum sie neu gesetzt werden

An dieser Stelle hilft dir der Besitz der Datenbank nicht. PrestaShop hasht die Passwörter von Kunden und Mitarbeitern. Gespeichert werden sie nicht. Aktuelle Versionen hashen mit bcrypt, über PHPs password_hash und PASSWORD_BCRYPT, und akzeptieren beim Prüfen eines alten Hashs weiterhin ein älteres md5 Verfahren, damit Altkonten weiter funktionieren.⁹ Seit PrestaShop 8.0 kommt eine Richtlinie zur Passwortstärke auf Basis der Bibliothek zxcvbn hinzu.¹⁰ Ein bcrypt Hash lässt sich konstruktionsbedingt nicht in das Ausgangspasswort zurückrechnen, es gibt also nichts mitzunehmen, womit sich eine Kundin mit ihrem bisherigen Passwort unverändert anmelden könnte.

Die ehrliche Folge: In einem maßgeschneiderten Solidus Shop vergibt die Kundschaft ihr Passwort einmal neu, über einen einmaligen sicheren Link, beim ersten Besuch nach dem Umstieg. Als vorbereitete Servicenachricht statt als Überraschung am Starttag bleibt das folgenlos. Das Wie steht in der Kunden Spoke, samt dem Erhalt der Einwilligungsnachweise und Adressen, sodass tatsächlich nur das Passwort neu ist.

Die Fallen, die gerade für PrestaShop typisch sind

Jede Plattform hat ihre eigenen Stellen, an denen eine Migration Zeit oder Geld verliert, wenn man sie nicht kommen sieht. Dies sind die von PrestaShop.

Der Modulturm. Was einen PrestaShop Shop zum Laufen bringt, ist selten der Kern allein. Es sind dreißig oder vierzig Module, mehrere davon kommerziell, gekauft über den offiziellen Marktplatz PrestaShop Addons.¹¹ Jedes trägt seine eigene Konfiguration, und manche bergen echte Geschäftslogik: eine Preisregel, eine Versandberechnung, ein Treueprogramm. Beim Umzug reist diese Logik nicht als Daten mit. Sie muss aus den Modulen herausgelesen, verstanden und neu gebaut werden. Die gute Nachricht: Ein Neubau als getesteter Rails Code beendet die Abhängigkeit endgültig. Die ehrliche Nachricht: Das Aufspüren all dessen ist die eigentliche Erkundungsarbeit, und ein Modul, an dessen Kauf sich niemand erinnert, ist genau dort, wo die Überraschungen warten.

Overrides. PrestaShop erlaubt Entwicklern, Kernverhalten zu ändern, indem sie Dateien in einen Ordner override legen. Das ist ein vernünftiger Mechanismus, und zugleich der Ort, an dem sich jahrelange undokumentierte Entscheidungen stapeln. Vor einem Umzug durchsuche ich die Overrides und die eigenen Module nach Logik, von der das Geschäft abhängt und die sonst nirgends steht, denn ein Override bleibt unsichtbar, bis es bricht.

Zahlungskonfiguration und Token. Zahlungen sind in PrestaShop Module, und jedes Zahlungsmodul legt seine Konfiguration und seine gespeicherten Kartenverweise auf eigene Weise ab. Einen einzelnen, mitnehmbaren Export der gespeicherten Karten gibt es nicht, weil die Kartendaten nie PrestaShop gehört haben. Sie liegen beim Zahlungsanbieter. Das sauberste Ergebnis ist, dasselbe Gateway zu behalten und den neuen Shop an dasselbe Konto anzubinden, damit gespeicherte Token gültig bleiben. Wo das Gateway wechselt, reisen gespeicherte Karten in aller Regel nicht mit, und das benenne ich ganz am Anfang, nicht am Ende. Die ausführliche Fassung steht in der Token Spoke, und die Risiken eines Gatewaywechsels überhaupt in die versteckten Gefahren beim Wechseln von Payment Gateways.

Abonnements. PrestaShop kennt keine eingebaute wiederkehrende Abrechnung. Abos stammen aus einem Modul, und dieses Modul hängt meist an einem Gateway, das das Mandat hält und die Abbuchungen fährt. Abodatensätze lassen sich als Daten leicht exportieren, doch die laufende Abrechnungsbeziehung, das, was nächsten Monat wirklich Geld einzieht, ist der schwierigste Teil jeder Migration und braucht oft die Mitarbeit des alten Gateways, um ohne Unterbrechung für die Kundschaft umzuziehen. Es ist die erste Frage, die ich stelle, nicht die letzte. Die Abo Spoke behandelt die Optionen ehrlich.

URLs und SEO. PrestaShop baut suchmaschinenfreundliche URLs, und an ihnen hängen deine Platzierungen und Backlinks. PrestaShop 9 hat die Voreinstellung so geändert, dass Produkt URLs die Kategorie nicht mehr enthalten,⁴ was daran erinnert, dass die URL Struktur eine Plattformentscheidung ist, in der du bisher gewohnt hast. In einem eigenen Shop legst du die Struktur fest, und jede alte URL, die einen Besuch oder einen Link verdient hat, bekommt eine dauerhafte 301 Weiterleitung auf ihren neuen Platz. Diese Weiterleitungskarte ist mühselige, eigene Arbeit, und sie auszulassen ist der häufigste Weg, auf dem eine Migration still Besucher verliert. Die Mechanik steht in der Produkt Spoke.

Der ehrliche Umzug auf einen maßgeschneiderten Solidus Shop

Ein Weg weg von PrestaShop ist kein einzelnes Projekt, sondern fünf Stränge, und jeder entspricht einem der Begleittexte.

Der Katalog ist der leichte Strang: Produkte, Kombinationen, Kategorien, Preise und Bilder aus MySQL gelesen, auf Solidus Produkte und Varianten abgebildet und geprüft. Kundschaft, ihre Adressen und die Bestellhistorie kommen als Datensätze mit, die Passwörter werden beim ersten Login neu gesetzt. Die Weiterleitungskarte formt jede bedeutsame alte URL zu einer 301. Zahlungen werden nach Möglichkeit an dasselbe Gateway angebunden, damit Token überleben. Abonnements werden zuerst geplant, weil sie der eine Strang sind, der einen Start aufhalten kann.

Neu gebaut statt migriert wird die Storefront und die Geschäftslogik, die die Module getragen haben. Das ist der Posten, der im ersten Jahr Geld kostet, und zugleich der, der danach aufhört zu kosten, weil er zu deinem eigenen, getesteten Code wird, ohne Lizenz und ohne Anbieter zwischen dir und ihm. Ich beschreibe, wie jedes Merkmal am Ende einen ausführbaren Test besitzt, sodass du nachlesen kannst, was dein eigener Shop verspricht, und ich lege die gesamte Rechnung über fünf Jahre, Besitzen gegen Mieten, in den Gesamtkosten über fünf Jahre offen, dazu den Vergleich Plattform für Plattform in Solidus vs Shopify vs Shopware vs Magento vs WooCommerce. Weil WooCommerce die andere verbreitete, selbst gehostete quelloffene Plattform ist, die man gleichzeitig prüft, steht ihr ehrlicher Ausstieg in von WooCommerce zu einem eigenen Shop wechseln.

Ein durchgerechnetes Beispiel

Machen wir es greifbar mit einem erfundenen Unternehmen. Kölner Radteile (koelnerradteile.example) ist ein Kölner Händler für Fahrradkomponenten und Verschleißteile, mit rund 9.000 Produkten und Kombinationen, kräftigen Suchplatzierungen, über ein Jahrzehnt aufgebaut, und einer kleinen, treuen Aboseite: einem monatlichen Verschleißclub, bei dem Mitglieder einen festen Betrag zahlen und eine Box mit Kettenöl, Bremsbelägen und Schläuchen erhalten, abgebucht über ein Abomodul, das an ihre gespeicherte Karte gebunden ist. Der Shop läuft auf PrestaShop 1.7, trägt zweiundvierzig Module, elf davon kostenpflichtig, und der Inhaber hat das Upgrade auf PrestaShop 8 zweimal verschoben, weil ihn das Angebot erschreckt hat und zwei der kostenpflichtigen Module keine passende Version haben. Sein Entwickler ist weitergezogen, und die neue Agentur will einen Retainer allein dafür, das Ding gepatcht zu halten. Gegen das Verkaufen im Netz hat er nichts. Gegen die Pflege sehr wohl.

Beim ersten Durchsehen sortiere ich die Stränge nach Schwierigkeit, den schwersten voran. Der Verschleißclub ist der schwere: Ich muss wissen, welches Gateway die Mandate hält und ob es die gespeicherten Token umziehen lässt, denn wenn nicht, müssten Mitglieder ihre Karten neu eingeben, und das ist ein Gespräch, das vor dem Bauen gehört, nicht danach. Die gespeicherten Karten der normalen Kundschaft sind dieselbe Frage in milderer Form. Diese beiden benenne ich am ersten Tag.

Alles Übrige ist beruhigend gewöhnlich. Die 9.000 Produkte und ihre Kombinationen kommen direkt aus MySQL, deutlich zuverlässiger als über den Webservice, und bilden auf Solidus Produkte und Varianten ab. Kundschaft, Adressen und ein paar Jahre Bestellhistorie kommen als Datensätze mit, die Passwörter werden beim ersten Login mit einer vorbereiteten Nachricht neu gesetzt. Das Jahrzehnt an Platzierungen schützt eine Weiterleitungskarte, jede alte PrestaShop URL auf ihr neues Gegenstück gezeigt, was bei dieser Größe ein paar tausend Zeilen und zwei sorgfältige Tage bedeutet. Die elf kostenpflichtigen Module werden auf die Logik gelesen, die zählt, die Clubpreise und ein Laufradkonfigurator darunter, und diese Logik wird als getesteter Code neu gebaut, der ihm allein gehört.

Das Ergebnis ist ein Solidus Shop, der wie seine Marke aussieht, keine Modullizenzen trägt, den Verschleißclub als echtes Merkmal statt als gekauften Aufsatz führt, und sich morgen an jede Rails Entwicklerin übergeben lässt. Der Aufbau kostet im ersten Jahr mehr als ein weiteres Jahr PrestaShop Pflege. Vom zweiten Jahr an kostet er weit weniger, und die Angst vor dem Upgrade ist fort, weil eine getestete Rails Anwendung gepflegt und nicht in Abständen neu gebaut wird.

Wann du auf PrestaShop bleiben solltest

Etlichen Shops würde ich zum Bleiben raten. Wenn dein PrestaShop schlank ist, wenn es eine Handvoll Module fährt, die du verstehst und gepatcht hältst, wenn eine Entwicklerin deines Vertrauens es aktuell hält, und wenn Katalog und Checkout gewöhnlich sind, dann erfüllt PrestaShop seinen Zweck und ein maßgeschneiderter Aufbau wäre Geld für ein Problem, das du nicht hast. Die Plattform ist wirklich gut darin, ein selbst gehosteter, eigener Shop für ein Unternehmen zu sein, dem die Pflege eines solchen liegt. Der ehrliche Auslöser für einen Wechsel ist nicht die Abneigung gegen PrestaShop. Es ist das Gewicht aus Modulen und Upgrades, das den Wert übersteigt, den sie zurückgeben, dazu ein echter Bedarf an Verhalten, das ein Modulturm nur näherungsweise trifft.

Bist du der Shop, der herausgewachsen ist, dann halte dich an eines: Dein Datenzugriff ist bereits gut. Du steckst nicht fest. Du bist beschwert, und das ist eine weit bessere Ausgangslage für einen Umzug.

Wie ich deinen Umzug führe

Ich baue den maßgeschneiderten Solidus Shop und führe die Migration. Das Ergebnis gehört dir, Code und Daten, sobald es bezahlt ist. Ich fange mit den zwei Fragen an, die einen Zeitplan versenken können, den gespeicherten Karten und den laufenden Abos, und ich hole schriftliche Antworten von den Gateways ein, bevor eine Zeile Migrationscode entsteht. Dann die gewöhnlichen Stränge: Katalog aus der Datenbank, Kundschaft und Bestellungen hinüber, die Weiterleitungskarte gebaut und getestet, die Modullogik mit Tests neu gebaut, und ein geprobter Umstieg, bei dem der alte Shop einen Monat lang unberührt als Rückfalllösung bestehen bleibt.

Wenn dich ein PrestaShop beschwert, das seine Pflege nicht mehr wert ist, bring es in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich sage dir ehrlich, welche Stränge für deinen Shop leicht und welche schwer sind, und wenn die ehrliche Antwort lautet, dass dir ein schlankes PrestaShop weiterhin gute Dienste leistet, dann sage ich dir auch das.