Van Magento naar Shopify: wat je meeneemt, wat je achterlaat, en waarom dat de hele migratie is

Elke Magento-update voelt als een nieuw project. Een module-update lijkt klein, maar vraagt developer-uren, een regressietest en soms een fix die niemand had voorzien. Een kleine wijziging op de productpagina wordt een ticket, omdat alleen de developer die de shop kent erbij durft. En hosting, caching, security en patches zijn jouw verantwoordelijkheid, ook als je ze hebt uitbesteed.

Dat is de reden dat Magento-shops naar ons toe komen. Niet omdat Magento slecht is. Omdat ze betalen voor complexiteit die ze niet meer gebruiken, en omdat de shop commercieel stilstaat terwijl het onderhoudsbudget wel doorloopt.

Dit is de gids die we zelf hadden willen lezen voordat we onze eerste migratie deden. Geen stappenplan voor een import, want een import is het kleinste deel. Wel de keuzes die bepalen of je over een jaar blij bent met de overstap.

Wanneer Magento nog wél klopt

Eerlijk is eerlijk: er zijn shops die op Magento horen. Een catalogus met tienduizenden artikelen en diep maatwerk in prijsregels, een ERP-landschap waar Magento de spil in is, een B2B-operatie met logica die in jaren is opgebouwd en die commercieel nog waarde heeft. Voor die shops is Magento de vrachtwagen die ze nodig hebben.

De vraag is dus niet Magento of Shopify. De vraag is welke Magento-complexiteit nog geld oplevert. Als het antwoord is: de modules die we ooit lieten bouwen omdat het toen kon, en die nu vooral updates blokkeren, dan is dat het moment om de platformkeuze opnieuw op tafel te leggen. Zelfde als de laatste upgrade meer kostte dan je in een kwartaal aan doorbouwen uitgeeft.

Tegenwerping die we vaak horen: Shopify is te beperkt. Soms klopt dat. Vaker gaat het om mogelijkheden die de vrager niet kent: metafields en metaobjects voor productdata, Functions voor prijs- en checkoutlogica, native B2B, Markets voor meerdere landen. Niet elke Shopify-beperking is Shopify. Een deel is gewoon een andere manier van bouwen.

Waar de kosten van Magento echt zitten

De licentie is zelden het probleem, zeker niet bij Magento Open Source. De kosten zitten in wat eromheen hangt: hosting die op piekmomenten moet meeschalen, een developer of bureau dat patches en versie-upgrades bijhoudt, extensies met eigen licenties en eigen updatecycli, en de uren die weglekken in regressietesten na elke wijziging. Op fora en in gesprekken met Magento-eigenaren komt steeds hetzelfde beeld terug: een versie-upgrade wordt geoffreerd als een project, en voor een kleine of middelgrote shop is dat project groter dan de shop.

Bij Shopify verdwijnt die hele laag. Hosting, security, updates en schaal zijn onderdeel van het abonnement. Wat overblijft is het werk dat over jouw shop gaat: het datamodel, de checkoutlogica, het thema. Dat is geen belofte dat Shopify goedkoper is; dat hangt af van je transactievolume, je plan en de apps die je alsnog nodig hebt. Het is wel een verschuiving van onderhoud naar bouwen, en dat is wat de meeste teams zoeken.

Er komt een nieuw argument bij dat we een jaar geleden niet noemden. AI-assistenten en zoekmachines lezen productdata steeds directer: categorie-metafields, structured data, reviews als gestructureerde velden. Een schoon datamodel op Shopify is daar klaar voor. Een Magento-catalogus met tien jaar attribuutgroei meestal niet, en dat verhuist niet vanzelf mee.

Platformschuld: wat je niet meeneemt

Het grootste risico van een migratie is niet dataverlies. Het is dat je oude platformschuld meeverhuist. Elke module die ooit een gat dichtte, elke workaround die normaal is geworden, elk attribuut dat in 2019 nog logisch was. Wie alles wil meenemen, bouwt zijn oude Magento na in Shopify, met dezelfde beheerlast als resultaat.

Daarom begint elke migratie bij ons met een lijst in drie kolommen: houden, vertalen, laten liggen. Voor Magento ziet die lijst er meestal zo uit.

Custom modules worden native waar het kan. Kortingslogica, verzendregels en betaalregels die nu in modules zitten, gaan naar Shopify Functions. Die draaien in de checkout zelf en updaten niet stuk. Wat er niet in past, wordt een kleine eigen app of blijft bewust achter.

Attribute sets worden metafields en metaobjects. Magento's kracht is de datastructuur per producttype. Shopify heeft daar een net antwoord op: metafield-definities per categorie, metaobjects voor alles wat op meerdere producten terugkomt (merk, materiaal, serie, configuratie). Het verschil is dat je die structuur nu bewust opnieuw ontwerpt, en dat is precies waar je de verzameling ongebruikte attributen kwijtraakt.

Configurable products worden varianten. De oude beperking van honderd varianten per product is weg: Shopify staat inmiddels tot 2.048 varianten per product toe. De opgeknipte producten en variant-apps die shops daarvoor bouwden, hoeven dus niet mee.

Multi-store wordt een keuze. Magento-shops draaien vaak meerdere storeviews voor landen en talen. Op Shopify zijn dat óf markten binnen één shop (talen, valuta, verzendregels per land) óf aparte stores. Welke van de twee hangt af van hoeveel assortiment en prijsbeleid de landen delen. Dat is een besluit, geen technisch detail.

Een module die checkout, prijzen of voorraad raakt, is geen add-on. Het is platformlogica. Die verdient de meeste aandacht in de vertaalkolom, en de meeste argwaan als iemand zegt dat er wel een app voor is.

De migratie als decision map

Een migratie is vooral een reeks besluiten met een import erachter. Wij zetten die besluiten vooraf op één kaart, zodat niemand ze tijdens de bouw hoeft te nemen. Dit zijn de vijf gebieden.

Data. Producten, varianten, collecties, klanten, orders, reviews, en de velden die nergens standaard in passen. Orderhistorie kan mee, zodat klanten hun oude bestellingen zien en je rapportages doorlopen. Klantwachtwoorden kunnen dat niet: die zijn versleuteld opgeslagen en niet over te zetten. Klanten krijgen een nieuw account op hun bestaande e-mailadres, en hoe je dat aankondigt is onderdeel van de launch, niet een verrassing erna.

URL's en SEO. Magento-URL's zien er vaak uit als /catalog/product/view/id/123 of hebben een eigen structuur met categoriepaden. Shopify gebruikt /products/handle en /collections/handle. Elke oude URL die verkeer of backlinks heeft, krijgt een 301 naar zijn nieuwe adres, en de lijst daarvan maak je vóór de bouw, uit Search Console en je analytics, niet de avond voor livegang. Titels, meta descriptions, structured data en interne links gaan in dezelfde map.

Checkout en betaalmethodes. iDEAL, creditcard, achteraf betalen, en de regels eromheen: wie krijgt welke methode, welke korting stapelt met welke. Op Magento zit dat in modules, op Shopify in Functions en checkout-instellingen. Dit is de plek waar we het langst stilstaan, omdat hier de omzet doorheen loopt.

Integraties. ERP, PIM, boekhouding, fulfilment, feeds. Per koppeling één vraag: wie is de bron van de waarheid voor voorraad, prijs en productdata? Magento-koppelingen zijn vaak op maat gebouwd en verwachten Magento's datamodel. Op Shopify werk je met de API of met een bestaande connector, en soms is de migratie het moment om een koppeling die niemand meer snapt te vervangen.

Timing. Niet migreren in je piekseizoen. Een livegang in oktober voor een shop die in november en december zijn jaar maakt, is een gok die niemand hoeft te nemen. Kies een rustige periode, plan de cutover op een dag met weinig verkeer, en houd de oude omgeving een paar weken beschikbaar als terugvaloptie.

“Het doel is niet live op Shopify. Het doel is live op Shopify zonder je oude platformschuld mee te verhuizen.”

Hoe de import zelf loopt

De import is het kleinste deel, maar hij moet wel kloppen. Producten en klanten komen als export uit Magento (System, Data Transfer, Export) of rechtstreeks via de API. Wij normaliseren die data eerst naar het nieuwe model: welke Magento-attributen worden welk metafield, welke configurables worden welke variantopties, welke categorieën worden collecties en welke worden een filter. Pas daarna gaat er iets richting Shopify, via de Admin API of via een import-tool, in een testshop, niet in productie.

Orders gaan als historie mee, gekoppeld aan de klant, zodat de klant zijn bestellingen ziet en je rapportages doorlopen. Reviews gaan mee als de review-app op Shopify ze kan importeren of als we ze in metaobjects zetten. Content (blogs, pagina's) wordt opgeschoond onderweg: oude paginabuilder-markup wordt schone HTML, en dit is meestal het moment waarop de helft van de blogartikelen bewust achterblijft.

Alles draait als script dat je opnieuw kunt uitvoeren. Een migratie doe je niet één keer; je doet hem drie keer op een testshop, en de vierde keer live, met de laatste orders en klanten als delta. Zo blijft de oude shop tot de cutover gewoon verkopen.

Hoe de livegang eruitziet

De livegang is geen datum, het is een procedure. Redirects staan klaar en zijn getest op de belangrijkste URL's. Tracking is opnieuw ingericht en gecontroleerd, want analytics en advertenties breken stil: het verkeer blijft gelijk terwijl de omzet zakt, en pas weken later blijkt dat de pixel nooit vuurde. De checkout is met echte betaalmethodes doorlopen. De feeds naar Google Shopping zijn ververst. Er is een go/no-go-moment en een terugvalplan.

Na livegang volgt een stabilisatieperiode waarin we Search Console, orders en de belangrijkste flows dagelijks nalopen. Daarna is de shop van jou, met documentatie van de keuzes, de mappings en de punten die bewust open zijn gelaten.

Wat er verandert in het beheer

Dit is het deel dat Magento-teams het meest onderschatten, in positieve zin. Updates, hosting, security en patches zijn geen werk meer. De marketeer past zelf de productpagina, de collectie en de content aan in de editor. Nieuwe acties zijn een kortingsregel en een datum, geen ticket. Wat wel developerwerk blijft: Functions, maatwerk-apps en het datamodel. Dat is precies het werk dat waarde toevoegt, en niet het werk dat de shop overeind houdt.

Superfoodstore.nl kwam van PrestaShop, een open-source platform met hetzelfde onderhoudsverhaal als Magento: elke update een technische keuze, elke uitbreiding een module. Na de overstap is de vraag niet meer of een update veilig is, maar wat het team deze maand wil bouwen.

Zeven vragen vóór je begint

Welke Magento-complexiteit levert commercieel nog iets op: B2B-prijslijsten, de catalogusstructuur, de multi-store, een ERP-koppeling? Welke modules zijn bedrijfskritisch en welke zijn er ooit bij gekomen? Wat kostte de laatste upgrade of patchronde, in euro's en in weken? Welke wijzigingen blijven liggen omdat er een developer voor nodig is? Wie is intern eigenaar van de besluiten over data, SEO, content en checkout? Wanneer is je rustigste periode van het jaar? En wat mag er bewust niet mee?

Als je die zeven kunt beantwoorden, heb je de helft van de decision map al. Als de vijfde vraag geen antwoord heeft, is dat de eerste die je oplost, want zonder interne eigenaar wordt elke migratie een import met een rekening.

Wat het kost en waar je begint

Een Magento-migratie zit bij ons vrijwel altijd in het complexe traject, omdat data, integraties en checkoutlogica zwaarder zijn dan bij een WooCommerce-shop. Wat een migratie kost en hoe de tracks zijn opgebouwd, staat in de gids over migratiekosten. Begin in elk geval niet met een offerte voor de bouw, maar met de decision map: welke complexiteit moet overleven, wat mag weg, en wat wordt native. Dat document is ook bruikbaar als je uiteindelijk bij een ander bureau bouwt.

En begin niet bij de laatste dag. Begin bij de lijst van modules, de laatste upgrade-factuur en de wijzigingen die al maanden liggen te wachten. Als die drie samen een verhaal vertellen, weet je genoeg.