Magento migratie zonder downtime in 7 stappen

Een checkout die tijdens een druk verkoopmoment wegvalt, kost meer dan directe omzet. Campagnes lopen door, klanten haken af en de klantenservice krijgt vragen die voorkomen hadden kunnen worden. Een Magento migratie zonder downtime draait daarom niet om één slimme DNS-wijziging, maar om een gecontroleerd proces waarin de bestaande shop verkoop blijft draaien totdat de nieuwe omgeving aantoonbaar klaar is.

Dat vraagt om technische discipline én heldere commerciële keuzes. Migreer je alleen hosting, of ook Magento-versie, thema, extensies en processen? Hoe meer onderdelen tegelijk veranderen, hoe groter de kans dat je een fout pas na livegang ziet. Tegelijk is een migratie juist het moment om oude ballast op te ruimen. De kunst is om vernieuwing door te voeren zonder klanten onderdeel van de test te maken.

Magento migratie zonder downtime begint met scope

Noem eerst precies wat er migreert. Een verhuizing van Magento 2 naar nieuwe managed hosting is iets anders dan een overgang van Magento 1, een nieuw Hyvä-front-end en een vervanging van ERP-, PIM- of betaalintegraties. Bij een beperkte infrastructuurmigratie ligt de nadruk op omgevingsgelijkheid en omschakeling. Bij een grotere replatforming komt daar functionele validatie, datamigratie en SEO-behoud bij.

Maak die scope niet mooier dan hij is. Een volledig nieuw thema kan bestaande conversieproblemen oplossen, maar introduceert ook nieuwe scenario's in navigatie, filtering, bundels en checkout. Een kritieke extensie behouden lijkt veilig, maar kan performance, compatibiliteit of veiligheid beperken. Kies bewust wat mee moet, wat vervangen wordt en wat je na livegang in een aparte release uitvoert.

Breng daarnaast alle afhankelijkheden in kaart: domeinen, DNS, CDN, e-mail, betalingsproviders, verzendmethoden, voorraadkoppelingen, feedmanagement, analytics, tagmanagement, zoekfunctie en externe API's. De meeste migraties lopen niet vast op Magento zelf, maar op een vergeten koppeling buiten Magento.

1. Bouw een productiegelijke parallelle omgeving

De nieuwe omgeving moet Magento niet alleen kunnen installeren, maar ook onder realistische belasting kunnen draaien. Gebruik dezelfde PHP-versie, databaseconfiguratie, Elasticsearch of OpenSearch-configuratie, Redis-inrichting, cronjobs, queues en cachelagen als je voor productie nodig hebt. Richt monitoring, back-ups, logging en toegangsrechten vooraf in.

Een tijdelijke URL is geschikt voor technische controles, maar test ook met het beoogde domein voordat je omschakelt. Denk aan cookies, redirects, betaalmethoden, webhooks en securityregels die domeingebonden zijn. Een preview die er goed uitziet, is nog geen productieshop.

2. Migreer data in lagen, niet in één grote sprong

Begin met relatief statische gegevens: categorieën, producten, attributen, CMS-content, klantgroepen en configuratie. Daarna volgen dynamische gegevens zoals klanten, adressen, orders, voorraad en reviews. Welke data je daadwerkelijk meeneemt, hangt af van wettelijke bewaartermijnen, klantenserviceprocessen en rapportagebehoefte.

De eerste dataload is een oefening, geen livegang. Vergelijk aantallen, controleer productvarianten, prijzen, media, URL-rewrites en rechten van klantaccounts. Let extra op gecodeerde wachtwoorden: die kunnen vaak alleen correct worden overgezet als de hashing en authenticatielogica compatibel zijn. Is dat niet het geval, communiceer dan vooraf dat klanten bij een eerste bezoek een wachtwoord opnieuw moeten instellen.

Na de initiële migratie blijft de oude shop verkopen. Daarom heb je een deltasynchronisatie nodig voor mutaties die in de tussentijd ontstaan, zoals nieuwe orders, voorraadwijzigingen, klanten en nieuwsbriefinschrijvingen. Zonder die stap kies je op het laatste moment tussen omzet missen of data handmatig herstellen.

3. Test klantreizen, niet alleen losse pagina's

Een homepage, PDP en categoriepagina die laden, zeggen weinig over de echte kwaliteit. Test de routes die omzet en operatie raken: zoeken, filteren, varianten kiezen, kortingscodes, gastcheckout, accountaanmaak, retourinformatie, facturatie, orderbevestigingen en terugbetalingen. Test op mobiel, desktop en in de browsers die jouw doelgroep gebruikt.

Werk met echte, afgebakende testscenario's. Plaats bijvoorbeeld een bestelling met een korting en een afwijkend afleveradres, verwerk die in het ERP en controleer de statusmail. Doe hetzelfde voor een product met lage voorraad, een B2B-prijsafspraak of een bundel als die voor jouw shop relevant is. Zo controleer je de hele keten in plaats van alleen de Magento-interface.

Performance verdient dezelfde aandacht. Cache warmen, indexeren en media optimaliseren doe je voor de launch, niet terwijl de eerste klanten al binnenkomen. Een moderne Hyvä-storefront kan veel onnodige front-endcomplexiteit wegnemen, maar een trage API, slecht ingestelde cache of zware third-party scripts blijft een risico.

4. Bescherm SEO voordat je het domein omzet

URL-structuren, metadata en canonicals zijn vaak stiller dan een checkoutfout, maar de schade ervan zie je maanden later in organisch verkeer. Maak daarom een crawl van de bestaande shop en leg alle belangrijke URL's vast. Controleer vervolgens of product-, categorie-, CMS- en filterpagina's op de nieuwe omgeving dezelfde bestemming, statuscode en indexatie-instructies krijgen.

Wijzigt een URL toch, gebruik dan een permanente 301-redirect naar de meest relevante nieuwe pagina. Stuur niet alles naar de homepage. Controleer ook structured data, hreflang waar van toepassing, XML-sitemaps, robots.txt en de instellingen in analytics en tagmanagement. Een nieuwe omgeving met een staging-blokkade die per ongeluk actief blijft, is een klassiek en kostbaar incident.

5. Kies een omschakelmoment met voldoende rust

Zonder downtime betekent niet dat niemand iets merkt. Tijdens de cutover kan een enkele sessie opnieuw laden, kan een DNS-record nog kort in cache staan of moet een klant opnieuw inloggen. Het doel is dat de shop beschikbaar blijft en dat transacties niet verloren gaan.

Kies een moment met relatief weinig verkeer, maar zorg dat de juiste mensen beschikbaar zijn. Vermijd een cutover vlak voor Black Friday, een grote campagne, een collectie-release of een ERP-wijziging. Verlaag de TTL van DNS-records ruim vooraf, zodat de wijziging sneller wordt opgepakt. Doe dat niet minuten voor de livegang: bestaande resolvers houden de oude waarde dan gewoon vast.

Zet vlak voor de switch de laatste datadelta over. Controleer daarna in de nieuwe omgeving orders, voorraad en betalingswebhooks opnieuw. Afhankelijk van de integratie kun je de oude shop kort in een beperkte onderhoudsmodus zetten voor backoffice-mutaties, terwijl klanten naar de nieuwe productieomgeving gaan. Dat is iets anders dan de volledige webshop offline halen.

6. Werk met een expliciet go/no-go-moment en rollback

Een lancering zonder eigenaar is een risico. Leg vast wie technisch de switch uitvoert, wie betalingen test, wie voorraad en orderverwerking controleert en wie de communicatie met stakeholders verzorgt. Maak ook vooraf duidelijk wanneer je niet live gaat. Een openstaand probleem in checkout, prijzen, voorraad of verzending is een reden om uit te stellen, hoe strak de planning ook is.

Een rollbackplan is geen gebrek aan vertrouwen, maar professioneel risicobeheer. Bewaar de oude omgeving gedurende een afgesproken periode beschikbaar, met een recente databaseback-up en een duidelijke procedure om DNS of routing terug te zetten. Bepaal vooraf welke signalen rollback rechtvaardigen, bijvoorbeeld foutieve orderverwerking of een storing bij een betaalprovider.

7. Behandel de eerste 48 uur als onderdeel van de migratie

Na de switch begint het bewijs. Monitor foutmeldingen, responstijden, conversie, betaalresultaten, zoekopdrachten, voorraadmutaties en orderdoorloop. Vergelijk die signalen met een normale periode, niet alleen met de uren direct voor livegang. Een verschil in omzet kan een campagne-effect zijn, maar ook een kapotte trackingtag, prijsregel of betaalmethode.

Laat marketing in deze fase vooral snel kunnen handelen. Landingspagina's, banners en campagnecontent moeten niet wachten op een development-sprint. Daar zit een praktisch voordeel van een geïntegreerde Magento- en Hyvä-stack: techniek, hosting en visuele contentcreatie zijn op elkaar afgestemd, zodat wijzigingen na livegang beheersbaar blijven. MageRex combineert die onderdelen in één maandabonnement, inclusief support en managed hosting.

Wanneer is nul downtime niet realistisch?

Soms is een korte onderhoudsperiode de verstandigste keuze. Bijvoorbeeld wanneer een complexe maatwerkkoppeling geen betrouwbare deltasynchronisatie ondersteunt, wanneer een database ingrijpend moet worden herstructureerd of wanneer PCI- en betaalinstellingen opnieuw gevalideerd moeten worden. Een gepland venster van enkele minuten is beter dan doen alsof er geen risico bestaat en vervolgens uren herstelwerk uitvoeren.

De juiste belofte is dus niet dat er letterlijk nooit een hapering kan optreden. De juiste belofte is dat je omzet, orders en klantvertrouwen beschermt met een parallelle omgeving, herhaalbare controles en een team dat weet wat het doet. Zo wordt een Magento-migratie geen spannend nachtelijk project, maar een beheersbare stap naar een snellere shop die klaar is voor de volgende groeifase.