Nikola Arsić
Pfade
1.6 → 1.7 → 8 → 9
Bleibt erhalten
Bestellungen, Kunden, URLs
Zusammenarbeit
Direkt, 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 führe genau diese Migration gerade über 23 Shops durch - deshalb kann ich Ihnen vorher sagen, welche Ihrer Module nicht mehr laufen werden.

Was sich zwischen den Versionen ändert - und was dabei kaputtgeht

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 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 hosten
  • 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 läuft 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 für die Produktion angesetzt - mit getestetem Rollback und einem Wartungsfenster, das der echten Dauer entspricht, nicht einer Schätzung.

Suchmaschinen-Rankings behandle ich wie Daten, die erhalten bleiben müssen - 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 strukturierte Daten. Wo sich eine URL ändern muss, bekommt sie eine 301-Weiterleitung und bleibt auf der Liste, bis Google nachgezogen hat.

Migration von einer anderen Plattform zu PrestaShop

Der Umstieg von WooCommerce, Magento, OpenCart oder einem Eigenbau auf PrestaShop 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 skriptgesteuert 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 ein Upgrade noch warten kann

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 wird nicht mehr unterstützt, und jeder Monat dort ist ein Monat ungepatchter Angriffsfläche. Die Bestandsaufnahme sagt Ihnen, welcher Fall auf Sie zutrifft - und ich sage es auch dann, wenn es kein Projekt bedeutet.

Was Kunden zuerst fragen

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 auch 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 durchführen?
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.