Magento 1.9 in 2026: een oorlogsverhaal uit Antwerpen

De overdracht gebeurde bij een kop koffie op het kantoor van een expediteur in Antwerpen, tussen het laadperron en een stapel douanepapieren. De eigenaar van een delicatessenexporteur met 16 mensen schoof een Post-it over de tafel met één SSH-wachtwoord erop. "De webshop is van jou," zei hij. "Onze laatste developer is in 2019 vertrokken."

We logden die avond in vanaf een keukentafel in Roeselare. Wat we aantroffen was een Magento 1.9.4.1, voor het laatst aangeraakt eind 2020, draaiend op PHP 7.0 achter een nginx die nog steeds een Let's Encrypt-certificaat vertrouwde dat door een script werd vernieuwd dat niemand kon vinden. Stripe was met de hand gepatcht. Cron was al zo lang dood dat de nieuwsbriefqueue 11.400 onverzonden regels had. En de btw-tabel, die de btw stuurde op elke bestelling die het magazijn verliet, had een laatst-gewijzigd tijdstempel van 14 maart 2019.

Zo zag die week eruit.

De staat van Magento 1 in 2026

Magento 1 bereikte end-of-life op 30 juni 2020. Adobe was er duidelijk over: geen security patches meer, geen support, migreer naar Magento 2 of ergens anders heen. Ze kondigden de deadline aan in 2018 en hij is niet verschoven.

Wat dat zes jaar later betekende: een installatie met een stapel ongepatchte CVE's tegen de core, inclusief de SQL-injectieketens die de MageCart-skimwave van 2020 voedden. De shop draaide nog omdat de host een WAF-regel had die de meest voor de hand liggende payloads blokkeerde, en omdat de vorige developer een handvol van de ergste issues met de hand had gepatcht. Gepatcht. Met de hand. In app/code/core/Mage/. Daar komen we nog op terug.

De catalogus: 1.840 SKU's met charcuterie, pralines, koekjes en trappistenbier. Jaarlijkse GMV rond de €2,1M, waarvan ongeveer 64% grensoverschrijdende B2C binnen de EU en 28% B2B intracommunautair. Zo'n €130k per maand liep door de Stripe-integratie die de vorige developer had aangesloten.

De gepatchte Stripe-module

De Stripe-integratie was een fork van een oude community-module uit 2017. De Git-historie eindigde in november 2018. Daarna was elke wijziging een directe edit die nergens werd gecommit; alleen de file mtimes vertelden ons dat er iets was gebeurd.

De patches waren niet kwaadaardig. Ze waren heldhaftig, op de manier waarop een developer heldhaftig is als hem gevraagd wordt een stervend systeem in leven te houden. De vorige engineer had de gepinde Stripe PHP SDK opgehoogd om de TLS-eisen werkend te houden nadat Stripe in 2018 de ondergrens optrok. Hij had de request body met de hand bewerkt om payment_method_types[]=card toe te voegen, omdat de oude Charges API waarschuwingen begon te geven. En hij had het SCA-authenticatiepad in een stille fallback gewikkeld:

// app/code/community/[Vendor]/Stripe/Model/Payment.php
try {
    $charge = \Stripe\Charge::create([...]);
} catch (\Stripe\Error\Card $e) {
    if (strpos($e->getMessage(), 'authentication_required') !== false) {
        // FALLBACK: redirect to a Stripe-hosted page
        // works on some banks, silently drops the cart on others
        $this->_redirectFallback($order);
        return;
    }
    throw $e;
}

Dat laatste blok kostte echt geld. Toen we de orderstabel met het Stripe-dashboard joinden, bleek 7,4% van de geprobeerde EU-kaartbetalingen sinds medio 2021 gestrand bij de 3-D Secure-stap, zonder dat het winkelmandje zich herstelde. De eigen migratiegids van Stripe naar PaymentIntents bestaat niet voor niets: SCA onder PSD2 is sinds 2021 geen optie meer.

Netto-effect op de boeken: zo'n €92k aan orders liep er stilletjes weg, elk jaar. De eigenaar dacht dat de conversie gewoon "de laatste tijd wat lager" was.

De cron die er niet was

Magento 1 heeft cron nodig voor zo goed als alles wat geen page render is. Reindexing, catalog price rules, nieuwsbrieven versturen, abandoned cart e-mails, sitemap-generatie, aggregatie van zoektermen. De cron.sh van de shop zweeg al sinds begin 2023.

De oorzaak was banaal. De hostingprovider had de box tijdens een onderhoudsvenster in 2023 gemigreerd van CentOS 7 naar AlmaLinux 9. De crontab bleef bewaard. De PHP-binary op /usr/bin/php was nu PHP 8.1, niet meer PHP 7.0. De shop draaide op een aparte PHP-FPM-pool die via een pad op 7.0 gepind stond, een pad waar cron niets van wist. Elke cronrun crashte op een strict type warning in een vendor library en eindigde met exit 255. Nergens een log, want de cronregel stuurde stderr naar een pad dat in diezelfde migratie was verwijderd.

*/5 * * * * /usr/bin/php /var/www/shop/cron.php >> /var/log/magento.log 2>&1
# /usr/bin/php is now 8.1, not 7.0
# /var/log/magento.log was deleted in the OS migration
# cron.php throws on PHP 8.1 and exits 255
# no errors visible anywhere

Eén regel crontab. Drie jaar stille uitval. Nieuwsbrieven, abandoned carts, reindex, allemaal dood. De nieuwsbriefqueue was gegroeid naar 11.400 regels. Toen we hem op een staging-kopie reanimeerden en lieten leeglopen, verstuurde hij vier jaar aan "welkom bij onze nieuwsbrief"-mails naar mensen die in hun hoofd allang waren afgehaakt. Dat hebben we niet naar productie laten gaan.

Een btw-tabel bevroren in 2019

Dit was degene waar de eigenaar van moest gaan zitten.

Belgische delicatessen vallen in drie btw-tarieven: 21% voor de meeste chocolade en suikerwerk, 12% voor sommige bereide gerechten, 6% voor onbewerkte boodschappen en de meeste voedingswaren. De lokale core_config_data had de juiste Belgische tarieven nog wel. De grensoverschrijdende regels niet.

Tot 1 juli 2021 werkte verkoop op afstand binnen de EU met een drempel per land, meestal €35.000 of €100.000. Eronder rekende je Belgische btw. Erboven registreerde je je in het land van bestemming en rekende je hun tarief. Voor die wereld klopten de btw-tabellen van 2019.

De OSS-regeling verving dat. Vanaf juli 2021 zakte de drempel naar €10.000 voor de hele EU, en erboven reken je het lokale btw-tarief van de klant en draag je dat af via één kwartaalaangifte One Stop Shop. De Europese Commissie legt de wijziging in gewone taal uit. De shop ging in week drie van januari 2022 over de €10k aan grensoverschrijdende B2C heen, zonder dat het opviel.

Vierenhalf jaar aan bestellingen naar Frankrijk, Duitsland, Nederland en Italië was gefactureerd tegen Belgische btw-tarieven, terwijl dat Franse, Duitse, Nederlandse en Italiaanse tarieven hadden moeten zijn. Soms te veel geheven (Italië op 22% tegen Belgisch 21% op de verkeerde regel). Soms te weinig (Duitsland op 7% verlaagd tegen Belgisch 6%). Toen onze boekhouder de rekensom maakte, kwam het neer op een netto te weinig geheven bedrag van ongeveer €38.000 op de Belgische aangifte, plus een onaangegeven OSS-schuld.

De migratiebeslissing

De eigenaar stelde de vraag die elke eigenaar op dit punt stelt: "Kun je het niet gewoon fixen?"

Het eerlijke antwoord was nee, niet voor lang. We konden de patiënt een kwartaal aan de beademing houden. Een jaar lukte niet zonder ofwel een rebuild, ofwel geld blijven gooien in handmatig patchen van een platform dat al zes jaar dood is. Magento 1 naar Magento 2 migreren is geen migratie in enige zinvolle zin van het woord; de database lijkt, de applicatie is een ander product. Het team had ook de interesse in Magento als merk verloren.

We legden drie paden uit in een memo van één pagina:

1. Nu triageren, binnen vier maanden rebuilden op Shopify. Laagste engineering-kosten, hoogste platformfees, makkelijkste overdracht aan de marketing lead intern.
2. Nu triageren, binnen zes maanden rebuilden op een headless Next.js plus Medusa-stack. Hogere engineering-kosten, volledige controle, geen platformfees behalve hosting.
3. Op Magento 1 blijven, blijven patchen. Dit kwartaal goedkoper. Over twaalf maanden hetzelfde gesprek, met erger samengestelde rente.

Ze kozen voor optie één. Een delicatessenzaak op €2,1M GMV heeft geen custom storefront nodig. Hij moet correct geld innen en de doos op tijd verzenden.

De eerste dertig dagen

Voor er ook maar één regel rebuild-werk werd gedaan, deden we eerst de bloeding-stelpende ronde. Niets ervan is glamoureus. Alles moest eerst gebeuren.

Dag 1 tot 3. Volledige database-dump en een tarball van app/code, skin, media en var. Versleuteld op een externe locatie opgeslagen. Bevestigd dat we beide lokaal in een schone container konden terugzetten. Als de live box in week twee zou omvallen, was dit de rollback.

Dag 3 tot 7. Stripe. We probeerden de integratie niet te migreren. We zetten een Stripe Checkout-redirect ervoor voor nieuwe orders en lieten de bestaande PaymentIntents in het systeem hun werk doen voor refunds en terugkerende authorisaties. SCA-uitval zakte binnen een week onder de 1%.

Dag 5 tot 10. Cron. De crontab herschreven zodat hij precies het PHP 7.0 binary-pad aanriep dat de FPM-pool gebruikte. Logs gericht op een pad dat ook bestond. De indexer een middag lang zien bijwerken. De vier jaar oude nieuwsbriefachterstand stilletjes geleegd zonder hem te versturen.

Dag 7 tot 21. Btw. De kapotte grensoverschrijdende berekening volledig uitgezet en alle EU-B2C-orders door één regel gerouteerd die voor het plaatsen van de order een externe btw-dienst aanriep. Btw-correcties achteraf ingediend bij de boekhouder. Aangemeld voor OSS. De €38k te weinig geheven werd een betalingsregeling, geen boete.

Dag 21 tot 30. Parallel de Shopify-rebuild gestart: theme-scaffolding, catalogus-export, klant-import, Belgische verzendregels. Live cutover gepland voor week 14.

Wat we elke eigenaar van een verouderde shop vertellen

Je hoeft niet in paniek te raken. Je moet kijken. De meeste eigenaren die we ontmoeten hebben in achttien maanden hun Magento-, Drupal- of WordPress-admin niet meer geopend. Ze zijn niet nalatig. Ze runnen een bedrijf. De shop staat in hun ooghoek, hij werkt tot hij niet meer werkt.

De audit van vijf minuten is gratis en kun je vanavond doen:

• Open de admin. Noteer de platformversie. Zoek de EOL-datum ervan op.
• Open de crontab. Zoek de regel die de cron van je shop draait. Voer dat exacte commando met de hand uit. Lees de output.
• Open één order van gisteren en één van drie jaar geleden. Kijk naar de btw-regel. Vergelijk hem met wat je boekhouder voor dat land zou verwachten.
• Open de payment-integratie. Kijk naar de wijzigingsdatums van de bestanden. Kijk naar de versie van de vendor SDK.
• Open het statusarchief van je hostingprovider. Vind het laatste OS- of PHP-upgradevenster. Vraag jezelf af wat niemand daarna heeft getest.

Als één van die vijf je een ongemakkelijk gevoel geeft, heb je het juiste startpunt gevonden.

Toen we deze opdracht voor de Antwerpse exporteur deden, kwamen we steeds bij hetzelfde uit: niets in hun stack viel hardop om. De Stripe-module gooide geen error. De cron gaf geen melding. De btw-tabel zei niets. Stille uitval is de standaardfaalmodus van verouderde commerce, en de enige verdediging is gaan kijken. Wij pakken dit soort legacy-migraties elke keer op dezelfde manier aan: eerst de bloeding stelpen, dan rebuilden op een platform dat hardop faalt als het faalt.

Het kleinste wat je vandaag kunt doen: SSH naar de server van je shop, draai php cron.php met de hand, en lees elke regel die hij print.