Als de developer die jouw systeem heeft gebouwd niet meer bereikbaar is, heb je een serieus probleem, maar geen onoplosbaar probleem. In de meeste gevallen kan een nieuwe developer een bestaand maatwerksysteem overnemen, mits de broncode beschikbaar is. De grootste uitdaging zit niet in de techniek zelf, maar in het ontbreken van documentatie en context. In dit artikel beantwoorden we de meest urgente vragen die je nu waarschijnlijk hebt.

Wat zijn de grootste risico’s als je systeem niet meer onderhouden wordt?

Als je legacy software niet meer actief wordt onderhouden, loop je vier concrete risico’s: beveiligingslekken die niet worden gedicht, compatibiliteitsproblemen met nieuwe browsers of besturingssystemen, het wegvallen van koppelingen met andere systemen, en het volledig vastlopen van je bedrijfsproces als er iets misgaat. Hoe langer je wacht, hoe groter die risico’s worden.

Veel organisaties merken dit pas als het al te laat is. Een update van een externe dienst breekt een koppeling. Een nieuwe medewerker kan niet meer inloggen omdat het authenticatiesysteem verouderd is. Of erger: klantgegevens raken onbereikbaar omdat de database niet meer compatibel is met de serveromgeving.

Verouderde software trekt ook vaker de aandacht van kwaadwillenden. Systemen die niet meer worden bijgewerkt missen beveiligingspatches, waardoor bekende kwetsbaarheden open blijven staan. Voor een bedrijf dat afhankelijk is van dat systeem voor dagelijkse operaties, is dit geen theoretisch risico maar een reëel bedrijfsrisico.

Naast technische risico’s speelt ook de afhankelijkheid van één persoon een grote rol. Als die ene developer de enige is die weet hoe het systeem werkt, dan is alle kennis over jouw bedrijfslogica in feite verdwenen zodra diegene niet meer beschikbaar is.

Hoe kom je erachter wat er precies in je systeem zit?

Om te begrijpen wat er in je systeem zit, begin je met drie dingen: toegang tot de broncode, toegang tot de database, en toegang tot de serveromgeving. Als je die drie hebt, kan een technisch persoon een eerste inventarisatie maken van de gebruikte technologieën, de structuur van de applicatie en de staat van de code.

Vraag jezelf als eerste af of je eigenaar bent van de broncode. Dit is een juridische kwestie die bij maatwerksoftware soms onduidelijk is. Als de developer freelancer was of via een bureau werkte, kunnen er afspraken zijn gemaakt waarbij de code niet automatisch van jou is. Controleer oude contracten of overeenkomsten.

Als je toegang hebt tot de code, kan een AI-gestuurde legacy scan snel inzicht geven in de technische staat van het systeem. Zo’n analyse brengt in kaart welke technologieën er gebruikt worden, hoe complex de codebase is, en waar de grootste risico’s zitten. Dat is waardevolle informatie voordat je beslissingen neemt over de volgende stap.

Heb je geen toegang tot de broncode? Dan is de situatie ingewikkelder. Je kunt proberen de developer alsnog te bereiken via LinkedIn, oude e-mails of via het bureau waarvoor diegene werkte. Als dat niet lukt, is juridisch advies soms nodig om te bepalen wat je rechten zijn.

Kan een nieuwe developer een bestaand maatwerksysteem overnemen?

Ja, een nieuwe developer kan een bestaand maatwerksysteem overnemen, maar de haalbaarheid hangt sterk af van de kwaliteit van de broncode en de beschikbaarheid van documentatie. Goed geschreven, moderne code is relatief snel over te nemen. Slecht gedocumenteerde of sterk verouderde code kost veel meer tijd en dus geld.

Een ervaren developer begint zo’n overname altijd met een grondige analyse. Wat zijn de gebruikte programmeertalen en frameworks? Hoe is de database opgebouwd? Zijn er externe koppelingen en hoe werken die? Zonder antwoorden op die vragen is het onmogelijk om een betrouwbare inschatting te geven van de benodigde tijd en kosten.

Praktisch gezien is het ook belangrijk dat je als opdrachtgever goed kunt uitleggen wat het systeem doet. Schrijf op welke functies je dagelijks gebruikt, welke processen via het systeem lopen en wat er niet meer werkt of nooit goed heeft gewerkt. Die functionele kennis is minstens zo waardevol als de technische code zelf.

Via detachering van softwareprofessionals is het mogelijk om tijdelijk een ervaren developer in te zetten die jouw systeem analyseert en stabiliseert, zonder dat je meteen een volledig herbouwtraject hoeft op te starten. Dat kan een goede tussenoplossing zijn als je snel zekerheid wilt.

Wanneer is herbouwen beter dan overnemen?

Herbouwen is beter dan overnemen wanneer de onderliggende technologie zo verouderd is dat verdere ontwikkeling meer kost dan een nieuw systeem bouwen, wanneer de code zo slecht gedocumenteerd of ongestructureerd is dat het begrijpen ervan langer duurt dan opnieuw schrijven, of wanneer je bedrijfsbehoeften inmiddels significant zijn veranderd.

Een goede vuistregel: als het oplossen van problemen in het bestaande systeem structureel meer tijd kost dan de waarde die het oplevert, is herbouwen de betere investering. Dat klinkt logisch, maar in de praktijk stellen veel organisaties deze beslissing uit omdat herbouwen spannend voelt. Toch is uitstel vaak de duurdere keuze.

Bij herbouwen, ook wel replatforming van legacy software genoemd, hoeft waardevolle bedrijfslogica niet verloren te gaan. Een goed replatforming-traject begint altijd met een grondige analyse van het bestaande systeem, zodat de kennis en functionaliteit die erin zit bewaard blijft en vertaald wordt naar de nieuwe oplossing.

Overnemen is de betere keuze als de code relatief modern en leesbaar is, de kernfunctionaliteit nog goed aansluit op je huidige processen, en de aanpassingen die je wilt maken beperkt zijn. In dat geval is overnemen sneller en goedkoper dan herbouwen.

Hoe voorkom je dat je opnieuw in deze situatie terechtkomt?

Je voorkomt deze situatie door drie dingen goed te regelen: eigenaarschap van de broncode vastleggen in het contract, zorgen voor actuele documentatie van het systeem, en nooit afhankelijk zijn van één persoon voor het beheer van kritieke software. Dit zijn geen luxe maatregelen, maar basisafspraken die elke organisatie met maatwerksoftware zou moeten maken.

Zorg er bij elk softwareproject voor dat je als opdrachtgever expliciet eigenaar bent van de broncode. Leg dit vast in de overeenkomst, inclusief afspraken over waar de code wordt bewaard, wie er toegang toe heeft en hoe overdracht plaatsvindt als de samenwerking eindigt.

Goede documentatie is minstens zo belangrijk. Vraag bij elk project om technische documentatie die beschrijft hoe het systeem is opgebouwd, welke keuzes er zijn gemaakt en waarom. Functionele documentatie, die beschrijft wat het systeem doet en voor wie, is ook essentieel. Zonder die context is zelfs de beste code moeilijk over te nemen.

Overweeg ook een onderhoudscontract af te sluiten met een softwarebedrijf dat het systeem actief monitort en up-to-date houdt. Zo ben je niet afhankelijk van één freelancer, maar van een team dat continuïteit kan garanderen. Dat geeft rust, ook als er onverwacht iets verandert.

Hoe VL Software helpt bij verouderde of verlaten software

VL Software helpt organisaties die vastzitten met legacy software die niet meer onderhouden wordt. Of je nu snel zekerheid wilt over de staat van je systeem, een tijdelijke developer nodig hebt om het te stabiliseren, of toe bent aan een volledige herbouw: VL Software biedt concrete oplossingen.

  • Legacy scan: een snelle technische analyse van je bestaande systeem, zodat je weet wat je hebt en wat de risico’s zijn
  • Detachering: een ervaren softwareprofessional die tijdelijk jouw systeem overneemt, analyseert en stabiliseert
  • Replatforming: het herbouwen van je verouderde systeem naar een moderne, onderhoudbare webapplicatie met behoud van je bedrijfslogica
  • Maatwerk webapplicaties: als je toe bent aan iets nieuws, bouwt VL Software een oplossing die volledig aansluit op jouw processen

Dankzij de combinatie van softwareontwikkeling en consultancy onder één dak zorgt VL Software voor strak projectmanagement, korte communicatielijnen en een soepele overgang van oud naar nieuw. Neem contact op en bespreek vrijblijvend wat de beste volgende stap is voor jouw situatie.

Gerelateerde artikelen