Business-kritische applicaties die te oud zijn om makkelijk uit te breiden, maar te belangrijk om zomaar te vervangen. Wij begeleiden de hele migratie: van portfolio-analyse en 6R-classificatie tot strangler-fig uitrol en beheer-overdracht.
Technische schuld is incrementele rommel: hier en daar een refactor, een testdekking aanvullen, dependencies upgraden. Een legacy-modernisering is een orde groter. Het gaat om systemen waar de tech-stack zelf het probleem is — een Delphi-applicatie waarvan de oorspronkelijke ontwikkelaar al jaren weg is, een AS/400 met RPG-code die niemand meer aandurft, een Classic ASP-portaal dat niet meer met moderne single sign-on praat, of een Oracle Forms-omgeving die alleen op een specifieke versie van Java draait die zelf alweer end-of-life is.
De pijn is bekend: elke wijziging is duur, elke uitbreiding voelt riskant, en de mensen die het systeem nog echt kennen worden steeds schaarser. Tegelijkertijd zit er vaak jaren aan zorgvuldig opgebouwde business-logica in. Die mag niet verloren gaan bij een migratie, maar de stack waarop ’ie draait verdient een tweede leven elders.
Wij doen dit werk al sinds bedrijven hun eerste cloud-migratie planden. We zijn pragmatisch: niet elke legacy-app moet herbouwd worden, sommige moeten gewoon retired worden, andere kunnen prima nog jaren mee na een rehost. De kunst is om per applicatie de juiste keuze te maken, en de migratie zo te plannen dat de business er geen last van heeft. Voor incrementele opruim-werkzaamheden binnen één codebase verwijzen we u graag naar onze pagina over technische schuld oplossen; voor de hosting-kant raden we onze pagina platform-migratie laten uitvoeren aan.
De omvang van een traject hangt af van het aantal applicaties, de afhankelijkheden ertussen en de mate waarin u nog grip op de oorspronkelijke code heeft. We adviseren in het eerste gesprek welk niveau bij uw situatie past.
Een specifieke applicatie die de organisatie remt — een desktop-Delphi-tool, een Classic ASP-portaal, een Access-database die exploded. We bouwen die opnieuw of replatformen ’m, met behoud van de business-logica die er in jaren in zit. Voor één app, met duidelijke afhankelijkheden in kaart.
U heeft een verzameling oudere systemen — vaak ontstaan na een acquisitie of jarenlange organische groei. We inventariseren, classificeren elk systeem volgens de Gartner 6R’s (retire, retain, rehost, replatform, refactor, repurchase, rebuild, replace) en bouwen een roadmap met prio en sequencing. Daarna voeren we de eerste tranches zelf uit.
Voor organisaties met multi-systeem-legacy waar compliance op meekijkt: financieel met DORA, kritieke infra met NIS2, zorg met NEN 7510. We treden op als orchestrator over meerdere leveranciers, voeren zelf de complexe migraties uit, en zorgen dat audit-trail en evidence van dag één meegroeit met het programma.
Niet alleen nieuwe software. Ook de inzichten en het beheer-fundament om de modernisering daarna zelf voort te zetten.
Een aantal patronen die we vaak tegenkomen. Herkent u er één, dan is dit waarschijnlijk een gesprek waard.
Een mid-90s of vroeg-2000s systeem waar de bouwer al lang niet meer rondloopt. Er is geen documentatie, de code is verweven met conventies die niemand meer kent, en elke wijziging voelt als russisch roulette.
Bij ICT-vendors of na een serie acquisities: vijf, zes of zeven verschillende tech-stacks naast elkaar, elk met een paar ontwikkelaars die ’m kennen. Beheerlast wordt onhoudbaar, integraties zijn fragiel.
DORA, NIS2, AI Act of NEN 7510 stelt eisen aan logging, beveiliging of dataminimalisatie die uw legacy-stack niet of nauwelijks kan leveren. Patchen lukt niet meer; moderniseren is de enige route.
De fysieke server waar uw AS/400 of Oracle Forms-applicatie op draait nadert end-of-life. Vervangen kost veel, maar er is geen on-prem opvolger meer. Migratie naar cloud is de logische stap.
U heeft een bedrijf gekocht en daarmee een hele applicatie-portfolio in een totaal andere stack. Twee silo’s naast elkaar is duur — consolidatie vraagt om een moderniserings-plan.
Een monoliet die op één server draait en niet horizontaal kan groeien, een database die het transactievolume niet meer aankan, of een desktop-app die niet geschikt is voor remote work. Schaal vraagt om een nieuwe architectuur.
Geen twee legacy-stacks zijn gelijk. Een mainframe-modernisering vraagt iets totaal anders dan een Delphi-replatform. Onderstaande categorieën dekken het overgrote deel van wat wij in de markt zien.
Met name banken en verzekeraars hebben nog kernsystemen op mainframe. Modernisering combineert vaak een gefaseerde uitname (rebuild of replace) met tijdelijke façades zodat moderne kanalen al kunnen worden ontwikkeld vóór het mainframe leeg is.
Vaak ERP-achtige systemen die jaren stabiel hebben gedraaid. Replatform naar Linux of containers met behoud van de data-modellen, of een geleidelijke herbouw met de RPG-applicatie als source-of-truth tijdens overgang.
Bouwbedrijven, productiebedrijven, ICT-vendors: veel sector-specifieke tools. Wij replatformen naar web of moderne desktop (.NET-modern, Electron of native web-apps) met behoud van workflows die gebruikers gewend zijn.
Verrassend veel B2B-portalen draaien hier nog op. Moderniseren naar Node.js, .NET, PHP 8 of een moderne front-end stack. Vaak met API-laag tussen oud en nieuw, zodat migratie incrementeel kan.
Veelal kleinere applicaties die ‘sluipenderwijs’ kritiek zijn geworden voor de organisatie. Migratie naar een moderne backend met API-laag, vaak gecombineerd met een nieuwe web-frontend.
Niet ‘oud’ in jaren maar wel verouderd in architectuur: niet horizontaal schaalbaar, geen CI/CD, geen observability. Replatform naar containers, infra-as-code en moderne deploy-pipelines.
De 6R-strategie van Gartner is dé industrie-standaard voor modernisering-keuzes. Wij gebruiken een uitgebreide variant met acht opties — omdat de werkelijkheid soms gewoon meer nuance vraagt.
Niet elk legacy-systeem hoeft een opvolger te krijgen. In een typisch portfolio kan een aanzienlijk deel simpelweg uit. Dat is niet falen — dat is opruimen. Datgeen wat er nog uit moet, archiveren we conform retentie-eisen.
Het systeem is oud maar werkt prima en heeft weinig change. Geen actie. Wel monitoring op risico (eind-van-leven van de stack, single-point-of-failure-personen) en een herzieningsmoment in de roadmap.
De applicatie van een fysieke server of VM naar een cloud-VM verhuizen, zonder code-aanpassing. Snel en goedkoop, maar de oude architectuur blijft. Goed als tussenstap om hardware-risico weg te halen.
Code blijft grotendeels intact maar gaat naar een container, PaaS-database of managed service. Meer operationele winst dan rehost, beperkte code-impact. Vaak het sweet spot voor desktop- en web-legacy.
Code intern moderniseren — modulariseren, testbaar maken, dependencies vervangen — zonder dat het gedrag wijzigt. Belangrijk vóór een rebuild als er nog veel ongedocumenteerde logica in zit.
Soms is het oude systeem iets wat de markt allang als standaard-SaaS levert (CRM, helpdesk, expense-management). Vervangen door een commercieel product is dan rationeler dan zelf bouwen. Wij begeleiden de selectie en data-migratie.
De applicatie van nul opnieuw bouwen, met dezelfde business-functionaliteit maar moderne stack en architectuur. Voor systemen die strategisch zijn, business-kritisch, en waar refactor niet meer rendabel is.
Niet alleen de techniek vervangen maar ook de scope herzien. Soms blijkt na inventarisatie dat het oude systeem doet wat in 2005 nodig was, maar dat het werkproces ondertussen veranderd is. Dan bouwen we niet de oude maar de nieuwe versie.
Er zijn goede automated-translation tools voor legacy: Modulus, Asysco AMT (COBOL naar .NET), Heirloom voor mainframe. Wij gebruiken ze waar ze passen. Maar in een aantal scenario’s schiet pure automation tekort en is maatwerk de juiste route.
Automated translation transformeert syntax: COBOL-code naar C#-code. Maar de echte waarde van een legacy-systeem zit vaak in onuitgesproken business-regels die over jaren in de code zijn geslopen. Die overleeft een one-shot vertaling zelden.
Bij applicaties waar uw concurrentievoordeel in zit, wilt u meer dan een 1-op-1 conversie. U wilt dat de modernisering tegelijk een upgrade is van wat de applicatie kan — en dat vraagt ontwerp, geen vertaling.
In portfolio-trajecten lopen meerdere migraties parallel — elk met eigen tooling, eigen leverancier, eigen risico. Iemand moet die orkestreren. Dat is een rol die geen tool kan invullen.
Zorg met NEN 7510, financieel met DORA, kritieke infra met NIS2. Audit-trail kun je niet achteraf bij-vertalen — die moet vanaf het eerste sprint in de migratie ingebakken zitten.
Een automated translation levert iets op. Maar als de oorspronkelijke ontwikkelaar weg is en de huidige beheerder geen idee heeft hoe het oude systeem werkte, kan niemand objectief beoordelen of het resultaat klopt. Wij regelen die reverse-engineering.
Vertaler X kan applicatie A migreren, maar applicatie A praat met B, C en D. Die integraties moeten meebewegen. Maatwerk en orchestratie zijn dan goedkoper dan zes losse migratie-projecten naast elkaar.
We brengen elke applicatie in kaart: tech-stack, hosting, gebruikers, integraties, licenties, beheerkosten. Tegelijk inventariseren we welke business-processen erop draaien en wie de eigenaren zijn. Soms blijkt al hier dat 10 tot 20 procent van het portfolio simpelweg retired kan worden.
Per applicatie zetten we Total Cost of Ownership af tegen business-impact. Hoog-impact + hoog-cost-systemen krijgen prioriteit; laag-impact + laag-cost mag blijven staan. Uitkomst is een visuele matrix waarop de leiding kan sturen.
Voor elke applicatie kiezen we de juiste strategie uit de uitgebreide 6R-set (retire, retain, rehost, replatform, refactor, repurchase, rebuild, replace). Daarna sequencen we: welke afhankelijkheden dwingen volgorde, waar zit risk-reduction-eerst-winst, en hoe verspreiden we de last over uw IT-organisatie.
Voor systemen die we gaan refactoren of herbouwen, bouwen we eerst een test-vangnet om de huidige werking. Geautomatiseerde end-to-end tests en, waar nodig, screen-recordings van bestaande gebruikers-flows. Doel: voorkomen dat ongeschreven business-rules in de migratie verdwijnen.
Geen big-bang. We zetten een façade vóór het oude systeem en migreren stukje voor stukje functionaliteit naar de nieuwe stack. Gebruikers merken er weinig van; de organisatie blijft door-werken. Pas als de laatste functionaliteit gemigreerd is, schakelen we het oude systeem uit.
Waar relevant gaat de nieuwe applicatie naar cloud (AWS, Azure, GCP) of een container-platform (Kubernetes, OpenShift). Alle infra in Terraform of Pulumi, deploys via CI/CD, monitoring in OpenTelemetry. On-prem blijven kan ook — soms is dat de juiste keuze.
De laatste fase. We trainen uw beheer-team, schrijven runbooks voor incidenten en planned changes, en regelen kennisoverdracht over de business-logica die we onderweg hebben blootgelegd. Daarna kunt u kiezen: u beheert zelf, of wij doen het tegen een vaste maandprijs.
Wat klanten meestal willen weten voor we starten met een modernisering-traject.
Een kennismaking van een half uur, vrijblijvend. Vertel ons welke systemen u doodlopen, welke wetgeving op u afkomt en welk deel van uw team nog grip op de oude stack heeft. Wij komen met een eerste richting — en zijn eerlijk als het niet bij ons past. Wilt u eerst breder kijken? Zie ook onze pagina over platform-modernisering-consultancy of over enterprise software laten ontwikkelen.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
