Zo voorkomt u downtime tijdens een migratie

Om tien uur 's avonds begint de migratie. De volgende ochtend om half negen staat de eerste medewerker voor een scherm dat blijft laden, en ontdekt de eerste klant dat afrekenen niet lukt. Zoiets kost meer dan een ongemakkelijke dag. Bestellingen blijven hangen, de supportmailbox loopt vol en het vertrouwen dat u jaren hebt opgebouwd krijgt een deuk.

Downtime voorkomen bij een migratie begint daarom niet bij het kopiëren van data. Het begint bij de vraag welke processen hoe dan ook moeten blijven draaien, en wat er nodig is om dat waar te maken.

Of u nu overstapt op nieuwe hosting, een applicatie moderniseert, een database verplaatst of twee systemen samenvoegt: zo'n wijziging raakt bijna altijd meer dan de omgeving zelf. DNS, e-mail, API-koppelingen, de betaalprovider, voorraadbeheer, de manier waarop mensen hun werk doen. Wie dat pas tijdens de livegang ontdekt, neemt een risico dat te vermijden was.

Één nuance vooraf, want die bepaalt de rest van uw aanpak. Downtime voorkomen betekent in de praktijk zelden dat er nul seconden onbereikbaarheid is. Het betekent dat u ongeplande uitval voorkomt, en dat elke onderbreking die u wél inplant kort, aangekondigd en omkeerbaar is. Dat onderscheid scheelt veel discussie achteraf.

Waarom migraties vaker misgaan dan nodig is

De meeste problemen ontstaan niet omdat een server zich niet laat kopiëren. Ze ontstaan door aannames. Een koppeling blijkt nog een oud IP-adres te gebruiken. Een achtergrondproces schrijft vrolijk door naar de oude database. Een certificaat is nooit meeverhuisd. En dan is er timing: migreren in een rustige week klinkt logisch, tot blijkt dat juist die week niemand beschikbaar is die het dagelijkse proces van binnenuit kent.

De vraag of de nieuwe omgeving technisch werkt, is daarom te smal. De betere vraag is of iedere kritieke handeling nog lukt. Kan een klant afrekenen? Landt een order in het juiste systeem? Krijgt het team zijn meldingen? Klopt de voorraad die iemand op het scherm ziet? Techniek is het middel, continuïteit is het doel.

Omgevingen met veel maatwerk vragen extra aandacht. Standaardchecklists zijn nuttig, maar zeggen weinig over uw boekhoudkoppeling, uw klantportaal of dat importscript dat elke nacht om drie uur draait. Precies die uitzonderingen bepalen of een overgang saai verloopt of eindigt in herstelwerk.

Begin bij de afhankelijkheden

Maak vooraf een overzicht van wat er draait en wat daarvan afhangt. Basaal, dat klopt. En het is de stap die onder tijdsdruk als eerste sneuvelt. Inventariseer niet alleen websites, applicaties en databases, maar ook domeinen en e-mailroutes, cronjobs, externe API's, firewallregels, SSL-certificaten, caching en monitoring.

Koppel daarna elk onderdeel aan een zakelijke functie. Een API is niet zomaar een technische verbinding; het kan de route zijn waarlangs orders bij uw fulfilmentpartij terechtkomen. Een mailserver is niet alleen infrastructuur, maar de plek waar orderbevestigingen en supportvragen binnenkomen. Na die vertaalslag ziet u meteen welke onderdelen geen minuut vertraging verdragen en welke een uurtje kunnen wachten.

Bepaal wat echt niet mag uitvallen

Niet elk systeem heeft dezelfde eisen. Voor een B2B-portaal is een onderhoudsvenster op zondagochtend vaak prima. Voor een webshop met lopende campagnes of klanten in andere tijdzones ligt dat anders, en een SaaS-applicatie met actieve gebruikers vraagt weer iets anders dan een intern systeem dat alleen tussen negen en vijf wordt gebruikt.

Leg per proces twee dingen vast: hoeveel uitval acceptabel is, en hoeveel dataverlies. Die twee worden vaak op één hoop gegooid, terwijl ze iets heel anders meten. Beschikbaarheid gaat over de tijd dat een systeem onbereikbaar is. Dataverlies gaat over wijzigingen die na de laatste synchronisatie niet zijn meegekomen. U kunt binnen vijf minuten weer online zijn en tóch de orders van het afgelopen uur missen. Beide grenzen horen vooraf op papier te staan.

Kies een strategie die past bij het risico

Een eenvoudige site die weinig verandert, verhuist u meestal in één geplande overgang: kopiëren, controleren, verkeer omzetten. Voor een druk platform met transacties is dat te grof. Daar past een gefaseerde aanpak beter, waarbij data meerdere keren wordt gesynchroniseerd en de definitieve omschakeling pas komt na een korte wijzigingsstop.

Soms is tijdelijk parallel draaien de verstandigste keuze. Oude en nieuwe omgeving blijven dan naast elkaar in de lucht, terwijl u verkeer stapsgewijs verplaatst of eerst een kleine groep gebruikers op de nieuwe omgeving laat landen. Dat kost meer voorbereiding en meer beheer. Bij systemen waar een storing direct omzet of productiviteit raakt, is dat het waard.

Complexiteit heeft een prijs, en die prijs is zelf ook een risico. Een constructie die nul downtime belooft maar die niemand in het team volledig doorgrondt, is gevaarlijker dan een eerlijk onderhoudsvenster van tien minuten met een helder pad terug. Kies de eenvoudigste aanpak die uw beschikbaarheidseis haalt, niet de indrukwekkendste.

Test de nieuwe omgeving alsof hij al live staat

Een testpagina die laadt, bewijst alleen dat een testpagina laadt. Werk met realistische scenario's en, waar het mag, met een zorgvuldig behandelde kopie van productiedata. Laat verschillende rollen inloggen. Plaats een bestelling van begin tot eind. Maak een mutatie aan, draai een export, controleer of het systeem aan de andere kant van de koppeling precies ontvangt wat u verwacht.

Vergeet vooral het onzichtbare werk niet: wachtrijen, geplande taken, uitgaande mail, logging, back-ups, zoekindexen en rapportages. Kijk ook naar prestaties onder belasting. Een applicatie die in een rustige testomgeving vlot reageert, kan in productie alsnog vastlopen door andere cachinginstellingen, netwerkregels of een databaseconfiguratie die net iets afwijkt.

En laat de test niet alleen over aan ontwikkelaars en beheerders. Zet er iemand bij die het proces dagelijks uitvoert. Die ziet binnen een minuut dat een order wel wordt aangemaakt maar de verkeerde status krijgt, of dat de export die de planning elke maandag gebruikt ineens ergens anders staat. Technisch correct en werkbaar zijn twee verschillende controles.

De livegang: klein team, duidelijke rollen

Op het moment van omschakelen moet helder zijn wie beslist, wie uitvoert en wie communiceert. Een grote chatgroep waar instructies doorheen rollen werkt zelden. Houd het migratieteam klein en wijs één iemand aan die de voortgang bewaakt en knopen doorhakt zodra iets afwijkt van het plan.

Werk met concrete go/no-go-momenten. Vooraf: is er een recente back-up, is de nieuwe omgeving getest, is iedereen bereikbaar? Tijdens: klopt de datasync, is de DNS-wijziging doorgevoerd, zijn de certificaten actief, doen de koppelingen het, komen de kernprocessen door? Pas als die punten zijn afgevinkt, meldt u de migratie geslaagd. Niet eerder, ook niet als het er goed uitziet.

DNS verdient aparte aandacht. De wijziging zelf is zo gedaan, maar wanneer iedereen hem ziet, hangt af van caching bij providers en op apparaten van gebruikers. Verlaag de TTL ruim van tevoren als uw situatie dat toelaat, en ga er niet van uit dat elke partij zich netjes aan die TTL houdt. Een tijdelijke doorverwijzing, monitoring op de oude omgeving en een plan voor verkeer dat daar nog binnenkomt, halen de scherpe randjes eraf.

Vertel medewerkers vooraf wat ze wel en niet moeten doen. Als iemand tijdens de laatste synchronisatie nog een record aanpast in het oude systeem, lopen de omgevingen uiteen. Een korte wijzigingsstop is dan onvermijdelijk. Maak die zo specifiek mogelijk: welke handelingen liggen stil, vanaf hoe laat, tot wanneer, en bij wie kan iemand terecht met een vraag?

Een terugvalplan is geen teken van twijfel

Migreren zonder terugvalplan is gokken met productie. Als een kritieke controle faalt, moet vooraf vaststaan wanneer u teruggaat, hoe dat gebeurt en wie dat besluit mag nemen. Die grens bepaalt u niet op het moment dat een klant belt.

Een bruikbaar plan beschrijft meer dan 'zet de oude server weer aan'. Wat gebeurt er met de gegevens die intussen zijn veranderd? Welke DNS-instellingen moeten terug? Wat betekent het voor gebruikers die ingelogd zijn? Wie informeert het team en wie de klanten? En hoelang blijft de oude omgeving staan? Wie die meteen opruimt, heeft zijn eigen vluchtroute afgesloten.

Back-ups horen daarbij, maar alleen als u het terugzetten hebt geoefend. Een back-up waarvan niemand weet of hij volledig en actueel is, geeft schijnzekerheid. Test dus niet alleen of de back-up wordt gemaakt, maar ook of hij op een aparte omgeving daadwerkelijk terugkomt, en hoe lang dat duurt.

De uren erna bepalen of het echt goed ging

De eerste uren na een migratie zijn minstens zo belangrijk als de omschakeling zelf, want lang niet alles valt meteen op. Een externe koppeling struikelt pas bij de volgende batch. Een mailprobleem wordt zichtbaar wanneer de eerste klant een formulier verstuurt. Performanceproblemen komen bovendrijven bij de eerste piek, en die kan dagen later liggen.

Monitor dus bereikbaarheid, foutmeldingen, responstijden en serverbelasting, maar volg vooral de bedrijfsflows zelf. Komen orders binnen, worden betalingen bevestigd, gaan notificaties de deur uit, lopen de nachtelijke taken door? Spreek daarbij af wie de meldingen beoordeelt en binnen welke tijd er actie volgt. Monitoring zonder eigenaar is een verzameling grafieken waar niemand naar kijkt.

Bij LJPc zitten ontwikkeling, infrastructuur en support dicht op elkaar. Tijdens een migratie scheelt dat tijd: een melding wordt meteen opgepakt door iemand die de code én de omgeving kent, in plaats van dat leveranciers eerst naar elkaar wijzen. Voor organisaties met maatwerk en bedrijfskritische processen is die korte lijn vaak het verschil tussen een klein oponthoud en een lange storing.

Een geslaagde migratie voelt achteraf bijna saai. Niet omdat er weinig is gebeurd, maar omdat de voorbereiding, de controles en het eigenaarschap hun werk hebben gedaan. Behandel de overstap daarom als een operationeel project met een eigenaar en een planning, niet als een technische klus die u er tussendoor bij doet. Dan blijft uw organisatie bereikbaar terwijl de techniek vooruitgaat.