[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3fcyvdAVDO2yGPRY-XGyUof53t5kFA0zk3-lDnxXF3w":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":29,"hasDownload":30,"fileName":9,"youtubeId":31,"domainCrumb":32,"clusterCrumb":35},"116","CB9719A0-E76D-E94A-BD44-47375001D277","5D5F3733-6027-284B-BC54-3DAF4A98517A","C9A2E812-0A2C-FC46-929B-A19F9A440E05","","why-old-software-is-not-necessarily-bad-software","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.\n\nDit 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.\n\n---\n\n## Wat bedoelen we eigenlijk met \"legacy software\"?\n\nHet 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.\n\nEen 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.\n\nDe 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?**\n\n---\n\n## Waarom grijpen bedrijven instinctief naar vervanging?\n\nEr zijn een paar terugkerende aanleidingen:\n\n- Een leverancier stopt met ondersteuning van het platform\n- Een nieuwe medewerker (vaak afkomstig van een groter bedrijf) pleit voor een 'moderne' stack\n- Een aantrekkelijke SaaS-demo belandt in de inbox van de CEO\n- Het systeem oogt verouderd vergeleken met consumentenapps\n- Een specifieke ontbrekende functie wordt een zichtbaar pijnpunt\n\nGeen 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.\n\nDe 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.\n\n---\n\n## Wat er verloren gaat bij een volledige vervanging, waar niemand genoeg over spreekt\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F18?w=700&f=webp\" alt=\"Old system with labeled business logic nodes being transferred to new system, some nodes missing\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\nWanneer een bedrijf een 15 jaar oud ERP vervangt, vervangt het niet zomaar een database. Het vervangt:\n\n- **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\n- **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\n- **Rapportagelogica** — dat wekelijkse margeoverzicht waar de CFO op vertrouwt, heeft waarschijnlijk jaren van iteratie gekost om goed te krijgen\n- **Integraties en omwegen** — zelfs systemen zonder formele API's hebben informele: CSV-exports, geplande scripts, e-mailtriggers waarvan andere processen afhankelijk zijn\n\nNiets hiervan komt naar voren in een leveranciersdemo. Dit alles moet vanaf nul worden herbouwd — of vaker: moeizaam herontdekt worden na de livegang.\n\n---\n\n## Wanneer is vervanging dan wél het juiste antwoord?\n\nOm eerlijk te zijn: soms is vervanging het juiste besluit. De gevallen waarin het werkelijk zinvol is:\n\n1. **Het kernplatform is technisch dood** — geen updates, geen community, geen haalbaar pad om op moderne infrastructuur te draaien\n2. **Het datamodel is fundamenteel gebroken** — niet alleen oud, maar structureel verkeerd op manieren die dagelijks operationele fouten veroorzaken\n3. **Aan compliancevereisten kan niet worden voldaan** — beveiligings-, privacy- of regelgevingseisen waaraan het systeem ook met uitbreidingen niet kan voldoen\n4. **De kosten van wijzigingen zijn hoger dan de kosten van herbouw** — elke nieuwe functionaliteitsvraag vergt maanden werk, zo verstrengeld is de architectuur\n5. **Het bedrijfsmodel zelf is veranderd** — u voert nu een fundamenteel andere operatie dan waarvoor het systeem is gebouwd\n\nAls 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.\n\n---\n\n## De moderniseringsaanpak: uitbreiden wat al werkt\n\nDit is hoe modernisering er in de praktijk uitziet, aan de hand van het voorbeeld van het productiebedrijf.\n\nHet bedrijf heeft een FileMaker ERP dat voorraad, productie, inkoop en facturering beheert. Het werkt. Maar:\n\n- Buitendienstmedewerkers hebben geen toegang via een tablet op de werkvloer\n- Het systeem kan geen gegevens uitwisselen met een leveranciersportaal via API\n- Finance wil realtime dashboards, geen exports\n- Het operationeel team vraagt zich af of AI afwijkingen in productieruns kan signaleren\n\nGeen van deze problemen vereist vervanging van het ERP. Ze vereisen het bouwen van een **moderne laag rondom de bestaande kern**.\n\n### Stap 1: Breng in kaart wat het systeem goed doet\nVoordat 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.\n\n### Stap 2: Identificeer de hiaten per categorie\nMaak onderscheid tussen:\n- **Toegangshiaten** (mobiel, cloud, op afstand) — meestal oplosbaar met een front-endlaag of progressive web app\n- **Integratiehiaten** (geen API, geen webhooks) — oplosbaar met middleware of een dedicated API-connector\n- **Inzichtshiaten** (geen dashboards, geen analyses) — oplosbaar met een rapportagelaag gekoppeld aan de bestaande data\n- **Intelligentiehiaten** (geen AI, geen automatisering) — steeds vaker oplosbaar door AI-mogelijkheden in of naast het bestaande systeem in te bedden\n\n### Stap 3: Bouw naar buiten, niet naar binnen\nWijzig 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.\n\n### Stap 4: Integreer incrementeel\nProbeer 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.\n\n### Stap 5: Valideer voor u uitbreidt\nValideer 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.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F17?w=700&f=webp\" alt=\"Manufacturing ERP system at center, with API connectors, mobile layer, AI module, and cloud dashboard extending outward from it\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n---\n\n## Uw eigen systeem evalueren: een praktische checklist\n\nDoorloop het volgende voordat u kiest voor één van beide paden:\n\n**Signalen dat uw systeem nog significant levensvatbaar is:**\n- [ ] Kernworkflows draaien zonder dagelijkse omwegen of handmatige correcties\n- [ ] Gebruikers begrijpen de data in het systeem en vertrouwen erop\n- [ ] De bedrijfslogica in het systeem heeft jaren gekost om te ontwikkelen en is nergens anders gedocumenteerd\n- [ ] De voornaamste klachten gaan over ontbrekende functies, niet over gebroken functionaliteit\n- [ ] Het systeem is stabiel — weinig uitval, weinig datacorruptie, lage onderhoudsbelasting\n- [ ] Een vervangingsproject zou vereisen dat processen opnieuw worden beschreven die nog niet goed genoeg worden begrepen om te specificeren\n\n**Signalen dat vervanging mogelijk werkelijk noodzakelijk is:**\n- [ ] Het systeem faalt regelmatig en de fixes worden steeds moeilijker\n- [ ] Het onderliggende platform heeft geen pad naar moderne infrastructuur\n- [ ] U kunt niet voldoen aan beveiligings- of compliancevereisten\n- [ ] U betaalt meer aan omwegen en handmatig werk dan u zou betalen om het te herbouwen\n- [ ] Het bedrijfsmodel is fundamenteel veranderd en het systeem kan het niet meer representeren\n\n---\n\n## Wat kost modernisering versus vervanging?\n\nDit is waar de cijfers interessant worden — en waar de meeste organisaties verrast worden.\n\nEen volledige ERP-vervanging voor een middelgroot productiebedrijf omvat doorgaans:\n- Softwarelicenties (vaak per gebruiker, terugkerend)\n- Implementatie en configuratie (doorgaans 1–3× de licentiekosten)\n- Datamigratie (bijna altijd onderschat)\n- Omscholing van medewerkers\n- Productiviteitsverlies tijdens de transitie (vaak 3–9 maanden)\n- Correcties na livegang voor de bedrijfslogica die niet in de requirements was vastgelegd\n\nEen 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.\n\nDe 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.\n\n---\n\n## Veelgestelde vragen\n\n**Is het niet riskant om oude software te blijven gebruiken?**\nDat 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.\n\n**Wat als de oorspronkelijke ontwikkelaars er niet meer zijn?**\nDit 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.\n\n**Kan AI echt worden toegevoegd aan een legacy-systeem?**\nJa — 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.\n\n**Hoe weten we wanneer we het moderniseringsplafond bereiken?**\nLet 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.\n\n**Wat is de eerste stap als we ons systeem willen evalueren?**\nBegin 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.\n\n---\n\n## Het grotere geheel: softwarebeslissingen zijn bedrijfsbeslissingen\n\nHet 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?\n\nBedrijven 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](https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-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.\n\nOude software die nog werkt is geen last. Het is een asset met een onderhoudsschema.\n\n---\n\nAls 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](https:\u002F\u002Floggix.com\u002Fen\u002Fcontact) als u het wilt doordenken.","\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>Wat bedoelen we eigenlijk met "legacy software"?\u003C\u002Fh2>\n\u003Cp>Het woord \u003Cem>legacy\u003C\u002Fem> wordt vaak gebruikt als synoniem voor \u003Cem>slecht\u003C\u002Fem>, 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>De echte vraag is nooit: 'is dit systeem oud?' De echte vraag is: \u003Cstrong>doet het nog wat het bedrijf nodig heeft, en kan het worden uitgebreid om te doen wat er daarna komt?\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>Waarom grijpen bedrijven instinctief naar vervanging?\u003C\u002Fh2>\n\u003Cp>Er zijn een paar terugkerende aanleidingen:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Een leverancier stopt met ondersteuning van het platform\u003C\u002Fli>\n\u003Cli>Een nieuwe medewerker (vaak afkomstig van een groter bedrijf) pleit voor een 'moderne' stack\u003C\u002Fli>\n\u003Cli>Een aantrekkelijke SaaS-demo belandt in de inbox van de CEO\u003C\u002Fli>\n\u003Cli>Het systeem oogt verouderd vergeleken met consumentenapps\u003C\u002Fli>\n\u003Cli>Een specifieke ontbrekende functie wordt een zichtbaar pijnpunt\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Geen van deze zijn automatisch geldige redenen om een volledig systeem te vervangen. Het zijn wel geldige redenen om het systeem te \u003Cem>evalueren\u003C\u002Fem>. Dat is een wezenlijk verschil.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>Wat er verloren gaat bij een volledige vervanging, waar niemand genoeg over spreekt\u003C\u002Fh2>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F18?w=700&f=webp\" alt=\"Old system with labeled business logic nodes being transferred to new system, some nodes missing\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Cp>Wanneer een bedrijf een 15 jaar oud ERP vervangt, vervangt het niet zomaar een database. Het vervangt:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Bedrijfsregels opgebouwd door jaren van echte uitzonderingen\u003C\u002Fstrong> — 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\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Impliciete kennis verankerd in veldnamen en workflows\u003C\u002Fstrong> — de mensen die het systeem hebben gebouwd en de mensen die het gebruiken, delen een mentaal model dat een nieuw systeem direct zal verstoren\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Rapportagelogica\u003C\u002Fstrong> — dat wekelijkse margeoverzicht waar de CFO op vertrouwt, heeft waarschijnlijk jaren van iteratie gekost om goed te krijgen\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Integraties en omwegen\u003C\u002Fstrong> — zelfs systemen zonder formele API's hebben informele: CSV-exports, geplande scripts, e-mailtriggers waarvan andere processen afhankelijk zijn\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Niets hiervan komt naar voren in een leveranciersdemo. Dit alles moet vanaf nul worden herbouwd — of vaker: moeizaam herontdekt worden na de livegang.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>Wanneer is vervanging dan wél het juiste antwoord?\u003C\u002Fh2>\n\u003Cp>Om eerlijk te zijn: soms is vervanging het juiste besluit. De gevallen waarin het werkelijk zinvol is:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Het kernplatform is technisch dood\u003C\u002Fstrong> — geen updates, geen community, geen haalbaar pad om op moderne infrastructuur te draaien\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Het datamodel is fundamenteel gebroken\u003C\u002Fstrong> — niet alleen oud, maar structureel verkeerd op manieren die dagelijks operationele fouten veroorzaken\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Aan compliancevereisten kan niet worden voldaan\u003C\u002Fstrong> — beveiligings-, privacy- of regelgevingseisen waaraan het systeem ook met uitbreidingen niet kan voldoen\u003C\u002Fli>\n\u003Cli>\u003Cstrong>De kosten van wijzigingen zijn hoger dan de kosten van herbouw\u003C\u002Fstrong> — elke nieuwe functionaliteitsvraag vergt maanden werk, zo verstrengeld is de architectuur\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Het bedrijfsmodel zelf is veranderd\u003C\u002Fstrong> — u voert nu een fundamenteel andere operatie dan waarvoor het systeem is gebouwd\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>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.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>De moderniseringsaanpak: uitbreiden wat al werkt\u003C\u002Fh2>\n\u003Cp>Dit is hoe modernisering er in de praktijk uitziet, aan de hand van het voorbeeld van het productiebedrijf.\u003C\u002Fp>\n\u003Cp>Het bedrijf heeft een FileMaker ERP dat voorraad, productie, inkoop en facturering beheert. Het werkt. Maar:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Buitendienstmedewerkers hebben geen toegang via een tablet op de werkvloer\u003C\u002Fli>\n\u003Cli>Het systeem kan geen gegevens uitwisselen met een leveranciersportaal via API\u003C\u002Fli>\n\u003Cli>Finance wil realtime dashboards, geen exports\u003C\u002Fli>\n\u003Cli>Het operationeel team vraagt zich af of AI afwijkingen in productieruns kan signaleren\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Geen van deze problemen vereist vervanging van het ERP. Ze vereisen het bouwen van een \u003Cstrong>moderne laag rondom de bestaande kern\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Ch3>Stap 1: Breng in kaart wat het systeem goed doet\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3>Stap 2: Identificeer de hiaten per categorie\u003C\u002Fh3>\n\u003Cp>Maak onderscheid tussen:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Toegangshiaten\u003C\u002Fstrong> (mobiel, cloud, op afstand) — meestal oplosbaar met een front-endlaag of progressive web app\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Integratiehiaten\u003C\u002Fstrong> (geen API, geen webhooks) — oplosbaar met middleware of een dedicated API-connector\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Inzichtshiaten\u003C\u002Fstrong> (geen dashboards, geen analyses) — oplosbaar met een rapportagelaag gekoppeld aan de bestaande data\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Intelligentiehiaten\u003C\u002Fstrong> (geen AI, geen automatisering) — steeds vaker oplosbaar door AI-mogelijkheden in of naast het bestaande systeem in te bedden\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Stap 3: Bouw naar buiten, niet naar binnen\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3>Stap 4: Integreer incrementeel\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch3>Stap 5: Valideer voor u uitbreidt\u003C\u002Fh3>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F17?w=700&f=webp\" alt=\"Manufacturing ERP system at center, with API connectors, mobile layer, AI module, and cloud dashboard extending outward from it\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Chr>\n\u003Ch2>Uw eigen systeem evalueren: een praktische checklist\u003C\u002Fh2>\n\u003Cp>Doorloop het volgende voordat u kiest voor één van beide paden:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Signalen dat uw systeem nog significant levensvatbaar is:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Kernworkflows draaien zonder dagelijkse omwegen of handmatige correcties\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Gebruikers begrijpen de data in het systeem en vertrouwen erop\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> De bedrijfslogica in het systeem heeft jaren gekost om te ontwikkelen en is nergens anders gedocumenteerd\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> De voornaamste klachten gaan over ontbrekende functies, niet over gebroken functionaliteit\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Het systeem is stabiel — weinig uitval, weinig datacorruptie, lage onderhoudsbelasting\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Een vervangingsproject zou vereisen dat processen opnieuw worden beschreven die nog niet goed genoeg worden begrepen om te specificeren\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Signalen dat vervanging mogelijk werkelijk noodzakelijk is:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Het systeem faalt regelmatig en de fixes worden steeds moeilijker\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Het onderliggende platform heeft geen pad naar moderne infrastructuur\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> U kunt niet voldoen aan beveiligings- of compliancevereisten\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> U betaalt meer aan omwegen en handmatig werk dan u zou betalen om het te herbouwen\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Het bedrijfsmodel is fundamenteel veranderd en het systeem kan het niet meer representeren\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Chr>\n\u003Ch2>Wat kost modernisering versus vervanging?\u003C\u002Fh2>\n\u003Cp>Dit is waar de cijfers interessant worden — en waar de meeste organisaties verrast worden.\u003C\u002Fp>\n\u003Cp>Een volledige ERP-vervanging voor een middelgroot productiebedrijf omvat doorgaans:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Softwarelicenties (vaak per gebruiker, terugkerend)\u003C\u002Fli>\n\u003Cli>Implementatie en configuratie (doorgaans 1–3× de licentiekosten)\u003C\u002Fli>\n\u003Cli>Datamigratie (bijna altijd onderschat)\u003C\u002Fli>\n\u003Cli>Omscholing van medewerkers\u003C\u002Fli>\n\u003Cli>Productiviteitsverlies tijdens de transitie (vaak 3–9 maanden)\u003C\u002Fli>\n\u003Cli>Correcties na livegang voor de bedrijfslogica die niet in de requirements was vastgelegd\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>Veelgestelde vragen\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Is het niet riskant om oude software te blijven gebruiken?\u003C\u002Fstrong>\nDat 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Wat als de oorspronkelijke ontwikkelaars er niet meer zijn?\u003C\u002Fstrong>\nDit 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Kan AI echt worden toegevoegd aan een legacy-systeem?\u003C\u002Fstrong>\nJa — 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Hoe weten we wanneer we het moderniseringsplafond bereiken?\u003C\u002Fstrong>\nLet 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Wat is de eerste stap als we ons systeem willen evalueren?\u003C\u002Fstrong>\nBegin 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.\u003C\u002Fp>\n\u003Chr>\n\u003Ch2>Het grotere geheel: softwarebeslissingen zijn bedrijfsbeslissingen\u003C\u002Fh2>\n\u003Cp>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?\u003C\u002Fp>\n\u003Cp>Bedrijven die die vragen helder stellen, nemen doorgaans veel betere beslissingen dan bedrijven die 'modern' als doel op zich nastreven. Zoals uitgebreid besproken in \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fblog\u002Fhow-to-modernize-business-software-without-starting-over\">How to modernize business software without starting over\u003C\u002Fa>, is de meest duurzame aanpak bijna altijd om bestaande systemen strategisch te laten evolueren in plaats van ze reactief te vervangen.\u003C\u002Fp>\n\u003Cp>Oude software die nog werkt is geen last. Het is een asset met een onderhoudsschema.\u003C\u002Fp>\n\u003Chr>\n\u003Cp>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. \u003Ca href=\"https:\u002F\u002Floggix.com\u002Fen\u002Fcontact\">Neem contact op\u003C\u002Fa> als u het wilt doordenken.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901658000,[19,20,21,22,23,24,25,26,27,28],"legacy software","software modernization","ERP","FileMaker","business software strategy","system integration","API connectors","AI in ERP","replace vs modernize","custom business software","\u002Fapi\u002Fknowledge\u002Fimage\u002F116\u002F?v=ee41af06196b",false,null,{"title":33,"slug":34},"Bedrijfssoftwarestrategie","business-software-strategy",{"title":36,"slug":37},"Hoe u bedrijfssoftware moderniseert zonder opnieuw te beginnen","how-to-modernize-business-software-without-starting-over"]