Om deze vraag te beantwoorden moeten we het eerst eens worden over mogelijke doelen van een migratie: If it ain't broke, why fix it? Een migratie zal pas succesvol kunnen worden als het ook aan een bepaalde behoefte voldoet. Bijvoorbeeld door het toevoegen van functionaliteit die in de oude omgeving niet mogelijk is. Of het herstructureren van een monoliet vol spaghetti, waardoor applicatiefunctionaliteiten hergebruikt kunnen gaan worden (soa). Of doordat de oude technieken niet meer ondersteund worden door de leverancier of in de vorm van competentie.
We moeten het eerst eens worden wat we onder migraties verstaan. Ik beperk de scope tot applicatiemigraties: het transformeren van de functionaliteit van één softwareplatform naar een ander softwareplatform. Dus bijvoorbeeld van Cobol naar Java of van Microsoft VB naar .NET.
Migraties in de zin van porten, de applicatie in zijn geheel ongemoeid overzetten van het ene hardwareplatform naar een ander hardwareplatform (down sizing) en datamigraties laat ik gemakshalve even buiten beschouwing.
Simpel beschouwd zijn er twee soorten migraties: van code naar code (C2C) en van model naar model (M2M). Bij de C2C-migraties wordt de oude code één-op-één omgezet naar de nieuwe code. In feite is dit dus een syntactische transformatie. De functionaliteit blijft gelijk, alleen de achterliggende technologie verandert. Er zijn vele geautomatiseerde gereedschappen in de markt die dergelijk migraties uitvoeren. Het probleem bij deze migraties mag duidelijk zijn: rubish in = rubish out.
M2M-migraties zijn wat complexer. De oude code wordt geanalyseerd en haar structuren worden weergegeven in een model. Dit model wordt getransformeerd naar een nieuw model, bijvoorbeeld opgesteld in de Unified Modelling Language (UML). Het model wordt onder een servicegeoriënteerde architectuur geplaatst en verrijkt met nieuwe, aanvullende functionaliteit. Vervolgens wordt met behulp van Model Driven Architecture aan de hand van het nieuwe en verrijkte model de nieuwe code (Java, C#) gegenereerd. Het voordeel van aanpasbaarheid en flexibiliteit brengt wel een duurder prijskaartje met zich mee in vergelijking met de C2C-migraties.
Zijn deze migraties zinvol in de betekenis van toegevoegde waarde voor de business?
Het lijkt mogelijk de oude techniek uit te faseren met C2C-migraties, maar is het resultaat inderdaad vrij van legacy-structuur en -techniek? Of is complexere M2M migreren de weg te gaan zodat er naar een soa bewogen kan worden en er nieuwe business requirements ingelost kunnen worden?
De migratie is de verplaatsing, niets meer, niets minder. Het schonen of verrijken is een separaat proces wat buiten de feitelijke migratie valt. Het lijkt echter een hardnekkig misverstand te blijven dat door te migreren automatisch de ‘spaghetti-code’ of vervuilingen worden hersteld cq opgeheven. Een migratie is als een verhuizing, je pakt aan de ene kant (bronsysteem) de boel in, tranporteert het en pakt het aan de andere kant (doelsysteem) weer uit. Wat stuk was op het oude adres komt niet op het nieuwe adres gerepareerd tevoorschijn (hooguit verder beschadigd). Een vervolg traject na de migratie is dus nodig. Uiteraard zijn migraties zinvol en winstgevend, alleen gaat het nooit om migreren om het migreren. Migraties moeten ingegeven worden door een bepaald doel (fusie, uitfaseren legacy, enterprise modernization etc.) Vanuit die optiek zijn migraties niet alleen gewenst, maar vaak ook noodzakelijk. Sommige applicaties zijn ouder dan de gemiddelde prgrammeur en de kennis van (ver)oude(rde) systemen sterft, letterlijk en figuurlijk, langzaam uit