Tjekliste til Magento 2.4.x-opgradering: før, under og efter

En sikker Magento 2.4.x-opgradering har tre faser. Før: Tjek, hvilken release-linje der stadig har support, bekræft de versioner af PHP, OpenSearch og database, som den nye release kræver, og hold alle extensions og egenudviklede moduler op mod den. Under: Opgrader på en staging-kopi med produktionsdata, og kør derefter regressionstest af checkout og alle integrationer. Efter: Gå live i et planlagt vindue med en testet rollback, og hold derefter øje med fejl, ordrer og performance de første dage. Nedenfor er den tjekliste, vi arbejder ud fra ved hver opgradering – skrevet til webshopejere og til bureauer, der overlader opgraderinger til os.

Versioner og datoer nedenfor er tjekket mod Adobes officielle dokumentation i november 2026. Adobe opdaterer disse sider jævnligt, så tjek dem igen, når du planlægger.

Før opgraderingen

1. Kend status for din version

Adobe giver hver 2.4.x-release-linje tre års standardsupport fra udgivelsesdatoen med kvalitetsrettelser og sikkerhedspatches. Nogle ældre linjer får ekstra tid. Magento Open Source-releases følger de samme 2.4.x-release-linjer og den samme patchplan som Adobe Commerce; livscyklusdatoerne offentliggøres af Adobe for Adobe Commerce.

Hvad det betyder i praksis:

• På 2.4.4 eller 2.4.5: Du får kun enkeltstående sikkerhedsrettelser, ingen kvalitetsrettelser, og perioden bliver ikke forlænget. Planlæg en minor-opgradering nu.
• På 2.4.6: Standardsupporten er udløbet. Du har tid, men ikke meget.
• På 2.4.7 eller 2.4.8: Installér hver sikkerhedspatch (-pN-releaserne), og planlæg den næste minor-opgradering i ro og mag.
• På Adobe Commerce Cloud: Fra 1. juni 2027 stopper Adobe med at vedligeholde Cloud-miljøer, der kører versioner uden support.

Tjek også, at du er på den nyeste patch i din linje. Adobes enkeltstående sikkerhedspatch-filer kan kun installeres oven på den, så en webshop, der er flere patches bagud, kan ikke hurtigt få en nødrettelse.

2.4.10-linjen er i alpha, mens dette skrives. Planlæg ikke en opgradering af produktion på en alpha- eller beta-release.

2. Tjek platformskravene

En stor del af risikoen ved opgraderingen ligger uden for selve Magento: PHP, søgemaskinen, databasen og cachen. Adobes systemkrav for den nyeste patch i hver linje (self-hosted):

Faldgruber, der ofte overrasker teams:

• Spring i PHP-version. At gå fra 2.4.6 til 2.4.9 betyder at skifte fra PHP 8.1/8.2 til 8.5. Alle egenudviklede moduler og extensions skal køre på den nye PHP-version, ikke kun Magento core. PHP 8.2 får selv kun sikkerhedsrettelser indtil 31. december 2026.
• Søgemaskine. Elasticsearch 7.17 nåede end of support den 15. januar 2026, og 2.4.9 understøtter kun OpenSearch 3. Kører du stadig Elasticsearch, er migreringen af søgningen en del af projektet. Afsæt budget til genindeksering og til at tjekke eventuelle søge-extensions mod OpenSearch.
• Database. MySQL 8.0 nåede end of support den 30. april 2026. Tjek, hvilke versioner af MySQL eller MariaDB din nye release understøtter, før du rører koden.
• Cache. Nyere patches angiver Valkey i stedet for Redis. Din hosting eller dit Cloud-setup skal kunne levere den version, som den nye release forventer.
• Commerce Cloud har sin egen tabel med krav, som afviger fra den for self-hosted. Brug Cloud-værdierne, hvis du er på Cloud.

3. Lav en kompatibilitetsmatrix for extensions

List alle tredjepartsmoduler i composer.json og app/code, og udfyld derefter én række pr. extension:

• installeret version og leverandør;
• den version, der understøtter din nye Magento-release og PHP-version (fra leverandørens changelog, ikke kun badget på markedspladsen);
• licens- eller supportstatus, da nogle opgraderinger kræver en betalt fornyelse;
• om modulet overhovedet stadig bruges.

Markér hver række som opdatér, udskift, patch selv eller fjern. Forladte moduler er en hyppig årsag til, at estimater for opgraderinger vokser. At fjerne moduler, som ingen bruger, er ofte den billigste løsning.

4. Gennemgå egen kode og udfasede API’er

• Ændringer i core. Kig efter ændringer i vendor/, overskrevne core-klasser og composer-patches. Hver af dem skal tjekkes igen mod den nye release.
• Plugins og preferences på core-klasser går i stykker, når metodesignaturer ændres.
• Bagudinkompatible ændringer. Adobe offentliggør en liste for hver release. For eksempel skifter 2.4.9 til Symfony 7.4 LTS, så egne klasser, der udvider Symfonys core-klasser, kræver opdaterede typeerklæringer og metodesignaturer. Den afviser også ordrer oprettet via API’et uden faktureringsadresse, hvilket har betydning, hvis en ERP- eller markedspladsconnector opretter ordrer.
• På Adobe Commercekan du køre Adobes Upgrade Compatibility Tool mod den nye version. Det rapporterer kritiske problemer, fejl og advarsler i dine moduler og i core-koden. Værktøjet findes ikke til Magento Open Source. Der laves den samme gennemgang manuelt og med statisk analyse.

5. Forbered staging og backups

• Et staging-miljø , der matcher produktion: samme versioner af PHP, søgemaskine, database og cache som målet – ikke som i dag.
• En nylig kopi af produktionsdata, anonymiseret, hvis staging-miljøet er mindre beskyttet end produktion.
• Backups, du har gendannet mindst én gang: databasedump, media/, app/etc/env.php og den deployede kode (eller release-artefaktet). En backup, du aldrig har gendannet, er et håb, ikke en backup.
• En code freeze eller i det mindste en klar branch-strategi, så funktioner, der udvikles under opgraderingen, ikke kolliderer med den.

Under opgraderingen

6. Opgrader i små trin, der kan reviewes

1. Opdatér infrastrukturen på staging først: PHP, søgemaskine, database og cache.
2. Opdatér Magento og extensions via Composer, én gruppe ad gangen, og commit efter hvert trin.
3. Kør setup:upgrade, kompilér DI og deploy statisk indhold, og ret alle fejl og deprecation-advarsler. Lad være med at undertrykke dem.
4. Genanvend eller fjern composer-patches; nogle composer-patches bliver overflødige efter en opgradering.
5. Byg frontend-assets igen, og tjek theme’et, især hvis det overskriver core-templates.

7. Regressionstest det, der tjener penge

Automatiserede tests hjælper, men en skriftlig testplan, der dækker de reelle forretningsflows, er minimum:

• Checkout: gæst og logget ind, alle betalingsmetoder (inklusive 3-D Secure og wallets), alle forsendelsesmetoder, rabatkoder, gavekort, moms og valuta pr. store view.
• Kundekonto: oprettelse, login, nulstilling af adgangskode, ordrehistorik, genbestilling.
• Katalog og søgning: kategorisider, layered navigation, søgeresultater og autocomplete efter genindeksering, konfigurerbare produkter og bundle-produkter, priser pr. kundegruppe.
• Integrationer: ERP- og lagersynkronisering, ordreeksport, webhooks for betaling og forsendelse, feeds til markedspladser, e-mail- og marketingværktøjer, statistik og tag manager-events. Test begge retninger med rigtige adgange (sandbox).
• Admin og drift: oprettelse af ordrer og fakturering, kreditnotaer, importer, cron jobs, queue consumers og transaktionelle e-mails.
• B2B-funktioner på Adobe Commerce: virksomhedskonti, delte kataloger, tilbud, indkøbslister.

Lav også et hurtigt performancetjek: hit rate i full-page cachen, serverens svartid på vigtige sider og Core Web Vitals på de templates, du har ændret.

8. Planlæg releasevindue og rollback

• Vælg et tidsrum med lav trafik uden for kampagner, udsalg og andre sæsontoppe.
• Skriv release-runbooken: trin, hvem der gør hvad, forventet varighed og beslutningspunktet for rollback.
• Fastlæg kriterier for rollback før releasen (for eksempel: checkout virker ikke, betalinger fejler, integrationsfejl, du ikke kan rette inden for vinduet).
• Hav den forrige release og en frisk databasebackup klar, og vid, hvor lang tid en gendannelse tager. Så snart der kommer nye ordrer efter databaseopgraderingen, betyder en rollback af databasen, at de går tabt, så vinduet for rollback er kort.
• Sæt kun webshoppen i maintenance mode i de trin, der kræver det, og giv support og marketing tidsplanen på forhånd.

Efter opgraderingen

9. Hold tæt øje de første dage

• Fejl: PHP- og exception-logs, fejlede cron jobs, queue consumers, der sidder fast.
• Ordrer: Sammenlign ordrevolumen og andelen af fejlede betalinger med en normal uge. Et stille fald er ofte det første tegn på et problem med betaling eller checkout.
• Integrationer: Bekræft, at ordrer når frem til ERP-systemet, at lagerstatus kommer tilbage, og at webhooks lykkes.
• Søgning og indeksering: indexere gyldige, fornuftige søgeresultater, ingen voksende kø af genindeksering.
• Performance: svartider, cache-hit rate og Core Web Vitals sammenlignet med før opgraderingen.

10. Afslut ordentligt

• Fjern de moduler og patches, du har erstattet, og ryd op i gamle deployment-artefakter.
• Opdatér dokumentationen: versioner, matrixen over extensions, runbooken.
• Sæt den næste sikkerhedspatch i kalenderen. Når du holder dig på den nyeste patch i din linje, forbliver den næste minor-opgradering lille.

Patch, minor eller ældre version: hvad du kan forvente

• Patch-opgradering (for eksempel fra 2.4.8-p4 til 2.4.8-p5): lille omfang, mest test. Det bør være rutine.
• Minor-opgradering (for eksempel fra 2.4.7 til 2.4.8 eller 2.4.9): nye versioner af PHP og services, opdaterede extensions og rettelser i egen kode. Det er et projekt, ikke en opgave.
• Opgradering fra 2.3 eller ældre: Forvent en større indsats, da der ligger flere PHP-versioner og mange udfasede komponenter imellem.

Overvejer du også at udskifte Luma, så læs Hvornår betaler Hyvä sig? først. En Hyvä-migrering kan kombineres med en minor-opgradering; på en version uden support kommer opgraderingen først.

Få hjælp til din opgradering

Vil du have et ekstra sæt øjne på det, før du går i gang, tilbyder vi en gratis ekspres-audit: versioner, patchniveau, performance og basal sikkerhed med en kort rapport og et opkald på 20 minutter. Til selve opgraderingen starter vores opgraderingspakker til fast pris ved 300 € for en patch-opgradering og 1.000 € for en minor-opgradering af 2.4.x med PHP-opdatering. Den endelige pris fastsættes efter auditten. For at holde webshoppen patchet bagefter, se Magento-serviceaftaler.

Kilder (på engelsk): Adobe Experience League: Livscykluspolitik, Systemkrav, Udgivne versioner, Udgivelsesplan, Release notes for Magento Open Source 2.4.9, Upgrade Compatibility Tool; Adobe Developer: Bagudinkompatible ændringer; Understøttede PHP-versioner.