Servermigratie uitvoeren: website verhuizen zonder dataverlies

Servermigratie, ook wel het verhuizen van een website genoemd, is het gepland overzetten van websitebestanden, databases, e-mailaccounts, DNS-records en applicatie-instellingen van de huidige server naar een nieuwe server. Een website verhuizen zonder dataverlies doe je in de basis als volgt: eerst maak je een volledige back-up, daarna richt je de nieuwe server in met dezelfde of nieuwere softwareversies, vervolgens zet je bestanden en databases over, test je via het hosts-bestand of een tijdelijke URL, wijzig je de DNS met een lage TTL en controleer je na de livegang logs, formulieren, betaalstromen, e-mailbezorging en SEO-signalen.

Een servermigratie is geen simpele kwestie van kopiëren en plakken. Vooral bij WordPress, WooCommerce, Laravel, maatwerk-PHP-applicaties, drukbezochte nieuwssites of bedrijven die zakelijke e-mail gebruiken, kan een onzorgvuldige verhuizing leiden tot gemiste bestellingen, kapotte speciale tekens, 500-fouten, SSL-waarschuwingen, e-mailuitval en dalingen in de zichtbaarheid in zoekmachines. Daarom hoort een migratie te worden uitgevoerd met een duidelijk plan, een technische checklist en een scenario om terug te kunnen draaien als dat nodig is.

In deze gids leggen we stap voor stap uit hoe je een hosting- of serverwijziging uitvoert op een manier die aansluit bij de SEO- en performanceverwachtingen van 2026. We behandelen daarnaast verschillende scenario’s, zoals cPanel, Plesk, VPS, cloudservers en handmatige migraties. Ook delen we praktische adviezen voor DNS-timing, back-upomvang, databasecompatibiliteit, SSL-installatie en SEO-controles na de verhuizing.

Wanneer is servermigratie nodig?

Een website naar een nieuwe server verhuizen gebeurt meestal vanwege prestaties, beveiliging, kosten of schaalbaarheid. Een kleine bedrijfswebsite met 5.000 bezoekers per maand kan bijvoorbeeld prima draaien op shared hosting, terwijl een webshop met 20.000 bezoekers per dag tegen CPU-limieten, trage databasequeries en time-outs op de betaalpagina kan aanlopen. Op dat moment is een krachtiger hostingpakket, een VPS of een cloudomgeving vaak een betere keuze.

Veelvoorkomende signalen dat servermigratie nodig is, zijn:

• De laadtijd van pagina’s loopt op tot meer dan 3 seconden en Core Web Vitals gaan achteruit.
• CPU-, RAM-, inode- of schijfruimtelimieten in het hostingpaneel worden regelmatig bereikt.
• Er is behoefte aan nieuwere versies van PHP, MySQL, MariaDB, Node.js of ionCube.
• Er zijn vaak problemen met SSL-verlenging, e-mailbezorging of DNS-beheer.
• De supportkwaliteit, back-ups of beveiliging van de huidige provider is onvoldoende.
• Het websiteverkeer stijgt plotseling tijdens campagnes, advertenties of seizoenspieken.

Als je website groeit en de grenzen van het huidige pakket nadert, is het veel veiliger om tijdig een gecontroleerd migratieplan te maken dan op het laatste moment tijdens een storing te moeten verhuizen. Afhankelijk van je behoefte kun je Web hosting pakketten, VPS-serveroplossingen of Zakelijk Hosting vergelijken om de juiste infrastructuur te kiezen.

Voorbereiding op de migratie: de belangrijkste fase

De meeste migratieprojecten waarbij dataverlies ontstaat, mislukken niet tijdens het overzetten zelf, maar door gebrekkige voorbereiding. Voordat de verhuizing begint, moet de huidige website volledig in kaart worden gebracht. Ook moet duidelijk zijn welke data worden verhuisd en welke diensten gevoelig zijn voor onderbrekingen.

1. Maak een inventaris van de website

De eerste stap is het opstellen van een technische kaart van de website. Noteer welk CMS of framework wordt gebruikt, welke PHP-versie actief is, welk type database draait, hoeveel schijfruimte nodig is, welke e-mailaccounts bestaan, welke cronjobs actief zijn, welke DNS-records zijn ingesteld, welk SSL-certificaat wordt gebruikt, welke speciale redirects bestaan en welke externe koppelingen actief zijn. Bij een WordPress-site is het bijvoorbeeld niet voldoende om alleen de map wp-content te verhuizen; ook .htaccess-regels, wp-config.php-instellingen, databaseprefixen, cacheplugins en mediabestanden moeten worden gecontroleerd.

Bij een webshop moeten daarnaast betaalproviders, verzendkoppelingen, voorraadsynchronisatie, ERP-integraties, SMTP-diensten en webhook-URL’s worden bekeken. Als er na de migratie geen bestellingen binnenkomen, ligt het probleem vaak niet bij de bestandsmigratie, maar bij een vergeten API-IP-whitelist of een beveiligingsregel die nog aan de oude server gekoppeld is.

2. Maak een volledige back-up en verifieer die

Bij een servermigratie is alleen een back-up maken niet genoeg; je moet ook controleren of de back-up daadwerkelijk teruggezet kan worden. Een volledige back-up moet de volgende onderdelen bevatten:

• Websitebestanden: public_html, applicatiemappen, uploadmappen, thema’s en pluginbestanden.
• Databases: MySQL, MariaDB, PostgreSQL of andere databases die de applicatie gebruikt.
• E-maildata: mailboxen, doorstuuradressen, filters en autoresponder-instellingen.
• DNS-records: A, AAAA, CNAME, MX, TXT, SPF, DKIM en DMARC-records.
• Configuraties: .htaccess, nginx.conf, php.ini, cronjobs en environment-bestanden.
• SSL-certificaten en specifieke beveiligingsregels.

Een praktische aanpak is om vóór de verhuizing minimaal twee kopieën van de back-up te maken: één op de huidige server en één op een andere locatie. Voor grotere websites kun je rsync gebruiken voor bestanden en mysqldump of paneelback-ups voor databases. Bij databases groter dan 10 GB zijn gecomprimeerde en opgesplitste back-ups vaak veiliger dan één groot dumpbestand.

3. Verlaag de DNS TTL vooraf

Om DNS-wijzigingen sneller te laten doorwerken, is het verstandig om de TTL-waarde 24 uur vóór de migratie te verlagen. Staat de TTL bijvoorbeeld op 14400 seconden, dan kunnen sommige bezoekers nog urenlang naar de oude server worden gestuurd. Door de TTL vóór de verhuizing naar 300 seconden te zetten, wordt de DNS-overgang beter beheersbaar. Zodra de migratie is afgerond en alles gecontroleerd is, kun je de TTL weer verhogen naar bijvoorbeeld 3600 of 14400 seconden.

Goed DNS-beheer heeft direct invloed op het succes van een migratie. Voor domein- en DNS-configuratie kun je de handleidingen bij Domeinsopzoeking en domeinbeheer bekijken.

Vergelijking van servermigratiemethoden

De beste migratiemethode is niet voor elke website hetzelfde. Een kleine bedrijfswebsite kan vaak eenvoudig via een hostingpaneel worden verhuisd, terwijl een drukbezochte webshop baat heeft bij gefaseerde synchronisatie en een onderhoudsvenster.

Let bij het kiezen van nieuwe infrastructuur niet alleen op schijfruimte. Ook het aantal PHP-workers, CPU-cores, RAM, NVMe-opslag, back-upfrequentie, locatie van het datacenter, ondersteuning voor LiteSpeed of Nginx, WAF en DDoS-bescherming bepalen de prestaties. Wie zonder behoefteanalyse voor het goedkoopste pakket kiest, loopt het risico binnen korte tijd opnieuw te moeten migreren.

Stap voor stap: hoe voer je een servermigratie uit?

Stap 1: Bereid de nieuwe server voor

Op de nieuwe server moeten het besturingssysteem, de webserver, PHP-versie, databaseservice en benodigde modules worden geïnstalleerd. Voor WordPress worden PHP 8.2 of 8.3, een actuele MariaDB-versie, OPcache en een passende memory_limit aanbevolen. Bij frameworks zoals Laravel moeten Composer, cron, queue workers en storage-rechten apart worden ingesteld. Als PHP-extensies die op de oude server actief waren ontbreken op de nieuwe server, kan de website na de verhuizing een wit scherm of 500-fout tonen.

Aan de beveiligingskant moeten SSH-poortbeleid, sterke wachtwoorden, firewall, malwarescans en automatische updates worden ingericht. Het is eenvoudiger om de beveiligingsbasis te leggen terwijl de nieuwe server nog leeg is dan achteraf alles aan te passen. Heb je SSL nodig, neem dan installatie van SSL certificaat zeker op in je migratieplan.

Stap 2: Zet de bestanden over

Voor de bestandsoverdracht kun je afhankelijk van de grootte van de website FTP, SFTP, SSH, rsync of een back-upfunctie in het hostingpaneel gebruiken. Bij kleine websites is het vaak voldoende om een gecomprimeerd archief te maken en dat op de nieuwe server uit te pakken. Bij grotere sites is het aan te raden eerst een volledige kopie met rsync te maken en vlak vóór de DNS-wijziging nogmaals te synchroniseren. Dat bespaart veel tijd, vooral bij websites waarvan de uploadmap voortdurend verandert.

Controleer na de bestandsoverdracht de rechten. In het algemeen werken mappen met 755 en bestanden met 644, maar elke applicatie kan eigen eisen hebben. wp-config.php, .env en vergelijkbare gevoelige bestanden mogen niet door iedereen leesbaar zijn. Controleer ook of verborgen bestanden, zoals .htaccess en .user.ini, daadwerkelijk zijn meegekopieerd.

Stap 3: Verhuis de database

De databasemigratie is het meest gevoelige onderdeel als je dataverlies wilt voorkomen. Maak eerst een dump van de oude server en maak daarna op de nieuwe server een database en databasegebruiker aan. Stel de karakterset bij voorkeur in op utf8mb4. Om problemen met accenten en speciale tekens te voorkomen, moet tijdens export en import dezelfde collationstructuur behouden blijven.

Bij websites die continu nieuwe data genereren, zoals WooCommerce-shops of ledenplatforms, is het verstandig om tijdens de verhuizing onderhoudsmodus te gebruiken. Anders kunnen tijdens DNS-propagatie sommige gebruikers data naar de oude server schrijven en andere naar de nieuwe server. Dat veroorzaakt inconsistenties in bestellingen, reacties, formulierinzendingen of ledengegevens. Bij kritieke websites moet de laatste database-dump pas worden gemaakt nadat de onderhoudsmodus is ingeschakeld.

Stap 4: Werk configuratiebestanden bij

Databasenaam, gebruikersnaam, wachtwoord, hostinformatie en bestandspaden moeten worden aangepast aan de nieuwe server. Voor WordPress controleer je wp-config.php, voor Laravel .env en voor maatwerkapplicaties config.php of vergelijkbare bestanden. Als absolute bestandspaden, IP-adressen, SMTP-instellingen of cachemappen van de oude server blijven staan, kan de website aan de voorkant lijken te werken terwijl er op de achtergrond fouten ontstaan.

Pas ook PHP-instellingen zoals memory_limit, upload_max_filesize, post_max_size en max_execution_time aan op de behoefte van je applicatie. Als een beheeromgeving productafbeeldingen van 200 MB moet kunnen uploaden maar de uploadlimiet op 32 MB blijft staan, is de migratie technisch misschien geslaagd, maar kan de dagelijkse operatie alsnog vastlopen.

Stap 5: Test vóórdat je DNS wijzigt

De veiligste migratiepraktijk is testen op de nieuwe server voordat je DNS aanpast. Je kunt hiervoor in het hosts-bestand van je computer je domeinnaam koppelen aan het IP-adres van de nieuwe server. Bezoekers blijven dan de oude server zien, terwijl jij de nieuwe server kunt testen met de echte domeinnaam.

De testlijst moet onder andere deze controles bevatten:

• Openen de homepage, categoriepagina’s, productpagina’s, blogartikelen en contactpagina’s correct?
• Werken formulierverzending, inloggen, wachtwoordherstel en het betaalproces?
• Laden afbeeldingen, CSS- en JavaScript-bestanden volledig?
• Opent het beheerpaneel zonder fouten?
• Is het SSL-certificaat geïnstalleerd voor de juiste domeinnaam?
• Zijn er 404-fouten, 500-fouten, mixed content-meldingen of redirectloops?
• Klopt de robots.txt, sitemap.xml en zijn canonical-tags correct?

Stap 6: Installeer het SSL-certificaat

Bij moderne websites is SSL niet alleen belangrijk voor beveiliging, maar ook voor SEO en vertrouwen van gebruikers. Als je DNS wijzigt voordat SSL op de nieuwe server klaarstaat, kunnen bezoekers een melding zien dat de site niet veilig is. Daarom moet het SSL-certificaat vlak vóór of tegelijk met de DNS-overgang worden voorbereid. Gratis certificaten zoals Let’s Encrypt zijn voor veel websites voldoende; voor zakelijke projecten met betalingen kunnen SSL-opties met een hoger validatieniveau passender zijn.

Controleer na de SSL-installatie of HTTP-adressen met een 301-redirect naar HTTPS verwijzen, of er geen mixed content-fouten zijn en of de sitemap HTTPS-URL’s bevat. Voor SSL-producten en installatieopties kun je SSL certificaten bekijken.

Stap 7: Wijzig de DNS-records

Als de tests succesvol zijn afgerond, verwijs je het A-record in DNS naar het IP-adres van de nieuwe server. Als e-mail ook naar dezelfde server wordt verhuisd, moeten MX-, SPF-, DKIM- en DMARC-records eveneens worden bijgewerkt. Blijft e-mail bij een andere provider, dan moet je de MX-records ongemoeid laten. Een van de meest gemaakte fouten is dat iemand alleen de website wil verhuizen, maar per ongeluk e-mailrecords wijzigt en daardoor het mailverkeer onderbreekt.

DNS-propagatie is meestal binnen enkele minuten tot 24 uur voltooid. Als de TTL vooraf is verlaagd, bereiken de meeste gebruikers de nieuwe server snel. Schakel de oude server in deze periode niet meteen uit. Het is een veilige aanpak om de oude server minimaal 48 uur, en liever 72 uur, bereikbaar te houden.

Stap 8: Voer de laatste synchronisatie uit en controleer logs

Na de DNS-wijziging moet worden gecontroleerd of er nog nieuwe data op de oude server zijn geschreven. Vergelijk vooral bestellingen, contactformulieren, gebruikersregistraties en reacties. Access logs en error logs van de webserver helpen om te zien welke IP-adressen verzoeken naar welke server sturen.

Volg in de eerste 24 uur na de migratie 500-fouten, een stijging in 404’s, trage queries, CPU-pieken en e-mailqueues. Zonder deze controles kan een site aan de buitenkant goed lijken te werken, terwijl er op de achtergrond conversies verloren gaan.

Professionele checklist voor een website verhuizen zonder dataverlies

De onderstaande checklist omvat de punten die in de praktijk het vaakst problemen veroorzaken. Door deze lijst vóór en na de migratie af te vinken, verklein je het migratierisico aanzienlijk.

• De verhuizing is gepland op een moment met weinig verkeer.
• Er is een volledige back-up gemaakt van bestanden, database, e-mail en DNS.
• Er is getest of de back-up geopend en teruggezet kan worden.
• De DNS TTL-waarde is minimaal 24 uur vooraf verlaagd.
• PHP, database en benodigde modules zijn voorbereid op de nieuwe server.
• Bestanden zijn volledig overgezet en rechten zijn gecontroleerd.
• Karakterset en collation van de database zijn gecontroleerd op compatibiliteit.
• Configuratiebestanden zijn bijgewerkt met gegevens van de nieuwe server.
• Er is getest via het hosts-bestand voordat de site live ging.
• SSL is geïnstalleerd en HTTPS-redirects zijn gecontroleerd.
• DNS A-, AAAA-, MX- en TXT-records zijn correct bijgewerkt.
• De oude server is minimaal 48 uur actief gehouden.
• Google Search Console, Analytics en logbestanden zijn gemonitord.

SEO-controles na migratie om rankings te behouden

Een servermigratie hoeft in theorie geen SEO-verlies te veroorzaken zolang de URL-structuur gelijk blijft. In de praktijk kunnen traagheid, 404-fouten, een verkeerde robots.txt, ontbrekende SSL of redirectproblemen echter wel invloed hebben op rankings. Daarom is SEO-controle na de verhuizing net zo belangrijk als de technische migratie zelf.

Controle van URL’s en redirects

Als je tijdens de verhuizing de URL-structuur niet verandert, is de behoefte aan 301-redirects minimaal. Verander je echter tegelijk van domeinnaam, permalinkstructuur of mappenstructuur, dan moeten oude URL’s met een 301-redirect naar hun nieuwe equivalent verwijzen. Een tijdelijke 302-redirect is niet geschikt voor het permanent doorgeven van SEO-signalen. Als de oude pagina /urun/abc bijvoorbeeld verhuist naar /magaza/abc, moet er een één-op-één-redirect worden ingesteld. Alle oude URL’s naar de homepage sturen is slecht voor de gebruikerservaring en kan SEO-prestaties schaden.

Controle van robots.txt en sitemap

Als je tijdens het testen zoekmachines hebt geblokkeerd met een Disallow-regel in robots.txt, moet die blokkade worden verwijderd zodra de site live gaat. Dit is een klassieker onder de oorzaken van indexatieverlies na een migratie. De sitemap moet nieuwe HTTPS-URL’s bevatten en opnieuw worden ingediend via Google Search Console.

Performance en Core Web Vitals

Ook een krachtigere nieuwe server kan traag aanvoelen als caching verkeerd is ingesteld. LiteSpeed Cache, Redis, OPcache, CDN en beeldoptimalisatie moeten goed worden geconfigureerd. Monitor in de eerste week na de verhuizing PageSpeed Insights, Chrome UX Report en serverlogs om te zien of LCP, INP en CLS achteruitgaan. Voor het verbeteren van hostingprestaties kun je gebruikmaken van de content bij WordPress snelheid optimalisatie.

Waar moet je op letten bij e-mailmigratie?

Bij veel websiteverhuizingen worden de webbestanden probleemloos overgezet, maar wordt e-mail vergeten. Als e-mails op de huidige server worden bewaard, moeten mailboxen, gebruikerswachtwoorden, doorstuuradressen en filters worden meegenomen. IMAP-synchronisatie is een betrouwbare methode om berichten uit de oude mailbox naar de nieuwe mailbox over te zetten.

Aan de DNS-kant bepaalt het MX-record de mailserver, SPF de verzendrechten, DKIM de ondertekening en DMARC het domeinbeleid. Als deze records verkeerd worden ingesteld, kunnen e-mails in de spammap belanden of volledig worden geweigerd. Stuur na de migratie testmails naar Gmail, Outlook en zakelijke mailaccounts en controleer de mailheaders.

Veelgemaakte fouten bij servermigratie

Succesvolle migratieprojecten hebben één ding gemeen: eenvoudige fouten worden vooraf voorkomen. De onderstaande fouten komen het vaakst voor:

• Migreren zonder back-up of zonder de back-up te testen.
• Het IP-adres wijzigen zonder vooraf de DNS TTL te verlagen.
• De oude server uitschakelen voordat DNS-propagatie is afgerond.
• De database met een verkeerde karakterset importeren en speciale tekens beschadigen.
• .htaccess- of nginx-redirectregels vergeten.
• HTTPS-verkeer naar de nieuwe server sturen zonder SSL te installeren.
• MX- en TXT-records voor e-mail verkeerd aanpassen.
• Een cacheplugin achterlaten met paden naar de oude server.
• Na de migratie Search Console en serverlogs niet monitoren.

Vooral websites die live verkopen, moeten niet tijdens drukke kantooruren worden verhuisd, maar in een periode waarin verkeer en ordervolume het laagst zijn. Bij grote e-commerceprojecten voorkomt een onderhoudsvenster van 15 tot 30 minuten veel mogelijke data-inconsistenties op de achtergrond.

Wanneer heb je professionele migratieondersteuning nodig?

Een eenvoudige informatieve website kun je vaak handmatig verhuizen, maar in sommige situaties is professionele ondersteuning goedkoper en veiliger. Denk aan webshops met een hoge maandomzet, bedrijven met veel e-mailaccounts, portals met maatwerksoftware, mediasites met veel verkeer en organisaties die gereguleerde data hosten.

Professionele migratieondersteuning bestaat meestal uit vooranalyse, back-up, inrichting van een testomgeving, overdracht, DNS-overgang, verificatie en monitoring. Zo worden niet alleen bestanden verhuisd, maar ook de bedrijfscontinuïteit. Als je overweegt naar de infrastructuur van Hostragons over te stappen, kun je via Hostragons hosting oplossingen hosting-, domein- en SSL-opties samen beoordelen en een passende aanpak kiezen.

Conclusie: een geplande servermigratie voorkomt downtime en dataverlies

Servermigratie is geen proces om bang voor te zijn, zolang het goed wordt gepland. De sleutel tot succes is dat je geen stappen overslaat: volledige back-up, correcte voorbereiding van de nieuwe server, DNS TTL-planning, testomgeving, SSL-installatie, e-mailcontroles en monitoring na de migratie. Vooral bij websites waarvan de database voortdurend verandert, zijn de laatste synchronisatie en onderhoudsmodus cruciaal.

Kortom: wil je een website verhuizen zonder dataverlies, haast je dan niet, verifieer elke stap en zet de oude server niet meteen uit. Als je je infrastructuur wilt vernieuwen en een snellere, veiligere webervaring wilt bieden, kun je de hosting-, domein- en SSL-oplossingen van Hostragons bekijken en rustig een migratieplan opstellen dat past bij jouw situatie.

Veelgestelde vragen

Hoe lang duurt een servermigratie?

De duur hangt af van de grootte en complexiteit van de website. Een kleine WordPress-site kan binnen 30 tot 60 minuten worden verhuisd, terwijl grote webshops of zakelijke projecten met veel e-mailaccounts inclusief voorbereiding, testen en DNS-propagatie 1 tot 3 dagen kunnen duren.

Gaat mijn website offline tijdens een servermigratie?

Met goede planning kan downtime worden beperkt tot enkele minuten, of merken gebruikers helemaal niets. Daarvoor moet de DNS TTL vooraf worden verlaagd, moet de nieuwe server vóór livegang worden getest en moet de oude server actief blijven totdat DNS-propagatie is afgerond.

Wat is de belangrijkste stap om dataverlies te voorkomen?

De belangrijkste stap is een geverifieerde volledige back-up. Bestanden, database, e-mail en DNS-records moeten worden geback-upt. Bij sites die bestellingen of ledengegevens genereren, moet de laatste databaseback-up worden gemaakt nadat de onderhoudsmodus is ingeschakeld.

Heeft servermigratie invloed op SEO-rankings?

Als de URL-structuur behouden blijft, de site snel werkt en SSL en redirects correct zijn ingesteld, veroorzaakt servermigratie op zichzelf geen SEO-verlies. Wel kunnen 404-fouten, een verkeerde robots.txt, een trage server of foutieve 301-redirects rankings negatief beïnvloeden.

Worden e-mailaccounts ook verhuisd bij servermigratie?

Als e-mails op de oude hostingomgeving staan, moeten ze apart worden verhuisd. Mailboxen, doorstuuradressen, filters en MX-, SPF-, DKIM- en DMARC-records moeten worden gecontroleerd. Blijft e-mail bij een andere provider, dan mogen de MX-records niet worden aangepast.