VPS verhuizen naar een andere provider zonder downtime

Kort antwoord: een VPS verhuis je zonder downtime door de nieuwe server naast de oude op te bouwen, je data in een paar rondes te synchroniseren, alles te testen voordat er één DNS-record verandert, en pas dan om te schakelen met een lage TTL. De oude server blijft draaien tot je zeker weet dat alles werkt. Het echte risico zit zelden in het kopiëren, maar in wat je vergeet: een cronjob, een IP-adres dat bij een externe partij op een toegangslijst staat, of een AAAA-record dat nog naar de oude server wijst.

Deze gids is voor ondernemers en webbouwers die al een VPS hebben en willen overstappen naar een andere provider, bijvoorbeeld omdat de prijs omhoog ging, de support tegenviel of omdat je je data binnen de EU wilt hebben. Kom je van shared hosting, lees dan eerst onze beslisgids voor de stap van shared hosting naar een Cloud VPS. Gaat het alleen om één WordPress-site, dan is onze gids voor een WordPress-verhuizing zonder downtime handiger.

Waarom een serververhuizing anders is dan een siteverhuizing

Bij een website verhuis je bestanden, een database en wat DNS. Op een VPS draait meestal meer: een paar sites, een database die ook een ander systeem gebruikt, Docker-containers, back-upscripts en geplande taken die ooit iemand heeft ingesteld. Daarom begint een goede verhuizing niet met kopiëren, maar met opschrijven wat er draait.

Stap 1: breng in kaart wat er op je huidige VPS draait

Loop de oude server door met deze vragen:

• Welke diensten draaien er? systemctl list-units --type=service --state=running laat het zien. Denk aan webserver, PHP-FPM, database, Redis, mail en eigen applicaties.
• Welke poorten staan open? ss -tlnp laat zien welk proces op welke poort luistert. Alles wat je daar niet herkent, zoek je uit voordat je verhuist.
• Welke geplande taken zijn er? Kijk in de crontab van elke gebruiker (crontab -l -u gebruiker), in /etc/cron.d/ en in de systemd-timers (systemctl list-timers). Een vergeten cronjob is de klassieke stille fout: alles lijkt te werken, tot blijkt dat de back-up een week niet heeft gedraaid.
• Draait er Docker? Noteer de compose-bestanden, de volumes en de images met hun versies. Data in volumes komt niet vanzelf mee als je alleen de compose-bestanden kopieert.
• Wie kan erbij? Gebruikers, SSH-sleutels, sudo-rechten en firewallregels.

Vergeet de afhankelijkheden buiten je server niet

Dit deel gaat makkelijk mis, omdat het niet op de server zelf staat:

• IP-adressen op toegangslijsten. Een betaalprovider, een boekhoudkoppeling, een API of de firewall van een klant laat soms alleen het IP-adres van je oude server toe. Met een nieuw IP-adres stopt die koppeling zonder duidelijke foutmelding.
• Mail. Verstuurt je server zelf mail, dan staat het oude IP-adres waarschijnlijk in je SPF-record. Zet het nieuwe adres erbij voordat je omschakelt, en regel reverse DNS (het PTR-record) voor het nieuwe IP.
• Licenties die aan een IP-adres of hostname vastzitten.
• Monitoring en back-ups die bij de oude provider geregeld zijn. Die verdwijnen als je opzegt.

Stap 2: kies je aanpak, opnieuw opbouwen of kopiëren

Een snapshot van de ene provider is bij een andere provider vaak niet zonder meer te gebruiken, omdat virtualisatie en netwerkinstellingen verschillen. Je kiest dus meestal tussen opnieuw opbouwen of de bestanden kopiëren naar een vers geïnstalleerde server.

Ons advies: bouw de nieuwe server schoon op, maar met dezelfde hoofdversies van PHP, je database en je applicaties als op de oude server. Een verhuizing en een grote upgrade tegelijk maakt het onmogelijk om te zien wat een probleem veroorzaakt. Eerst verhuizen, daarna upgraden. Hoe je een nieuwe server de eerste dag veilig inricht, lees je in een Cloud VPS in gebruik nemen in de eerste 24 uur.

Stap 3: regel de timing en het contract

Kijk vooraf naar de opzegtermijn bij je huidige provider en reken op een periode waarin je twee servers tegelijk betaalt. De oude zeg je pas op als de nieuwe een tijdje probleemloos draait.

Sinds 12 september 2025 geldt de Europese Dataverordening (Data Act). Die geeft klanten van clouddiensten, waaronder servers die je huurt, rechten bij het overstappen. Volgens de leidraad Cloud van de ACM moet het contract onder meer een opzegtermijn van maximaal twee maanden voor het overstappen vastleggen, een overgangsperiode van maximaal 30 kalenderdagen waarin de dienst blijft werken, en minimaal 30 kalenderdagen om je data op te halen. Tot 12 januari 2027 mag een aanbieder alleen kosten rekenen die rechtstreeks met de overstap samenhangen; daarna mogen er geen overstapkosten meer zijn. Hoe dat bij jouw provider uitpakt, staat in je contract.

Stap 4: synchroniseer je data in rondes

Je maakt de grote kopie terwijl de oude server gewoon draait. Daarna kopieer je alleen nog wat er veranderd is.

1. Eerste ronde. Kopieer bestanden met rsync -aHAX --numeric-ids naar de nieuwe server. Bij veel data duurt dat even, maar je bezoekers merken er niets van.
2. Tussenrondes. Draai dezelfde rsync opnieuw. Nu gaan alleen de wijzigingen over, en dat gaat snel.
3. Databases. Bij een kleine database is een dump en import voldoende (bij MySQL of MariaDB met --single-transaction, zodat je een consistente momentopname krijgt). Bij een grote of drukke database zet je de nieuwe server als replica op van de oude. Dan loopt de nieuwe database bij tot het moment dat je omschakelt.
4. Laatste ronde. Die doe je tijdens het omschakelen, zie stap 6.

Stap 5: test de nieuwe server zonder DNS aan te raken

Zet in het hosts-bestand van je eigen computer je domeinnaam op het IP-adres van de nieuwe server. Dan zie jij de nieuwe server en de rest van de wereld nog de oude. Test vooral wat je niet ziet:

• Komen formulieren en transactionele mails aan, en komen ze niet in de spam terecht?
• Werken koppelingen met externe partijen vanaf het nieuwe IP-adres?
• Draaien de cronjobs en timers? Kijk in de logs of ze echt iets gedaan hebben.
• Werkt inloggen, afrekenen of wat je applicatie ook doet, van begin tot eind?

Let op SSL: een Let's Encrypt-certificaat via de gebruikelijke HTTP-controle krijg je pas als de DNS naar de nieuwe server wijst. Kopieer je bestaande certificaten tijdelijk mee, of gebruik de DNS-controle, zodat de nieuwe server vanaf de eerste minuut HTTPS heeft.

Stap 6: schakel om met een lage TTL

Verlaag de TTL van je DNS-records ruim op tijd, bijvoorbeeld naar 300 seconden. "Ruim op tijd" betekent minstens zo lang van tevoren als de huidige TTL: staat die op 24 uur, verlaag hem dan minimaal een dag voor de verhuizing. Staat je DNS bij je oude VPS-provider, verhuis die DNS dan eerst als aparte stap, zodat je niet twee dingen tegelijk verandert.

Op het moment zelf:

1. Zet schrijfacties op de oude server even stil: een onderhoudsmelding, of de applicatie alleen-lezen. Bij een rustige site is dat een kwestie van minuten.
2. Draai de laatste rsync en de laatste database-sync, of promoveer de replica tot hoofddatabase.
3. Wijzig de A-records en de AAAA-records. Een vergeten IPv6-adres stuurt een deel van je bezoekers stilletjes naar de oude server.
4. Laat de oude server tijdelijk verkeer doorsturen naar de nieuwe (bijvoorbeeld met een reverse proxy). Dan komen bezoekers die nog een oud DNS-antwoord in hun cache hebben toch op de nieuwe server uit, en komen alle nieuwe gegevens op één plek terecht.

Heb een terugvalplan

Spreek vooraf af wanneer je teruggaat, bijvoorbeeld als afrekenen na een kwartier nog niet werkt. Terug is dan de DNS-records terugzetten. Gegevens die intussen op de nieuwe server binnenkwamen, moeten dan met de hand terug. Houd het omschakelvenster dus kort.

Stap 7: ruim netjes op, ook voor de AVG

Laat de oude server nog een paar dagen tot een paar weken staan, uitgeschakeld of afgeschermd, als vangnet. Daarna:

• Bewaar een laatste volledige back-up zelf, buiten beide providers.
• Laat de data bij de oude provider verwijderen. Staan er persoonsgegevens op de server, dan is je provider verwerker. Volgens artikel 28 van de AVG wist of retourneert een verwerker na afloop van de dienst de persoonsgegevens. Vraag een schriftelijke bevestiging, dan heb je dat voor je eigen administratie vastgelegd.
• Regel de verwerkersovereenkomst bij je nieuwe provider, en zet hem in je verwerkingsregister. Bij ons hoort die bij elke overeenkomst.
• Haal oude IP-adressen weg uit je SPF-record en uit de toegangslijsten bij externe partijen.
• Zet back-ups en monitoring aan op de nieuwe server, en zet de TTL weer op een normale waarde.
• Werk je documentatie bij. Valt je organisatie onder NIS2, dan vraagt die om aandacht voor de beveiliging van je toeleveringsketen en voor bedrijfscontinuïteit. Een leverancierswissel en je nieuwe herstelprocedure horen dus in je dossier.

Zelf doen of laten doen?

Met Linux-kennis en een overzichtelijke server is dit goed zelf te doen. Draait er veel, of heeft iemand anders de server ooit ingericht, laat het dan doen.

Bij PC Patrol verhuizen we je bestaande site of applicatie naar een Cloud VPS kosteloos. „De verhuizing doen we zelf, niet een externe partij. Loopt er iets anders dan verwacht, dan bel ik je.” We zetten alles klaar, testen op een tijdelijke omgeving en zetten pas daarna de DNS om. We schakelen nooit om op iets dat niet werkt, en je oude omgeving blijft nog even staan als terugvaloptie.

De feiten op een rij, zodat je kunt vergelijken:

• De Cloud VPS-pakketten beginnen bij € 8,78 per maand (Cloud VPS 2: 2 CPU, 4 GB RAM, 40 GB NVMe), exclusief btw, maandelijks opzegbaar en zonder setupkosten.
• De servers staan in een EU-datacenter in Nuremberg, Duitsland, en worden door ons beheerd.
• Dagelijkse externe back-ups zijn niet standaard inbegrepen. Je zet ze aan bij het bestellen, voor € 1,20 per maand, met zeven dagen bewaartermijn in een gescheiden datacenter.
• Wil je de server na de verhuizing niet zelf bijhouden, dan nemen we met Managed Cloud de updates, beveiliging en monitoring over, voor € 29,50 per maand plus eenmalig € 149 onboarding.
• Support is er op werkdagen van 9 tot 17 uur. Een vastgelegde reactietijd, ook 's avonds en in het weekend, krijg je alleen met Managed Cloud Business-critical.

Veelgestelde vragen

Kan een VPS-verhuizing echt zonder downtime?

Voor bezoekers meestal wel, als je de stappen hierboven volgt. Bij applicaties die continu schrijven, zoals een drukke webshop, staan schrijfacties vaak een kort moment stil. Met databasereplicatie en een reverse proxy op de oude server houd je dat moment zo kort mogelijk.

Krijg ik mijn IP-adres mee naar de nieuwe provider?

Meestal niet. IP-adressen horen bij het netwerk van de provider. Ga er dus van uit dat je een nieuw IP-adres krijgt, en werk alle plekken bij waar het oude adres in staat.

Twijfel je of je de verhuizing zelf doet, of welke configuratie je nodig hebt? Bel even op 085 130 8931. We kijken mee naar wat er nu draait en zeggen het ook als een kleiner pakket volstaat.