← Terug naar blog

Website migreren naar andere hosting: zo doe je dat veilig

16 september 2026
Website migreren naar andere hosting: zo doe je dat veilig

Ja, je kunt je website veilig naar een andere hosting verhuizen zonder noemenswaardige downtime. Kies één van drie routes: een gratis verhuisservice van je nieuwe host, een migratieplugin zoals All-in-One WP Migration, of een handmatige verhuizing via FTP en phpMyAdmin. Wat je ook kiest, maak eerst een volledige backup en test alles op een staging-omgeving of via je hosts-bestand voordat je live gaat.


Kort samengevat:

  • Een succesvolle migratie vereist het maken van een volledige backup en het testen op een staging-omgeving voordat je live gaat, om problemen te voorkomen.
  • Gebruik bij grote of complexe sites een handmatige migratie, automatische plugins of een verhuisservice, en verzamel altijd alle inloggegevens vooraf.
  • Verlaag de TTL-waarde van je DNS vooraf, test via je hosts-bestand, en voer de DNS-wijziging door op een rustig moment om downtime te minimaliseren.
  • Controleer na de verhuizing of SSL-certificaat, e-mail, links, redirects en snelheid correct werken, en houd de oude hosting nog minimaal een week als veiligheidsnet.
  • Gebruik veilige overdrachtstechnieken zoals SFTP, beperk toegang tijdens de migratie en verifieer dat bestandsrechten en configuraties correct zijn ingesteld om beveiligingsrisico's te vermijden.

Sneleenwebsitenodig
Een nieuwe website zonder vooraf betalen
Durfmakers bouwt je website eerst volledig af en toont die op een testadres, zodat je pas betaalt als je hem wilt houden.
Bekijk Durfmakers

Inhoudsopgave

Hoe migreer je een website stap voor stap naar een andere hosting?

Een geslaagde migratie is geen kwestie van geluk, maar van volgorde. Wie de stappen in de juiste reeks doorloopt, voorkomt de meeste problemen die achteraf voor paniek zorgen.

1. Inventariseer je huidige omgeving. Noteer de PHP-versie, actieve plugins of modules, cron jobs, SSL-instellingen en alle inloggegevens (FTP, database, hostingpaneel). Zonder dit overzicht mis je later cruciale instellingen op de nieuwe server.

2. Maak een volledige backup. Sla bestanden, database (als .sql-bestand) én e-mail apart op, zowel lokaal als op een externe locatie. Een backup die alleen op de oude server staat, is geen backup.

3. Richt de nieuwe hosting in. Maak de database aan, controleer of de PHP-versie overeenkomt met je huidige site en regel de SSL-certificaatopties voordat je iets uploadt.

4. Zet bestanden en database over. Upload de bestanden en importeer de database. Test daarna via een staging-URL of door je hosts-bestand aan te passen, zodat je de site kunt bekijken zonder dat bezoekers al iets merken.

5. Wijzig de DNS. Pas het A-record aan of verander de nameservers, afhankelijk van je situatie. Houd de propagatie in de gaten; die kan enkele uren duren.

6. Doe de nazorg. Controleer SSL, formulieren, redirects en e-mail, en zet de oude hosting pas stop nadat je zeker weet dat alles werkt.

Deze volgorde komt terug in vrijwel elke degelijke checklist voor website migreren, en niet zonder reden: elke stap bouwt voort op de vorige.

Pro-tip: Plan de migratie op een moment met weinig verkeer, bijvoorbeeld een rustige avond, zodat een eventuele hik niemand in de weg zit.

Hoe migreer je een website stap voor stap naar een andere hosting? — overview diagram

Verhuisservice, plugin of handmatig: welke methode past bij jouw site?

De juiste methode hangt af van je technische kennis, de grootte van je site en hoeveel controle je wilt houden.

  • Verhuisservice van de nieuwe host: veel Nederlandse hostingproviders bieden dit gratis aan bij een nieuw abonnement. Vraag altijd naar de omvang die ze overnemen (database, e-mail, SSL) en de doorlooptijd, want dit soort diensten verschilt sterk per aanbieder.
  • Migratieplugins zoals All-in-One WP Migration of Duplicator: deze automatiseren export en import van je WordPress-site in één pakket. All-in-One WP Migration werkt met een exportbestand dat je op de nieuwe server importeert; houd rekening met een uploadlimiet bij grotere sites. Duplicator maakt een installer plus zip-archief en is geschikt voor iets grotere installaties.
  • Handmatige migratie via FTP/SFTP: je kopieert bestanden zelf, gebruikt rsync bij grote sites, exporteert de database via phpMyAdmin en past daarna wp-config.php aan met de nieuwe databasegegevens. Dit geeft de meeste controle, maar vraagt ook de meeste kennis.

Welke methode je ook kiest: verzamel eerst alle toegangsgegevens, test grondig vóór je live gaat, en plan bij dynamische sites of webshops een laatste database-synchronisatie kort voor de overschakeling, zodat geen enkele bestelling verloren gaat.

Pro-tip: Bij WordPress staan URL's soms verstopt in serialized data. Gebruik WP-CLI of een tool als Search en Replace DB om ze veilig te vervangen, anders raken links en afbeeldingen stuk.

Hoe pas je DNS aan bij een hostingverhuizing?

Een hostingverhuizing en een domeinnaamverhuizing zijn twee verschillende dingen. Bij een hostingverhuizing verplaats je bestanden en wijzig je waar het domein naar wijst; bij een domeinregistratieverhuizing verplaats je het administratieve beheer van je domeinnaam, en daarvoor heb je een verhuiscode nodig, zoals Theory7 uitlegt.

  • Verlaag de TTL-waarde (Time To Live) van je DNS-record naar ongeveer 300 seconden, 24 uur voordat je de overstap maakt. Dat versnelt de propagatie aanzienlijk.
  • Gebruik een A-recordwijziging als je alleen de hosting verandert en de nameservers gelijk blijven; gebruik een nameserverwijziging als het volledige DNS-beheer verhuist.
  • Vergeet e-mail niet: een verkeerde nameserverwijziging kan ook je mailverkeer platleggen als de MX-records niet meeverhuizen.
  • Test de nieuwe omgeving via je hosts-bestand voordat de DNS daadwerkelijk omgaat. Propagatie duurt meestal een paar uur, in uitzonderlijke gevallen tot 48 uur.

Zet de TTL na de succesvolle overgang weer terug naar de normale waarde, na verloop van tijd.

Hoe migreer je e-mail zonder berichten te verliezen?

E-mail is het onderdeel dat het vaakst wordt vergeten en het meest pijn doet als het misgaat.

  • Inventariseer eerst welke mailaccounts je hebt en of ze via IMAP of POP3 werken. Bij IMAP blijft alles op de server staan; bij POP3 kan mail al lokaal gedownload zijn.
  • Maak dezelfde mailaccounts aan op de nieuwe host en synchroniseer de inhoud met een IMAP-migratietool of een handmatige export/import.
  • Controleer bij de DNS-switch of MX-records, SPF, DKIM en DMARC correct zijn ingesteld op de nieuwe server. Een foutje hier laat je mail rechtstreeks in de spammap van ontvangers belanden.
  • Test versturen en ontvangen vanaf meerdere clients (webmail, telefoon, desktopprogramma) voordat je de oude hosting opzegt.

Wat controleer je direct na de migratie?

De eerste 24 uur en de eerste twee weken na de overstap zijn het moment waarop verborgen fouten alsnog naar boven komen.

  1. Direct na livegang: controleer HTTPS/SSL, de belangrijkste pagina's, contactformulieren en eventuele checkout-processen bij webshops.
  2. Technisch: bekijk foutlogs, controleer of cron jobs weer draaien, of bestandspermissies correct staan en of redirects en .htaccess-regels (of hun Nginx-equivalent) goed zijn overgezet.
  3. SEO en snelheid: meet met PageSpeed Insights en controleer de Core Web Vitals, en speur naar onverwachte 404-pagina's of kapotte redirects.
  4. Rollback-optie: houd de oude hosting minimaal 7 tot 14 dagen actief als vangnet.

Dat je de oude hosting nog even aanhoudt, is geen overbodige voorzichtigheid: het is de meest genoemde veiligheidsmaatregel in stappenplannen voor website migreren, precies omdat een laatste, onverwachte fout zich vaak pas na een paar dagen toont.

Hoe bescherm je gegevens tijdens de overdracht?

Tijdens een migratie staan je bestanden en database tijdelijk op twee plekken tegelijk, en dat vraagt om discipline. Gebruik altijd SFTP of FTPS in plaats van gewone FTP, want die versleutelen het dataverkeer tussen jouw computer en de server. Onversleutelde FTP-verbindingen sturen wachtwoorden in leesbare tekst over het internet, wat een onnodig risico is als je toch een veilig alternatief hebt.

Wees terughoudend met wie toegang krijgt tot inloggegevens tijdens het traject. Als je een extern bureau of freelancer inschakelt, geef tijdelijke toegang met beperkte rechten en verwijder die na afronding, in plaats van je hoofdwachtwoord te delen. Bij de database-export via phpMyAdmin is het slim om het exportbestand niet onbeschermd in een publieke map op de server te laten staan; iedereen die de bestandsnaam raadt, kan anders bij je volledige database.

Controleer ook de bestandspermissies op de nieuwe server. Mappen horen doorgaans op 755 te staan en bestanden op 644; te ruime rechten (zoals 777) maken je site onnodig kwetsbaar voor ongeautoriseerde wijzigingen. Verwijder installatiebestanden van migratieplugins na gebruik, want een vergeten installer-script kan een achterdeur vormen voor kwaadwillenden die de URL toevallig vinden.

Wat doet migratie met je SEO-posities?

Een technisch correcte migratie hoeft geen invloed te hebben op je posities in Google, maar een slordige migratie kan wekenlang schade aanrichten. Het grootste risico is niet de serververhuizing zelf, maar wat er onderweg fout gaat: kapotte interne links, verdwenen redirects of een vergeten canonical tag.

Controleer voor de migratie welke URL-structuur je site heeft en zorg dat die identiek blijft na de overstap. Verandert de structuur toch, dan heb je 301-redirects nodig van elke oude URL naar de nieuwe, anders verliest Google de waarde die aan die pagina's hangt. Vergeet ook je XML-sitemap niet opnieuw te laten genereren en in te dienen via Google Search Console zodra de nieuwe site live staat.

Meet de laadsnelheid vóór en na de migratie met PageSpeed Insights. Een tragere server na de overstap raakt niet alleen de gebruikerservaring, maar ook je Core Web Vitals, die meewegen in de zoekresultaten. Controleer daarnaast of robots.txt niet per ongeluk de hele site blokkeert, iets wat verrassend vaak gebeurt wanneer een staging-configuratie wordt meegenomen naar productie. Blijf de eerste weken na livegang de posities van je belangrijkste zoektermen volgen, zodat je snel kunt ingrijpen bij afwijkingen.

Hoe verhuis je een site die niet op WordPress draait?

De meeste migratiegidsen gaan over WordPress, maar het principe geldt net zo goed voor Joomla, Drupal, Magento of een volledig custom gebouwde site. Het verschil zit vooral in de details.

Bij Joomla en Drupal werkt de database-export via phpMyAdmin vrijwel identiek aan WordPress, maar de configuratiebestanden heten anders: bij Joomla is dat configuration.php, bij Drupal settings.php. Pas daar de databasegegevens van de nieuwe server in aan, net zoals je bij WordPress wp-config.php bijwerkt.

Magento-webshops vragen extra aandacht omdat de cache- en indexeerstructuur na een serverwissel vaak opnieuw opgebouwd moet worden, en de sessiegegevens van klanten in een winkelwagentje niet automatisch meeverhuizen. Een custom-gebouwde site zonder standaard CMS heeft geen pluginoplossing; daar blijft handmatige migratie via SFTP en een directe database-dump de enige route.

Migratieroutes voor verschillende websiteplatforms

Voor statische sites (platte HTML/CSS, of gegenereerd met een static site generator) is de migratie het simpelst: geen database, geen e-mailkoppelingen om te checken, alleen bestanden kopiëren en DNS aanpassen. Bij elk CMS geldt hetzelfde uitgangspunt: test eerst via een hosts-bestand of staging-omgeving, ongeacht welk systeem erachter draait.

Hoe informeer je klanten en collega's tijdens de verhuizing?

Een migratie voelt voor jou als een technisch project, maar voor bezoekers en collega's kan onaangekondigde downtime overkomen als een storing. Kondig een geplande migratie minstens een paar dagen vooraf aan bij collega's die de site beheren, zeker als zij formulieren verwerken of bestellingen opvolgen.

Bij een webshop of site met veel dagelijks verkeer is een korte melding op de site zelf ("we werken aan onderhoud, mogelijk trage momenten") voldoende om verwarring te voorkomen, mocht er toch een korte hik optreden. Informeer ook iedereen die toegang nodig heeft tot nieuwe inloggegevens, zoals een marketingcollega die zelf blogposts plaatst, zodat niemand na de overstap voor een verlopen wachtwoord staat.

Werk je met een extern bureau of freelancer aan de migratie, spreek dan vooraf een vast moment af waarop je bereikbaar bent voor terugkoppeling, en leg vast wie de knop omzet naar de nieuwe DNS-instellingen. Onduidelijkheid over wie waarvoor verantwoordelijk is, is een veelgehoorde oorzaak van vermijdbare downtime.

Hoe voorkom je downtime tijdens de migratie?

Downtime tijdens een migratie is vrijwel altijd te voorkomen, want de site blijft op de oude server bereikbaar terwijl je alles op de nieuwe voorbereidt en test.

Werk zoveel mogelijk op een staging-omgeving of via je hosts-bestand, zodat de site pas na een geslaagde test live gaat. Kies bovendien een rustig moment voor de daadwerkelijke DNS-switch, buiten kantooruren of in het weekend, zodat een eventueel probleem minder bezoekers raakt. Verlaag de TTL-waarde ruim vooraf, zodat de omschakeling zelf sneller verloopt zodra je hem doorvoert.

Voor dynamische sites met veel wijzigingen, zoals webshops, is een laatste database-synchronisatie net voor de switch cruciaal: zo mis je geen bestelling die binnenkomt tussen je laatste backup en het omzetten van de DNS. Houd de oude server actief tot je zeker weet dat alles op de nieuwe omgeving werkt, dat is je vangnet als er toch iets misgaat.

Wat zijn de meest voorkomende fouten en hoe los je ze op?

De meeste migratieproblemen zijn te herleiden tot een paar terugkerende oorzaken.

  1. Witte pagina of foutmelding na de overstap: meestal een PHP-versieverschil tussen oude en nieuwe hosting. Controleer de PHP-versie in het hostingpaneel en zet die gelijk aan de oude omgeving.
  2. Afbeeldingen of links werken niet meer: vaak veroorzaakt door hardgecodeerde URL's in de database. Gebruik WP-CLI of een zoek-en-vervang-tool om oude domeinverwijzingen bij te werken.
  3. SSL-waarschuwing in de browser: het certificaat is nog niet actief op de nieuwe server, of DNS wijst nog naar de oude host. Wacht de propagatie af en installeer het certificaat opnieuw als het probleem blijft.
  4. E-mail komt niet meer aan: controleer of MX-records correct wijzen naar de juiste mailserver en of SPF/DKIM niet per ongeluk zijn overschreven.
  5. Formulieren sturen niets door: vaak een verkeerd ingesteld e-mailadres in het formulierplugin na de overstap, of een ontbrekende PHP-mailfunctie op de nieuwe server.

Loop bij twijfel altijd terug naar je backup: dat is de reden waarom die stap nooit overslaan mag.

Zelf migreren of hulp inschakelen: wat is wijs?

Een migratie is geen hogere wiskunde, maar het vraagt wel geduld en precisie. Bij Durfmakers zien we vaak dat ondernemers een migratie zelf proberen en pas achteraf merken dat een paar uur "even snel" uitgroeit tot een hele avond puzzelen met wp-config.php of een DNS-record dat niet wil propageren.

Heb je een simpele site, wat technische affiniteit en tijd over? Dan is zelf migreren met een plugin of verhuisservice prima te doen. Draai je een webshop, een site met veel maatwerk, of heb je simpelweg geen tijd om risico te lopen op downtime tijdens piekuren? Dan is het inschakelen van hulp de verstandigere keuze.

Wil je het traject overzichtelijk houden, verzamel dan vooraf al je toegangsgegevens op één plek, documenteer welke plugins en aanpassingen actief zijn, en spreek met je hosting of bureau een duidelijk moment af voor de overstap. Bij Durfmakers werken we sowieso pas met een testadres: je ziet en test eerst alles, en beslist daarna pas of je verder gaat.

— Patrick

Bronnen

Wil je meteen aan de slag? De checklist van Start24 loopt stap voor stap door de voorbereiding en nazorg. Voor de pluginroute vind je de officiële download en installatie-instructies op de pagina van All-in-One WP Migration en van Duplicator.

Veelgestelde vragen

Hoe zet ik mijn website over naar een andere webhosting?

Maak eerst een volledige backup van bestanden, database en e-mail, richt daarna de nieuwe hosting in en zet alles over via een verhuisservice, migratieplugin of handmatig met FTP. Test via een staging-omgeving of hosts-bestand voordat je de DNS wijzigt.

Hoe migreer ik mijn website zonder downtime?

Werk op een staging-omgeving of test via je hosts-bestand zodat de site pas live gaat na een geslaagde controle, en voer de DNS-wijziging uit op een rustig moment met een vooraf verlaagde TTL-waarde. Houd de oude hosting nog 7 tot 14 dagen aan als vangnet.

Wat kost het verhuizen van een domeinnaam?

De kosten voor het overzetten van een domeinnaam verschillen per registrar en per extensie (.nl, .com, .eu), en veel providers rekenen alleen de normale verlengingsprijs zonder extra verhuiskosten. Vraag dit bij zowel je huidige als je nieuwe provider concreet na, want tarieven en voorwaarden liggen niet vast.

Hoe zet ik mijn domeinnaam over naar een andere provider?

Vraag bij je huidige registrar een verhuiscode (ook wel autorisatiecode of token genoemd) op en geef die door aan je nieuwe provider, die de overdracht daarmee in gang zet. Dit is een ander proces dan een hostingverhuizing, waarbij alleen de DNS-instellingen wijzigen en het domein bij dezelfde registrar blijft.

Moet ik mijn oude hosting meteen opzeggen na de migratie?

Nee, houd de oude hosting minimaal 7 tot 14 dagen actief nadat de nieuwe site live staat. Zo houd je een directe rollback-optie als er achteraf toch iets misgaat met e-mail, formulieren of DNS-propagatie.

Heb je liever dat een ander de technische kant van je website oppakt, van bouw tot migratie? Bij Durfmakers bouwen we eerst je volledige site op een testadres en betaal je pas als je hem wilt houden, zonder abonnement en met vooraf vaste prijzen.

Aanbevelingen