Bij een webshopmigratie moeten klanten hun product vinden, de juiste prijs zien en een bestelling kunnen afronden. Ook bestaande zoekresultaten, terugbetalingen en dagelijkse beheerhandelingen verdienen een plaats in het plan.
Deze checklist is onze aanbevolen aanpak voor het afbakenen en accepteren van een migratie. Google en Stripe bieden de primaire onderbouwing voor de onderdelen over URL-wijzigingen en betaalberichten. De precieze uitvoering hangt af van je platform en betaalprovider.
Begin met wat de winkel moet kunnen
Maak eerst een functie-inventaris, voordat je een nieuw ontwerp of een techniek kiest. Laat de eigenaar en degene die dagelijks bestellingen verwerkt samen een normale werkdag doorlopen. Schrijf per functie op wat behouden moet blijven, wat mag verdwijnen en wat anders moet werken.
Dat voorkomt dat een offerte alleen aantallen producten en pagina’s telt, terwijl de ingewikkelde onderdelen pas tijdens de bouw verschijnen. Koppelingen, uitzonderingen en historische gegevens bepalen vaak hoeveel werk werkelijk nodig is.
- Productvarianten, voorraad, prijslijsten, kortingscodes en verzendregels.
- Btw-instellingen, facturen, retouren en gehele of gedeeltelijke terugbetalingen.
- Betaalmethoden, abonnementen, openstaande bestellingen en eventuele opgeslagen betaalmandaten.
- Boekhouding, vervoerders, leveranciers, marketplaces en andere koppelingen.
- Beheerrollen, talen, klantaccounts, downloads en informatie die je echt moet bewaren.
Behoud URL’s waar dat kan; maak anders een mapping
Een andere techniek vereist niet automatisch andere publieke adressen. Als URL’s veranderen, adviseert Google om oude en nieuwe adressen te koppelen, permanente redirects in te richten en de overgang te volgen. Google waarschuwt ook voor tijdelijke schommelingen in zoekposities.
Onze aanbeveling: maak een tabel met oud adres, nieuw adres, reden en testresultaat. Begin met product- en categoriepagina’s die verkeer of externe links krijgen. Neem afbeeldingen, handleidingen en andere waardevolle bestanden mee. Stuur niet iedere vervallen productpagina zonder inhoudelijke reden naar de homepage.
Controleer vóór livegang de belangrijke pagina’s, interne links, canonieke adressen, taalverwijzingen en sitemap. Bewaar een nulmeting van verkeer en fouten, zodat veranderingen na de overstap bespreekbaar worden. Niemand kan met alleen een nieuw platform gelijke zoekposities garanderen.
Test de volledige betaalroute
Een bedankpagina bewijst nog niet dat een bestelling correct is betaald en verwerkt. Stripe beschrijft webhooks als berichten voor asynchrone gebeurtenissen, waaronder betaalbevestigingen. De documentatie behandelt verificatie en het testen van zulke berichten. Gebruik bij een andere provider diens eigen integratiehandleiding.
Onze aanbevolen acceptatieproef loopt door van winkelmand tot administratie. Gebruik testgegevens en de testomgeving van de provider. Spreek apart af of er vervolgens een beperkte echte betaal- en terugbetaalproef nodig is, wie die uitvoert en hoe je die controleert.
- Geslaagde, mislukte, geannuleerde en nog openstaande betalingen geven de juiste orderstatus.
- Een dubbel of later binnengekomen betaalbericht leidt niet tot dubbele levering of voorraadwijziging.
- Bevestigingsmail, factuur, verzendkosten en kortingsregels kloppen.
- Volledige en gedeeltelijke terugbetalingen komen goed in webshop en administratie terug.
- Bestaande abonnementen en mandaten worden alleen meegenomen als de provider en gekozen integratie dat ondersteunen.
Plan de laatste gegevensoverdracht en de terugweg
Tijdens een migratie kunnen in de oude winkel nog orders binnenkomen. Leg daarom vast wanneer de laatste overdracht plaatsvindt, of bestellen tijdelijk wordt gepauzeerd en hoe je nieuwe orders en voorraadverschillen afstemt. Een oudere database terugzetten kan intussen ontvangen orders overschrijven.
Onze aanbeveling: spreek een beslismoment voor doorgaan of teruggaan af, met een verantwoordelijke en concrete stopcriteria. Denk aan een onbereikbare checkout, verkeerde bedragen of ontbrekende betaalbevestigingen. Schrijf ook op wat er met nieuwe orders gebeurt als je teruggaat. Alleen een back-upbestand hebben is nog geen uitgewerkt terugvalplan.
Controleer na de overstap echte orderstatussen, providerberichten, foutmeldingen en de belangrijkste oude URL’s. Bewaar de oude omgeving alleen zo lang en op zo’n manier als afgesproken; voorkom dat twee omgevingen zelfstandig dezelfde orders gaan verwerken.
Wat TovieIT eerst nodig heeft
Voor een maatwerkherbouw met React en Node.js bespreken we eerst de huidige functies, koppelingen, gegevens en gewenste beheerwijze. Daarna kunnen scope, fasering, hosting, onderhoud en acceptatiecriteria worden afgesproken. Een visueel vergelijkbare demo bewijst niet dat alle commercefuncties al zijn overgezet.
Begin met je platform, een globale productomvang, je betaalprovider, belangrijke koppelingen en de reden voor de overstap. Vermeld ook welke functies absoluut moeten blijven werken. Wacht met het delen van exports of toegangen tot daar duidelijke afspraken over zijn.
Bronnen gecontroleerd:
Bronnen & controle
De links hieronder verwijzen naar de oorspronkelijke documentatie. Versies en adviezen kunnen veranderen; laat je eigen situatie bij je host controleren.
- Google Search Central: site moves met URL-wijzigingen
- Stripe: webhooks ontvangen, verifiëren en testen
Bijgewerkt:
Over deze publicatie. TovieIT bouwt en host websites. Deze uitleg is onze eigen publicatie; een algemene uitleg is geen individuele beveiligingscontrole.