Blog

Tutorials, handleidingen, productnieuws en technische inzichten van het team dat uw hosting draait.

Blog

Website migratie zonder downtime aanpakken

28 juni 2026 7 min. leestijd
Dit bericht delen

Website migratie zonder downtime aanpakken

Een website die tijdens kantooruren ineens niet bereikbaar is, kost meer dan alleen een paar minuten. Offerteaanvragen blijven liggen, bestellingen haken af en medewerkers krijgen direct de vraag wat er mis is. Juist daarom is website migratie zonder downtime voor veel mkb-bedrijven geen luxe, maar een zakelijke randvoorwaarde.

Bij een migratie verplaatst u niet alleen bestanden van A naar B. Vaak gaan ook databases, DNS-instellingen, e-mailkoppelingen, SSL-certificaten, cronjobs, caching, firewallregels en applicatieversies mee. Als daar één schakel verkeerd staat, merkt de bezoeker dat direct. Het goede nieuws is dat uitval meestal te voorkomen is, zolang de migratie niet wordt benaderd als een simpel verhuisdoosje, maar als een gecontroleerde wijziging in uw bedrijfsvoering.

Waarom website migratie zonder downtime vaak misgaat

De meeste problemen ontstaan niet tijdens het kopiëren zelf, maar in de voorbereiding. Een website draait zelden op alleen wat losse bestanden. Er zijn koppelingen met formulieren, betaalproviders, mailboxen, externe API’s, plugins en soms zelfs interne systemen. Wie alleen kijkt naar de homepage, mist al snel wat er op de achtergrond echt nodig is.

Daarnaast wordt DNS nog vaak onderschat. Veel ondernemers horen dat een wijziging “even moet propageren” en nemen aan dat tijdelijke onbereikbaarheid erbij hoort. Dat is niet altijd waar. Met de juiste volgorde en instellingen kunt u de overgang zo plannen dat bezoekers niets of vrijwel niets merken. Het verschil zit in details zoals TTL-waarden, actieve sessies, database-synchronisatie en het moment waarop verkeer wordt omgezet.

Ook tijdsdruk speelt mee. Een website moet “snel even” naar een nieuwe partij, omdat de oude omgeving te duur is, support tekortschiet of prestaties achterblijven. Begrijpelijk, maar haast vergroot de kans op fouten. Zeker bij webshops, klantportalen en websites die continu leads verwerken, is een migratie zonder strak plan vragen om gedoe.

Wat er eerst op tafel moet liggen

Voor een betrouwbare migratie begint u niet met verplaatsen, maar met in kaart brengen. Welke website draait er precies, welke softwareversies zijn actief, welke domeinen en subdomeinen horen erbij, waar staat de DNS en welke mailstromen mogen absoluut niet worden geraakt? Dat klinkt technisch, maar dit is juist het moment waarop u risico’s voorkomt.

Een goede inventarisatie kijkt ook naar piekbelasting en bedrijfsuren. Een restaurant met online reserveringen heeft andere kritieke momenten dan een groothandel die vooral overdag orders ontvangt. Een accountantskantoor wil rond deadlines geen verrassingen. Het ideale migratiemoment verschilt dus per bedrijf.

Verder moet duidelijk zijn of de bestaande omgeving wordt nagebouwd of direct verbeterd. Soms is een één-op-één verhuizing verstandig, omdat u eerst stabiliteit wilt. In andere gevallen is de migratie juist hét moment om verouderde software, trage databaseconfiguraties of rommelige hostinginstellingen op te schonen. Dat kan veel opleveren, maar maakt het traject ook gevoeliger. Daar geldt heel nuchter: hoe meer tegelijk verandert, hoe meer getest moet worden.

Website migratie zonder downtime vraagt om een parallelle omgeving

De veiligste aanpak is meestal een parallelle opzet. Dat betekent dat de nieuwe omgeving volledig wordt ingericht terwijl de huidige website gewoon live blijft. U bouwt dus niet op de productiesite zelf, maar op een kopie die technisch klaarstaat voor de overstap.

In die nieuwe omgeving test u niet alleen of pagina’s laden. U controleert formulieren, inlogfunctionaliteit, redirects, SSL, caching, betaalprocessen, afbeeldingen, zoekfunctie en eventuele koppelingen met CRM of boekhouding. Juist die onderdelen veroorzaken later de meeste supportvragen.

Voor dynamische websites is de database het aandachtspunt. Een informatieve site zonder dagelijkse wijzigingen kunt u relatief eenvoudig kopiëren. Een webshop of portal waar bestellingen en klantdata continu veranderen, vraagt om een slimmere overgang. Dan volstaat één export vaak niet. In dat geval werkt u met een laatste synchronisatie vlak voor livegang, zodat nieuwe gegevens niet verloren gaan.

De rol van DNS, TTL en omschakelmoment

DNS bepaalt naar welke server een domeinnaam verwijst. Wie website migratie zonder downtime serieus aanpakt, bereidt deze stap ruim van tevoren voor. Een veelgebruikte maatregel is het tijdelijk verlagen van de TTL. Daardoor verversen DNS-records sneller en schakelen bezoekers eerder over naar de nieuwe omgeving zodra u de wijziging doorvoert.

Dat klinkt eenvoudig, maar het omschakelmoment moet passen bij de website. Bij een brochurewebsite kan dat vaak buiten piekuren. Bij een webshop of reserveringssysteem is het slimmer om te kiezen voor een moment met weinig transacties, terwijl support wel beschikbaar is als er iets gecontroleerd moet worden.

Belangrijk is ook dat DNS niet het hele verhaal is. Zelfs als het domein goed verwijst, kunnen oude caches, hardcoded instellingen of certificaatproblemen nog roet in het eten gooien. Daarom hoort monitoring direct na de switch standaard bij het proces. Niet afwachten, maar actief controleren.

Testen is geen formaliteit

Veel migraties mislukken op punten die vooraf prima te testen waren. Een contactformulier dat geen mail verstuurt. Een plugin die op de nieuwe PHP-versie foutmeldingen geeft. Een bestelpagina die lokaal werkt, maar in productie vastloopt door een firewallregel. Zulke fouten zijn vervelend, maar zelden verrassend als iemand vooraf goed heeft gekeken.

Praktisch testen betekent dat u werkt met een checklist vanuit echte bedrijfsprocessen. Kan een bezoeker een aanvraag doen? Komt die aanvraag op de juiste plek binnen? Werkt de mobiele versie net zo goed als desktop? Zijn alle redirects correct, zodat u geen verkeer en vindbaarheid verliest? En minstens zo belangrijk: kunnen medewerkers na livegang gewoon verder zonder extra handwerk?

Acceptatietesten met de klantzijde zijn daarbij nuttig. Technisch beheer kan veel controleren, maar de eindgebruiker ziet vaak als eerste of iets in de praktijk logisch blijft werken. Zeker bij websites met maatwerk of veel inhoud is dat geen overbodige stap.

Wanneer nul downtime niet letterlijk nul is

Eerlijk is eerlijk: in sommige situaties betekent website migratie zonder downtime niet dat er technisch absoluut nul seconden risico zijn. Het betekent meestal dat bezoekers en gebruikers geen merkbare onderbreking ervaren. Dat verschil is belangrijk.

Bij statische sites is vrijwel naadloze migratie goed haalbaar. Bij drukke webshops, applicaties met live transacties of complexe multi-serveromgevingen kan een heel kort onderhoudsvenster soms de veiligste keuze zijn. Dat klinkt minder mooi, maar is zakelijk vaak verstandiger dan een geforceerde livegang met dataverlies of inconsistente bestellingen.

De juiste vraag is dus niet alleen: kan het zonder downtime? De betere vraag is: wat is voor uw organisatie de veiligste route met de minste impact? Soms is dat volledig zonder merkbare onderbreking. Soms is een gecontroleerde overgang van een paar minuten verstandiger. Geen mooie praat, wel een oplossing die werkt.

Veelgemaakte fouten bij een migratie

Wat we in de praktijk vaak terugzien, is dat bedrijven te laat beginnen met voorbereiden. Of er wordt alleen naar de website gekeken, terwijl e-mail, DNS en beveiliging bij een hostingwissel net zo belangrijk zijn. Een andere klassieke fout is geen rollback-scenario hebben. Als de nieuwe omgeving niet goed functioneert, moet u direct weten hoe u terugschakelt.

Ook communicatie wordt vaak vergeten. Niet richting bezoekers, maar intern. Als marketing, sales of receptie niet weten dat er een migratie plaatsvindt, worden normale controlepunten gemist en ontstaan er onnodige meldingen. Een kort intern plan voorkomt veel ruis.

Ten slotte is er de onderschatting van nazorg. De livegang is niet het einde van het traject. De eerste uren en dagen daarna wilt u logs controleren, prestaties volgen en kleine afwijkingen direct oppakken. Juist daar maakt een betrokken beheerpartij het verschil. Geen ticketsysteem waar u achteraan moet, maar snel kunnen schakelen als er iets speelt.

Wat mkb-bedrijven vooral nodig hebben

Voor mkb-bedrijven draait dit onderwerp zelden om techniek alleen. Het gaat om continuïteit, voorspelbare kosten en één partij die verantwoordelijkheid neemt. U wilt niet zelf drie leveranciers bellen om uit te zoeken waar het misgaat. U wilt weten dat de migratie is voorbereid, getest en begeleid, en dat er support klaarstaat als er toch iets afwijkt.

Daarom werkt een nuchtere aanpak meestal het best. Eerst inventariseren, dan een testomgeving opzetten, daarna gecontroleerd omschakelen en actief monitoren. Geen onnodig ingewikkelde trajecten, maar ook geen gokwerk. Dat is precies waar een managed partij als NLXS waarde toevoegt: techniek onder één dak, duidelijke communicatie en geen stress als het spannend wordt.

Een goede migratie voelt voor uw klanten alsof er niets gebeurd is. En dat is eigenlijk het hoogste compliment. Als uw website gewoon bereikbaar blijft terwijl onder water alles is verhuisd, dan is het werk goed gedaan. Precies daar moet de lat liggen.

Reacties0

Nog geen reacties

Deel als eerste uw gedachten.

Doe mee aan het gesprek

Meld u aan of registreer u om een reactie te plaatsen.

Mis geen enkel bericht

Ontvang onze nieuwste tutorials, handleidingen en productnieuws in uw inbox.

U bent ingeschreven voor onze nieuwsbrief.