Website migreren naar nieuwe hosting zonder downtime

"We willen graag van hosting wisselen, maar de site mag absoluut niet uit de lucht — wij draaien e-commerce." Bekende vraag. En het kan, mits je het goed plant. De truc is dat je niet "knipt en plakt" tussen twee hosters, maar werkt met een overlapping van een paar dagen waarin beide hosters live zijn — en je via een paar slimme technieken zorgt dat de overgang voor bezoekers ongemerkt verloopt.

Dit artikel beschrijft de complete werkwijze, in de volgorde waarin ik ze zelf uitvoer.

Voorbereiding: wat moet je weten vóór je begint

Voordat je iets verplaatst, breng het volgende in kaart:

• Huidige hosting: provider, type pakket (shared/VPS/dedicated), control panel (cPanel, Plesk, DirectAdmin), OS, PHP-versie, MySQL/MariaDB-versie
• Nieuwe hosting: idem — let op compatibiliteit. Oudere CMS-versies werken soms niet met PHP 8.2+, en nieuwe MariaDB-versies hebben strikter SQL-strict-mode
• DNS-provider: heb je toegang tot DNS-management? Bij sommige bundels regelt de hosting dit automatisch; bij andere is DNS apart geregeld bij je registrar of bij Cloudflare
• Mail: wordt mail bij de huidige hosting afgehandeld of via een aparte provider zoals Microsoft 365? Mail-migratie is vaak het pijnlijkste deel — daarover later meer
• Externe diensten: CDN, betaalintegraties, CRM-koppelingen, monitoring, externe API's — alles wat naar je domein verwijst of vanaf je domein wordt aangeroepen
• SSL: is er een Let's Encrypt-certificaat dat automatisch geregeld wordt door beide hosters? Of een betaald certificaat dat je moet meenemen?

Hou een document bij met alle credentials, URL's, en wijzigingen die je gaat doorvoeren. Tijdens de migratie zelf is dit document goud waard — je zoekt niet midden in de uitvoering naar een wachtwoord of IP.

Stap 1: TTL verlagen — 24 tot 72 uur vooraf

DNS heeft een Time-to-Live (TTL) waarde die bepaalt hoe lang een record gecached wordt. Standaard is dit vaak 14400 seconden (4 uur) tot 86400 (24 uur).

Verlaag de TTL van je A-records (en CNAME, MX als die meegaan) naar 300 seconden — minimaal 24 uur vóór de migratie. Dat zorgt ervoor dat de uiteindelijke DNS-switch binnen 5 minuten wereldwijd actief is, niet pas na 24 uur. Zonder TTL-verlaging zit je in een limbo waarin sommige bezoekers de oude site krijgen, anderen de nieuwe — terwijl jij maar moet hopen dat het allemaal goed gaat.

Na een succesvolle migratie zet je TTL weer terug op 3600 of hoger. Lange TTL = minder DNS-belasting, snellere DNS-resolves voor bezoekers.

Niet zeker over DNS records en TTL? Lees dan eerst het DNS-records artikel — daar staat de basis.

Stap 2: Complete backup

Backup bestaat uit drie delen:

1. Files: alles in de webroot, plus configuratie buiten de webroot indien aanwezig (bv. vendor/ in moderne PHP-applicaties). Tools: SFTP voor kleine sites, of efficiënter via SSH met rsync of een tarball:

   tar czf site-backup.tar.gz public_html/

2. Database: mysqldump via SSH is het meest betrouwbaar voor grotere databases:

   mysqldump --single-transaction --quick \
     --user=DBUSER --password DBNAME > database.sql

   Voor kleinere databases werkt phpMyAdmin ook, mits onder de ~500MB.
3. Mailboxen: vaak vergeten, niet zelden de oorzaak van veel pijn na een migratie. Tools: imapsync voor server-naar-server (zie ook stap 9 hieronder)

Stap 3: Site klonen op nieuwe hosting

Op de nieuwe hosting:

1. Maak een database aan via het control panel (let op: nieuwe credentials, vergelijkbare naam)
2. Importeer de database dump
3. Upload alle files via SFTP, of efficiënter via SSH met rsync
4. Update je config-file met nieuwe database credentials:
   • WordPress: wp-config.php — de DB_NAME, DB_USER, DB_PASSWORD, DB_HOST regels
   • Drupal: sites/default/settings.php
   • Joomla: configuration.php
   • OpenCart: config.php én admin/config.php (twee bestanden)
   • CMS Made Simple: config.php

Op dit moment heb je een complete kopie van je site op nieuwe hosting, maar nog niemand bezoekt 'm — DNS wijst nog naar de oude.

Stap 4: Testen via /etc/hosts (zonder DNS te wijzigen)

Hier zit de kracht van een nette migratie: je kunt de nieuwe site volledig testen zonder iets aan de DNS te veranderen. Werkwijze:

1. Vraag het IP-adres van je nieuwe hosting op (vaak in het control panel of in de welkomstmail)
2. Open je hosts-bestand:
   • macOS / Linux: /etc/hosts
   • Windows: C:\Windows\System32\drivers\etc\hosts
3. Voeg een regel toe:

   123.45.67.89  jouwsite.nl  www.jouwsite.nl

4. Sla op (vereist admin/sudo) en flush je DNS-cache:
   • macOS: sudo dscacheutil -flushcache
   • Linux (systemd): sudo resolvectl flush-caches
   • Windows: ipconfig /flushdns

Nu wijst alleen jouw computer naar de nieuwe server, terwijl alle andere bezoekers nog naar de oude gaan. Doorloop op de nieuwe site:

• Volledige doorklik-check: homepage, category-pagina's, product-pagina's, contactformulier, login/registratie, betaling-flow
• Performance-check (snelheid van laden)
• HTTPS-check: heeft de nieuwe hosting al een geldig SSL-certificaat?
• Mail van formulieren: wordt er echt verzonden? (Test echt versturen — niet alleen "lijkt te werken")
• Zoekfunctie, filters, sortering
• Mobile- en desktop-rendering
• WordPress: alle plugins testen — sommige hebben hardcoded configuratie die per server verschilt

Vind je een issue, los het op vóór je verder gaat. De hosts-truc is je veiligheidsnet — gebruik 'm tot je 100% zeker bent dat de nieuwe site werkt.

Vergeet niet: na het testen die regel uit je hosts-file halen, anders blijft jouw computer naar de nieuwe site gaan terwijl iedereen anders nog naar de oude gaat — heel verwarrend tijdens debuggen later.

Stap 5: Final database sync (voor actieve sites)

Bij een statische brochure-site kun je deze stap overslaan. Maar als je site dagelijks updates krijgt — orders, blog-posts, contact-submissions, voorraad-mutaties — dan zit er nieuwe data in de oude database die de nieuwe nog niet heeft.

Aanpak:

1. Zet de oude site in maintenance mode (geen nieuwe writes meer). Voor WordPress: een plugin als "WP Maintenance Mode". Voor anderen: een plaatje of statische HTML-pagina via .htaccess:

   RewriteEngine On
   RewriteCond %{REMOTE_ADDR} !^123\.45\.67\.89$
   RewriteRule .* /maintenance.html [R=503,L]

2. Maak een nieuwe database dump van de oude site
3. Importeer over de bestaande nieuwe database (drop existing + import, of selectief tabellen)
4. Voor file-uploads die in de tussentijd zijn gemaakt: sync via rsync:

   rsync -avz oude-server:/public_html/wp-content/uploads/ ./uploads/

Dit "downtime venster" duurt typisch 5-15 minuten, afhankelijk van database-grootte. Plan het in een rustig moment (vroege ochtend, of laat in de avond voor B2C, weekend voor B2B).

Stap 6: De DNS-switch

Het moment van de waarheid:

1. Log in bij je DNS-provider (registrar of Cloudflare, afhankelijk van je setup)
2. Wijzig de A-record van @ (jouw root domein) naar het nieuwe IP
3. Wijzig de A-record (of CNAME) van www ook
4. Niet vergeten: MX-records als mail meeverhuist, TXT-records voor SPF
5. Sla op

Dankzij de verlaagde TTL is de switch binnen 5 minuten wereldwijd actief. Sommige hardnekkige resolvers (en routers met eigen cache) houden de oude waarde nog wat langer aan, maar binnen een uur ziet 99% van het verkeer de nieuwe site.

Stap 7: Monitoring en validatie

Eerste uren na de switch:

• Test je site vanaf verschillende devices en netwerken (mobile data, andere wifi-netwerk)
• Test mail in/out
• Check server logs op de NIEUWE hosting voor ongebruikelijke 404's of errors
• Houd de OUDE hosting nog 7-14 dagen actief — voor het geval een DNS-cache ergens hardnekkig is, of voor het geval er iets terug moet

Tools om te checken:

• DNS-propagatie wereldwijd: dnschecker.org — ziet welke locaties al de nieuwe waarde hebben
• Uptime-monitoring: UptimeRobot of BetterUptime — krijg een mail als je site offline gaat
• Server logs: Apache access_log via control panel — zie welke pagina's bezocht worden en welke fouten geven

Veelvoorkomende valkuilen

Hardcoded URL's in database

Vooral bij WordPress en Drupal staan vaak absolute URL's (https://oude-site.nl/wp-content/uploads/...) hardcoded in de database. Niet bij een echte hosting-migratie naar hetzelfde domein, maar wel bij een verhuizing naar een ander domein. Search-and-replace via:

• WordPress: wp search-replace 'oude-domein.nl' 'nieuw-domein.nl' via WP-CLI
• Drupal: drush sql-sanitize met aangepaste config, of de "Search and Replace" module

Vergeet de serialized data niet — gewone SQL UPDATE breekt PHP-serialized strings (bv. widget-instellingen). Gebruik altijd een tool die dat correct afhandelt.

SPF-records klopen niet meer

Nieuwe hosting heeft een ander mailserver-IP. Update je SPF-record in DNS naar de nieuwe include: of IP-range. Anders gaan je outgoing mails (vooral van WordPress-formulieren) naar spam. Zie het SPF/DKIM/DMARC artikel voor de details.

Cache-plugins serveren oude config

Redis/memcached caches op de oude server, of cache-files in /wp-content/cache/ kunnen oude config cachen. Direct na de switch: alle caches flushen, eventueel cache-plugins tijdelijk deactiveren tot je zeker weet dat alles werkt.

File permissions verschillen

Nieuwe hosting kan andere user/group gebruiken. Files moeten voor de webserver-user leesbaar zijn — typisch www-data, apache of nobody. Bij rare permissie-issues:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Sommige hosters hebben specifieke ownership-vereisten — vraag dit na bij de support.

PHP-versieverschil

Oude WordPress (5.x) of OpenCart (2.x) werkt soms niet op PHP 8.2+. Test eerst, of forceer de PHP-versie via .htaccess waar dat kan (zie het .htaccess artikel).

SSL niet automatisch op nieuwe hosting

Sommige hostingpakketten genereren Let's Encrypt automatisch zodra DNS gewijzigd is — andere vereisen handmatig instellen. Gevolg: na de DNS-switch krijgen bezoekers een SSL-waarschuwing. Configureer SSL vóór de switch waar mogelijk.

Vergeten subdomeinen of applicaties

Heb je shop.jouwsite.nl draaien op een ander platform, of blog.jouwsite.nl via WordPress.com? Die DNS-records moeten ook meeschuiven. Maak vooraf een complete lijst van alle DNS-records, dan vergeet je niets.

E-mail apart: vaak het pijnlijkste deel

Mailboxen verhuizen vraagt om aparte aandacht. Je verplaatst niet alleen "een mailaccount" — je verplaatst potentieel jaren aan correspondentie, contacten, filters, en autoresponders.

Aanpak in volgorde:

1. Inventariseer alle mailaccounts die op de oude hosting draaien
2. Maak op de nieuwe hosting alle accounts aan met dezelfde namen — niet per se met dezelfde wachtwoorden, dat veranderen we later toch
3. Sync mailboxen met imapsync: open source CLI tool voor server-to-server IMAP-sync, inclusief mappen en flags. Werkt verbluffend goed:

   imapsync --host1 oude.host --user1 info@jouwsite.nl --password1 PASS \
            --host2 nieuwe.host --user2 info@jouwsite.nl --password2 PASS

4. SPF / DKIM / DMARC records bijwerken naar nieuwe mailserver — anders gaan outgoing mails naar spam
5. Autoresponders en filters opnieuw instellen — vrijwel nooit migreren die mee
6. E-mail clients herconfigureren — Outlook, Mail, Thunderbird op klantdevices. Geef ze de nieuwe IMAP/SMTP-instellingen vooraf door zodat ze direct kunnen overschakelen na de DNS-switch

Wanneer schakel je hulp in?

• De site is groter dan 5GB of de database meer dan 1GB — dat zijn andere tools en strategieën
• E-commerce site met live orders die niet stil kan staan
• Multi-site WordPress installatie
• Custom development boven de standaard CMS — bv. eigen API's of integraties die per hosting-omgeving config-aanpassingen vereisen
• Migratie tussen verschillende control panels (cPanel → Plesk, of Plesk → DirectAdmin) waarbij je veel handmatig moet hertypen
• Mail-migratie met 50+ accounts, of mailboxen van meer dan 5GB per stuk
• Je hebt geen SSH-toegang en bent afhankelijk van de filemanager + phpMyAdmin — voor grote sites kost dat dagen

Een doordachte migratie van een gemiddelde site kost een halve tot hele dag. Als je het zelf doet, plan dan een rustige periode in en zorg dat je een backup hebt waarvan je weet dat 'ie restorebaar is — dat is je echte vangnet als iets misgaat.