Overstappen naar een nieuw webshopplatform begint bijna altijd met dezelfde gids: exporteer je data, breng je URL's in kaart, zet 301-redirects, controleer je canonicals. Dat klopt allemaal, en het is ook het makkelijkste deel.
Waar het in de praktijk misgaat, is elders. Het gaat mis in de weken waarin je twee systemen tegelijk draait en ze het oneens zijn over dezelfde werkelijkheid. Welke voorraad is de echte? Welk systeem mag die e-mail versturen? Wie weet er dat die retour al binnen is?
Waarom de standaardgids niet genoeg is
De meeste migratiegidsen zijn geschreven door bureaus die migraties verkopen. Dat maakt ze niet onbetrouwbaar, maar het maakt ze wel eenzijdig: ze beschrijven het deel van de migratie dat het bureau uitvoert en oplevert. Data eruit, data erin, redirects erop, factuur eruit.
Dat deel is technisch werk met een duidelijk einde. Je kunt controleren of het gelukt is: staat het product erin, geeft de oude URL een 301, is de titel meegekomen. Ga of niet ga.
Het deel dat niemand beschrijft, is de periode erna. Je oude systeem staat nog aan, want je durft het nog niet uit te zetten. Je nieuwe systeem draait mee. En zolang beide aan staan, heb je twee administraties die allebei denken dat zij gelijk hebben. Dat is geen technisch probleem dat je oplost met een script. Het is een organisatorisch probleem dat je oplost met volgorde en met afspraken over wie de waarheid bezit.
De inventarisatie die niemand maakt
Voor je begint, maak je een URL-inventarisatie. Dat weet iedereen. Maar maak daarnaast een tweede lijst, en die is belangrijker: welke systemen schrijven naar dezelfde waarheid?
Loop je hele stack langs en noteer per systeem niet wat het doet, maar wat het verandert. Niet "Klaviyo verstuurt e-mail" maar "Klaviyo bepaalt of een klant een e-mail krijgt en registreert dat hij hem gehad heeft". Niet "het magazijnsysteem toont voorraad" maar "het magazijnsysteem verlaagt voorraad bij een pick".
Zodra twee systemen naar hetzelfde veld schrijven, heb je een migratierisico. Bij Grill Bill waren dat er meer dan we vooraf dachten. De voorraad werd aangeraakt door de webshop, het magazijnsysteem, de bol.com-koppeling en handmatige correcties. Vier schrijvers op één getal.
Die lijst bepaalt je volgorde. Systemen met één schrijver kun je in willekeurige volgorde overzetten. Systemen met meerdere schrijvers zet je over als geheel, in één keer, met een hard omschakelmoment. Doe je dat niet, dan krijg je precies waar dit artikel over gaat.
Overstappen naar een nieuw webshopplatform doe je in fases, niet in één nacht
Het draaiboek hierboven staat in acht fases, en de drie die er in de meeste gidsen niet in staan zijn precies de drie die geld kosten: de koppelingen, de testbestelling en het moment waarop je je oude systeem opzegt. Die behandelen we hieronder apart.
Eén principe loopt er doorheen. Alles wat maar één schrijver heeft, mag geleidelijk. Alles wat meerdere schrijvers heeft, zoals voorraad, orders en e-mail, gaat op één dag om. Die dag is je go-live, en het is de enige dag in het traject waarop het echt spannend is.
De koppelingen die niet meeverhuizen
Producten en klanten migreren is een kwestie van data verplaatsen. Koppelingen zijn dat niet: die moet je opnieuw leggen, en een deel ervan kun je überhaupt niet meenemen.
- Je betaalprovider. Een nieuwe koppeling betekent nieuwe webhooks. Test niet alleen of een betaling lukt, maar ook of de statusterugkoppeling aankomt. Een order die op "in afwachting" blijft hangen terwijl het geld binnen is, merk je pas als de klant belt.
- Doorlopende mandaten en abonnementen. SEPA-mandaten en opgeslagen betaaltokens zijn gekoppeld aan je oude account bij de provider. Heb je abonnementen of herhaalaankopen, dan is dit het zwaarste onderdeel van je hele migratie en verdient het een eigen plan.
- Je factuurnummerreeks. Die moet doorlopen. Een nieuw platform dat vrolijk weer bij 1 begint, levert je een probleem op bij de eerstvolgende boekhoudcontrole.
- Verzendlabels en retourportaal. Inclusief de vraag hoe je een pakket labelt dat op het oude platform besteld is.
- Feeds en marktplaatsen. Google Merchant Center, bol.com, je Meta-catalogus. Allemaal wijzen ze naar URL's die veranderen.
- Meten en toestemming. Analytics, je consent-oplossing, de pixels. Zet ze vóór go-live klaar, anders ben je je nulmeting kwijt op precies het moment dat je hem nodig hebt.
- Reviews. Verzamelde beoordelingen zitten bij je reviewpartij, niet in je shop. Koppel ze opnieuw en match op EAN, niet op productnaam.
De testbestelling van één cent
Er is precies één controle die telt, en het is niet een vinkje op een checklist. Plaats een echte bestelling op het nieuwe platform, met een echte betaling van één cent, en volg hem helemaal uit: komt de order binnen, staat de betaalstatus goed, gaat de bevestigingsmail eruit, klopt de factuur, komt het label uit de verzendkoppeling, en kun je hem daarna retourneren en terugbetalen?
Elke stap die je hier overslaat, ontdek je terug bij een klant. Doe deze test met minstens drie soorten producten: een gewoon product, een product met varianten en iets afwijkends, zoals een cadeaubon, een digitaal product of een bundel. Dat zijn de drie plekken waar het misgaat.
Wachtwoorden komen niet mee
Klantaccounts migreren prima. Wachtwoorden meestal niet: platformen slaan ze versleuteld op in een eigen formaat, en dat formaat is zelden uitwisselbaar. Je kunt ze dus niet overzetten, en je wilt ze al helemaal niet in leesbare vorm ergens tussen hebben staan.
Dat betekent dat je een keuze maakt vóór go-live, niet erna. Ofwel je stuurt iedereen een reset-mail op de dag van de omschakeling, ofwel je vangt de eerste inlogpoging op met een vriendelijk scherm dat uitlegt waarom het even anders gaat. Wat je niet moet doen, is dit ontdekken op de ochtend dat je live bent.
De data-overdracht bij WooCommerce
Bij WooCommerce-shops loopt de overdracht via onze eigen WordPress-plugin, neura-wp-woo-sync. Die installeer je in de bestaande shop en hij leest producten, klanten en orders rechtstreeks uit de WooCommerce-database. Geen zelfgebouwde CSV-export dus, en geen handmatige veldmapping die je bij elke herhaling opnieuw goed moet krijgen. Er zit een aparte migratietab in waarin je per onderdeel kunt overzetten en controleren.
Dat maakt het herhaalbaar, en herhaalbaar is wat je wilt. Je doet een migratie zelden in één poging helemaal goed. De plugin is precies daarom ontstaan: uit de constatering dat we bij de tweede migratie hetzelfde handwerk deden als bij de eerste.
Je posities behouden
Dit is het onderdeel waar de meeste angst zit, en waar het minst misgaat mits je het saai uitvoert:
- Zet je staging-omgeving op noindex zodra je hem opbouwt. Een tweede indexeerbare versie van je shop is de duurste fout die je in week twee kunt maken.
- Breng elke bestaande URL in kaart, inclusief prestaties: verkeer, posities, backlinks.
- Map ze één op één naar de nieuwe structuur en zet de 301-redirects live op de dag van de omschakeling, niet de dag erna.
- Vergeet de uitverkochte en uitgefaseerde producten niet. Dat is de klassieke fout: die pagina's lijken waardeloos, maar ze hebben vaak links en verkeer. Redirect ze naar een vergelijkbaar product of naar de bovenliggende categorie, niet naar de homepage.
- Verlaag de TTL van je DNS een dag van tevoren. Dan duurt het omzetten minuten in plaats van uren, en een eventuele terugval ook.
- Werk je interne links bij naar de nieuwe URL's. Een redirect die werkt is prima, maar een interne link die er direct naartoe wijst is beter.
- Dien een nieuwe sitemap in en houd je indexering twee tot vier weken actief in de gaten.
Wat er brak
Op de omschakeldag week de voorraadteller van één SKU drie stuks af van de fysieke telling. Klein verschil, en precies daarom leerzaam.
De oorzaak: een retour van bol.com stond in het oude systeem nog als "onderweg", terwijl de doos fysiek al in het magazijn stond. Het nieuwe systeem had het pakket geteld, het oude nog niet. Beide systemen hadden gelijk volgens hun eigen administratie. Er was geen bug.
Dit is de reden dat de omschakeling een harde knip moet zijn en geen geleidelijke overgang. Zolang twee systemen allebei bijhouden waar een pakket is, krijg je verschillen die je niet kunt debuggen, want er is niets kapot. Je kunt alleen kiezen wie er vanaf nu gelijk heeft.
Praktisch: tel fysiek op de dag van de omschakeling, zet die stand als waarheid, en zet de schrijfrechten van het oude systeem dezelfde dag uit. Niet de week erna.
Drie momenten waarop je moet kunnen terugvallen
Plan je terugvalmomenten voordat je begint, niet als het misgaat:
- Na de klantdata-import. Je hebt nog niets omgeschakeld. Terugvallen kost je een verwijderde import.
- Vlak voor de omschakeldag. Dit is je laatste echte uitweg. Daarna heb je een fysieke telling gedaan die je niet terugdraait, en staan er orders in het nieuwe systeem die niet terug kunnen.
- Voor je advertenties omzet. Campagnes pauzeren en terugzetten kost een dag, geen week.
Na de omschakeldag is terugvallen geen technische handeling meer maar een tweede migratie, in omgekeerde richting. Weet dat, en beslis er bewust over.
Wanneer je het oude systeem mag opzeggen
Later dan je denkt, en dat is de saaiste besparing die je kunt uitstellen. Je oude platform mag pas uit als de laatste retourtermijn van een daar geplaatste bestelling verlopen is, als je garantie- en klachtdossiers elders leesbaar zijn, en als je boekhouding het afgesloten jaar niet meer nodig heeft.
Reken op twee tot drie maanden overlap. Zet in die periode wel de schrijfrechten uit; het oude systeem mag alleen nog gelezen worden. Een systeem dat je uit voorzichtigheid laat meedraaien, is precies het systeem dat je administratie stilletjes uit elkaar trekt.
Wat het opleverde
Bij Grill Bill vervingen we twaalf losse tools: Klaviyo, Trengo, Sendcloud, Pipedrive, Hootsuite en Mailchimp, plus zes andere plekken waar werk lag. Takenbeheer, productinformatiebeheer, de brand kit, EAN-beheer, cadeaubonnen inclusief fysieke kaarten, en de koppelingen zelf. Die migratie hebben we uitgebreid opgeschreven in de post-mortem van twaalf tools naar één.
Het interessantste getal is niet de besparing, maar de nul. In het seizoen van 2023 verbrandde Grill Bill € 1.700 aan advertentiebudget op een product dat al uitverkocht was. Niemand deed iets fout. De voorraadstand stond in het ene systeem en de campagne in het andere, en niets zorgde ervoor dat ze met elkaar praatten. Dat is precies het soort verlies dat niet in een businesscase staat, omdat je het pas ziet als je het niet meer hebt.
De besparing van € 1.310 per maand is makkelijk te becijferen. De vijf uur handwerk per piekweek is dat ook. De ROAS-verbetering is lastiger toe te schrijven aan één oorzaak, en we doen niet alsof die volledig op het conto van de migratie komt. Wil je weten wat jouw stack nu kost, dan kun je dat hier doorrekenen, of je huidige platform naast Neuramerce leggen.
Waar we nu staan
We hebben drie migraties gedaan en willen dit jaar onze eigen tien websites overzetten. De vierde loopt nu, en die is bewust de moeilijkste die we konden vinden: NomadFire, een complexe WooCommerce-shop met tientallen plugins, een cursusomgeving, receptcontent en meerdere talen. Die moet eind september live.
We doen dat niet omdat het makkelijk is, maar omdat elke migratie die pijn doet iets blootlegt wat de volgende migratie makkelijker maakt.