Verouderde software vervangen

Een incidenteel technisch probleem is meestal geen reden om een compleet systeem te vervangen. Dat verandert wanneer dezelfde beperkingen steeds opnieuw terugkomen.

Denk aan kleine wijzigingen die veel ontwikkeltijd kosten, regelmatige storingen na updates, beperkte API-mogelijkheden of een architectuur waarin nieuwe functionaliteit steeds moeilijker kan worden toegevoegd.

Ook stijgende onderhoudskosten kunnen een indicatie zijn dat verder investeren in de bestaande oplossing minder aantrekkelijk wordt.

Moderniseren of opnieuw bouwen?

Beide routes kunnen passend zijn.

Volledige vervanging is niet altijd noodzakelijk. Soms kunnen onderdelen van een bestaand systeem worden vernieuwd terwijl andere componenten behouden blijven.

Zo kan bijvoorbeeld een oude frontend worden vervangen, terwijl de bestaande database en bepaalde backendfunctionaliteit tijdelijk blijven bestaan.

Wanneer de technische basis sterk verouderd is of veel onderlinge afhankelijkheden bevat, kan een volledige herbouw juist overzichtelijker zijn. Welke aanpak technisch mogelijk is, hangt af van de bestaande architectuur en de gewenste nieuwe situatie.

Wat gebeurt er met functies?

Behoud wat werkelijk nodig is.

Bij het vervangen van software hoeft niet automatisch iedere bestaande functie opnieuw te worden gebouwd.

De opdrachtgever bepaalt welke processen, functies, rollen en businessregels in de nieuwe software nodig zijn. Bestaande onderdelen kunnen daarbij als referentie dienen.

Op basis van deze informatie kan APPelit de technische uitwerking maken. Zo wordt duidelijk welke functionaliteit behouden blijft, welke onderdelen veranderen en welke nieuwe onderdelen ontwikkeld moeten worden.

Dit voorkomt dat historische functionaliteit zonder duidelijke reden opnieuw wordt gerealiseerd.

Hoe werkt een migratie?

Oud en nieuw kunnen tijdelijk naast elkaar bestaan.

Een softwaresysteem hoeft niet altijd in één keer te worden vervangen. Bij veel maatwerkoplossingen kan een gefaseerde migratie worden toegepast.

Een organisatie kan bijvoorbeeld gebruikmaken van één systeem voor planning, administratie, rapportages en koppelingen. Eerst kan de rapportagemodule worden vernieuwd, waarna andere onderdelen volgen.

Nieuwe onderdelen worden ontwikkeld en getest voordat gebruikers worden overgezet.

Daarbij moet ook rekening worden gehouden met bestaande gegevens. Datamigratie, gebruikersaccounts, autorisaties en koppelingen met externe systemen kunnen onderdeel zijn van de overgang.

Welke techniek speelt mee?

De achterkant bepaalt veel.

Bij softwarevervanging moet verder worden gekeken dan alleen naar de zichtbare schermen.

De gebruikte programmeertalen, frameworks, databases, API’s, hostingomgeving, authenticatie en beveiligingsmaatregelen bepalen mede hoe een systeem kan worden vernieuwd.

Ook technische schuld kan een rol spelen. Wanneer een applicatie jarenlang is uitgebreid met tijdelijke oplossingen, kan de onderliggende structuur aanzienlijk complexer zijn dan aan de voorkant zichtbaar is.

Externe afhankelijkheden moeten eveneens worden meegenomen. Denk aan koppelingen met ERP-software, boekhouding, betaalproviders, identity providers of andere databronnen.

Kan de software blijven draaien?

Continuïteit vraagt om een goede overgang.

In veel situaties kan de bestaande software tijdens de ontwikkeling van de nieuwe oplossing actief blijven.

Nieuwe onderdelen kunnen eerst afzonderlijk worden getest voordat gebruikers worden overgezet. Daardoor hoeft een organisatie niet direct volledig afhankelijk te zijn van één grote overgang.

Of dit mogelijk is, hangt wel af van de technische opbouw van het huidige systeem. Wanneer onderdelen sterk met elkaar verweven zijn, kan een gefaseerde migratie ingewikkelder worden.

Daarom is het verstandig om de overgang technisch vooraf uit te werken.