Dienst · Software-ontwikkeling

Legacy software vervangen.

Oude bedrijfssoftware die nog draait maar niemand meer durft aan te raken. Een FoxPro-database uit 1998, een Delphi-applicatie waarvan de bouwer al jaren weg is, een Lotus Notes-systeem dat alleen op één laptop blijft werken. Wij vervangen of moderniseren legacy software zonder dat uw operatie stilvalt — gefaseerd, met behoud van data en met een traject dat aansluit bij de complexiteit van uw bestaande landschap.

Plan een kennismaking Bekijk ons werk

↻

Legacy is geen technisch probleem — het is een bedrijfsrisico.

De meeste organisaties die wij spreken hebben het uitstellen niet uit luiheid gedaan. Ze hebben het uitgesteld omdat het oude systeem nog draait, omdat de oorspronkelijke leverancier er niet meer is, omdat niemand precies meer weet wat het systeem allemaal doet, en omdat de gedachte aan een vervanging spanning oplevert die niemand er bovenop wil hebben. Tot het moment dat het ene aanblijven van die laatste server, of het ene wegvallen van die ene developer die de code nog snapt, de bedrijfsvoering acuut bedreigt.

Wij zijn gewend om met die situatie binnen te komen. Een verouderd Access-bestand dat de financiële administratie aanstuurt. Een ASP.NET WebForms-applicatie die nog op Windows Server 2008 draait. Een Exact Globe-installatie die richting Exact Online migratie moet. Onze aanpak begint met begrijpen wat er staat, vóór we bepalen hoe het vervangen wordt — en welke onderdelen overigens prima nog een paar jaar kunnen blijven.

De meest gemaakte fout bij legacy-vervanging is het idee dat je het oude systeem in één keer kunt vervangen door een nieuw systeem. Bij elk niet-triviaal traject loop je tegen ongedocumenteerde flows, vergeten integraties en stilzwijgende business-regels aan. Daarom kiezen we vrijwel altijd voor een patroon waarin het oude en nieuwe systeem een tijd naast elkaar leven en het oude geleidelijk wordt uitgefaseerd. Dat klinkt onhandiger dan een big-bang, maar het is in praktijk vrijwel altijd sneller én veiliger.

Hoe wij legacy-trajecten aanpakken.

Strangler-eerst

Oud en nieuw draaien parallel, oud wordt geleidelijk uitgezet

Discovery-fase

We documenteren wat er staat voordat we vervangen

Data-eigenaarschap

Volledige migratie met audit-trail en rollback-pad

Build of buy

Per module beoordeeld — maatwerk waar het echt onderscheidt

Vijf manieren om legacy software te vervangen.

Elke situatie vraagt een andere aanpak. Welke route past wordt bepaald door de scope, de leeftijd van de stack, de beschikbaarheid van documentatie en het aantal externe systemen dat ermee praat. Onderstaande drie clusters dekken samen het overgrote deel van de trajecten waar wij bij betrokken raken.

Aanpak 01

Strangler pattern — geleidelijk uitfaseren

De meest gebruikte route bij grotere systemen

Het nieuwe systeem groeit module voor module naast het oude. We zetten een routeringslaag voor de oude applicatie waarin we elk afzonderlijk deel — eerst de eenvoudige modules, daarna de complexe — kunnen omleiden naar de nieuwe codebase zodra die klaar is. Het oude systeem blijft draaien zolang er nog onvervangen onderdelen in zitten en wordt uitgezet zodra de laatste flow is overgenomen. Deze aanpak — beschreven door Martin Fowler als strangler fig pattern — werkt vooral goed bij omvangrijke applicaties waar een rewrite in één keer onhaalbaar of te risicovol is.

In praktijk betekent dit dat uw eindgebruikers maandenlang met twee schermen werken (of, beter, met één scherm dat onder de motorkap geleidelijk omschakelt) terwijl het oude systeem stapje voor stapje wordt leeggehaald. Dat geeft uw organisatie tijd om de nieuwe werkwijze te leren, terwijl er nooit een moment is waarop alles tegelijk omgaat. Geen big-bang, geen weekend waarin de operatie stilligt, geen all-or-nothing-risico.

Routerings-laagModule-voor-moduleParallel-draaienAnti-corruption layerFeature flagsGefaseerde uitrol

Aanpak 02

Rewrite of build new met data-migratie

Voor compacte systemen met heldere scope

Een volledige herbouw is alleen aan te raden voor relatief afgebakende systemen waar de scope goed gedocumenteerd is en het aantal externe integraties beperkt blijft. Wij bouwen de nieuwe applicatie op een moderne stack, kopiëren de data over via een gevalideerde migratie en plannen één cut-over-moment waarop het oude systeem wordt uitgezet. Vooraf draaien beide systemen meestal parallel zodat we vergelijkende tests kunnen doen op echte data.

De grootste valkuil bij deze route is feature-creep: tijdens de herbouw komen er continu nieuwe wensen bij omdat "we toch opnieuw beginnen". Wij houden daar strak grip op door eerst een nul-versie te bouwen die functioneel gelijk is aan het oude systeem, en pas daarna verbeteringen toe te voegen in een opvolgend traject. Dat scheelt scope-discussies en houdt de cut-over haalbaar. Voor situaties die op deze route lijken bestaat ook onze service enterprise software laten ontwikkelen voor de zwaardere stack-keuzes.

Volledige herbouwData-migratieCut-over-planFeature-parity-eerstValidatie-suiteRollback-scenario

Aanpak 03

Lift-and-shift, koppel-laag of buy-met-maatwerk

Wanneer het oude systeem deels nog mag blijven

Niet elk legacy-systeem hoeft direct vervangen. Soms is een lift-and-shift voldoende: de oude applicatie blijft draaien maar wordt op moderne infrastructuur gezet, omhuld met een nieuwe API-laag zodat andere systemen er via een schone interface mee kunnen praten. Andere keren kiezen we voor een SaaS-pakket voor het standaard-deel — bijvoorbeeld een nieuw boekhoudpakket of CRM — en bouwen we alleen het uniek-stukje van uw organisatie als maatwerk bovenop. Onze digitale-transformatie-consultancy begint vaak met die afweging.

De build-vs-buy-keuze maken we per module, niet per heel systeem. Voor uw boekhouding is er meestal geen reden om maatwerk te bouwen — daar is een prima SaaS voor. Voor het stuk dat uw werkwijze onderscheidt — het stuk dat in het oude systeem ooit als maatwerk is gemaakt en waarom u nooit overgegaan bent op een standaardpakket — bouwen we wél maatwerk. Het resultaat is een hybride landschap waarin het standaard-deel onderhoudsarm is en het maatwerk-deel echt op uw flow past.

Lift-and-shiftAPI-laag erbijBuild-vs-buyHybride landschapSaaS-integratieMaatwerk-add-on

Wat u aan het einde heeft.

Een modern systeem in productie, een leeggehaalde oude server en een organisatie die niet meer afhankelijk is van één persoon die de oude code begrijpt.

Productie + staging

Twee omgevingen, in uw eigen cloud of bij ons gehost — uw keuze.

Codebase + architectuur-docs

Volledige source code, build-instructies en overzicht van alle gemaakte keuzes.

Migratie-rapport

Welke data is overgegaan, welke validaties zijn uitgevoerd, waar zaten afwijkingen.

Decommissioning-plan

Hoe en wanneer het oude systeem wordt uitgezet — en welke read-only-archief overblijft.

Beheer (optie)

Monitoring, backups, security-patches en doorontwikkeling onder een onderhoudscontract.

Wanneer een legacy-traject onvermijdelijk wordt.

Vier patronen waarin uitstellen niet langer een optie is — en waarin wij meestal eerst worden uitgenodigd voor een audit-gesprek vóór er iets concreets gepland wordt.

Stack

Onderliggende technologie wordt niet meer ondersteund

Een FoxPro-database, Delphi 7, Visual Basic 6, een verouderde versie van Lotus Notes of een Cobol-mainframe waar geen patches meer voor komen. Microsoft heeft de support van het besturingssysteem of de runtime al jaren beëindigd. Het systeem werkt nog wel, maar elk security-incident is een acute crisis omdat er geen leverancier meer is die kan helpen.

Kennis

De oorspronkelijke developer is weg

De applicatie is ooit gebouwd door één interne developer of door een klein bureau dat inmiddels is opgeheven. Niemand in uw organisatie kent de codebase nog goed. Aanpassingen kosten dagen onderzoek voor er één regel verandert. Een tweede ontwikkelaar inwerken op de oude stack is moeilijker en duurder dan opnieuw bouwen op een moderne stack.

Vendor

De leverancier ondersteunt het product niet meer

Een softwarepakket waarvan de leverancier richting end-of-life beweegt — bijvoorbeeld een ERP-vendor die zijn klassieke on-premise-product uitfaseert ten gunste van een cloud-product. Of een nichetool waarvan de fabrikant is overgenomen en het product is afgeschaald. U wordt onder druk gezet om mee te migreren en wilt zelf de regie nemen over wat er gebeurt.

Integratie

Hidden integraties knellen het systeem in

Tien andere systemen praten met het oude systeem via een bonte verzameling van bestandsexports, gedeelde databases, scripts en handmatige imports. Niemand heeft het volledige overzicht. Een wijziging in het oude systeem breekt zomaar drie andere processen. Op dit punt wordt het oude systeem feitelijk een single-point-of-failure voor uw hele landschap.

Risico's die we expliciet adresseren.

Een legacy-vervanging is geen technisch project — het is een verandering die uw operatie raakt. Vier risico-categorieën die we in elk traject bovenaan zetten.

Data

Data-verlies bij migratie

Oude databases zitten vaak vol met ongeoorloofde tekens, dubbele records en ontbrekende referenties die in productie nooit zijn opgevallen omdat het oude systeem ze tolereerde. Wij doen een data-audit vooraf, bouwen een validatie-suite die elke migratie-run vergelijkt tegen het origineel en houden een rollback-pad open tot na de cut-over.

Functionaliteit

Functionaliteits-erosie en vergeten flows

Het oude systeem deed nog drie dingen waar niemand zich meer bewust van was — een nachtelijke export, een specifiek rapport voor de directie, een eenmalige correctie-knop. We doen stakeholder-interviews met elke gebruikersgroep, draaien shadow-tests waarin oud en nieuw parallel dezelfde inputs verwerken, en houden een lijst van "kleine knoppen" die anders bij cut-over verdwijnen.

Continuiteit

Business-disruptie tijdens cut-over

Een cut-over die fout gaat kost dagen aan productiviteit en weken aan vertrouwen bij uw team. We faseren elke transitie zodat één deelproces tegelijk overgaat, plannen cut-overs in rustige periodes voor uw operatie, en hebben een rollback-script paraat. Pas wanneer een deelproces meerdere dagen stabiel draait, zetten we de volgende stap.

Adoptie

Weerstand van gebruikers en sleutelfiguren

Mensen die jarenlang met de oude software gewerkt hebben ervaren een nieuw systeem aanvankelijk als achteruitgang — ook als het objectief beter is. We betrekken sleutelgebruikers vanaf sprint één, bouwen workflows die de oude shortcuts respecteren en organiseren training zodat de overgang niet als verlies voelt. Geen change-management-theater, wel praktisch begeleiden.

Hoe een legacy-traject loopt.

01Kennismaking→ 02Discovery→ 03Bouw & migratie→ 04Cut-over & beheer

Stap 01

Kennismaking

Welk systeem staat er, hoe oud is het, wie kent het nog, welke pijn is acuut. Vrijblijvend gesprek met IT en operations.

Stap 02

Discovery & architectuur

We documenteren het oude systeem, interviewen sleutelgebruikers, doen een data-audit en kiezen per module tussen rewrite, lift-and-shift, build of buy.

Stap 03

Bouw & data-migratie

Werkende modules in sprints, parallel-draaien naast het oude systeem, validatie-suite voor data-migratie en regelmatige shadow-tests.

Stap 04

Cut-over & decommissioning

Gefaseerde overgang per deelproces, rollback-pad paraat, oude systeem leegmaken en uiteindelijk uitzetten — read-only-archief blijft beschikbaar.

Stacks waar we vandaan komen en naartoe bouwen.

Wij komen veel oude stacks tegen — soms is de oude stack zelf nog houdbaar en koppelen we er een moderne laag overheen, soms is volledige vervanging de enige route. Naast deze pagina kan ook onze service maatwerk software en het bredere overzicht onder software-ontwikkeling relevant zijn als startpunt.

Legacy stacks die we tegenkomen

FoxProDelphiVB6Lotus NotesAccessCobolPowerBuilderASP.NET WebFormsAS/400 RPGExact Globe

Doelstack — frontend & backend

Next.jsAstroReactVueNode.jsPython.NET 8PostgreSQLRedis

Migratie, infra & integratie

Strangler-routeringETL-pipelinesAuth0Azure ADGCP/AWSTerraformDockerAnti-corruption layer

Veelgestelde vragen.

Hoe groot is het risico dat de operatie tijdens de vervanging stilvalt?

Beheersbaar — mits u kiest voor een gefaseerde aanpak in plaats van een big-bang. In vrijwel elk traject dat wij doen, draait het oude systeem maandenlang naast het nieuwe en wordt het pas uitgezet wanneer alle deelprocessen aantoonbaar stabiel zijn overgenomen. Het belangrijkste risico is niet de technische kant, maar het mislopen van een ongedocumenteerde flow — daarom doen we vooraf stakeholder-interviews per gebruikersgroep en draaien we shadow-tests waarin oude en nieuwe systemen dezelfde input verwerken, zodat afwijkingen al vóór cut-over zichtbaar worden.

Hoe lang duurt zo'n traject?

Dat hangt sterk af van de scope, de leeftijd van de stack, de hoeveelheid externe integraties en de mate waarin er nog documentatie en kennis aanwezig is. Een compact systeem met goed gedocumenteerde flows en weinig integraties kan binnen een traject van enkele sprints vervangen worden. Een groot integraal landschap met meerdere modules en tientallen integraties vraagt een traject van meerdere sprints, vaak gefaseerd over een langere periode waarin steeds een deelproces in productie gaat. We geven na de discovery-fase een eerlijke inschatting — vóór die discovery is elk getal een gok die u in de problemen kan brengen.

Kunnen we parallel met het oude systeem blijven werken?

Ja, en dat is in vrijwel elk legacy-traject ook de gekozen route. We zetten een strangler-laag voor het oude systeem zodat verkeer per module kan worden omgeleid naar de nieuwe applicatie zodra die klaar is. Uw eindgebruikers werken een tijd met beide systemen tegelijk, of — als we het slimmer kunnen oplossen — met één scherm dat onder de motorkap geleidelijk omschakelt. Daarmee is er nooit een moment waarop alles tegelijk overgaat, en dus nooit een risico dat de hele operatie afhankelijk wordt van één succesvolle cut-over.

Hoe betrouwbaar is de data-migratie?

We beginnen met een data-audit op het oude systeem: hoeveel records zitten erin, welke velden zijn onvolledig, welke referenties klopt niet meer, welke data is mission-critical. Op basis daarvan bouwen we een migratie-pipeline met een validatie-suite die elke run vergelijkt tegen het origineel — aantallen, sommen, sleutelvelden, referentiële integriteit. Tot na de cut-over houden we het oude systeem read-only beschikbaar zodat rollback altijd een optie blijft. Voor financiële data en data onderhevig aan wettelijke bewaarplicht houden we sowieso een archief-kopie van het oude systeem aan.

Wat als de oorspronkelijke developer al weg is en niemand de code nog snapt?

Dit is een van de meest voorkomende startsituaties bij onze legacy-trajecten en geen blokkade. We reverse-engineeren het bestaande systeem in een discovery-fase: code-analyse, interviews met eindgebruikers over de feitelijke workflows, schermopnames van dagelijks gebruik en analyse van de database om de onderliggende business-regels te reconstrueren. We accepteren dat we nooit 100% van de oude logica zullen terugvinden — daarom zetten we ook shadow-tests op waarin oud en nieuw parallel draaien en eventuele afwijkingen zichtbaar worden vóór de cut-over.

Wat bepaalt de kosten van een legacy-vervanging?

De scope van wat vervangen wordt, de hoeveelheid integraties met andere systemen, de mate van documentatie van het bestaande systeem, het aantal gebruikersgroepen en de complexiteit van de data-migratie. Een lift-and-shift met een API-laag erover is een ander traject dan een volledige herbouw van een mission-critical ERP. We geven nooit een prijs vóór de discovery-fase — zonder zicht op wat er staat is elk getal een gok. Na de discovery krijgt u een eerlijke inschatting met een gefaseerde scope, zodat u zelf kunt sturen op welk deel eerst aangepakt wordt.

Vervangen jullie alles in één keer of in modules?

Bijna altijd in modules. Een volledige rewrite-in-één-keer is alleen verdedigbaar voor compacte, goed afgebakende systemen — in vrijwel alle andere gevallen kiezen we voor het strangler-pattern: nieuw groeit naast oud, en oud wordt geleidelijk uitgefaseerd. Dat betekent dat u na enkele sprints al een eerste deelproces in productie heeft, in plaats van pas op het einde van een lang traject iets te zien. Het verlaagt het risico, geeft uw team tijd om te wennen en houdt het traject stuurbaar.

Werken jullie samen met onze interne IT-afdeling?

Vrijwel altijd. Bij legacy-trajecten raken we vrijwel zeker bestaande systemen aan: ERP, boekhouding, AD/SSO, fileshares, soms een legacy-WMS of CRM. We werken transparant samen met uw interne IT en — waar nodig — met externe vendoren die de aangrenzende systemen onderhouden. Heldere API-contracten, gedocumenteerde koppelingen en een runbook voor incidenten zijn standaard. Aan het einde van het traject draagt onze code over naar uw team of nemen wij beheer onder contract, afhankelijk van wat u wilt.

Behouden we eigenaarschap van de nieuwe software?

Ja, volledig. De code, infrastructuur, documentatie en credentials komen op uw naam te staan. We werken in een repository die door u beheerd wordt of die we aan het einde van het traject overdragen. Ook als u kiest voor onze beheer-laag na oplevering, blijft alle code en infra van u — beheer is een dienst, geen vendor-lock-in. Dat geldt ook voor de data: u bent te allen tijde eigenaar van alle records, met een gedocumenteerd export-formaat voor toekomstige migraties.

Praat met ons over uw legacy-systeem.

Een kennismaking van een half uur, vrijblijvend. We luisteren naar wat er nu draait, waar het knelt en wat de aanleiding is om er nu wél naar te kijken — ook als blijkt dat een vervanging op dit moment niet de juiste route is.

Plan een kennismaking Mail fabian.vandijk@appfront.nl