Legacy software moderniseren

Kijk naar twee dingen: klopt de bedrijfslogica nog, en is de code te begrijpen. Klopt de logica en herkent u uw proces nog in het systeem, dan is herontwikkelen bijna altijd goedkoper, want er zitten jaren aan uitzonderingen in die niemand nog volledig kan opschrijven. Is de logica zelf verouderd, bijvoorbeeld omdat uw proces intussen anders werkt, dan verhuist u met herontwikkeling vooral oude aannames naar een nieuwe stack. Ook de datastructuur weegt mee: een databaseontwerp dat niet meer past bij hoe u werkt, wordt de rem op elke nieuwe feature. Daarom begint een traject bij ons met een audit voordat die keuze valt.

Bij de strangler-aanpak zetten we een nieuwe laag om het oude systeem en verhuizen we functie voor functie, waarbij oud en nieuw naast elkaar draaien. Voordeel: kleine stappen, weinig risico, snel eerste resultaat. Nadeel: langere totale doorlooptijd, tijdelijk twee systemen onderhouden en soms een dubbele datalaag. In één keer omzetten betekent alles bouwen en op één moment overgaan. Voordeel: geen tussenoplossingen en een korter traject op papier. Nadeel: het risico zit gebundeld in één avond en gaten ontdekt u pas als iedereen erop werkt. Hybride komt het vaakst uit: de kern in één keer, randmodules gefaseerd. Bepalend is hoeveel stilstand uw operatie verdraagt.

Signalen die vaker samen voorkomen: één persoon die weet hoe het werkt en zonder wie niemand iets durft aan te passen, kritische processen in een Access-database of Excel met VBA-macro's, een applicatie op PHP 5 of een .NET-versie uit 2012 die geen security-updates meer krijgt, een leverancier die niet meer bestaat of niet meer reageert, een hostingomgeving die niemand durft te patchen, en aanpassingen die weken duren omdat elke wijziging elders iets breekt. Ook typisch: nieuwe medewerkers hebben maanden nodig om het systeem te begrijpen, en er groeit een web aan spreadsheets naast het systeem om te doen wat het systeem niet kan.

Vier soorten trajecten komen het meest voor. Bestaande webapplicaties op een verouderde stack, die naar een moderne architectuur gaan met behoud van functionaliteit en data. Desktopsoftware die naar de browser moet, zodat mensen niet meer aan één werkplek vastzitten en installaties verdwijnen. Spreadsheets en Access-oplossingen die feitelijk bedrijfskritisch zijn geworden en een echte applicatie met rollen, validatie en historie nodig hebben. En monolieten die worden opgesplitst in afgebakende diensten, meestal niet omdat losse services een doel zijn maar omdat één onderdeel apart moet kunnen schalen of vaker uitgerold moet worden.

Migratie is meestal het grootste en zeker het meest onderschatte deel. We beginnen met profiling: wat staat er werkelijk in de database, inclusief dubbele records, lege verplichte velden en betekenis die in vrije tekstvelden is beland. Daarna volgt mapping per veld, een testmigratie op een kopie en vergelijkingen op aantallen en totalen. Voor de overgang draaien oud en nieuw parallel, in het begin met alleen lezen in het nieuwe systeem. De echte omzetting plannen we op een rustig moment, met een delta-migratie voor wat tijdens de overgang nog wijzigt en een terugvalscenario dat we vooraf hebben getest. Stilstand blijft daardoor doorgaans beperkt tot een venster van enkele uren.

In de trajecten die wij begeleiden ligt de terugverdientijd meestal tussen twaalf en achttien maanden, en dat komt zelden uit besparing op licenties of hosting. Het grootste deel zit in kosten die nu nergens op een factuur staan: uren aan handmatig overtypen en controleren, onboarding van nieuwe medewerkers die maanden duurt, klantvragen die niet snel beantwoord kunnen worden, omzet die u laat liggen omdat een feature technisch niet haalbaar is, en het risico van een systeem zonder security-updates. Voor de audit vragen we u die posten grof in te schatten. Zonder die cijfers blijft elke businesscase voor modernisering een gevoelskwestie.

Dat is vaak de verstandigste start. We beginnen bij het onderdeel waar de pijn zit, bijvoorbeeld de module die dagelijks vastloopt of het scherm waarin uw mensen het meest werken, en laten de rest voorlopig staan. Voorwaarde is dat de nieuwe onderdelen via een duidelijke grens met het oude systeem praten, zodat u niet twee half verbonden systemen overhoudt. Voordeel is dat de investering gespreid is en dat u snel resultaat ziet op de plek die het meest oplevert. Nadeel is dat het totale traject langer loopt en dat er tijdelijk twee omgevingen onderhouden worden. Dat zeggen we vooraf, niet halverwege.

Dat is eerder regel dan uitzondering. We werken dan van buiten naar binnen: eerst vastleggen wat het systeem voor gebruikers doet door met uw mensen mee te kijken, daarna de code en database lezen om te vinden waar de regels echt staan, en de aannames die we vinden opschrijven in leesbare documentatie. Logs, databaseinhoud en zelfs oude e-mails helpen bij vragen als waarom een bepaalde uitzondering bestaat. Wat we niet doen is vreemd gedrag stilzwijgend wegoptimaliseren, want vreemd gedrag blijkt vaak een klantafspraak. Die documentatie beëindigt bovendien uw afhankelijkheid van één persoon.

Modernisering slaagt of sneuvelt bij de mensen die er elke dag in werken. We betrekken daarom een aantal dagelijkse gebruikers vanaf het begin, niet alleen de opdrachtgever, en houden veelgebruikte handelingen bewust dicht bij wat mensen kennen; een nieuwe interface hoeft niet te betekenen dat elke werkwijze verandert. Voor de omzetting kunnen mensen meekijken in een testomgeving met echte gegevens. Bij livegang leveren we korte werkinstructies per rol, een of meer sessies en extra bereikbaarheid in de eerste week. Waar het proces echt verandert zeggen we dat expliciet en oefenen we het, in plaats van te hopen dat gebruikers het zelf ontdekken.

Nee. Herontwikkeling is vaak goedkoper omdat bewezen bedrijfslogica en data blijven bestaan, maar niet altijd. Bij code die niemand meer kan volgen gaat een groot deel van het budget op aan uitzoeken hoe het huidige systeem zich gedraagt, en dan kan nieuwbouw op basis van een frisse specificatie voordeliger uitkomen. Ook geldt: hoe verder de bestaande datastructuur van de wenselijke afligt, hoe duurder de migratie. Daarom leveren we na de audit een eerlijke vergelijking van beide routes met kosten, risico's en doorlooptijd, ook als de conclusie is dat opnieuw bouwen de betere keuze is.

Die eerste vier weken zijn het belangrijkst. We zetten monitoring en foutmeldingen scherper dan normaal, kijken naar performance op de zwaarste schermen en volgen of achtergrondtaken en koppelingen elke dag netjes doorlopen. Daarnaast houden we een korte lijn met uw gebruikers, omdat de eerste weken altijd dingen opleveren die geen test vindt: een rapport dat iemand maandelijks draait, een export naar de accountant, een handeling die alleen bij de jaarafsluiting voorkomt. Kleine correcties pakken we in die periode direct op. Het oude systeem blijft in die weken beschikbaar als naslag, meestal alleen-lezen.

Reken op één tot drie weken audit, en daarna drie tot negen maanden voor het traject zelf, afhankelijk van omvang, aantal koppelingen en de staat van de data. Bij een gefaseerde aanpak is het eerste vernieuwde onderdeel meestal binnen zes tot tien weken in gebruik, terwijl de rest nog op het oude systeem loopt. Wat de planning het sterkst beïnvloedt is niet het bouwen maar de onbekende factoren: ongedocumenteerde regels, datakwaliteit en de beschikbaarheid van mensen die kunnen uitleggen hoe iets hoort te werken. Die risico's benoemen we in de audit met een marge, in plaats van met één datum.

Overdracht is geen moment maar een periode. Standaard horen bij een traject nazorg in de eerste weken, documentatie en een overdracht aan wie het beheer overneemt, of dat uw eigen team is of een andere partij. Daarna kiest u: een retainer waarin wij monitoring, security-updates, dependency-onderhoud en doorontwikkeling doen, of alleen beschikbaarheid op afroep voor vragen en incidenten. Omdat code, infrastructuur en documentatie van u zijn is dat een vrije keuze en geen afhankelijkheid. In de praktijk is het eerste jaar na een modernisering vaak drukker dan verwacht, omdat er eindelijk aanpassingen mogelijk zijn die jarenlang niet konden.