Door Devolvio · Cloud, software en AI-engineering
Een exitplan is een architectuurvraagstuk
Een overstap vraagt zowel contractuele voorbereiding als technische uitvoering. Opzegtermijnen en exitafspraken horen in het plan. Technische blokkades ontstaan door applicaties die zijn gebouwd op diensten waarvoor geen equivalent bestaat, data in formaten die alleen binnen één platform betekenis hebben, en koppelingen waarvan niemand meer weet wie ze onderhoudt.
Dat betekent dat een exitstrategie niet ontstaat op het moment dat je wilt vertrekken, maar op het moment dat je bouwt. Elke keuze voor een dienst, een dataformaat of een integratiepatroon bepaalt mede hoe duur vertrekken later wordt.
Het doel is niet om alle afhankelijkheden te vermijden. Dat leidt tot een architectuur die overal een abstractielaag heeft en nergens de kracht van het platform gebruikt. Het doel is om te weten welke afhankelijkheden je hebt aanvaard en wat het kost om ze te vervangen.
Begin bij de inventaris, niet bij de oplossing
Een bruikbare inventaris gaat verder dan een lijst servers. Per applicatie leg je vast welke gegevens erin zitten, welke diensten van de leverancier worden gebruikt, welke systemen ermee koppelen en wie eigenaar is.
Juist de koppelingen worden onderschat. Een applicatie die zelfstandig lijkt, blijkt in de praktijk een gedeelde database, een nachtelijke bestandsoverdracht en drie systemen die haar API aanroepen te hebben. Dat bepaalt de volgorde waarin je kunt bewegen.
- Welke diensten van de leverancier gebruikt deze applicatie, en bestaat daar buiten dat platform een alternatief voor?
- Welke data zit erin, hoeveel is het, en in welk formaat kan het eruit?
- Welke systemen zijn afhankelijk van deze applicatie, en wat gebeurt er als zij tijdelijk niets krijgen?
- Wie kan beslissen dat deze applicatie mag verhuizen, en wie test of het gelukt is?
Data-export is de kern, en meestal het zwakste punt
Bijna elke dienst biedt een vorm van export. Veel minder vaak is getest of die export volledig is, of hij binnen een redelijke tijd doorloopt, en of het resultaat elders bruikbaar is.
Drie dingen bepalen of een export in de praktijk werkt. Het formaat: een uitvoer die alleen door hetzelfde product gelezen kan worden, verplaatst het probleem. De volledigheid: metadata, versies, rechten en relaties tussen objecten horen erbij, niet alleen de ruwe records. En de doorlooptijd: bij grote datasets is transport vaak de bepalende factor, niet de export zelf.
De enige manier om dat te weten is het een keer doen. Een representatieve export uitvoeren, elders terugzetten en op volledigheid controleren maakt aannames toetsbaar. De benodigde tijd hangt af van volume, formaat en afhankelijkheden.
Maak exitcriteria testbaar
Een exitcriterium is pas bruikbaar als je kunt aanwijzen wanneer eraan is voldaan. 'Data moet exporteerbaar zijn' is geen criterium; 'de volledige dataset van dit systeem is binnen 48 uur te exporteren in een open formaat en aantoonbaar terug te zetten op een andere omgeving' is dat wel.
- Per systeem: het exportformaat, het maximale tijdvenster en de manier waarop volledigheid wordt gecontroleerd.
- Per component: of er een alternatief bestaat en hoeveel werk de omzetting ongeveer is.
- Per keten: welke koppelingen tijdens de overgang moeten blijven werken en welke tijdelijk stil mogen liggen.
- Per rol: wie de export uitvoert, wie de controle doet en wie het resultaat accepteert.
Een werkbaar stappenplan
- Inventariseer applicaties, data, diensten en koppelingen, en wijs per onderdeel een eigenaar aan.
- Markeer de kritieke afhankelijkheden: onderdelen zonder alternatief of met een onbekende exportroute.
- Beschrijf een doelarchitectuur waar naartoe bewogen wordt, ook als de verhuizing nog niet gepland is.
- Test de export van de twee of drie zwaarste datasets en leg doorlooptijd en bevindingen vast.
- Bepaal de migratievolgorde op basis van koppelingen, niet op basis van applicatiegrootte.
- Schrijf per stap een terugvalscenario en beleg wie mag besluiten dat het gebruikt wordt.
- Plan een periodieke toets, zodat de inventaris en de exports actueel blijven.
Ook op het nieuwe platform
Een exitplan is geen eenmalig document dat je afsluit zodra de migratie klaar is. De nieuwe omgeving vraagt precies dezelfde discipline: een actuele inventaris, geteste exports en beschreven verantwoordelijkheden.
Als dat onderdeel wordt van het reguliere beheer, is een toekomstige verandering — een andere leverancier, een andere architectuur, een fusie — een plan in plaats van een crisis.