Legacy software vervangen als MKB

Werkt jouw systeem nog, maar net niet meer goed genoeg? Dat is het lastigste moment om over te beslissen. Het valt niet om, dus er is geen paniek. Maar elke nieuwe klant, elke nieuwe medewerker en elke koppeling kost net iets meer moeite dan zou moeten. Legacy software vervangen als MKB is precies daarom zo'n taai vraagstuk: je moet iets aanpakken dat het nog dóét, zonder dat de tent ondertussen stilvalt.

In deze post lopen we langs de signalen dat je systeem je in de weg zit, de drie manieren om het te vervangen, hoe je de volgorde bepaalt en wat het realistisch kost. Geen grote beloftes, wel een eerlijk beeld.

Hoe weet je dat je legacy systeem je groei blokkeert?

Verouderde software gaat zelden in één klap stuk. Het knaagt. De vraag is niet of het perfect is, want dat is geen enkel systeem, maar of het je tegenhoudt. Een paar concrete signalen.

Alles wordt traag, ook de mensen

Rapportages die minuten duren. Een scherm dat hapert als er drie mensen tegelijk in werken. Handelingen die je team met een omweg oplost omdat "dat nou eenmaal zo werkt". Die omwegen zijn verborgen kosten. Ze staan nergens op een factuur, maar ze vreten uren.

Het koppelingsinferno

Elk nieuw pakket dat je erbij wilt, boekhouding, een webshop, een planningstool, vraagt weer een aparte koppeling. En elke koppeling is broos. Er gaat iets stuk in het ene systeem en je merkt het pas als de facturen in het andere niet meer kloppen. Als je bang bent om iets aan te sluiten omdat je niet weet wat er dan omvalt, zit je in dat inferno.

Er is één iemand die het echt begrijpt

Misschien wel het gevaarlijkste signaal: sleutelpersoonafhankelijkheid. Eén ontwikkelaar, één leverancier of één collega die als enige weet hoe het in elkaar zit. Zolang die persoon er is, gaat het goed. Maar je bedrijf mag niet afhangen van of iemand met vakantie is of ergens anders gaat werken. Kennis die maar in één hoofd zit, is geen bezit. Het is een risico.

Herken je twee of drie van deze punten, dan gaat het gesprek niet meer over óf je iets doet, maar wanneer en hoe.

De drie vervangingsstrategieën: big bang, gefaseerde migratie en de strangler-fig aanpak

Er zijn grofweg drie manieren om verouderde software te moderniseren. Ze verschillen enorm in risico. Voor de meeste MKB-bedrijven valt er eentje snel af.

Big bang: alles in één keer om

Je bouwt het nieuwe systeem naast het oude, en op een gekozen zondag zet je alles over. Klinkt daadkrachtig. Het probleem: je ontdekt pas op livegang of het écht werkt, en tegen die tijd staat je hele bedrijf op het nieuwe systeem. Gaat er iets mis, dan gaat er veel tegelijk mis. Voor een klein, overzichtelijk systeem kan het prima. Voor het draaiende hart van een MKB-bedrijf is het meestal te veel risico op één moment.

Gefaseerde migratie: in stukken overzetten

Je knipt het systeem op in brokken en verhuist ze één voor één. Eerst de klantgegevens, dan de facturatie, dan de planning. Na elke stap draait het bedrijf weer stabiel voordat je verder gaat. Langzamer, ja. Maar je fouten blijven klein en je kunt terug. Voor de meeste MKB-migraties is dit de verstandige basis.

De strangler-fig aanpak: het nieuwe groeit om het oude heen

De naam komt van de wurgvijg, een plant die om een boom heen groeit tot die de boom volledig vervangt. Zo pak je het hier ook aan. Je bouwt nieuwe functionaliteit náást het oude systeem en leidt er stukje bij beetje het verkeer naartoe. Het oude systeem blijft draaien tot het laatste onderdeel is overgenomen, en dan zet je het uit. Je hebt nooit een moment waarop alles tegelijk kwetsbaar is. Dit vraagt wat meer denkwerk vooraf, maar het is de veiligste route als je systeem echt bedrijfskritisch is.

Welke past bij jou hangt af van hoe kritisch het systeem is en hoeveel je bedrijf een storing kan hebben. Als je twijfelt tussen maatwerk en een standaardpakket, is dat trouwens een aparte afweging die je het beste vooraf maakt. Daar hebben we los over geschreven in maatwerk of standaardpakket.

Wat bepaalt de volgorde? Waardestroom in kaart brengen voor je ook maar een regel code schrijft

Hier zit de fout die het meest voorkomt: mensen beginnen bij het onderdeel dat technisch het makkelijkst is, of bij wat de leverancier toevallig als eerste aanbiedt. Verkeerde vraag. De vraag is: waar zit de meeste waarde en het meeste risico?

Breng eerst je waardestroom in kaart. Volg letterlijk hoe een order, een klant of een aanvraag door je bedrijf loopt, van het eerste contact tot de betaling. Bij welke stap loopt het vast? Waar zitten de handmatige lapmiddelen? Waar liggen je grootste kosten en je grootste kansen? Dat is denkwerk dat je op papier doet, niet in code.

Een paar vuistregels voor de volgorde:

• Begin bij het onderdeel met de meeste pijn en het minste risico. Een snelle winst die het team direct voelt, geeft vertrouwen voor de rest.
• Ontwar de koppelingen vroeg. Zolang alles kriskras aan elkaar hangt, kun je niks los vervangen. Zorg dat onderdelen zelfstandig kunnen draaien.
• Laat het bedrijfskritische deel niet als laatste liggen. Dan bouw je maandenlang aan de rand terwijl de kern blijft knellen.

Wil je een deel echt vernieuwen in plaats van één op één overzetten, behandel dat stuk dan als een MVP die je laat bouwen: klein beginnen, in het echt testen met je mensen, en pas uitbreiden als het werkt. Zo verklein je de kans dat je iets bouwt wat niemand blijkt te gebruiken.

Deze fase voelt soms als "we doen nog niks". Dat is een misverstand. Een goede volgorde bepalen ís het werk. Het bepaalt of de migratie soepel verloopt of een halfjaar uitloopt.

Kosten en tijdlijn: realistische verwachtingen voor een MKB-migratie

De eerlijke waarheid over de kosten van een legacy systeem vervangen: dat hangt te veel van je situatie af om er een bedrag op te plakken zonder je systeem te kennen. Wie je wel een vast getal geeft zonder gekeken te hebben, gokt. Wat de prijs vooral bepaalt:

• De staat van je huidige data. Schone, goed gestructureerde gegevens overzetten is werk. Rommelige data eerst opschonen is vaak méér werk dan de migratie zelf.
• Het aantal koppelingen. Elke verbinding met een ander systeem is iets dat opnieuw gebouwd en getest moet worden.
• Hoeveel je wilt vernieuwen versus overzetten. Precies namaken wat er is, is goedkoper dan verbeteren. Maar precies namaken lost je oorspronkelijke probleem soms niet op.

Over tijdlijn: een gefaseerde of strangler-fig aanpak duurt in doorlooptijd langer dan een big bang, en dat is bewust. Je ruilt snelheid in voor de zekerheid dat het bedrijf blijft draaien. Reken niet op weken maar op maanden, in stappen, met tussendoor telkens een werkend bedrijf. Een verstandige start is klein: één afgebakend deel migreren, ervan leren, en dat leren gebruiken om de rest scherper te begroten.

Wil je een vollediger beeld van hoe we naar prijzen kijken, lees dan wat een website of app laten maken kost.

Zin om er eens naar te kijken?

Als je systeem "net niet meer goed genoeg" is en je wilt weten welke aanpak bij jouw situatie past, denken we graag een keer vrijblijvend mee. Geen verkoopverhaal, gewoon samen kijken naar je waardestroom en een eerlijke volgorde. Neem gerust contact op, dan plannen we een gesprek.