Waarom oude software niet per definitie slechte software is

Verouderde software bevat vaak onvervangbare bedrijfslogica. Ontdek wanneer modernisering beter is dan vervanging — en hoe u kunt voortbouwen op wat al werkt.

Uw ERP draait al 15 jaar. Het beheert de voorraad, verwerkt inkopen, stuurt de facturering aan — en iedereen in het pand weet precies hoe het werkt. Maar er is geen mobiele toegang, geen API, geen cloudlaag en absoluut geen AI. De druk om het systeem 'gewoon te vervangen' neemt toe. Lees dit voordat u die stap zet.

Dit artikel maakt de volledige zaak voor waarom oude software niet automatisch slechte software is — en biedt u een praktisch kader om te beslissen of u moet moderniseren, uitbreiden of daadwerkelijk vervangen.

Wat bedoelen we eigenlijk met "legacy software"?

Het woord legacy wordt vaak gebruikt als synoniem voor slecht, maar dat zijn ze niet. Legacy software is simpelweg een systeem dat in een eerder tijdperk is gebouwd — vaak voordat cloud computing, REST API's en mobiele apparaten standaard waren. Het betekent niet dat het systeem tekortschiet. In veel gevallen betekent het juist het tegenovergestelde: het heeft overleefd omdat het werkt.

Een op FileMaker gebaseerd ERP dat al 15+ jaar door een productiebedrijf wordt gebruikt voor voorraadbeheer, productieplanning, inkoop en facturering is daar een perfect voorbeeld van. Dat systeem heeft die 15 jaar niet bij toeval volgehouden. Het heeft volgehouden omdat het is gebouwd rondom de werkelijke manier waarop dat bedrijf opereert — met alle uitzonderingen, afwijkingen en institutionele kennis ingebakken.

De echte vraag is nooit: 'is dit systeem oud?' De echte vraag is: doet het nog wat het bedrijf nodig heeft, en kan het worden uitgebreid om te doen wat er daarna komt?

Waarom grijpen bedrijven instinctief naar vervanging?

Er zijn een paar terugkerende aanleidingen:

Een leverancier stopt met ondersteuning van het platform
Een nieuwe medewerker (vaak afkomstig van een groter bedrijf) pleit voor een 'moderne' stack
Een aantrekkelijke SaaS-demo belandt in de inbox van de CEO
Het systeem oogt verouderd vergeleken met consumentenapps
Een specifieke ontbrekende functie wordt een zichtbaar pijnpunt

Geen van deze zijn automatisch geldige redenen om een volledig systeem te vervangen. Het zijn wel geldige redenen om het systeem te evalueren. Dat is een wezenlijk verschil.

De vervangingsreflex is bovendien kostbaar. Migraties van bedrijfssoftware lopen regelmatig uit in tijd en budget, en leveren minder op dan verwacht — zeker wanneer teams onderschatten hoeveel bedrijfslogica in het oude systeem is verankerd en nooit gedocumenteerd.

Wat er verloren gaat bij een volledige vervanging, waar niemand genoeg over spreekt

Old system with labeled business logic nodes being transferred to new system, some nodes missing

Wanneer een bedrijf een 15 jaar oud ERP vervangt, vervangt het niet zomaar een database. Het vervangt:

Bedrijfsregels opgebouwd door jaren van echte uitzonderingen — de factuurafronding die aansluit op de verwachtingen van uw grootste klant, de productieorder die voor één productlijn altijd anders wordt opgesplitst, de inkoopgoedkeuring die drie niveaus heeft in plaats van twee, vanwege één slechte leverancierservaring in 2014
Impliciete kennis verankerd in veldnamen en workflows — de mensen die het systeem hebben gebouwd en de mensen die het gebruiken, delen een mentaal model dat een nieuw systeem direct zal verstoren
Rapportagelogica — dat wekelijkse margeoverzicht waar de CFO op vertrouwt, heeft waarschijnlijk jaren van iteratie gekost om goed te krijgen
Integraties en omwegen — zelfs systemen zonder formele API's hebben informele: CSV-exports, geplande scripts, e-mailtriggers waarvan andere processen afhankelijk zijn

Niets hiervan komt naar voren in een leveranciersdemo. Dit alles moet vanaf nul worden herbouwd — of vaker: moeizaam herontdekt worden na de livegang.

Wanneer is vervanging dan wél het juiste antwoord?

Om eerlijk te zijn: soms is vervanging het juiste besluit. De gevallen waarin het werkelijk zinvol is:

Het kernplatform is technisch dood — geen updates, geen community, geen haalbaar pad om op moderne infrastructuur te draaien
Het datamodel is fundamenteel gebroken — niet alleen oud, maar structureel verkeerd op manieren die dagelijks operationele fouten veroorzaken
Aan compliancevereisten kan niet worden voldaan — beveiligings-, privacy- of regelgevingseisen waaraan het systeem ook met uitbreidingen niet kan voldoen
De kosten van wijzigingen zijn hoger dan de kosten van herbouw — elke nieuwe functionaliteitsvraag vergt maanden werk, zo verstrengeld is de architectuur
Het bedrijfsmodel zelf is veranderd — u voert nu een fundamenteel andere operatie dan waarvoor het systeem is gebouwd

Als twee of meer van deze punten tegelijk van toepassing zijn, is vervanging waarschijnlijk het juiste besluit. Als slechts één ervan speelt — of als de drijvende reden esthetisch is ('het ziet er oud uit') of sociaal ('we willen iets dat meer op Salesforce lijkt') — stop dan en heroverweeg.

De moderniseringsaanpak: uitbreiden wat al werkt

Dit is hoe modernisering er in de praktijk uitziet, aan de hand van het voorbeeld van het productiebedrijf.

Het bedrijf heeft een FileMaker ERP dat voorraad, productie, inkoop en facturering beheert. Het werkt. Maar:

Buitendienstmedewerkers hebben geen toegang via een tablet op de werkvloer
Het systeem kan geen gegevens uitwisselen met een leveranciersportaal via API
Finance wil realtime dashboards, geen exports
Het operationeel team vraagt zich af of AI afwijkingen in productieruns kan signaleren

Geen van deze problemen vereist vervanging van het ERP. Ze vereisen het bouwen van een moderne laag rondom de bestaande kern.

Stap 1: Breng in kaart wat het systeem goed doet

Voordat u iets aanpast, brengt u de workflows, bedrijfsregels en integraties (formeel en informeel) in kaart die het systeem al betrouwbaar afhandelt. Dit is uw activainventaris. Behandel het als zodanig.

Stap 2: Identificeer de hiaten per categorie

Maak onderscheid tussen:

Toegangshiaten (mobiel, cloud, op afstand) — meestal oplosbaar met een front-endlaag of progressive web app
Integratiehiaten (geen API, geen webhooks) — oplosbaar met middleware of een dedicated API-connector
Inzichtshiaten (geen dashboards, geen analyses) — oplosbaar met een rapportagelaag gekoppeld aan de bestaande data
Intelligentiehiaten (geen AI, geen automatisering) — steeds vaker oplosbaar door AI-mogelijkheden in of naast het bestaande systeem in te bedden

Stap 3: Bouw naar buiten, niet naar binnen

Wijzig het kernsysteem zo min mogelijk. Bouw in plaats daarvan connectors en uitbreidingen die gebruikmaken van het bestaande datamodel. In FileMaker betekent dit vaak het gebruik van de Data API om data beschikbaar te stellen aan externe applicaties — een webportaal voor klanten, een mobiele interface voor magazijnmedewerkers, of een AI-module die productieregistraties leest en voorspellingen genereert.

Stap 4: Integreer incrementeel

Probeer geen grote modernisering in één keer door te voeren. Koppel één systeem tegelijk. Begin met de integratie met de duidelijkste ROI — bijvoorbeeld het elimineren van het handmatig overtypen van orders vanuit FileMaker naar Exact Online, elke order, elke dag. Die ene connector alleen al kan uren per week vrijmaken en een significant foutenrisico wegnemen.

Stap 5: Valideer voor u uitbreidt

Valideer na elke integratie in productie. Wat werkt niet? Wat nemen gebruikers daadwerkelijk aan? Welke datakwaliteitsproblemen komen aan het licht? Bouw de volgende laag pas nadat de vorige stabiel is.

Manufacturing ERP system at center, with API connectors, mobile layer, AI module, and cloud dashboard extending outward from it

Uw eigen systeem evalueren: een praktische checklist

Doorloop het volgende voordat u kiest voor één van beide paden:

Signalen dat uw systeem nog significant levensvatbaar is:

Kernworkflows draaien zonder dagelijkse omwegen of handmatige correcties
Gebruikers begrijpen de data in het systeem en vertrouwen erop
De bedrijfslogica in het systeem heeft jaren gekost om te ontwikkelen en is nergens anders gedocumenteerd
De voornaamste klachten gaan over ontbrekende functies, niet over gebroken functionaliteit
Het systeem is stabiel — weinig uitval, weinig datacorruptie, lage onderhoudsbelasting
Een vervangingsproject zou vereisen dat processen opnieuw worden beschreven die nog niet goed genoeg worden begrepen om te specificeren

Signalen dat vervanging mogelijk werkelijk noodzakelijk is:

Het systeem faalt regelmatig en de fixes worden steeds moeilijker
Het onderliggende platform heeft geen pad naar moderne infrastructuur
U kunt niet voldoen aan beveiligings- of compliancevereisten
U betaalt meer aan omwegen en handmatig werk dan u zou betalen om het te herbouwen
Het bedrijfsmodel is fundamenteel veranderd en het systeem kan het niet meer representeren

Wat kost modernisering versus vervanging?

Dit is waar de cijfers interessant worden — en waar de meeste organisaties verrast worden.

Een volledige ERP-vervanging voor een middelgroot productiebedrijf omvat doorgaans:

Softwarelicenties (vaak per gebruiker, terugkerend)
Implementatie en configuratie (doorgaans 1–3× de licentiekosten)
Datamigratie (bijna altijd onderschat)
Omscholing van medewerkers
Productiviteitsverlies tijdens de transitie (vaak 3–9 maanden)
Correcties na livegang voor de bedrijfslogica die niet in de requirements was vastgelegd

Een moderniseringsproject — cloud-toegang toevoegen, een API-laag en één of twee integraties aan een bestaand stabiel systeem — kost doorgaans een fractie daarvan, wordt sneller opgeleverd en brengt een veel lager operationeel risico met zich mee.

De afweging: modernisering heeft wél een plafond. U kunt een systeem onbeperkt uitbreiden, maar als de onderliggende architectuur zoveel uitbreidingen accumuleert dat het moeilijker te onderhouden is dan te vervangen, heeft u de onvermijdelijke beslissing slechts uitgesteld. Het doel is slimme tijd kopen — geen oneindige tijd.

Veelgestelde vragen

Is het niet riskant om oude software te blijven gebruiken? Dat hangt volledig af van wat 'oud' in context betekent. Oud-en-stabiel heeft een ander risicoprofiel dan oud-en-falend. De risico's om te beoordelen zijn: platformondersteuning, beveiligingskwetsbaarheden, bus-factor (wat gebeurt er als de enige persoon die het systeem kent vertrekt) en integratiecapaciteit. Veel van deze risico's zijn beheersbaar zonder vervanging.

Wat als de oorspronkelijke ontwikkelaars er niet meer zijn? Dit is een reële zorg, maar geen reden om te vervangen. Een goed gestructureerd FileMaker-systeem kan bijvoorbeeld door een ervaren ontwikkelaar worden begrepen en uitgebreid, ook zonder het oorspronkelijke team. De eerste stap is een code-audit — geen migratieproject.

Kan AI echt worden toegevoegd aan een legacy-systeem? Ja — in toenemende mate. Het patroon is om de data van het legacy-systeem via een API te koppelen aan een AI-laag, in plaats van het systeem te herbouwen om 'AI-native' te zijn. De bestaande data is vaak het meest waardevolle onderdeel: 15 jaar aan productieregistraties, inkooppatronen en voorraadmutaties is precies het materiaal dat AI-tools nodig hebben voor training en inferentie.

Hoe weten we wanneer we het moderniseringsplafond bereiken? Let op deze signalen: de tijd om een wijziging door te voeren groeit sneller dan de wijziging zelf rechtvaardigt; het systeem heeft meer integraties dan één persoon kan overzien; de datakwaliteit verslechtert omdat te veel systemen naar dezelfde opslag schrijven. Wanneer twee of meer hiervan optreden, is het tijd om de vervangingsvraag opnieuw te stellen — maar dan met een veel helderder beeld van wat er gebouwd moet worden, omdat u de hele tijd in productie heeft gedraaid.

Wat is de eerste stap als we ons systeem willen evalueren? Begin met een gestructureerde audit: breng elke workflow, elke integratie (handmatig en geautomatiseerd) en elk stuk bedrijfslogica in kaart dat nergens anders is vastgelegd. Dit alleen al is waardevol, ongeacht wat u daarna besluit.

Het grotere geheel: softwarebeslissingen zijn bedrijfsbeslissingen

Het kader van 'legacy versus modern' is een technologisch kader. Het juiste kader is een zakelijk: wat kost dit systeem om te exploiteren, wat maakt het mogelijk, wat verhindert het, en wat zou het kosten — in geld, risico en verloren capaciteit — om het te wijzigen?

Bedrijven die die vragen helder stellen, nemen doorgaans veel betere beslissingen dan bedrijven die 'modern' als doel op zich nastreven. Zoals uitgebreid besproken in How to modernize business software without starting over, is de meest duurzame aanpak bijna altijd om bestaande systemen strategisch te laten evolueren in plaats van ze reactief te vervangen.

Oude software die nog werkt is geen last. Het is een asset met een onderhoudsschema.

Als u deze beslissing voor uw eigen systeem overweegt — of u nu een FileMaker ERP wilt uitbreiden, koppelen aan moderne API's, voorzien van een weblaag, of simpelweg wilt begrijpen waar het plafond ligt — werkt Loggix dagelijks met productiebedrijven, distributeurs en professionele dienstverleners door precies deze vragen. De juiste volgende stap is doorgaans een gestructureerde audit, geen migratieproject. Neem contact op als u het wilt doordenken.