Nikola Arsić
Pfade1.6 → 1.7 → 8 → 9Bleibt erhaltenBestellungen, Kunden, URLsZusammenarbeitDirekt, ohne Agenturebene

PrestaShop-Upgrade und -Migration - und danach sind Bestellungen, Kunden und URLs noch da.

Jeder Versionssprung in PrestaShop ist eine kleine Migration: 1.6 auf 1.7 hat die Theme-Ebene verändert, 1.7 auf 8 die PHP-Untergrenze verschoben, 8 auf 9 den Symfony-Kern und die Admin-API ersetzt und Hummingbird zum Theme der Zukunft gemacht. Ich fahre genau diese Migration gerade über 26 Shops - deshalb kann ich Ihnen vorher sagen, welche Ihrer Module brechen werden.

Was sich zwischen den Versionen ändert - und was es bricht

PrestaShop 8 hat die PHP-Anforderung angehoben und ein Jahrzehnt Altlasten ausgeräumt - genau dort scheitern alte Module. PrestaShop 9 geht weiter: aktuelles Symfony, PHP 8.1 oder neuer, eine neue Admin API und Hummingbird als unterstütztes modernes Theme, auf Bootstrap 5 und ohne das jQuery, das die Hälfte des Modul-Ökosystems noch voraussetzt.

Praktisch heißt das: Ein Upgrade ist nie nur das Ausführen des Upgrade-Moduls. Es ist eine Prüfung jedes installierten Moduls gegen die Zielversion, eine Entscheidung pro Modul - aktualisieren, ersetzen, neu schreiben oder entfernen -, eine Theme-Portierung oder ein Neubau, ein Server mit der neuen PHP-Version und ein Testplan für Checkout, Zahlung, Versand und die Admin-Abläufe, die Ihr Team täglich nutzt.

  • Modul-Kompatibilitätsprüfung mit Urteil pro Modul: behalten, aktualisieren, ersetzen, neu schreiben oder entfernen
  • Theme-Pfad: Classic für die Zielversion flicken oder auf Hummingbird portieren und die jQuery-Altlast loswerden
  • PHP- und Serverwechsel, einschließlich der AWS-Seite, wenn Sie dort betreiben
  • Eigener Code und Overrides auf Hooks und Services portiert, die das nächste Release überleben
  • Daten durchgehend erhalten: Katalog, Kombinationen, Kunden, Bestellungen, Rechnungen, URL-Rewrites

So läuft die Migration, ohne den Live-Shop anzufassen

Das Upgrade passiert auf einer vollständigen Staging-Kopie - Datenbank, Dateien, Module, Serverkonfiguration. Dort führe ich es aus, behebe, was bricht, und wiederhole es von einer frischen Kopie, bis der Durchlauf sauber und reproduzierbar ist. Erst dann wird er gegen die Produktion terminiert - mit getestetem Rückweg und einem Wartungsfenster, das der echten Dauer entspricht, nicht einer Schätzung.

Suchmaschinen-Rankings gelten als Daten, die zu erhalten sind - auf derselben Liste wie Bestellungen. Jede URL, die in der Search Console Impressionen hat, wird vorher und nachher geprüft: gleiche Adresse, gleiches Canonical, gleiches Hreflang, gleiche strukturierten Daten. Wo sich eine URL ändern muss, bekommt sie eine 301-Weiterleitung und bleibt auf der Liste, bis Google nachgezogen hat.

Migration nach PrestaShop von einer anderen Plattform

Der Wechsel zu PrestaShop von WooCommerce, Magento, OpenCart oder einem Eigenbau folgt derselben Disziplin mit einem anderen ersten Schritt: das alte Datenmodell auf PrestaShop-Kategorien, Kombinationen, Eigenschaften und Kundengruppen abbilden, bevor eine einzige Zeile importiert wird. Der Katalogimport ist geskriptet und wiederholbar, die URL-Zuordnung steht vor dem Launch, und der alte Shop bleibt als Referenz eingefroren, bis die Zahlen übereinstimmen.

Wenn Sie PrestaShop in Richtung Shopify verlassen, hat das eine eigene Seite im Shopify-Bereich - die Überlegungen sind andere, die Arbeit auch.

Wann Sie noch nicht upgraden sollten

Manchmal ist die ehrliche Antwort: warten. Ein Shop auf 1.7 mit stabilem, gepatchtem Modulbestand und einer starken Saison vor sich hat im Oktober nichts in einer Migration verloren. Ein Shop auf 1.6 hat diesen Luxus nicht: Er ist außerhalb des Supports, und jeder Monat dort ist ein Monat ungepatchter Angriffsfläche. Die Bestandsaufnahme sagt Ihnen, welcher Fall Sie sind - und ich sage es auch dann, wenn es kein Projekt bedeutet.

Was zuerst gefragt wird

Wie lange dauert ein PrestaShop-Upgrade?
Das hängt fast ausschließlich von der Modulliste und der Menge eigenen Codes ab. Ein sauberer 1.7-Shop mit einem Dutzend gepflegter Module ist ein anderes Projekt als ein stark angepasster mit vierzig. Die Bestandsaufnahme liefert eine echte Schätzung; die Werbeseiten der Upgrade-Module nicht.
Verlieren wir unsere Google-Rankings?
Nicht, wenn URLs, Canonicals, Hreflang und strukturierte Daten vorher und nachher geprüft werden - und das ist Teil jeder Migration, die ich durchführe. Rankings gehen verloren, wenn jemand sie als Nebeneffekt behandelt statt als zu migrierende Daten.
Müssen wir auf Hummingbird wechseln?
Nicht sofort. Classic läuft auf 9 weiter. Aber jede neue Theme-Funktion und die meisten neuen Module werden Hummingbird voraussetzen - wer jahrelang auf 9 bleiben will, sollte die Portierung planen, statt zwei Generationen Theme-Schulden anzuhäufen.
Können Sie das Upgrade auf unseren Servern oder in unserem AWS-Konto machen?
Ja. Den Bestand, den ich betreue, betreibe ich auf AWS, und ich arbeite routinemäßig in Kundenkonten. Nichts muss auf Infrastruktur umziehen, die ich kontrolliere.