De echte kosten van overstappen naar een nieuwe tool worden vaak pas zichtbaar nadat de migratie is begonnen. Accountkoppelingen, omgevingsconfiguraties, netwerkuitgangen, teamrechten en het aanhouden van de oude omgeving bepalen of de migratie soepel verloopt of dubbel werk oplevert.
Overstappen op een andere tool voor omgevingsbeheer lijkt op het eerste gezicht simpel: software installeren en gegevens exporteren.
De meeste tijd gaat echter zitten in details die normaal weinig aandacht krijgen: kunnen de koppelingen tussen tientallen accounts en omgevingen worden meegenomen? Moeten omgevingsinstellingen volledig opnieuw worden opgebouwd? Blijven de bestaande werkwijzen van het team geldig? Kan de oude omgeving echt dezelfde dag uit? Als dit soort vragen tijdens de besluitvorming niet is uitgewerkt, verandert een migratie al snel in herstelwerk.
Controleer eerst of accounts en omgevingen correct gekoppeld kunnen blijven
Wat moet worden overgezet zijn niet alleen gebruikersnamen en wachtwoorden, maar de volledige mapping van welk account in welke omgeving draait en welke netwerkuitgang aan die omgeving is gekoppeld. Kan die mapping niet worden geëxporteerd, dan komt de migratie in feite neer op handmatig opnieuw opbouwen. Bij tientallen of honderden accounts zijn fouten dan bijna onvermijdelijk.
De controle is eenvoudig: bekijk in de oude tool de exportfunctie en controleer of de geëxporteerde velden omgevings-ID's en netwerkconfiguratie bevatten. Als alleen accounts en wachtwoorden worden geëxporteerd, heb je er voor deze mapping nauwelijks iets aan.
Omgevingsconfiguratie moet worden herbouwd, niet gekopieerd
Fingerprintparameters, tijdzone en taal, en de gekoppelde uitgang vormen de kern van een omgeving. De parametersystemen van verschillende tools zijn echter niet universeel. Waarden één voor één overzetten levert vaak een onvolledig of niet-passend resultaat op.
Praktischer is het om de configuratie-intentie vast te leggen, bijvoorbeeld regio Verenigde Staten, Windows en een bepaalde hardwareklasse, en de omgeving in de nieuwe tool opnieuw op te bouwen op basis van die intentie. Het doel is een consistente, bruikbare omgeving, niet een exacte kopie van de oude.
Cookies en aanmeldstatus
Voor accounts die aangemeld moeten blijven, bepaalt de overdraagbaarheid van de sessiestatus of alles na de migratie opnieuw moet inloggen. Een makkelijk gemist punt is dat tientallen accounts die op dezelfde dag opnieuw inloggen op zichzelf al een afwijkend signaal vormen. Spreid het tempo daarom en voer de omschakeling niet in één keer uit.
Is de koppeling van de netwerkuitgang compatibel?
Als de uitgang via de omgeving is gekoppeld, moet worden gecontroleerd of de nieuwe tool hetzelfde protocol en dezelfde koppelingsmethode ondersteunt. Zo niet, dan moet de volledige netwerkconfiguratie opnieuw worden opgebouwd. Die werklast hoort vooraf in de planning te staan.
Worden de werkgewoonten van het team onderbroken?
Is het rechtenmodel vergelijkbaar? Kunnen teamleden werken zonder wachtwoorden aan elkaar door te geven? Zijn activiteitenlogs nog beschikbaar? Deze drie punten bepalen hoeveel het team opnieuw moet leren. Hoe groter het team, hoe hoger deze kosten.
Moet de oude omgeving nog een tijdje blijven bestaan?
Een migratie hoeft niet in één stap te worden afgerond. De oude omgeving nog een paar weken beschikbaar houden is vaak nuttiger dan gedacht: je kunt haar vergelijken met de nieuwe omgeving, accounts met problemen tijdens de migratie afhandelen en terugvallen als de nieuwe tool onverwachte problemen vertoont.
De overgang plannen
Voer in de eerste één tot twee weken eerst een kleine proefmigratie uit met vijf tot tien minder belangrijke accounts en doorloop het volledige bedrijfsproces. Het doel is te testen of de nieuwe tool echte werkzaamheden aankan, niet hoe lang de functielijst is.
Daarna volgt een observatieperiode van twee tot vier weken. Houd de operationele werkwijze zo dicht mogelijk bij de oude situatie en vergelijk de accountstabiliteit, de frequentie waarmee verificaties worden geactiveerd en het succespercentage van taken aan beide kanten. Als de nieuwe omgeving dan duidelijk slechter presteert, zijn de kosten van terugdraaien nog laag.
Migreer tot slot in batches op basis van bedrijfsbelang. Laat nieuwe aanmeldingen binnen één batch niet allemaal op hetzelfde moment plaatsvinden. Vermijd tijdens de migratie ook andere gelijktijdige wijzigingen, zoals een andere contentstrategie, omdat anders moeilijk is vast te stellen wat een probleem heeft veroorzaakt.
Veelvoorkomende beoordelingsfouten
Alleen naar de softwareprijs kijken en op basis daarvan migreren betekent dat zichtbare kosten worden verward met totale kosten. Personeelsuren, schommelingen in de bedrijfsvoering tijdens de overgang en mogelijk accountverlies zijn samen vaak veel groter dan de besparing op software.
Een andere fout is migreren om het migreren. Als de huidige tool aan de eisen voldoet, is overstappen alleen omdat een nieuwe tool meer functies heeft vaak moeilijk te rechtvaardigen. Breng eerst concreet in kaart waar de huidige tool tekortschiet en bepaal daarna of de nieuwe tool die punten daadwerkelijk oplost.
Het riskantst is alle accounts tegelijk overzetten. Daarmee wordt al het risico op één moment geconcentreerd. Als er iets misgaat, is er geen uitweg meer.
Beantwoord vóór de beslissing drie vragen
Wat is precies het probleem met de huidige tool? Maak het concreet per scenario in plaats van alleen te zeggen dat de tool niet prettig werkt. Kan de nieuwe tool deze problemen aantoonbaar oplossen, bij voorkeur al tijdens de proefmigratie? En als de migratie mislukt, wat zijn dan de kosten, kan er worden teruggedraaid en hoe lang duurt dat?
Begin pas wanneer op alle drie de vragen een duidelijk antwoord bestaat.
