In het kort: Bij replatforming verhuis je je webshop naar een nieuw e-commerceplatform. Het is de riskantste release die je doet: platform, data en koppelingen veranderen tegelijk. Test daarom de hele keten en niet alleen de nieuwe site. Denk aan gemigreerde data, koppelingen, checkout en betalen, en de overstap zelf.

De meeste handleidingen over replatforming gaan vooral over het kiezen van een platform. Testen krijgt een paar regels aan het eind. Zodra de keuze gemaakt is, zou dat precies andersom moeten zijn. Een nieuw platform kan in een demo prima werken en toch de orderhistorie kwijtraken. Het kan de verkeerde prijs tonen, of orders zonder afleveradres naar het magazijn sturen. Klanten merken dat binnen een paar uur. Je team is daarna weken bezig met wat testen had moeten vinden.

Wat is replatforming?

In e-commerce betekent replatforming dat je je webshop verhuist van het ene commerceplatform naar het andere. Bijvoorbeeld van één grote alles-in-één-suite naar een composable opzet. Daarin verzorgen losse diensten de commerce, de content, het zoeken en het inloggen. Of van een oude versie van een platform naar een nieuw SaaS-product. Het woord wordt ook gebruikt voor het verhuizen van applicaties naar de cloud, maar dat is een ander onderwerp. Teams stappen over als het oude systeem ze tegenhoudt: het is traag, lastig aan te passen of wordt niet meer ondersteund. Vaak wordt de front-end meteen opnieuw gebouwd, en verhuizen of veranderen de koppelingen mee. Daar zit het risico. Bij een gewone release verandert één ding en blijft de rest stabiel. Bij replatforming blijft bijna niets hetzelfde. Op “gisteren werkte het nog” kun je dus niet bouwen.

Waarom gaat een webshopmigratie mis na de livegang?

De meeste problemen zie je niet op de nieuwe homepage. Ze zitten in de delen van de keten waar tijdens een demo niemand naar kijkt. Dit zijn de bekende boosdoeners:

• Data die is verhuisd, maar net niet goed. Klanten loggen in en missen hun orderhistorie. Een productkenmerk komt binnen als gewone tekst, waardoor het filter dat erop leunde niet meer werkt.
• Koppelingen die één keer zijn getest. De koppeling met ERP, voorraad of betaalprovider werkte bij de eerste test. Daarna veranderde er een veld en draaide niemand de test opnieuw. Bij e-commercebedrijven zien we dit vaak.
• Meerdere leveranciers, geen eigenaar van het geheel. Een bureau bouwt de front-end, een leverancier beheert het platform en IT beheert het ERP. Iedereen test zijn eigen deel. Niemand test de bestelling van begin tot eind.
• Testdata die onder je handen verandert. Gedeelde testomgevingen veranderen steeds, dus tests falen zonder echte bug en mensen gaan ze wantrouwen.

Wat test je bij een platformmigratie?

Test de keten zoals je klant hem gebruikt, van de eerste zoekopdracht tot de order in het magazijn. Een klant ziet je systemen niet. Die ziet één bestelling die wel of niet werkt. Loop deze onderdelen langs en begin met wat het meeste pijn doet als het breekt:

• Zoeken en productdata. Producten, prijzen, varianten, filters en zoekresultaten kloppen met de bron.
• Prijzen, acties en voorraad. Kortingen, bundels en beschikbaarheid volgen dezelfde regels als voorheen. Test die op API-niveau, waar ze snel en stabiel zijn. In ons artikel over API testen lees je hoe.
• Accounts en inloggen. Bestaande klanten kunnen inloggen, hun wachtwoord herstellen en hun historie zien.
• Winkelmandje, checkout en betalen. Elke betaalmethode, ook mislukte en afgebroken betalingen, en de koppeling met je betaalprovider.
• Orders na de checkout. De order komt met de juiste gegevens aan bij ERP, magazijn en klantenservice.
• Oude URL’s. Redirects van oude product- en categoriepagina’s. Google raadt aan om elke oude URL permanent door te sturen naar de nieuwe en dat voor en na de verhuizing te controleren.

Hoe test je gemigreerde data?

Records tellen is niet genoeg. De aantallen kunnen kloppen terwijl de inhoud niet klopt. Vergelijk steekproeven veld voor veld: neem een paar honderd producten, klanten en orders en bekijk ze op het oude en het nieuwe platform. Kies bewust de lastige gevallen, zoals producten met veel varianten, klanten met een lange historie en orders met retouren. Test daarna wat klanten met die data doen: inloggen, opnieuw bestellen, filteren, afrekenen. Draai de datamigratie vaker dan één keer voor de echte overstap. Dan test je de uitkomst en verbeter je het script, in plaats van data met de hand te herstellen. De meeste platforms hebben hier importtools voor, zoals de Import API van commercetools. Welke tool je ook gebruikt, de testvraag blijft dezelfde: ziet de klant wat hij eerst ook zag?

Hoe bereid je de overstap zelf voor?

Behandel de dag van de livegang als een test die je kunt oefenen. Drie dingen maken het verschil:

1. Draai dezelfde regressietests op het oude en het nieuwe platform. Het oude platform laat zien hoe “goed” eruitziet. Verschillen komen zo vroeg boven, en niet pas op de dag van de lancering.
2. Oefen de overstap. Doorloop de hele overgang op een testomgeving, met de datamigratie, de redirects en de controles erna. Meet hoe lang het duurt, zodat je weet wat de echte overstap kost.
3. Spreek de controles voor de eerste uren en dagen af. Testorders met elke betaalmethode, orders die in het ERP aankomen, een steekproef van de redirects en het aantal mislukte betalingen vergeleken met een normale dag.

Dit alles werkt het best als je de tests automatiseert terwijl het nieuwe platform wordt gebouwd, en niet pas na de livegang. Met geautomatiseerde tests draai je de datacontroles na elke proefmigratie opnieuw, en de regressietest op beide platforms zo vaak als je wilt. Ze groeien mee met het project, zodat ze bij de overstap de keten afdekken. En na de livegang draaien ze gewoon door. Het nieuwe platform blijft veranderen, met releases van de leverancier, nieuwe functies en nieuwe koppelingen. De tests die de overstap beschermden, beschermen ook elke release daarna, zolang iemand ze draaiend houdt. We zien het vaak gebeuren: een paar maanden na een grote livegang staat de dekking stil, omdat niemand het onderhoud had ingepland. In ons artikel over de regressietest lees je hoe je dat voorkomt.

Wat betekent dit voor je team?

Begin met een kaart van je keten: elk systeem waar een order doorheen gaat en elke koppeling daartussen. Zet bij elk onderdeel wie de eigenaar is, en kijk waar niemand staat. Op die plek gaat een migratie meestal mis, en dat is precies het deel dat geen enkele leverancier voor je test.

Daar helpen we teams bij. We hebben complete e-commerceplatformmigraties getest, inclusief checkout, betalen en de koppelingen erachter. We testen over leveranciers heen, zodat de keten als één geheel wordt gecontroleerd. Meer lees je op onze pagina over e-commerce testen. Met Test Automation as a Service bouwen we die automatisering samen met je team op terwijl de migratie loopt. Na de livegang houden we hem elke nacht draaiend. Je krijgt een stabiele testset waar je team op kan vertrouwen, die niet van één persoon afhangt en je team geen extra werk geeft.

Veelgestelde vragen

Wat is het verschil tussen replatforming en rehosting?

Bij rehosting verhuis je een applicatie naar nieuwe infrastructuur zonder hem te veranderen, ook wel lift and shift genoemd. Bij replatforming verandert het platform zelf. In e-commerce betekent dat meestal een nieuw commercesysteem, gemigreerde data en herbouwde koppelingen. Daar hoort veel meer testwerk bij.

Hoe lang test je een platformmigratie?

Plan het testen vanaf het begin van het project, niet in de laatste weken. Begin met de koppelingen en de datamigratie zodra die er zijn, en draai de volledige regressietest ruim voor de overstap op beide platforms. Het oefenen van de overstap komt als laatste.

Kun je migratietests automatiseren?

Ja, en bij een migratie is dat juist slim. Datavergelijkingen, API-tests en de belangrijkste klantreizen kunnen allemaal automatisch en herhaaldelijk draaien. Bouw ze vanaf het begin van het project op. Zo draai je de datamigratie en de controles vaak voor de livegang, en houd je de tests daarna.

Wat controleer je in de eerste week na de livegang?

Controleer orders met elke betaalmethode en orders die in ERP en magazijn aankomen. Let op mislukte betalingen, vragen bij de klantenservice en fouten op doorgestuurde URL’s. Vergelijk alles met een normale week op het oude platform.