PrestaShop-Migration von Hestia zu DirectAdmin
Eine PrestaShop-Migration muss nicht bedeuten, den gesamten Stack zu verschieben. In diesem Fall habe ich das Backend von einer älteren Hestia-Installation an einen neuen DirectAdmin-basierten Host an einem Abend verschoben. Das Frontend blieb auf seiner bestehenden Plattform. Newsletter- und CRM-Dienste blieben dort, wo sie waren. Der Umfang war enger: Das neue Backend sollte REST-APIs, Cache und Cron für ein Multistore-E-Commerce-System verwalten.
Die aktive Arbeit dauerte etwa drei bis vier Stunden. Der Dateitransfer war der einfache Teil. Die eigentliche Aufgabe bestand darin, nachzuweisen, dass Routing, Redis, Cron, Cache-Invalidierung und store-spezifische API-Antworten nach der Migration weiterhin funktionierten.
Was ich bei der PrestaShop-Migration verschoben habe
Das Backend landete auf einem modernen Shared-Hosting-Plan mit NVMe-Speicher, zugewiesenem CPU und zugewiesenem RAM. Das Hosting-Panel meldete das erwartete Paket und die Disk-Quota.
Ich habe nicht alles verschoben, und das war absichtlich.
Verschoben:
An Ort und Stelle gelassen:
Ich bevorzuge diese Art von enger PrestaShop-Migration, da sie das Rauschen reduziert. Wenn Sie das Frontend, den Marketing-Stack und das Backend gleichzeitig verschieben, schaffen Sie zu viele Variablen. Hier wollte ich ein klares Geschäftssystem validieren.
Routing war das erste Problem
PrestaShop läuft als Multishop-Backend. Das bedeutet, dass ein Backend korrekt für zwei Stores antworten muss. Auf dem alten Host verbargen Panelregeln und das bestehende URL-Verhalten einen Teil der Komplexität. Auf dem neuen Host mussten REST-Aufrufe den Store-Kontext beibehalten, bevor PrestaShop die Anfrage umleitete oder kanonisierte.
Die Lösung bestand darin, store-präfixierte REST-Aufrufe korrekt zu routen:
Das sieht auf dem Papier geringfügig aus. In der Praxis ist dies die Art von Detail, die eine Migration gebrochen erscheinen lässt, selbst wenn die Dateien, die Datenbank und die DNS korrekt sind. In meiner Arbeit überprüfe ich das Routing, bevor ich PHP, Redis oder die Datenbank beschuldige.
Redis half, aber Cache-Leerung war wichtiger
Redis wurde über einen Unix-Socket aktiviert:
text /home/account/.redis/redis.sock
PrestaShop verwendete dann Redis als Cache-Backend. Die API-Antworten verbesserten sich, aber Cache ist nur wichtig, wenn er zur richtigen Zeit geleert wird.
Das Back Office ist die Quelle der Wahrheit. Wenn jemand einen Preis, eine Produktbeschreibung, einen PageBuilder-Block, eine Kategorie oder eine Kampagne in PrestaShop ändert, muss die Frontend-API frische Daten bereitstellen. Nur Cache zu aktivieren reicht nicht aus. Ich musste auch die Cache-Leerung mit den relevanten PrestaShop-Hooks verbinden.
Ich habe das Verhalten direkt überprüft:
Das ist der Unterschied zwischen "Cache ist aktiviert" und "Cache kann vertraut werden." Im E-Commerce ist dieser Unterschied sofort wichtig.
Cron-Jobs benötigten sorgfältige Filterung
Die erste Hestia-Cron-Überprüfung fand Jobs, die zu einem anderen Dienst gehörten, nicht zum PrestaShop-Backend. Diese Jobs gehörten nicht auf den neuen Host, da dieser Dienst nicht Teil dieser Migration war.
Die relevanten PrestaShop-Jobs waren auf dem alten Live-Hestia-Server:
Ich habe einen ausstehenden CRM-Job nicht migriert. Ich habe auch Hestias interne Systemjobs übersprungen. DirectAdmin hat seinen eigenen Wartungs- und Backup-Flow, daher hätte das Kopieren von Panel-Resten nur Verwirrung gestiftet.
Ein Datenbank-Dump-Job wurde zunächst als vorsichtiger Entwicklungs-Dump zugeordnet. Ich habe ihn entfernt, als ich bestätigte, dass das Hosting-Panel bereits Backups verwaltete. Das Duplizieren von Backup-Workflows erzeugt Rauschen, es sei denn, es gibt einen klaren Wiederherstellungsgrund.
Leistungsergebnisse aus dem Backend-Umzug
Ich habe denselben öffentlichen REST-Endpunkt 12 Mal pro Store getestet:
text /rest/pagebuilder/placements
Hier sind die Ergebnisse:
| Umgebung | Store A Durchschnitt | Store B Durchschnitt |
|---|---|---|
| --- | ---: | ---: |
| Alter Live Hestia | 0.500s | 0.420s |
| Stage Hestia | 0.305s | 0.302s |
| Neuer DirectAdmin-Host | 0.267s | 0.220s |
Der Staging-Server war ein einfacher Referenzserver und antwortete konsistent. Der neue Host antwortete immer noch schneller für beide Stores.
Der neue Host zeigte auch einen höheren durchschnittlichen Serverlastwert, etwa 10-13. SSH zeigte mehr CPU-Threads auf dem physischen Host als die Kontozuweisung, daher war diese Zahl an sich nicht alarmierend. Das Konto sah ruhig aus: Redis war fast im Leerlauf, PHP-Worker trieben die CPU nicht an, und die Datenbank hatte eine niedrige aktive Abfragebelastung, als ich nachschaute.
Deshalb gehe ich vorsichtig mit dem durchschnittlichen Lastwert bei Shared Hosting um. Er spiegelt den Host wider, nicht nur ein Konto. Wenn Ihr Anbieter einen Plan mit klaren CPU- und RAM-Spezifikationen verkauft, hilft es dennoch zu fragen, wie diese Grenzen durch CloudLinux oder LVE durchgesetzt werden.
Mein KI-Workflow für die Migration
Ich verwendete Codex als operativen Agenten für SSH, DirectAdmin-API-Arbeiten, Serverüberprüfungen, Crontab-Änderungen, Timing-Tests und PrestaShop-Überschreibungsarbeiten.
Zur Überprüfung benutze ich meinen offenen Workflow ai-collab-bridge. Die Idee ist einfach: Eine KI implementiert die Änderung, dann erhält eine andere KI ein Überprüfungspaket mit dem Diff, dem Kontext und fokussierten Fragen. Claude Code kann dann die Arbeit als zweiter technischer Leser überprüfen, anstatt auf eine lose Zusammenfassung zu reagieren.
Das ist wichtig bei einer PrestaShop-Migration, da es viele kleine Entscheidungen gibt:
KI hilft, wenn sie ihre Überprüfungen zeigen muss. "Es funktioniert" reicht nicht aus. Ein nützlicher Migrationslauf zeigt Befehle, Statuscodes, Cache-Verhalten, Cron-Zustand und die Teile, die absichtlich nicht verschoben wurden.
Lektionen, die ich aus dieser Migration mitgenommen habe
Kopieren Sie das Panel-Verhalten nicht blind. Hestia und DirectAdmin lösen die Wartung des Hostings unterschiedlich. Hestia-Panel-Cron gehört nicht in DirectAdmin.
Halten Sie die Backend-Migration eng. Wenn das Frontend bereits woanders läuft, erhöht sich nur das Risiko.
Überprüfen Sie den Cache aus der Sicht des Back Offices. E-Commerce-Änderungen erfolgen durch Preis-, Bestands-, Text- und Kampagnenbearbeitungen. Cache, der nicht geleert wird, wird zu einem Geschäftsproblem.
Messen Sie denselben Endpunkt wiederholt. Eine `curl`-Anfrage sagt wenig aus. Zwölf Durchläufe pro Store gaben mir ein viel klareres Signal.
Härten Sie Datenbankpasswörter nicht in Skripten. Lesen Sie bei Bedarf aus der bestehenden Konfiguration der Anwendung und lassen Sie das Hosting-Panel die Backups verwalten.
Ergebnis
Nach dem Umzug antwortete das Backend schneller als sowohl der alte Live-Server als auch der Staging-Referenzserver in meinen Tests. Redis und LiteSpeed halfen. Die DirectAdmin-API war ausreichend für die Panel-Einstellungen, die ich benötigte. Der OPcache-Speicher stellte sich als eine Einstellung auf Host-Ebene heraus, daher gehört das zur Hosting-Unterstützung und nicht zum Anwendungs-Code.
Das Hauptresultat war nicht ein niedrigerer TTFB. Das wichtige Ergebnis war, dass das Backend weiterhin wie ein E-Commerce-Backend funktionierte: Das Back Office besitzt die Daten, die API antwortet pro Store, der Cache wird bei Änderungen geleert, und Cron führt nur die Jobs aus, die zum neuen Host gehören.
FAQ
Wie lange hat die Migration gedauert?
Die aktive Backend-Migration dauerte etwa drei bis vier Stunden. Mit Timing-Tests, Cron-Inventar, Cache-Überprüfung und Unterstützungsnotizen war die Arbeit näher an vier bis fünf Stunden.
Warum haben Sie nicht alles verschoben?
Das Frontend lief bereits woanders. Newsletter-Automatisierung und CRM hatten ihre eigenen Umgebungen. Eine enge Backend-Verschiebung reduzierte das Risiko.
Warum war Redis wichtig?
Redis verbesserte die Geschwindigkeit des Backend-Caches, aber der echte Wert kam, als die Cache-Leerung mit PrestaShop-Hooks verbunden wurde. Ohne das können Änderungen im Back Office die API nicht erreichen.
Warum ist der durchschnittliche Lastwert bei Shared Hosting schwer zu lesen?
Der durchschnittliche Lastwert zeigt oft die gesamte Host-Warteschlange, nicht nur Ihr Konto. In dieser Migration sah das Konto ruhig aus, während der Host eine höhere Last zeigte. Deshalb sollten CloudLinux- oder LVE-Grenzen von der Unterstützung bestätigt werden.
Warum KI bei einer Servermigration verwenden?
KI ist nützlich, wenn sie mit Beweisen arbeitet: Konfigurationslesungen, Timing-Tests, Cron-Vergleiche, API-Überprüfungen und dokumentierte Änderungen. Peer-Review durch einen offenen Workflow erleichtert es, ein anderes Modell die Risiken überprüfen zu lassen.