Website migreren: Waarom ’technisch succesvol’ niet genoeg is
De DNS klopte. De database draaide. SSL werkte. Maar klanten konden niet afrekenen. Waarom een technisch perfecte migratie toch je omzet kan stoppen.
Vorige maand migreerden we een webshop naar onze hosting. Technisch gezien ging alles perfect. DNS overgezet, database verhuisd, SSL-certificaat actief, emails werkten. Precies zoals het hoort.
Totdat de eigenaar me belde. “Gimle, er is iets mis. Klanten kunnen niet afrekenen.”
En dat is precies waar het bij website migraties vaak misgaat. Niet bij de techniek, maar bij de details waar je bedrijf van draait.
Waarom bedrijven hun platform migreren
Er zijn genoeg redenen om van hosting te wisselen. Kosten die te hoog oplopen. Slechte performance. Een hosting provider die niet reageert op support tickets. Of gewoon de wens om volledige controle te hebben over waar je data staat.
Voor veel MKB-bedrijven komt het moment waarop ze denken: “Dit moet beter kunnen.”
En dat klopt. Het kán beter. Maar een migratie is niet alleen een kwestie van bestanden verhuizen. Het gaat om alle systemen die je webshop, website of ERP-systeem laten draaien – en die moeten allemaal blijven werken.
Wat er bij een migratie komt kijken
Een platform migreren lijkt simpel. Je maakt een backup, zet alles op de nieuwe server, wijst de DNS om, klaar.
De praktijk is complexer, en het verschilt per platform.
Voor WordPress sites heb je te maken met:
- Bestanden en database
- Plugin compatibiliteit met de nieuwe server
- Theme configuratie en custom code
- Permalink structuur en SEO
Voor PrestaShop webshops komt daar bij:
- Module compatibiliteit (vooral payment en verzend modules)
- Productcatalogus met categorieën en attributen
- Klantaccounts en orderhistorie
- Multi-language en multi-currency instellingen
Voor Dolibarr ERP systemen is het nog complexer:
- Relaties tussen modules en data
- Gebruikersrechten en workflows
- Externe koppelingen (boekhouding, CRM)
- Documenten en templates
En ongeacht het platform:
- DNS configuratie – bezoekers moeten naar de juiste server wijzen
- SSL-certificaten – anders krijgen klanten beveiligingswaarschuwingen
- Email instellingen – contactformulieren en transactie-emails moeten blijven werken
- Server instellingen – PHP versie, database versie, memory limits
En dat is alleen de technische kant.
Het webshop verhaal
Ik vertel je graag wat er misging bij de migratie van de webshop.
We hadden alles voorbereid. De VPS bij Hetzner stond klaar met Ubuntu en een LAMP stack. Backup gemaakt van de oude server. Database geëxporteerd. Bestanden overgezet. DNS aangepast naar de nieuwe server.
Technisch was alles in orde:
- Website bereikbaar op het nieuwe adres
- Admin panel werkte
- Database verbinding actief
- SSL-certificaat geldig
- Email formulieren werkten
Maar toen de eigenaar ging testen, stopte het bij de checkout.
Wat er gebeurde
In opdracht van de klant hebben we tijdens de migratie een nieuw professioneel WordPress-thema geïnstalleerd en geactiveerd. – een design dat de klant al een tijdje wilde gebruiken. Logisch moment leek het, toch? Als je toch bezig bent met migreren, kun je meteen dat nieuwe design activeren.
Het thema werkte. De site zag er goed uit. Producten werden mooi weergegeven. Alles leek prima.
Tot klanten probeerden af te rekenen.
De checkout gaf geen foutmelding. Geen duidelijke error. Het proces stopte gewoon op het moment dat de betaling geïnitieerd moest worden. Voor de klant leek het alsof de site vastliep. Voor de webshop-eigenaar betekende het: geen omzet.
De oorzaak
Het probleem zat in de combinatie van het nieuwe thema en de payment plugin.
Het thema had custom checkout code die product informatie op een bepaalde manier doorgeeft. Bedragen van producten werden als tekst doorgegeven in plaats van als getal. Voor de meeste plugins maakt dat niet uit. Maar deze payment gateway verwachtte strikte numerieke waardes voor de berekening.
Het resultaat: een PHP error diep in de code. Onzichtbaar voor de klant, maar funest voor de checkout.
De oplossing
We hebben het opgelost door de payment plugin code aan te passen – technisch niet heel ingewikkeld, maar je moet wel weten waar je moet zoeken. En belangrijker: je moet weten dat het probleem bestaat.
Als we het thema eerst op een testomgeving hadden getest, waren we dit bij de live gang voor. Nu had de webshop een paar uur geen werkende checkout.
Voor een fysieke winkel is een paar uur niet rampzalig. Voor een webshop betekent het direct omzetverlies.
Waarom testen zo cruciaal is
Moraal van het verhaal: technisch succesvol is niet genoeg.
Je kunt een technisch perfecte migratie uitvoeren waarbij alle bestanden kloppen, de database intact is, en de DNS naar de juiste server wijst. Maar als bijvoorbeeld de checkout niet werkt, dan is de migratie alsnog mislukt.
Voor webshops (WordPress/WooCommerce, PrestaShop) zijn er kritieke onderdelen:
- Checkout proces – van winkelwagen tot betaalbevestiging
- Payment gateway – iDEAL, creditcard, PayPal, etc.
- Order emails – bevestiging naar klant en naar jezelf
- Voorraad synchronisatie – als je externe voorraadsystemen gebruikt
- Zoekfunctie en filters – klanten moeten producten kunnen vinden
- Mobiele weergave – 60-70% van webshop verkeer komt van mobiel
Voor Dolibarr ERP zijn andere zaken kritiek:
- Facturatie module – moet orders kunnen aanmaken
- PDF generatie – offertes en facturen
- Email templates – klantcommunicatie
- Koppelingen met boekhoudsoftware
- Gebruikersrechten – niet iedereen mag alles zien
Het is niet genoeg om te zien dat de homepage werkt. Je moet het hele klanttraject testen.
Migreren met of zonder nieuwe features
Een veelgemaakte fout: combineren van een migratie met andere wijzigingen.
“Nu we toch bezig zijn, laten we ook meteen…”
- Een nieuw thema activeren
- Plugins of modules updaten naar de nieuwste versie
- De checkout aanpassen
- Extra functionaliteit toevoegen
Het lijkt efficiënt. In de praktijk vergroot het de kans op problemen.
Bij die webshop hadden we beter kunnen doen:
- Eerst migreren – exact zoals de oude site was
- Testen – alles checken, vooral checkout en payments
- Dan pas het nieuwe thema activeren op een testomgeving
- Opnieuw testen – grondig, met echte test-bestellingen
- Live zetten – als alles werkt
Dat kost meer tijd. Maar het voorkomt dat je klanten een niet-werkende webshop zien.
De onzichtbare kosten van downtime
Voor ecommerce bedrijven is elke minuut dat je site niet werkt meetbaar verlies.
Ga maar eens na:
- Gemiddeld 20 bezoekers per uur
- Conversie van 2%
- Gemiddelde orderwaarde €75
Dat betekent €30 omzet per uur onder normale omstandigheden. Als je checkout een dag niet werkt, loop je dus €720 mis. Naast deze directe omzetverliezen, is er ook een verborgen verliespost: klanten die door de slechte ervaring afhaken en niet meer terugkomen.
Bij B2B webshops zijn de bedragen vaak nog hoger. Een niet-werkende site voor zakelijke klanten betekent dat ze naar de concurrent gaan – en daar vaak blijven.
Voor Dolibarr gebruikers kan een niet-werkend systeem betekenen dat facturatie stilligt, offertes niet verstuurd kunnen worden, of dat je geen inzicht hebt in je voorraad of cashflow.
Daarom is het bij zakelijke systemen geen overbodige luxe om grondig te testen.
Wat wij anders doen nu
Na deze ervaring hanteren we een verbeterd stappenplan:
Fase 1: Exacte kopie
Migreer het platform precies zoals het is. Geen nieuwe thema’s, geen grote updates, geen structurele wijzigingen. Alleen verhuizen.
Fase 2: Uitgebreid testen
Niet alleen de homepage bekijken. Het hele proces doorlopen:
Voor webshops:
- Winkelwagen toevoegen
- Checkout starten
- Betaling initiëren (testmodus)
- Order bevestiging controleren
- Admin emails checken
- Mobiel testen
Voor Dolibarr:
- Factuur aanmaken
- PDF generatie testen
- Email verzending controleren
- Module integraties verifiëren
- Gebruikersrechten checken
Fase 3: Nieuwe features (optioneel)
Als de klant wijzigingen wil – nieuw thema, extra plugins, design aanpassingen – doen we dat daarna. Op een testomgeving. Met grondige tests voordat het live gaat.
Dit kost meer tijd vooraf. Maar het scheelt problemen achteraf.
Voor welke platforms is migratie risicovol?
Niet elk platform is even risicovol voor de business als het andere.
Laag risico:
- Informatieve WordPress websites zonder interactieve elementen
- Blogs met standaard setup
- Websites zonder kritieke business processen
Gemiddeld risico:
- WordPress sites met maatwerk plugins
- Websites met contactformulieren en leads
- Sites met SEO-gevoelige content
Hoog risico:
- PrestaShop of WooCommerce webshops met actieve verkoop
- Dolibarr ERP systemen met klantdata en facturatie
- B2B platforms met klantportals
- Sites met externe integraties (ERP, CRM, boekhouding)
Hoe kritischer je platform voor je bedrijf, hoe zorgvuldiger de migratie moet zijn.
Kun je dit zelf doen?
Technisch gezien kan iemand met kennis van het platform een eenvoudige site migreren. Er zijn genoeg tutorials en tools die je kunnen helpen.
Maar de vraag is niet of het kan. De vraag is: wil je het risico nemen?
Bij een informatieve blog is het risico beperkt. Staat je site een uurtje offline, dan is dat hooguit vervelend.
Bij een webshop die €500-1000 per dag omzet, is elk uur downtime meetbaar verlies. En een checkout die stilletjes faalt – zonder duidelijke foutmelding – kan dagen blijven voortbestaan voordat je het doorhebt.
Bij een Dolibarr systeem waar je dagelijkse bedrijfsvoering van afhangt, kun je niet wachten tot het “weer werkt”.
De meeste ondernemers hebben betere dingen te doen dan zich zorgen maken over DNS propagatie, SSL certificate chains, en plugin compatibiliteit.
Hoe wij migraties aanpakken
Bij DSCloud9 werken we met een stappenplan dat risico’s minimaliseert, ongeacht of het WordPress, PrestaShop of Dolibarr is:
Voorbereidingsfase:
- Complete backup van huidige platform (bestanden + database)
- Inventarisatie van alle actieve plugins, modules en integraties
- Check van externe koppelingen en API’s
- Planning van optimale migratietiming (minste verkeer/gebruik)
Migratiefase:
- Opzetten nieuwe serveromgeving
- Overzetten van bestanden en database
- Configuratie van DNS en SSL
- Email instellingen migreren
Testfase:
- Technische checks (bereikbaarheid, database, SSL)
- Functionele checks (formulieren, checkout, payments, facturatie)
- Performance tests (laadtijd, mobiel)
- Platform-specifieke tests (volledige testbestelling, factuur genereren, etc.)
Live fase:
- DNS definitief omzetten
- Monitoring eerste 24-48 uur
- Backup van oude server bewaren (veiligheidsnet)
En voor kritieke systemen voegen we daar nog een stap aan toe: testomgeving eerst, live pas als alles 100% werkt.
Onder aan de streep
Een platform migreren is meer dan bestanden verplaatsen. Het gaat om continuïteit van je business.
Technisch kunnen we vrijwel elk systeem foutloos migreren. Maar “technisch succesvol” is niet hetzelfde als “business succesvol”.
Die webshop werkte technisch perfect na de migratie. Toch verloor de eigenaar omzet door een detail dat we hadden moeten testen.
Dat is de les: bij kritieke platformen – vooral webshops en ERP-systemen – is grondig testen geen overbodige luxe. Het is de kern van een goede migratie.
Overweeg je een migratie?
Elke situatie is anders. Misschien is jouw platform simpel genoeg om zelf te migreren. Misschien is het risico te groot om het niet uit handen te geven.
Benieuwd wat een migratie voor jouw situatie betekent? Stuur me een email naar info@dscloud9.nl en ik denk met je mee over de beste aanpak.
Liever geen verrassing achteraf.
