WooCommerce naar Shopify: acht valkuilen na de cutover

Om 02:17 verloopt eindelijk de DNS TTL op de oude A-record en wordt de nieuwe Shopify-storefront de canonieke waarheid. Het winkelmandje op staging had elke test doorstaan. De redirect-map zag er compleet uit in het spreadsheet. Het team ging naar bed. Om 09:00 staan er 312 wachtwoord-resetverzoeken in de support-inbox, vraagt finance waarom ordernummers opnieuw beginnen bij #1001, en piept Search Console over 404's op URL's waar niemand sinds 2019 nog aan heeft gedacht.

Dit is het deel van een WooCommerce-naar-Shopify-migratie waar niemand over schrijft. De cutover zelf is saai. De week erna is waar de rekening valt. Hieronder een veldgids voor de acht dingen die misgaan na de cutover, op volgorde van hoeveel nachten slaap ze een echt team hebben gekost. We hebben deze migratie meer dan tien keer gedaan, in meubels, supplementen en B2B-onderdelen. De volgorde hieronder is de volgorde van pijn.

1. De stortvloed aan wachtwoord-resets

WooCommerce slaat klantwachtwoorden op als phpass-hashes (hetzelfde schema dat WordPress gebruikt). Shopify gebruikt bcrypt en accepteert een phpass-hash niet bij de standaard klantenimport. Elke terugkerende klant wordt uitgelogd wakker en kan niet inloggen. Ze klikken op "wachtwoord vergeten" en je transactionele e-mailstack, die ook nieuw is en waarschijnlijk nog warmloopt, smelt.

De oplossing is niet technisch, het is een communicatieplan. Zet vóór de cutover een "we zijn verhuisd, hier is een magic link met één klik"-mail klaar voor elke klant met een recente bestelling. Spreid de verzending per regio om de support-druk te verdelen. Vervang na de cutover de standaard Shopify wachtwoord-resetmail door één die de verhuizing in twee zinnen uitlegt, in gewone taal. Schrijf alvast drie macro's voor je supporttool: "ik heb mijn account meegenomen maar mijn bestelling is weg", "de magic link is verlopen", "ik heb de mail nooit gekregen". Je hebt ze alle drie nodig op dinsdag.

2. De redirect-map die geen map was

De meeste teams maken een redirect-map door de oude site te crawlen, /shop/product-slug af te lopen, die te mappen naar /products/handle en zich klaar te voelen. Ze missen elke keer vier categorieën URL.

• Categorie- en tag-archieven: /product-category/lighting/, /product-tag/oak/.
• Gepagineerde archieven: /shop/page/4/.
• Oude blogposts die linkten naar producten die niet meer bestaan.
• UTM-gevulde ad-URL's die klantenservice nog steeds in mails plakt.

De URL Redirects-tool van Shopify accepteert een CSV maar staat per regel maar één source-to-target paar toe, geen wildcards. Je eindigt met een bestand van 4.000 regels. Genereer 'm, typ 'm niet. Crawl de oude site met Screaming Frog of Sitebulb vóór de DNS-flip, exporteer elke interne URL, en schrijf dan een klein script dat elke URL mapt naar het Shopify-equivalent en "/" wegschrijft voor wat je niet kunt oplossen. Die "/"-regels zijn niet lui. Ze zijn een bewuste keuze om verweesd verkeer terug te kaatsen naar de homepage, in plaats van een 404 te serveren die Google vervolgens indexeert.

Verwijs oude product-URL's niet door naar categoriepagina's "omdat ze op elkaar lijken". Google behandelt dat binnen zes weken als een soft 404 en je verliest precies de linkwaarde die je wilde meenemen.

3. EU-btw en OSS die stilletjes uit compliance glijden

Verkoop je aan EU-consumenten, dan zit je in de One Stop Shop-regeling en deed je oude WooCommerce-stack waarschijnlijk de berekening met een btw-plugin. Shopify Tax pakt dit anders aan. De tariefstabellen kloppen, maar de drempellogica en de manier waarop Shopify B2B-reverse-charge facturen behandelt zijn niet hetzelfde als bij de WooCommerce EU VAT Number-extensie.

De val: Shopify rekent vrolijk 21% Nederlandse btw aan een Duitse B2B-klant met een geldig btw-nummer, omdat de vrijstellingsregels per klant of per markt geconfigureerd moeten worden. Tot je dat aan Shopify vertelt, is elke grensoverschrijdende B2B-order fout. Controleer de eerste tien zulke orders met de hand. Klopt de btw-regel niet, dan beschadig je niet alleen het vertrouwen van de klant, je dient drie maanden later ook een verkeerde OSS-aangifte in en mag dat aan je accountant uitleggen.

4. Abonnementen waarvan je vergat dat het abonnementen waren

WooCommerce Subscriptions zit bovenop WC en koppelt terugkerende facturatie aan de opgeslagen betaalmethode van de klant. Niets daarvan mapt schoon naar Shopify. De nieuwe winkel heeft een abonnementen-app nodig (Recharge, Bold, Skio, of Shopify's eigen Subscriptions API). Het grotere probleem is de payment vault: het verhuizen van recurring tokens van je oude gateway naar de nieuwe vereist meestal dat de klant opnieuw autoriseert.

Bouw vóór de cutover een spreadsheet met elk actief abonnement, de volgende factuurdatum, de frequentie en het product. Behandel de eerste factuurcyclus na de cutover als handwerk. Mail elke abonnee de dag voor de volgende afschrijving even kort dat het eraan komt, met een één-klik-link om hun kaart op de nieuwe winkel te bevestigen. Sla je deze stap over, dan wordt een onvrijwillige churn van 5% in de eerste maand 25%.

5. Transactionele e-mail die in spam belandt

Je oude winkel verstuurde via WP Mail SMTP of een Postmark- of SendGrid-plugin. Het verzenddomein had DKIM- en SPF-records die naar die provider wezen. Shopify verstuurt transactionele mail via zijn eigen infrastructuur, en als je niet vóór de eerste order de sender-authentication CNAMEs instelt, gaan de wachtwoord-reset- en orderbevestigingsmails direct naar het tabblad Reclame in Gmail, of erger.

Zet de Shopify CNAMEs minstens 48 uur vóór de cutover, niet de avond ervoor. DNS-propagatie plus DMARC-rapportagevertraging betekent dat je pas een dag later weet of je mail überhaupt in de inbox landt. Houd het dashboard op postmaster.google.com de eerste twee weken in de gaten en behandel elke dip in inbox-plaatsing als een P1.

6. Cadeaubon-saldo dat achterblijft op de oude database

Cadeaubonnen zijn het migratie-item dat niemand op het spreadsheet zet, omdat niemand eraan denkt totdat een klant mailt. WooCommerce slaat saldo's op in een custom tabel (of in postmeta als je YITH of Smart Coupons gebruikte). Shopify heeft een eigen cadeaubon-object met een eigen codeformaat. Er is geen native brug.

Twee opties. Eén: exporteer elk openstaand saldo, geef een nieuwe Shopify-cadeaubon uit met hetzelfde saldo en een nieuwe code, en mail de klant de nieuwe code met excuses. Twee: bouw een klein support-workflow waarin klantenservice op verzoek handmatig een Shopify-cadeaubon uitgeeft als een klant met een oude code aan komt zetten. We hebben beide gedaan. De eerste is meer werk vooraf, nul werk erna. De tweede is één Slack-bericht per claim, voor altijd. Kies bewust.

7. Verzendregels die bijna werkten

WooCommerce-verzendzones zijn willekeurig. Je kunt een 4kg-tot-5kg-tier hebben van €12,50 voor de Benelux op dinsdagen, bovenop een table rate-plugin, plus een gratis-verzending-boven-€75-regel en een carrier-calculated PostNL-fallback. Shopify-verzendzones zijn simpeler, wat goed klinkt totdat je doorhebt dat je echte tariefkaart drie plugins aan elkaar gelijmd was.

Dump vóór de cutover de afgelopen 90 dagen aan orders, met de verzendkosten die je de klant rekende en de verzendkosten die je aan de vervoerder betaalde. Draai na de cutover dezelfde orders door de nieuwe Shopify-tarieven en vergelijk. Liggen de nieuwe tarieven systematisch hoger, dan reken je de klant te weinig en verlies je winkelmandjes bij checkout. Liggen ze lager, dan laat je marge liggen. Hoe dan ook ontdek je het voordat de klant het doet, en dat is het hele punt.

8. Order-ID-sequentie die je boekhoudkoppeling breekt

Shopify-orders beginnen standaard bij #1001. Je boekhoudsoftware, je ERP, je Exact Online- of Moneybird- of Yuki-koppeling verwachten allemaal dat ordernummers verdergaan waar WooCommerce stopte (bijvoorbeeld #38914). Dat doen ze niet. Sommige koppelingen slaan stilletjes "missende" orders over. Andere gooien duplicate-key errors en stallen de nachtelijke sync. Finance merkt het twee weken niet, want de totalen kloppen ruwweg nog.

Shopify laat je het startordernummer één keer instellen, vóór de eerste order, in Settings > Checkout. Zet 'm op één hoger dan het laatste WooCommerce-ordernummer. Bevestig dat de boekhoudkoppeling de eerste nieuwe order oppikt voordat je gaat juichen. Dit is een fix van vijf minuten die vier dagen forensische reconciliatie wordt als je 'm overslaat.

De eervolle vermeldingen

Een paar kleinere items die slaap hebben gekost, maar de top acht niet haalden. Productreviews die in de native reviews-tabel van WooCommerce staan importeren niet automatisch in Shopify Product Reviews of Judge.me. Je hebt een CSV-export en een CSV-import nodig, en de sterscores worden soms platgeslagen naar 5 als de veldnaam niet matcht. Klant-wishlists, vrijwel altijd plugin-gedreven op WC, zijn meestal een afschrijving: vertel klanten dat ze opnieuw moeten beginnen en bied korting aan op een herbouw. Wholesale-prijstiers uit B2B for WooCommerce vragen een volledig nieuwe Shopify B2B-catalogus. Geen van deze zal je om 03:00 wakker maken, maar ze kosten elk een dinsdag.

De truc vóór de cutover die wel echt helpt

Het nuttigste wat we ooit bij een migratie deden, was de nieuwe Shopify-winkel twee weken parallel laten draaien onder een staging-subdomein, met een klein percentage echte klanten dat via een feature flag op WP-niveau ernaartoe werd gerouteerd. Daarmee vingen we het wachtwoord-issue (we stuurden magic links), het mail-deliverability-issue (we warmden het verzenddomein op) en het abonnementen-issue (we bouwden het terugkerende schema met de hand opnieuw) op, voordat ze een ochtend met 312 tickets werden.

Toen we vorig najaar een migratie deden voor een Rotterdamse woninginrichter, was het ene wat iedereen verraste de order-ID-gap. We hadden elk ander item afgedekt. Het boekhoudteam was met vakantie in de cutover-week en de Exact Online-sync faalde negen dagen stilletjes. Dat soort details is waarom we de achtpunten-lijst hierboven aan de muur hebben hangen, en waarom we een legacy migratie meestal afsluiten met twee weken betaalde nazorg, in plaats van het bij de DNS-flip klaar te noemen.

Migreer je komend kwartaal, dan is het goedkoopste wat je vandaag kunt doen: draai Screaming Frog op je huidige winkel, exporteer elke interne URL naar een CSV, en begin met de redirect-map. Je krijgt geen spijt van dat bestand klaar te hebben, en het bouwen ervan brengt drie andere problemen aan het licht voordat ze toebijten.