Waarom wachten met migreren je meer kost dan je denkt

Wat kost het je om niet te migreren?

Het makkelijkste antwoord is: risico. Een oude versie die niet meer wordt ondersteund door Microsoft is kwetsbaar. Geen updates, geen beveiligingspatches, geen vangnet als er iets misgaat. Voor de IT-afdeling is dat meestal de reden om aan de bel te trekken.

Maar Ieva wijst op iets dat minstens zo belangrijk is en vaak dichter bij de directietafel ligt: concurrentiekracht. Wie op een oud systeem blijft zitten, mist de automatiseringen en AI-functionaliteit die Microsoft continu toevoegt. Het werk dat automatisch zou kunnen, blijft handwerk. En terwijl dat gebeurt, bewegen concurrenten die wel zijn gemigreerd sneller. Elk jaar uitstel is dus niet alleen een technisch risico, het is ook een jaar achterstand op de rest van de markt.

Dat raakt precies de vragen die spelen op directieniveau. Een CEO wil weten of het bedrijf klaar is om te groeien en verkoopbaar te blijven, zonder dat maatwerk en een verouderd systeem in de weg zitten. Een CFO wil grip op kosten en een helder beeld van waar het geld naartoe gaat, in plaats van verrassingen. Een COO wil dat processen soepel lopen, met minder handmatig werk en meer overzicht. Business Central is gebouwd om precies op die vragen antwoord te geven, maar dan moet je wel op een versie zitten die het toelaat.

De eerste vraag is geen IT-vraag

Een van de meest waardevolle inzichten uit het gesprek is dat migreren in de kern geen technisch vraagstuk is. Het is een strategische keuze. Voordat er ook maar één technisch gesprek wordt gevoerd, moet een organisatie voor zichzelf beantwoorden: wat willen we bereiken, en hoe past IT daarbij?

Ieva noemt dit expliciet als het beginpunt. Weet je niet waar je over een jaar wilt staan als bedrijf, dan is het ook lastig te bepalen hoe je systeem daarbij moet helpen. Pas als die richting helder is, kun je zinvol nadenken over het technische pad.

Een goede analyse voorkomt een hoop ellende

Zodra de strategische knoop is doorgehakt, begint het echte werk: uitzoeken wat er precies op het huidige systeem gebeurt. Dat klinkt simpel, maar in de praktijk is dit vaak de fase waar het misgaat. Systemen zijn in de loop der jaren aangepast, teams zijn gewisseld, soms is zelfs de implementatiepartner veranderd. Het gevolg is dat niemand meer precies weet wat er allemaal in het systeem zit en waarom.

Daarom start elk goed migratietraject met een gedetailleerde analyse. Met tooling zoals de Objects usage log tool, breng je in kaart welke onderdelen van het systeem daadwerkelijk worden gebruikt. Dat voorkomt dat je tien jaar oude maatwerkoplossingen meesleept die niemand meer nodig heeft, en zorgt er tegelijk voor dat de functionaliteit die er echt toe doet niet verloren gaat. Sommige workarounds van vroeger blijken bovendien standaard beschikbaar te zijn in de nieuwste versie, waardoor je ze helemaal niet hoeft over te zetten.

Deze analysefase is ook de plek waar veel migraties struikelen als ze zonder ervaring worden aangepakt. Wie maar eens in de paar jaar een migratie doet, mist het referentiekader om goed in te schatten. Een partner die dit dagelijks doet, heeft dat scherpe beeld juist wel, simpelweg omdat elk project de aanpak verder aanscherpt.

Verhuizen, verbouwen of alles slopen: drie manieren om te migreren

Om het wat tastbaarder te maken, gebruikt Dirko een treffende vergelijking: migreren is als verhuizen. Er zijn grofweg drie manieren om dat te doen.

De eerste is de verbouwing. Je behoudt je oude meubels, oftewel je data en historie, maar je knapt het huis op naar de nieuwste standaard. Dit heet een clean migratie: je gaat naar de nieuwste versie van Business Central, met al je bestaande gegevens intact, maar zonder overbodige ballast mee te slepen.

De tweede optie is alles in één keer meenemen zoals het nu is, ook wel een as-is migratie genoemd. Je verhuist met je complete inboedel, inclusief alles wat je misschien niet meer gebruikt. Sneller in sommige gevallen, maar je neemt ook meteen alle rommel mee die zich heeft opgestapeld.

De derde optie is radicaler: het huis slopen en opnieuw bouwen. Dat is een volledige herimplementatie. Deze route kies je meestal als het bestaande systeem zo complex of verweven is geraakt dat renoveren niet meer efficiënt is.

Interessant is dat deze opties niet strikt gescheiden hoeven te zijn. Soms is de slimste keuze een combinatie: je haalt bijvoorbeeld je keuken eruit, zoals Dirko het verwoordt, en behoudt die tijdens de verbouwing, terwijl de rest van het huis opnieuw wordt opgebouwd. In de praktijk betekent dit dat een deel van de functionaliteit technisch wordt gemigreerd, terwijl een ander deel opnieuw wordt geïmplementeerd. Dat kan aanzienlijk sneller en voordeliger zijn dan een volledige herimplementatie, en past goed bij grotere of complexere organisaties waar niet alles evenveel aandacht nodig heeft.

Waarom migraties uitlopen (en hoe je dat voorkomt)

Een migratie die uit de hand loopt, komt vrijwel altijd terug op hetzelfde probleem: de scope was niet duidelijk. Zonder scherp afgebakende reikwijdte begint een project, maar weet niemand precies waar het eindigt. Ontwikkelaars proberen migratietaken tussen ander werk door te proppen, prioriteiten schuiven steeds, en wat drie tot zes maanden had moeten duren, sleept zich jaren voort.

De oplossing klinkt eenvoudig maar vraagt discipline: behandel de migratie als een strategisch project met een duidelijke tijdlijn, vaste prioriteit en een partner die het proces vanaf de eerste dag begeleidt. Voor grotere trajecten is drie tot zes maanden een realistisch en haalbaar tempo, mits scope, kosten en planning vanaf het begin onder controle zijn.

Voor organisaties die nog met klassieke NAV versies werken, geldt vaak een extra stap. In plaats van in één keer naar de nieuwste cloudversie te springen, is het verstandig om gefaseerd te werk te gaan, met een tussenstap en telkens een nieuwe analyse voordat je verdergaat. Zo behoud je grip op elke fase in plaats van in het diepe te springen.

De belangrijkste vraag blijft: wat willen we bereiken?

Voor een directeur die al vijftien jaar op hetzelfde systeem draait, voelt migreren al snel als een kostenpost zonder duidelijke opbrengst. Maar de vraag die daaraan vooraf zou moeten gaan, is niet "wat kost dit", maar "wat willen we als bedrijf bereiken en past ons huidige systeem daar nog bij". Vanuit die vraag wordt de rest logischer: eerst helderheid over de strategie, dan een gedegen analyse van wat er werkelijk wordt gebruikt, en pas daarna de keuze voor de route die daarbij past.

Uitstel is soms een bewuste en verstandige keuze, bijvoorbeeld omdat de strategische richting nog niet vaststaat. Maar uitstel uit gewoonte of onduidelijkheid is iets anders. Zoals Ieva het treffend samenvat: begrijp waar je naartoe wilt, begrijp wat het kost, en begrijp hoeveel tijd het vraagt. Wie dat scherp heeft, voorkomt dat een migratie eindigt in een project zonder einde, en houdt tijd en aandacht over voor waar het bedrijf eigenlijk om draait: ondernemen.

Sta je nu zelf op dit kruispunt?

Zit je organisatie momenteel nog op een oudere versie van Dynamics NAV of Business Central en vraag je je af wat de beste route is? Wacht dan niet tot de urgentie je inhaalt, maar maak er nu al een strategisch actiepunt van. Door het onderwerp vandaag nog intern op de agenda te zetten, creëer je de ruimte om in alle rust je opties te verkennen, de échte behoeften van je bedrijf in kaart te brengen en de migratie slim op te nemen in je roadmap. Zo houd je zelf de regie, voorkom je overhaaste beslissingen en leg je een stevig fundament voor de toekomst van je organisatie. Neem contact met Blisss op en zet de eerste stap.