Wanneer is legacysoftware echt aan vervanging toe?

Er is altijd dat ene systeem. Een magazijnapplicatie die alleen in een oude browser wil draaien. Een klantportaal waarvan de bouwer al jaren niet meer in dienst is en waar niemand de code nog durft aan te raken. Of, de klassieker, het Excel-bestand dat elke ochtend met de hand wordt bijgewerkt omdat drie systemen niet met elkaar praten.

Zolang zo'n systeem nog net doet wat het moet doen, blijft het staan. Dat is niet eens onlogisch: vervangen kost geld, tijd en aandacht die je ook aan klanten kunt besteden. Maar doorgaan kost ook iets, en die rekening is minder zichtbaar. Hij zit in handwerk, in fouten die achteraf rechtgezet moeten worden, in die ene collega die als enige weet welke omweg nodig is, en in dingen die klanten vragen maar die je niet kunt bouwen.

De vraag is dus niet of oude software per definitie weg moet. De vraag is welk risico je wegneemt, en hoe de operatie ondertussen gewoon doorloopt.

Oud is niet hetzelfde als slecht

Een applicatie van vijftien jaar oud kan uitstekend passen bij een proces dat in vijftien jaar nauwelijks is veranderd. Draait het stabiel, is het netjes beveiligd, valt het nog te onderhouden en zit het niemand in de weg, dan is er geen enkele reden om eraan te beginnen. Leeftijd op zichzelf is geen argument.

Het wordt pas legacy als het systeem niet meer meebeweegt met de organisatie. Een webshop die bij een campagne onderuit gaat. Een planningstool zonder bruikbare koppelingen. Interne software die prima werkt zolang je precies weet in welke volgorde je moet klikken. Daar zit de pijn: niet in de techniek zelf, maar in de afhankelijkheid en de beperking die eruit volgen.

Een paar nuchtere vragen helpen om dat scherp te krijgen. Kun je het systeem nog binnen redelijke tijd aanpassen? Is er iemand die de techniek echt kent, en is dat niet toevallig één persoon? Houdt het stand tegen de beveiligings- en privacy-eisen van nu? En wat gebeurt er als de leverancier stopt of de server omvalt op een vrijdagmiddag? Daar zit de werkelijke beoordeling, niet in het bouwjaar.

De signalen die wel iets betekenen

Eén storing is geen reden voor een vervangingsproject. Een patroon wel. Als mensen dagelijks om het systeem heen werken, is het geen hulpmiddel meer maar een extra laag in het proces. En als klanten moeten wachten omdat gegevens met de hand worden overgetypt, raakt dat je omzet en je reputatie, ook al verschijnt het nergens op een dashboard.

De patronen die we het vaakst tegenkomen:

• Updates, beveiligingspatches of support zijn er niet meer, of alleen tegen een prijs die niet in verhouding staat.
• Een kleine wijziging kost weken, omdat de code onduidelijk is en de documentatie uit een vorig decennium stamt of nooit heeft bestaan.
• Koppelen lukt niet of nauwelijks, terwijl je boekhouding, CRM en leveranciers juist aan elkaar wilt hebben, net als betaalproviders en andere essentiële onderdelen.
• Exports, spreadsheets en dubbele invoer houden het dagelijkse werk overeind.

Twee signalen worden vaker over het hoofd gezien. Het eerste is schaalbaarheid. Software die bij de huidige omvang net meekomt, kan bij groei zomaar de bottleneck worden. Een webshop met campagnepieken, een SaaS-platform dat er gebruikers bij krijgt, een uitgever met toenemend verkeer: traagheid is dan geen technisch detail. Bezoekers haken af, medewerkers zitten te wachten en een incident is veel moeilijker terug te draaien.

Het tweede is eigenaarschap. Hosting bij partij A, de applicatie bij partij B, een koppeling bij partij C. Zodra er iets omvalt begint het doorschuiven, en niemand pakt het hele probleem op. Voor een proces waar je bedrijf op draait is dat een te dunne afspraak.

Reken ook met de kosten van niets doen

Meestal wordt de vraag te smal gesteld: wat kost vervangen? Interessanter is wat niets doen je de komende twee of drie jaar kost.

Maak dat concreet. Tel de uren die opgaan aan controleren, corrigeren en dubbel invoeren. Schat wat je misloopt door een traag platform, of door functies die klanten verwachten en die er niet kunnen komen. Reken het spoedwerk mee, en de externe specialist die je inhuurt omdat de techniek van toen nauwelijks nog iemand kent.

Daar staan investeringen tegenover: analyse, ontwikkeling, datamigratie, testen, training en beheer. Die staan netjes op een offerte en wegen daarom zwaarder in het gesprek. De kosten van het oude systeem staan nergens, maar lopen elke maand door. Zet die twee eerlijk naast elkaar en de uitkomst verschilt per geval: soms wijst het richting vervangen, soms richting een veel kleinere ingreep.

Die kleinere ingreep is vaker de beste optie dan mensen verwachten. Is de kern nog betrouwbaar, dan kun je er een API-laag naast zetten, een versleten interface vernieuwen of een paar handmatige stappen automatiseren. Je wint snelheid en gebruiksgemak zonder de bedrijfslogica van nul op te bouwen.

Behouden, moderniseren of vervangen

Behouden mag, als het systeem stabiel, veilig en onderhoudbaar is en de behoefte nauwelijks verschuift. Zorg dan wel voor monitoring, back-ups, documentatie en harde afspraken over kennisoverdracht. Behouden zonder beheer is geen keuze, dat is uitstel.

Moderniseren past als de kern waardevol is en de randen versleten zijn. Een administratief systeem dat betrouwbaar rekent maar niet kan koppelen. Een intern platform met goede logica en een interface waar niemand vrolijk van wordt. Door gericht stukken te vernieuwen houd je grip op budget en risico.

Vervangen is aan de orde als de basis zelf het probleem is. Beveiliging die niet meer te repareren valt, code die je niet betrouwbaar kunt aanpassen, of software die simpelweg niet past bij hoe het bedrijf nu werkt. Dan is blijven plakken op termijn duurder dan opnieuw bouwen, hoe groot dat laatste in eerste instantie ook voelt.

Er speelt nog iets mee: hoe onderscheidend is dit stuk software eigenlijk? Zit er iets in dat jullie dienstverlening, planning of klantbeleving echt anders maakt, dan is maatwerk meestal verstandig. Gaat het om een standaardproces waar niemand wakker van ligt, dan is een bestaand pakket met goede koppelingen prima. Maatwerk is geen doel op zich, maar wel logisch zodra standaardsoftware je dwingt tot omwegen.

Vervangen zonder de tent plat te leggen

De klassieke fout is alles in één keer willen opleveren. Een big bang lijkt overzichtelijk, één datum en één livegang, maar vergroot juist de afhankelijkheden. Eén vergeten uitzondering in de facturatie of de voorraadkoppeling en je zit maandagochtend in de problemen.

Gefaseerd werken geeft meer grip. Begin met inventariseren, technisch en functioneel: welke processen zijn kritiek, welke data zijn betrouwbaar, welke koppelingen bestaan er en waar lopen mensen dagelijks tegenaan? Praat daarbij niet alleen met management en IT, maar vooral met de mensen die het systeem elke dag openen. Zij kennen de uitzonderingen die in geen enkel document staan.

Kies daarna een eerste oplevering die klein is en toch meteen iets oplevert. Een nieuw klantportaal, een koppeling die dubbele invoer wegneemt, of een tool voor dat ene foutgevoelige proces. Laat oud en nieuw tijdelijk naast elkaar lopen waar dat nodig is. Dan kan de organisatie wennen, testen met echte situaties en bijsturen, terwijl de dienstverlening gewoon doorloopt.

Datamigratie krijgt zijn eigen plan. In oude systemen zitten dubbele klantrecords, lege velden en historie die niemand meer opvraagt. Alles blind meenemen maakt het nieuwe systeem onnodig ingewikkeld. Spreek vooraf af wat de operatie echt nodig heeft, wat alleen raadpleegbaar hoeft te blijven en wat volgens de bewaartermijnen gearchiveerd of verwijderd kan worden.

Leg hosting en beheer ook meteen op tafel. Een nieuwe applicatie die technisch netjes is gebouwd maar slecht wordt gemonitord, geback-upt of geschaald, levert vooral een nieuwer probleem op. Ontwikkeling, infrastructuur en support moeten op elkaar aansluiten, en als er iets misgaat moet duidelijk zijn wie het oppakt en hoe snel.

Wat je vooraf moet uitvragen

Een lijst met functies is niet genoeg om op te starten. Zo'n lijst beschrijft wat mensen nu doen, niet waarom ze het doen. Vraag dus welke processtappen echt waarde toevoegen, welke uitzonderingen regelmatig voorkomen en welke informatie op welk moment nodig is. Geregeld blijkt een veelgevraagde functie vooral een workaround voor iets heel anders.

Vraag ook hoe succes er na een half jaar uitziet. Minder handwerk? Orders die sneller door het proces gaan? Minder supporttickets? Beschikbaarheid die ook tijdens een piek overeind blijft? Met meetbare doelen voorkom je een project dat technisch wordt opgeleverd en operationeel weinig verandert.

Een goede technische partner komt in het eerste gesprek niet direct met een pakket of een groot nieuwbouwplan aanzetten. Eerst moet helder zijn waar de kwetsbaarheid zit, wat van het bestaande landschap kan blijven staan en hoe je de overgang beheersbaar houdt. Bij LJPc kijken we naar applicatie, koppelingen en hosting als één geheel, omdat een oplossing pas wat waard is als die ook op een drukke dinsdag blijft staan.

Wachten tot legacysoftware er echt mee ophoudt is de duurste manier om te vervangen. Begin op het moment dat de risico's zichtbaar worden en er nog ruimte is om te kiezen. Dan bouw je vanuit controle in plaats van paniek, en doet de techniek weer waar ze voor bedoeld is: het werk makkelijker maken.