Bestaande software moderniseren of opnieuw bouwen: vergelijk de hele overgang

Beschrijf wat de huidige software belemmert

Begin met een concrete beperking: een nieuwe klantgroep past niet in het rechtenmodel, publicaties zijn moeilijk te controleren of een wijziging vraagt veel handmatige afstemming. Noteer ook wat goed functioneert. Een vervanging die alleen de problemen inventariseert kan belangrijke bestaande waarde vergeten, zoals betrouwbare rapportages of een goed begrepen werkwijze.

Laat gebruikers een voorbeeld geven van de gewenste verandering. Welke uitkomst is nu onmogelijk of onnodig lastig? Dat maakt de vergelijking scherper. Een wens voor een andere programmeertaal kan een middel zijn, maar is zelden een volledige zakelijke doelstelling. Onderzoek welk effect die technische keuze op beheer, wijzigingen en continuïteit zou moeten hebben.

Vergelijk vier echte opties

Behouden betekent de bestaande applicatie blijven gebruiken met expliciete beperkingen en onderhoud. Gericht verbeteren verandert een afgebakend knelpunt. Gefaseerd vervangen brengt onderdelen naar een nieuwe oplossing terwijl andere blijven bestaan. Volledige herbouw maakt een nieuwe applicatie, maar vraagt nog steeds een plan voor overgang en uitschakelen van het oude systeem.

Werk voor iedere optie dezelfde vragen uit: welke doelen worden bereikt, welke beperkingen blijven, welk onderzoek ontbreekt en wie beheert de uitkomst? Een vergelijking is niet eerlijk wanneer herbouw alle gewenste functies krijgt en behouden wordt voorgesteld als niets doen. Ook behoud kan documentatie, een ondersteunde omgeving en betere tests omvatten. Maak de aangeboden scope daarom per alternatief zichtbaar.

Maak verborgen bedrijfsregels zichtbaar

Een bestaande applicatie bevat vaak afspraken die gebruikers niet meer als bijzonder zien. Denk aan een uitzondering voor één klant, een correctie rond maandafsluiting of een import die bepaalde records overslaat. Bij een vervanging kunnen zulke regels verdwijnen omdat alleen de zichtbare schermen zijn nagebouwd.

Volg daarom enkele echte soorten handelingen van begin tot eind met veilige voorbeeldgegevens. Vraag medewerkers welke gevallen zij controleren en welke workarounds bestaan. Leg vast welke regels behouden moeten blijven, welke bewust veranderen en welke eerst nader onderzocht worden. Het doel is niet iedere oude eigenaardigheid voor altijd vast te zetten. Het doel is zorgen dat verandering een besluit is, geen verrassing tijdens ingebruikname.

Een bestaand pakket kan een deel van het probleem oplossen. Neem die mogelijkheid mee in de vergelijking: Standaardpakket of maatwerksoftware: vergelijk het werk dat moet gebeuren.

Begroot de overgang als eigen werk

De kostenvergelijking moet ook gegevensoverdracht, testen, instructie, tijdelijke dubbele verwerking en afbouw van oude diensten meenemen. Een goedkope nieuwe applicatie kan alsnog een dure overgang vragen wanneer gegevens moeilijk zijn te verklaren of medewerkers lange tijd twee werkwijzen moeten gebruiken. Benoem welke kosten eenmalig zijn en welke na de overgang blijven terugkomen.

Gebruik bandbreedtes of scenario’s wanneer informatie ontbreekt. Een precieze totaalsom zonder onderzochte aannames wekt meer zekerheid dan het project heeft. Vraag welke proef de onzekerheid kan verminderen. Bijvoorbeeld één gegevensgroep migreren, één koppeling afbakenen of één nieuwe gebruikersroute demonstreren. Dat onderzoek levert een onderbouwder besluit op dan alleen een langere lijst met gewenste functies.

Onderzoek of een geleidelijke grens mogelijk is

Gefaseerd vervangen werkt alleen wanneer duidelijk is welk onderdeel waarvoor verantwoordelijk is. Een nieuwe aanvraagroute kan bijvoorbeeld naast een bestaande administratie bestaan, mits identiteit, gegevensrichting en foutafhandeling zijn afgesproken. Zonder die grens ontstaat gemakkelijk tijdelijke complexiteit die jarenlang blijft bestaan.

AWS beschrijft het strangler-fig-patroon voor geleidelijke vervanging. Dat is een ontwerpmogelijkheid, geen opdracht om iedere applicatie in microservices op te delen. Kies een grens die bij gebruikers en beheer past. Vraag welke oude verantwoordelijkheid na een fase daadwerkelijk kan verdwijnen en welke extra koppeling tijdelijk nodig is. Een fase die alleen toevoegt maar niets afbouwt moet bewust worden beoordeeld.

AWS Prescriptive Guidance: Strangler fig pattern ↗

Beslis wie tijdens de overgang gegevens beheert

Als twee applicaties hetzelfde gegeven kunnen wijzigen, moet duidelijk zijn welke waarde leidend is en hoe conflicten worden afgehandeld. Anders kan een schijnbaar geslaagde demonstratie later tot tegengestelde statussen of ontbrekende wijzigingen leiden. Leg ook vast hoe laat binnenkomende berichten worden herkend wanneer een verantwoordelijkheid naar het nieuwe systeem verschuift.

Een vertaalgrens kan helpen wanneer oude en nieuwe modellen verschillende betekenissen gebruiken. Microsoft beschrijft daarvoor het anti-corruption-layer-patroon. Ook dan blijven concrete afspraken nodig over velden, uitzonderingen en beheer. Vraag een klein voorbeeld van een normale wijziging én een mislukte verwerking. Een architectuurplaat alleen bewijst niet dat beide systemen dezelfde zakelijke gebeurtenis begrijpen.

Microsoft Azure Architecture: Anti-Corruption Layer ↗

Voorbeeld: een reserveringsplatform vernieuwen

Fictief voorbeeld: een organisatie wil een reserveringsplatform vernieuwen omdat wijzigingen in beschikbaarheid lastig zijn. De bestaande facturatie werkt bruikbaar en medewerkers kennen de correctieroute. Een volledige herbouw zou beide onderdelen tegelijk vervangen. Een alternatief vernieuwt eerst beschikbaarheid en houdt de bestaande financiële afhandeling tijdelijk in gebruik.

Het team onderzoekt één reservering met wijziging en annulering. Het vergelijkt niet alleen de nieuwe schermen, maar ook de gegevensoverdracht en de handmatige controle die tijdens de overgang nodig blijft. Als de scheiding te veel tijdelijke koppeling vraagt, kan volledige vervanging alsnog passend zijn. Het voorbeeld laat zien welke proef een keuze kan ondersteunen; het bewijst niet dat faseren altijd goedkoper is.

Definieer wanneer een fase afgerond is

Een werkend nieuw scherm is niet altijd het eindpunt. Een fase kan pas worden afgesloten wanneer de afgesproken gebruikersroute, gegevenscontrole, foutafhandeling en beheerafspraak zijn aangetoond. Beschrijf welke oude functies worden uitgeschakeld en welke uitzonderingen nog bewust naar het oude systeem gaan.

Neem ook een stopbesluit op. Welke waarneming betekent dat de volgende fase nog niet kan starten? Denk aan onverklaarde verschillen, ontbrekende beheerkennis of een te grote handmatige achterstand. Maak de beoordeling niet afhankelijk van alleen de geplande datum. Een fase met zichtbare beperkingen kan beheersbaar zijn, maar dan moeten gebruikers en verantwoordelijken weten welke aanvullende controles nodig blijven.

Koop eerst kennis als de grootste onzekerheid openstaat

Soms is een keuze tussen verbeteren en herbouw nog niet verantwoord te maken. Dan kan een begrensd onderzoek waardevol zijn: een proefmigratie, een controle van publicatie en herstel, of een demonstratie van een nieuwe rol op bestaande gegevens. Spreek af welke conclusie het onderzoek moet kunnen ondersteunen.

Bewaar na het besluit de gebruikte aannames. Als later blijkt dat gegevens complexer zijn of een leverancier toegang beperkt, kan de vergelijking opnieuw worden bekeken. Dat is geen mislukking van het eerste besluit, maar een manier om de uitvoering aan nieuw bewijs aan te passen. Vraag daarom om een voorstel met keuzemomenten en overdraagbare resultaten, niet uitsluitend een eindbeeld van de gewenste software.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

• Legacy Software Moderniseren ↗
• Software Audit ↗

Vragen over dit onderwerp

Verder met een aansluitende vraag