Software nabouwen betekent hier dat je benodigde functies uit een bestaand systeem opnieuw ontwikkelt. Dat kan passen als het proces nog bruikbaar is, maar de huidige toepassing aantoonbaar lastig te wijzigen of te beheren is. Leeftijd alleen is geen reden voor herbouw. Vergelijk de route met gericht onderhoud en een bestaand pakket; onze gids over maatwerksoftware helpt bij die bredere keuze.

Wat neem je over als je software nabouwt?

Je neemt de functies over die je bedrijf nodig heeft, niet automatisch ieder scherm en iedere oude uitzondering. Het bestaande systeem is een bron van informatie over het proces. Het is geen foutloze specificatie.

Een scherm kan bijvoorbeeld een verplicht veld bevatten omdat een verdwenen koppeling dat ooit nodig had. Dat veld opnieuw bouwen houdt een oude beperking in stand. Omgekeerd kan een onopvallende afrondingsregel van belang zijn voor iedere factuur. Die wil je niet verliezen omdat niemand haar op de eerste demonstratie benoemt.

Laat gebruikers dus complete taken uitvoeren. Kijk naar de invoer, het resultaat en wat ze buiten het systeem nog doen. Een eigen spreadsheet naast de applicatie kan laten zien welk deel van het werk in de huidige software ontbreekt.

Wanneer kies je onderhoud, herbouw of een pakket?

Onderzoek eerst waarom de huidige toepassing niet meer voldoet. Een trage zoekopdracht vraagt mogelijk een gerichte ingreep. Als de leverancier een benodigde functie niet meer ondersteunt en niemand wijzigingen kan uitvoeren, kan het probleem breder zijn.

Route Reden om te onderzoeken Wat je moet meewegen
Bestaande software onderhouden Het grootste deel voldoet en de oorzaak is af te bakenen Beschikbare kennis, ondersteunde onderdelen en toegang
Functies opnieuw bouwen Het proces past, maar de uitvoering belemmert noodzakelijke wijzigingen Verborgen regels, gegevensoverdracht en tijdelijke dubbele werking
Overstappen op een pakket Een bestaand product ondersteunt je belangrijkste taken Procesaanpassing, licenties, export en ontbrekende functies
Het proces opnieuw ontwerpen Werkwijze en software sluiten allebei niet meer aan Besluiten en begeleiding naast het ontwikkelwerk

Een pakket kan goedkoper uitvallen, maar dat volgt niet automatisch uit het abonnement. Migratie, inrichting en veranderingen in het dagelijks werk tellen mee. Andersom wordt nieuwe maatwerksoftware niet vanzelf makkelijker te onderhouden doordat ze een nieuw framework gebruikt.

Een bestaande TopDevs-case illustreert waarom je naar de taak kijkt. Bij Peters Bouwkundig Adviesbureau werd het werk rond oudere rapportagesoftware vernieuwd met invoer op een tablet, foto’s en standaardteksten, gevolgd door controle op kantoor en documentuitvoer. Die case beschrijft een andere werkwijze, geen garantie dat het letterlijk namaken van oude schermen de juiste route is.

Hoe maak je de bestaande werking testbaar?

Verzamel representatieve opdrachten met geanonimiseerde invoer en verwachte uitkomsten. Neem ook een annulering, correctie en onvolledig dossier mee. Laat een inhoudelijk verantwoordelijke aangeven welk resultaat juist is als de oude software en de praktijk elkaar tegenspreken.

Maak vervolgens onderscheid tussen behouden, veranderen en vervallen. Bij behouden leg je het verwachte gedrag vast. Bij veranderen beschrijf je bewust het nieuwe resultaat. Bij vervallen controleer je wie de functie nog gebruikt en welke andere systemen ervan afhangen.

Begin de technische proef met de onzekerheid die de keuze kan veranderen. Kun je de gegevens exporteren? Mag de nieuwe toepassing de benodigde koppeling gebruiken? Kun je een kenmerkend rapport correct opbouwen? Een geslaagde proef beantwoordt die afgebakende vraag, niet meteen de haalbaarheid van de hele migratie.

Kun je overstappen zonder alles tegelijk te vervangen?

Soms kun je functies stapsgewijs overnemen terwijl de rest blijft draaien. Het Strangler Fig-patroon van Microsoft beschrijft zo’n aanpak met een tussenlaag die verkeer naar oude of nieuwe functies stuurt. Daarvoor moet je het verkeer kunnen onderscheppen en kunnen ingrijpen in de bestaande toepassing. Tijdelijke infrastructuur en afhankelijkheden kosten beheer; de aanpak past niet bij ieder systeem.

Een andere mogelijkheid is een afgebakende groep eerst laten overstappen. Dat werkt alleen als duidelijk is waar die groep gegevens wijzigt en hoe de overige organisatie die wijzigingen ziet. Twee schrijfbare versies zonder eigenaarschap per gegevenssoort maken vergelijking juist moeilijker.

Kies de overgang daarom op basis van de samenhang van het werk. Een klein losstaand hulpmiddel kun je mogelijk in één gepland moment vervangen. Een gedeelde orderadministratie vraagt afspraken over lopende opdrachten, wijzigingen tijdens de overgang en het moment waarop de oude route sluit.

Hoe controleer je de datamigratie?

Een geslaagde importmelding bewijst niet dat medewerkers met de gegevens kunnen werken. Controleer aantallen, relaties en inhoudelijke uitkomsten. Een factuur zonder gekoppelde klant kan technisch zijn opgeslagen en toch onbruikbaar zijn.

Werk voor een proefmigratie met een afgesproken kopie van de gegevens. Noteer welke velden worden omgezet en hoe onbekende waarden worden behandeld. Laat het team daarna herkenbare dossiers openen, rapporten vergelijken en openstaande acties terugvinden. Houd verschillen bij totdat iemand ze kan verklaren of herstellen.

Plan ook wat er met oude historie gebeurt. Misschien moet die in de nieuwe toepassing doorzoekbaar zijn; misschien volstaat een apart archief met passende toegang. Beslis dat voordat de oude licentie afloopt, zodat je niet pas na afsluiting ontdekt welke export ontbreekt.

Leg bij de overstap vast wanneer invoer stopt en welke wijzigingen daarna nog meegaan. Een terugvalplan moet rekening houden met nieuw ingevoerde gegevens. Alleen de oude server opnieuw starten kan onvoldoende zijn als die de nieuwe opdrachten niet kent.

Mag je software van een andere partij nabouwen?

Binnen het Europese softwareauteursrecht maakt het Hof van Justitie in SAS Institute/WPL onderscheid tussen functionaliteit en de uitdrukkingsvorm daarvan. Functionaliteit als zodanig wordt niet door dat softwareauteursrecht beschermd; broncode kan dat wel zijn. Het arrest geeft geen algemene toestemming om een product te kopiëren. Andere beschermde onderdelen en de omstandigheden van toegang blijven van belang.

Laat bij een concreet project vaststellen welke rechten en afspraken gelden. Van wie is de bestaande code, welke licenties gebruik je en welke documentatie of gegevens wil je overnemen? Betaald hebben voor ontwikkeling is op zichzelf geen bruikbare beschrijving van wat je juridisch mag hergebruiken. Onze uitleg over code-eigendom en afhankelijkheid helpt die vragen voorbereiden.

Vraag bij twijfel juridisch advies vóór je beschermd materiaal laat overnemen. Een functionele beschrijving op basis van je eigen werkproces is ook inhoudelijk een beter startpunt dan de opdracht om een concurrent pixel voor pixel te kopiëren.

Wat bepaalt de kosten van nabouwen?

De omvang van de nieuwe functies is maar een deel van de raming. Onderzoek van de bestaande werking, ontbrekende documentatie, gegevensopschoning en de overgang zelf vragen ook werk. Laat die posten zichtbaar begroten.

Vergelijk scenario’s over dezelfde gebruiksperiode. Neem onderhoud van het oude systeem tijdens de bouw mee, plus eventuele dubbele licenties en ondersteuning na de overstap. Voor een onderbouwde vergelijking biedt onze gids over softwarekosten een kader; een vaste prijsrange zonder deze scope helpt weinig.

Maak duidelijk welke onzekerheden nog openstaan en welke proef ze kan verkleinen. Een vaste prijs werkt alleen met afspraken over wat is inbegrepen, wat als wijziging geldt en wie de uitkomsten goedkeurt. Hij laat onbekende afhankelijkheden niet verdwijnen.

Hoe borg je onderhoud en overdracht?

Vraag om een werkende installatiehandleiding, documentatie van koppelingen en een overzicht van benodigde accounts en licenties. Laat een andere beheerder met die informatie een testomgeving opzetten. Zo toets je of overdracht meer is dan een map broncode.

Leg vast wie updates uitvoert, meldingen opvolgt en herstel oefent. Bij TopDevs is en blijft de code van jou. Eigendom en praktisch kunnen doorwerken zijn verschillende zaken; je hebt beide nodig om later een andere partij te kunnen inschakelen.

Hoe begin je concreet?

Beschrijf welk probleem de bestaande software veroorzaakt en kies een complete taak waarmee je mogelijke routes vergelijkt. Verzamel het verwachte resultaat, toegangsafspraken en een gegevensvoorbeeld. Daarmee kun je een eerste onderzoeksopdracht afbakenen zonder al de hele herbouw te bestellen.

Wil je bespreken wat maatwerkapplicaties laten bouwen voor jouw bestaande proces vraagt? Plan een gesprek.