Bestaande software doorontwikkelen: de gids.
Wil je verder met je huidige applicatie, of zoek je een nieuwe partij om je software over te nemen? In deze gids lees je hoe je bepaalt of doorontwikkelen, moderniseren of vervangen past, en wat er bij een overname komt kijken.
Doorontwikkelen of opnieuw bouwen?
Wanneer bestaande software knelt, is opnieuw beginnen een verleidelijke gedachte. Toch zit er in een applicatie die al jaren draait veel kennis over je bedrijf: uitzonderingen, rekenregels en werkafspraken die ooit zorgvuldig zijn ingebouwd. Bij volledig opnieuw bouwen moet al die kennis opnieuw worden boven water gehaald, en dat kost tijd en brengt risico’s mee. Bovendien moeten gebruikers wennen aan een volledig nieuwe applicatie, terwijl de oude nog nodig is tot de overstap is afgerond.
Doorontwikkelen betekent dat je voortbouwt op wat er staat. Dat kan door functies toe te voegen, verouderde onderdelen bij te werken of delen stap voor stap te vervangen. Of dat verstandig is, hangt af van de toestand van de basis. Moet alles opnieuw? Dat volgt uit het onderzoek. We wegen behouden, verbeteren en vervangen af tegen de risico’s en het gewenste resultaat. Soms is opnieuw bouwen wel de beste keuze, en dan onderbouwen we waarom.
Wat is legacy software?
Legacy software is software die nog in gebruik is, maar is gebouwd met technieken of versies die niet meer actueel zijn. Dat hoeft geen probleem te zijn zolang de applicatie goed werkt en veilig kan worden beheerd. Het wordt lastig wanneer updates niet meer beschikbaar zijn, ontwikkelaars de techniek moeilijk kunnen ondersteunen of nieuwe wensen niet meer passen. Ook gebrek aan documentatie en kennis bij de huidige beheerders maakt software kwetsbaar.
Legacy software moderniseren betekent niet per se dat alles anders wordt. Vaak begint het met het bijwerken van de programmeertaal en het framework naar een ondersteunde versie, het toevoegen van tests en het vastleggen van hoe de applicatie werkt. Daarmee leg je een stabiele basis voor verdere doorontwikkeling. Pas daarna is het verstandig om grotere veranderingen te plannen, zoals nieuwe functies of het vervangen van onderdelen die niet meer passen.
Wat we bekijken bij een technische verkenning
Een technische verkenning geeft zicht op wat er staat. We bekijken binnen de afgesproken scope de broncode, de opbouw van de database, de gebruikte versies van taal en framework, externe pakketten en koppelingen, de hosting en de beschikbare documentatie. We kijken ook of er een testomgeving is en hoe updates tot nu toe zijn uitgevoerd. Ook kijken we naar de manier waarop gegevens worden opgeslagen en of er onderdelen zijn die extra aandacht vragen.
Minstens zo belangrijk is het gebruik. Welke onderdelen zijn cruciaal voor het dagelijkse werk, welke worden nauwelijks gebruikt en waar lopen mensen tegenaan? Die combinatie van techniek en praktijk bepaalt welke volgende stap het meest oplevert. De bevindingen vatten we samen met een advies, zodat je een onderbouwde keuze kunt maken. Zo wordt de verkenning geen technisch rapport in een la, maar een praktisch en concreet startpunt voor de volgende stap.
Software overnemen van een andere partij
Software overnemen gebeurt om verschillende redenen. De vorige ontwikkelaar stopt, de samenwerking loopt af of je zoekt een partner die beter aansluit bij je plannen. Voor een soepele overgang zijn onder meer toegang tot de broncode, de ontwikkelomgeving, het versiebeheer en relevante accounts nodig, zoals hosting, domein en externe diensten. Hoe eerder die toegang geregeld is, hoe soepeler de overdracht verloopt. Ook een overdrachtsgesprek met de vorige ontwikkelaar kan veel kennis opleveren, als dat mogelijk is.
Rechten en afspraken met de huidige leverancier moeten duidelijk zijn. Wie is eigenaar van de code, welke licenties gelden er en welke kennis wordt overgedragen? We beoordelen eerst of de techniek, toestand en toegang passen bij wat we verantwoord kunnen ondersteunen. Daarna plannen we de overgang, zodat er geen moment is waarop niemand verantwoordelijk is. Tijdens die overgang houden we de bestaande situatie zo stabiel mogelijk en voeren we eerst geen grote wijzigingen door.
Stapsgewijs moderniseren
Wanneer vervanging nodig is, hoeft dat niet in één keer. Bij een gefaseerde aanpak bouw je nieuwe onderdelen naast de bestaande applicatie en zet je functies één voor één over. Gebruikers blijven werken met de software die ze kennen, terwijl delen ervan worden vernieuwd. Zo spreid je de investering en beperk je het risico van een grote overstap. Bovendien wennen gebruikers geleidelijk aan de nieuwe onderdelen, in plaats van in één keer aan een geheel nieuw systeem.
Een voorbeeld: eerst wordt een verouderde importmodule vervangen, daarna de rapportages en pas later het hart van de applicatie. Na elke stap kun je beoordelen of de aanpak werkt. Dit vraagt wel goede afspraken over hoe oude en nieuwe onderdelen tijdelijk samenwerken en welke gegevens moeten worden overgezet. Ook de volgorde van de stappen kiezen we bewust: eerst de onderdelen met het meeste risico of de grootste wens, daarna de rest.
Risico’s beperken bij wijzigingen
Aanpassen in bestaande software vraagt zorgvuldigheid. Een kleine wijziging op de ene plek kan onverwachte gevolgen hebben op een andere. Daarom werken we met een aparte testomgeving, versiebeheer en back-ups, zodat een wijziging eerst kan worden gecontroleerd voordat die live gaat. Grotere wijzigingen voeren we bij voorkeur stapsgewijs door, zodat duidelijk blijft welke aanpassing welk effect heeft. En als er toch iets misgaat, is er een weg terug naar de vorige versie.
Waar tests ontbreken, voegen we die toe rond de functies die het belangrijkst zijn voor je bedrijf. AI helpt ons om onbekende code sneller te doorgronden en tests op te stellen. Een ontwikkelaar beoordeelt het resultaat en beslist over elke aanpassing. Zo bouw je stap voor stap meer zekerheid op in een applicatie die eerder als kwetsbaar voelde. Dat maakt toekomstige aanpassingen overzichtelijker en beter te controleren, ook voor ontwikkelaars die later aan de software werken.
PHP- en Laravel-applicaties doorontwikkelen
Veel bedrijfsapplicaties in het mkb zijn gebouwd in PHP, vaak met een framework zoals Laravel. Lilopel heeft ervaring met PHP- en Laravel-maatwerk en kan zulke applicaties onderzoeken, bijwerken en uitbreiden. Een bekende uitdaging is een applicatie die op een oude versie van PHP of Laravel draait, waardoor updates en nieuwe pakketten niet meer passen. Ook pakketten van derden die niet meer worden bijgewerkt, vragen dan om een passend alternatief binnen de applicatie.
Het bijwerken naar een ondersteunde versie gebeurt meestal in stappen, met tests en controle na elke stap. Voor software in andere technieken beoordelen we per situatie of we die verantwoord kunnen ondersteunen. Is dat niet zo, dan zeggen we dat eerlijk. Na elke stap controleren we of de applicatie werkt zoals afgesproken, zodat het werk kan doorgaan. Zo bouw je in overzichtelijke stappen toe naar een actuele basis waarop je verder kunt ontwikkelen.
