PrestaShop-migrering från Hestia till DirectAdmin

PrestaShop-migrering från Hestia till DirectAdmin

En PrestaShop-migrering behöver inte innebära att hela stacken flyttas. I det här fallet flyttade jag backenden från en äldre Hestia-miljö till en ny DirectAdmin-baserad värd på en kväll. Frontenden stannade på sin befintliga plattform. Tjänster för nyhetsbrev och CRM stannade där de var. Omfattningen var snävare: få den nya backenden att hantera REST API:er, cache och cron för ett multistore-ecommercesystem.

Det aktiva arbetet tog cirka tre till fyra timmar. Filöverföringen var den enkla delen. Det verkliga jobbet var att bevisa att routing, Redis, cron, cache-invalidering och butiksspecifika API-svar fortfarande fungerade efter flytten.

Vad jag flyttade i PrestaShop-migreringen

Backenden landade på en modern delad hostingplan med NVMe-lagring, tilldelad CPU och tilldelat RAM-minne. Hostingpanelen rapporterade det förväntade paketet och diskkvoten.

Jag flyttade inte allt, och det var avsiktligt.

Flyttat:

Lämnat på plats:

Jag föredrar denna typ av snäv PrestaShop-migrering eftersom den reducerar brus. Om du flyttar frontend, marknadsföringsstack och backend samtidigt skapar du för många variabler. Här ville jag validera ett tydligt affärssystem.

Routing var det första problemet

PrestaShop körs som en multishop-backend. Det innebär att en backend måste svara korrekt för två butiker. På den gamla värden döljde panelregler och befintligt URL-beteende en del av komplexiteten. På den nya värden måste REST-anrop bevara butikskontexten innan PrestaShop omdirigerade eller kanoniserade begäran.

Lösningen var att routa butiksprefixade REST-anrop korrekt:

Det ser mindre ut på papperet. I praktiken är detta den typ av detalj som får en migrering att kännas trasig även när filer, databas och DNS är korrekta. I mitt arbete kontrollerar jag routing innan jag skyller på PHP, Redis eller databasen.

Redis hjälpte, men cache-radering var viktigare

Redis aktiverades via en Unix-socket:

text /home/account/.redis/redis.sock

PrestaShop använde sedan Redis som cache-backend. API-svaren förbättrades, men cache är bara viktigt om den rensas vid rätt tillfälle.

Back office är källan till sanning. När någon ändrar ett pris, en produktbeskrivning, ett PageBuilder-block, en kategori eller en kampanj i PrestaShop måste frontend-API:t leverera färska data. Att aktivera cache räcker inte. Jag behövde också koppla cache-radering till relevanta PrestaShop-hookar.

Jag verifierade beteendet direkt:

Det är skillnaden mellan "cache är aktiverad" och "cache kan litas på". Inom e-handel spelar den skillnaden roll omedelbart.

Cron-jobb behövde noggrann filtrering

Den första Hestia-cron-kontrollen hittade jobb som tillhörde en annan tjänst, inte PrestaShop-backenden. Dessa jobb hörde inte hemma på den nya värden eftersom den tjänsten inte ingick i denna migrering.

De relevanta PrestaShop-jobben fanns på den gamla live-Hestia-servern:

Jag migrerade inte ett suspenderat CRM-jobb. Jag hoppade också över Hestias interna systemjobb. DirectAdmin har sitt eget flöde för underhåll och säkerhetskopiering, så att kopiera panel-skrap skulle bara ha skapat förvirring.

Ett databasdump-jobb mappades först som en försiktig utvecklingsdump. Jag tog bort det när jag bekräftade att hostingpanelen redan hanterade säkerhetskopior. Att duplicera flöden för säkerhetskopiering skapar brus om det inte finns en tydlig anledning till återställning.

Prestandaresultat från backend-flytten

Jag testade samma publika REST-slutpunkt 12 gånger per butik:

text /rest/pagebuilder/placements

Här var resultaten:

Stage-servern var en enkel referensserver och svarade konsekvent. Den nya värden svarade fortfarande snabbare för båda butikerna.

Den nya värden visade också ett högre genomsnittligt serverbelastning (load average), runt 10–13. SSH exponerade fler CPU-trådar på den fysiska värden än kontotilldelningen, så den siffran var inte alarmerande i sig. Kontot såg lugnt ut: Redis var nästan inaktivt, PHP-workers drev inte CPU:n och databasen hade låg aktiv frågelast när jag kontrollerade.

Därför behandlar jag load average försiktigt på delad hosting. Det speglar värden, inte bara ett konto. Om din leverantör säljer en plan med tydliga CPU- och RAM-specifikationer hjälper det ändå att fråga hur dessa gränser tillämpas via CloudLinux eller LVE.

Mitt AI-arbetsflöde för migreringen

Jag använde Codex som operativ agent för SSH, DirectAdmin API-arbete, serverkontroller, crontab-ändringar, timingtester och PrestaShop-override-arbete.

För granskning använder jag mitt öppna arbetsflöde ai-collab-bridge. Idén är enkel: en AI implementerar ändringen, sedan tar en annan AI emot ett granskningspaket med diff, kontext och fokuserade frågor. Claude Code kan sedan granska arbetet som en andra teknisk läsare istället för att reagera på en lös sammanfattning.

Det spelar roll i en PrestaShop-migrering eftersom det finns många små beslut:

AI hjälper när den måste visa sina kontroller. "Det fungerar" räcker inte. En användbar migreringskörning visar kommandon, statuskoder, cache-beteende, cron-tillstånd och de delar som avsiktligt inte flyttades.

Lärdomar jag tog med mig från denna migrering

Kopiera inte panelbeteende blindt. Hestia och DirectAdmin löser hostingunderhåll på olika sätt. Hestia panel-cron hör inte hemma i DirectAdmin.

Håll backend-migreringen snäv. Om frontend redan körs någon annanstans ökar en flytt av den bara risken.

Verifiera cache ur back office-perspektiv. E-handelsändringar sker via pris, lager, text och kampanjredigeringar. Cache som misslyckas med att rensas blir ett affärsproblem.

Mät samma slutpunkt upprepade gånger. En `curl`-begäran säger lite. Tolv körningar per butik gav mig en mycket tydligare signal.

Hardkoda inte databaslösenord i skript. Läs från applikationens befintliga konfiguration vid behov och låt hostingpanelen äga säkerhetskopieringarna.

Resultat

Efter flytten svarade backenden snabbare än både den gamla live-servern och stage-referensen i mina tester. Redis och LiteSpeed hjälpte. DirectAdmin API räckte för de panelinställningar jag behövde. OPcache-minne visade sig vara en inställning på värdnivå, så det hör hemma hos hosting-supporten snarare än i appkoden.

Huvudresultatet var inte ett lägre TTFB. Det viktiga resultatet var att backenden fortfarande betedde sig som en e-handels-backend: back office äger datan, API:t svarar per butik, cachen rensas vid ändringar och cron kör bara de jobb som hör hemma på den nya värden.

FAQ

Hur lång tid tog migreringen?

Den aktiva backend-migreringen tog cirka tre till fyra timmar. Med timingtester, cron-inventering, cache-verifiering och supportanteckningar var arbetet närmare fyra till fem timmar.

Varför flyttade du inte allt?

Frontend kördes redan någon annanstans. Automatisering av nyhetsbrev och CRM hade sina egna miljöer. En snäv backend-flytt minskade risken.

Varför var Redis viktigt?

Redis förbättrade backendens cachehastighet, men det verkliga värdet kom när cache-radering kopplades till PrestaShop-hookar. Utan det kan ändringar i back office misslyckas med att nå API:t.

Varför är load average svårt att läsa på delad hosting?

Load average visar ofta hela värdens kö, inte bara ditt konto. I denna migrering såg kontot lugnt ut medan värden visade högre belastning. Därför bör CloudLinux- eller LVE-gränser bekräftas av supporten.

Varför använda AI i en servermigrering?

AI är användbart när det arbetar med bevis: config-läsningar, timingtester, cron-jämförelser, API-kontroller och dokumenterade ändringar. Peer review genom ett öppet arbetsflöde gör det lättare att låta en annan modell inspektera riskerna.