Magento 2.4.7-audit: checklist in 90 minuten voor migratie

Het is vrijdagmiddag bij een Nederlandse groothandel die €11M per jaar omzet op Magento 2.4.7. Hun CTO wil maandagochtend een offerte op vaste prijs voor de migratie. Het bestuur heeft de keuze teruggebracht tot Shopware 6 of Shopify Plus, en de doorslaggevende vraag is of we het nieuwe platform parallel kunnen draaien zonder de B2B-quoteflow te breken waar 60% van hun omzet van afhangt.

We beginnen niet met het schrijven van de offerte. We openen de auditchecklist. Het kost ongeveer 90 minuten read-only SSH en nog eens twee uur analyse. Op maandag weten we of de migratie een project van vier maanden of veertien maanden is, en de klant weet waarom.

Dit is die checklist.

Waarom een audit vooraf beter werkt dan een discovery-sprint

Het standaard alternatief is een betaalde discovery van twee weken. Die hebben we genoeg gedaan. Het is eerlijk werk, maar het legt risico bij de klant op precies het moment dat ze dat het minst kunnen dragen: voordat ze beslist hebben of het project überhaupt de moeite waard is. Een korte gestructureerde audit beantwoordt de drie vragen die echt iets doen met het offertebedrag.

• Wat is de blast radius van elke third-party module die we moeten houden, porten of herbouwen?
• Hoeveel EAV-bloat zit er verstopt in de catalogus, en kost het een week dataschoonmaak of drie maanden?
• Welke Hyvä-frontend-overrides zijn dragend voor een B2B-flow die het doelplatform anders afhandelt?

De audit levert geen ontwerp. Het levert een verdedigbaar getal. Daar gaat het om.

Stap 1: bus-factor van third-party modules

De eerste SSH-sessie gaat direct naar app/code/ en de composer.lock. We lezen nog geen code. We scoren elke module op drie assen: hoe dood is de leverancier, hoe diep zit de integratie, en hoe vervangbaar is de functie.

Dit is het read-only commando dat we als eerste draaien, na een verse DB-dump voor de zekerheid.

cd /var/www/html
bin/magento module:status --enabled \
  | grep -v '^Magento_' \
  | grep -v '^None
 \
  | sort -u > /tmp/third-party-modules.txt

# Composer-tracked modules and their last-release date
jq -r '.packages[] | select(.type=="magento2-module") | "\(.name) \(.time)"' \
  composer.lock | sort -k2 > /tmp/module-ages.txt

Nu gaan we scoren. Een module heeft een hoge bus-factor als de leverancier in de laatste zes maanden een release heeft uitgebracht, een eigen Hyvä-compatibiliteitsmodule levert, en een publieke issue tracker heeft met afgesloten tickets in de laatste maand. Een module heeft een lage bus-factor als de laatste release uit 2023 stamt, de GitHub-repo gearchiveerd is, of de module in het wild rondzwerft als een fork waar niemand eigenaar van is. Mirasvit, Amasty en Aheadworks scoren meestal hoog. De marketplace-vondsten van €49 scoren meestal laag.

We letten extra op modules die de quote-, checkout- en pricingflow raken. Een dode "request a quote"-module op een B2B-site is geen porteerprobleem; het is het kritieke pad van de migratie.

Stap 2: EAV-attribuut-bloat, gemeten en niet geschat

De EAV-catalogus van Magento staat bekend om één ding: agencies die hem tien jaar lang open lieten staan. Elk veld per product dat in 2018 voor een campagne werd toegevoegd, bleef staan. Het resultaat is een catalog_product_entity_*-tabelset die het migratiedoel weigert netjes te modelleren.

We meten dat voor we offreren. Twee queries, gedraaid tegen een read-replica of een lokaal teruggezette dump.

-- How many product attributes do they actually use?
SELECT
  ea.attribute_code,
  ea.backend_type,
  COUNT(DISTINCT cpe.entity_id) AS products_with_value
FROM eav_attribute ea
JOIN catalog_eav_attribute cea ON cea.attribute_id = ea.attribute_id
LEFT JOIN catalog_product_entity_varchar cpe
  ON cpe.attribute_id = ea.attribute_id
WHERE ea.entity_type_id = 4
GROUP BY ea.attribute_code, ea.backend_type
ORDER BY products_with_value DESC;

-- How many user-defined attributes carry data on under 1% of the catalog?
SELECT COUNT(*) AS dead_attributes
FROM eav_attribute ea
JOIN catalog_eav_attribute cea ON cea.attribute_id = ea.attribute_id
WHERE ea.entity_type_id = 4
  AND cea.is_user_defined = 1;

Op een typisch Nederlands bestand onder €20M zien we 180 tot 400 user-defined productattributen, waarvan er 30 tot 60 echte data dragen op meer dan 5% van de catalogus. De rest is migratiekost. Shopware 6 mapt de levende attributen netjes op zijn custom_field-systeem. Shopify Plus mapt ze op metafields, plus een belasting op elke storefront-query die ze aanraakt. Het aantal levende attributen is daarmee een van de grootste drivers van het platformadvies dat we uiteindelijk uitschrijven.

Stap 3: Hyvä-overrides die bij cutover gaan bijten

Hyvä Themes is het juiste antwoord voor bijna elk Magento-bestand dat nog twee jaar op Magento wil blijven. Het is alleen lastig te auditen, want elke override waar de klant voor betaald heeft, is nu een stuk businesslogica dat het migratiedoel moet erven.

Het patroon waar we naar zoeken zijn overrides onder app/design/frontend/<Vendor>/<theme>/Magento_Checkout/, Magento_Quote/, en Magento_NegotiableQuote/. Op een B2B-site zijn de gevaarlijke niet de visuele aanpassingen. Het zijn degene die de cart-payload onderscheppen voordat die het quote-endpoint raakt.

# Find every override of a checkout or quote component
find app/design/frontend -type f \
  \( -path '*Magento_Checkout*' -o -path '*Magento_Quote*' \
     -o -path '*Magento_NegotiableQuote*' \) \
  \( -name '*.phtml' -o -name '*.js' -o -name '*.xml' \) \
  | xargs -I{} sh -c 'echo "=== {} ==="; head -5 "{}"'

We lijsten elke override en stellen de klant per bestand één vraag: "Als we dit bestand morgen weggooien, wie belt er dan support?" Is het antwoord "de inkoopmanager bij onze grootste klant", dan wordt dat bestand een acceptatietest-fixture voor het nieuwe platform, geen porteren-of-niet-vraag. We hebben phtml-bestanden van zes regels gezien die stilletjes coderen: "als de klantgroep wholesale is en het ordertotaal boven €5k komt, route via het negotiable-quote-endpoint in plaats van de standaardcheckout." Dat soort logica moet het migratiedoel leren vóór parallel run, niet tijdens.

Stap 4: het parallel-run-cutoverplan, in drie kolommen

Zodra de eerste drie stappen klaar zijn, tekenen we een eenvoudige tabel. Drie kolommen: flow, bron van waarheid tijdens parallel run, cadans van reconciliatie. Voor de meeste B2B-sites onder €20M heeft het antwoord dezelfde vorm.

• Catalogus: de bron van waarheid verhuist op dag één naar het nieuwe platform. Magento wordt een read-only spiegel, gevoed door een nachtelijke export.
• Orders: de bron van waarheid blijft de eerste vier weken op Magento. Orders die op het nieuwe platform worden geplaatst, repliceren terug naar Magento via een webhook naar een custom REST-endpoint. Finance houdt één grootboek om tegen te reconciliëren.
• Quotes: hier gaat het mis. De B2B-quoteflow draagt te veel klantspecifieke logica om betrouwbaar dual-write te kunnen doen. Het eerlijke antwoord is om bij cutover-uur nul nieuwe quote-aanmaak op Magento te bevriezen en vanaf minuut één elke nieuwe quote via het nieuwe platform te routeren, met een rollback-venster van 72 uur.

De auditchecklist levert dat plan niet in zijn eindvorm. Hij levert genoeg bewijs dat we, op het moment van offreren, weten of die freeze-en-route een oefening van één weekend is of een veranderingstraject van zes weken.

Stap 5: de versie- en security-check

De laatste kolom op de checklist: waar zit het bestand eigenlijk op de patchlijn van Magento 2.4.7? Adobe leverde 2.4.7 in maart 2024 en de patchcadans is sindsdien stabiel. We controleren de draaiende versie, de PHP-versie, de OpenSearch-versie, en of het bestand ooit de security-only patches heeft toegepast.

bin/magento --version
php -v
curl -s "$ES_HOST:9200" | jq .version.number
composer show magento/product-community-edition | grep versions

Vinden we een 2.4.7-p0 op PHP 8.2 zonder dat er sinds release security patches zijn toegepast, dan krijgt de migratieofferte een regel "eerst stabiliseren". Je migreert niet van een brandend platform; je blust eerst en migreert dan rustig. Dit jaar zijn we weggelopen van een project omdat de klant die regel wilde overslaan en wij de uitkomst niet wilden bezitten.

Wat de audit ons kost en wat hij de klant bespaart

De audit van 90 minuten plus de write-up van twee uur kost ons een halve dag senior engineering per prospect. Ongeveer één op de drie audits leidt tot een project. De andere twee derde bevestigen of dat de klant nog een release-cyclus op Magento moet blijven, of ze leggen een probleem bloot waardoor de migratie commercieel nog niet haalbaar is. Beide uitkomsten zijn prima. De audit is geen verkoop-tool; het is een filter dat ons ervan weerhoudt werk te offreren dat we niet kunnen leveren voor een prijs die we niet waar kunnen maken.

Toen we de Shopware 6-migratie bouwden voor een Rotterdamse groothandel in bouwmaterialen, ving de audit een Mirasvit-module af die dragend was voor hun BTW-verlegde EU-exports en geen Shopware-equivalent had. We besteedden de eerste twee sprints aan het porten van die logica naar een Shopware-plugin voordat we de storefront aanraakten. Dat soort beslissingen wil de audit bovenwater krijgen. Zit je zelf op een Magento-bestand en wil je een second opinion voor je de RFP schrijft, dan is dit een snee uit ons werk in legacy-migratie.

De versie van één pagina

Doe je vandaag maar één ding, open dan een SSH-sessie tegen je staging-omgeving en draai de twee SQL-queries uit stap 2. Het aantal productattributen dat data draagt op meer dan 5% van je catalogus is op zichzelf het meest bruikbare getal over migratie-gereedheid dat je in tien minuten kunt produceren.