Is jullie software nog up to date?
Op deze pagina beschrijven we verschillende situaties waar organisaties zich in kunnen bevinden met betrekking tot verouderde bedrijfssoftware.
Vaak ziet de directie in dit geval beren op de weg.
Wij laten zien dat oude software overnemen en up to date brengen geen risico hoeft te zijn en helpen jullie hier graag mee.
Liever direct actie ondernemen, scroll dan maar meteen naar onze aanpak.
Is jullie software nog een fundament voor groei, of inmiddels een risico?
Wij nemen bestaande softwarepakketten over, ook wanneer ze vastzitten aan legacy systemen of verouderde technologie.
Legacy software en verouderde systemen zijn IT-oplossingen die nog functioneren, maar technisch achterhaald zijn en niet meer aansluiten op moderne eisen. Het gaat vaak om oude maatwerkapplicaties of systemen die gebouwd zijn met verouderde technologieën. Denk aan applicaties op oude PHP, Java of Laravel versies en servers die bij jouw op locatie draaien zonder actieve ondersteuning.
Hoewel deze systemen vaak “nog werken”, vormen ze een risico voor veiligheid, continuïteit en verdere digitale groei.
Wanneer software cruciaal is, maar kwetsbaar voelt
Voor veel organisaties is software het kloppend hart van de operatie. Tegelijkertijd voelt het vaak fragiel.
Veel bedrijven gebruiken nog steeds uitgebreide Excel-sheets om data te verzamelen, planningen te maken en resultaten te monitoren, vaak in combinatie met tools zoals Power BI.
Deze werkwijze vormt een risico, omdat de kennis over de opzet, formules en samenhang van deze bestanden vaak bij één persoon ligt. Wanneer die persoon uitvalt of vertrekt, kan dit leiden tot verlies van inzicht, fouten in rapportages en vertraging in besluitvorming.
Een systeem dat traag wordt bij piekbelasting.
De software werkt, maar is regelmatig traag, wat zorgt voor continue frustratie. Bij drukte stapelen wachttijden zich op en wordt werk onnodig vertraagd.
Voorbeeld situatie: Werkvloer
Medewerkers met scanners in het magazijn of operators aan de machinelijn moeten telkens wachten tot schermen laden voordat ze verder kunnen, waardoor werk wordt onderbroken en fouten toenemen.
Software die lastig is in gebruik waardoor medewerkers hun eigen werkwijzen bedenken.
Neem bijvoorbeeld een Shop Floor Control-systeem waarin operators storingen melden wanneer een productielijn stilstaat. Door onduidelijke instructies en een lastig te gebruiken systeem bepalen operators zelf wanneer zij een storing registreren. De ene operator meldt een storing al na 1 minuut stilstand, terwijl een andere dit pas doet na 2 minuten of langer.
Dit leidt tot inconsistente storingsdata, waardoor analyses onbetrouwbaar zijn en het moeilijk wordt om oorzaken van stilstand goed te vergelijken of gericht te verbeteren.
Daarnaast kun je ook denken aan het huidige klantportaal gekoppeld aan de administratie of ERP systeem.
Het huidige systeem laat medewerkers zelf bepalen hoe zij klanten, orders, reparatie aanvragen en het aanvragen van verbruiksartikelen vastleggen. Door het gebrek aan vaste structuur en begeleiding ontstaan verschillende werkwijzen en benamingen.
Hierdoor raakt informatie versnipperd, is deze lastig terug te vinden en ontstaan onduidelijke situaties
Beslissingen blijven liggen omdat niemand het geheel overziet
Iedereen voelt dat er iets moet gebeuren, maar niemand durft het besluit te nemen. De impact is onduidelijk en eerdere pogingen hebben weinig opgeleverd.
Wij merken dat het probleem vaak niet technisch is, maar inhoudelijk onvoldoende is afgebakend waardoor de software niet op de juiste manier wordt ingezet of doorontwikkeld.
Met twee projectmanagers die fulltime bezig zijn met het blootleggen van het échte probleem en ondersteund worden door onze junior & senior developers, hebben we in de meeste gevallen binnen twee kennismakingsgesprekken en een nullmeting/code review een helder, overzichtelijk kader waarmee we samen aan de slag kunnen.
Plan een vrijblijvende kennismakingSoftware groeit niet mee met de ambities
Wat ooit prima werkte voor tien medewerkers, begint te knellen bij dertig. En wat ooit prima werkte bij dertig medewerkers begint te knellen bij 100.
Waar onze klanten zoal tegenaan liepen toen ze bij ons aanklopten:
- Processen die niet schaalbaar zijn -> voorbeeld case: OMS4Business
- Systemen die niet zijn ingericht op groei -> voorbeeld case: Synorga
- Software die elke verandering vertraagt in plaats van versnelt -> voorbeeld case: KNLTB
Maatwerk Software moet zich aanpassen aan je bedrijf, niet andersom
Wij merken vaak dat processen worden verbogen bij bedrijven die zich bij ons melden omdat “het systeem dat nu eenmaal zo doet”. Dat leidt tot omwegen, frustraties en inefficiëntie. Onze overtuiging is simpel: Maatwerk software moet aansluiten op hoe jullie werken, niet andersom. Anders ben je prima geholpen door een SaaS oplossing.
Jens van Lierop, Projectmanager Fruitcake
3 veelvoorkomende signalen die aangeven dat het tijd is om jouw bedrijfssoftware te vernieuwen
1. Doorontwikkeling kost steeds meer tijd en geld
Na de initiële oplevering wordt software vaak verder uitgebouwd; dat is juist de kracht van (maatwerk) software.
Het gebeurt vaak dat doorontwikkeling steeds meer tijd en geld kost.
In de afgelopen jaren hebben wij diverse software systemen overgenomen, waarbij het gebrek aan actuele documentatie en beschikbare tests veruit de meest voorkomende oorzaak bleek van het duurder en complexer worden van verdere ontwikkeling, zelfs bij kleine aanpassingen.
Documentatie fungeert als de handleiding van een softwaresysteem, maar is in de praktijk vaak verouderd en bevat onwaarheden doordat functies in de loop der tijd anders zijn gaan werken dan oorspronkelijk beschreven.
Tests helpen developers om standaard handelingen automatisch door het systeem te laten controleren vóór deployment; hoewel het opzetten hiervan eenmalig tijd en geld kost, verkleinen ze op de lange termijn aanzienlijk de kans op bugs en maken ze toekomstige uitbreidingen meer beheers- en voorspelbaar.
2. Angst om de software aan te passen omdat alles met elkaar samenhangt
Het voelt vaak alsof de software een kaartenhuis is: één kleine aanpassing en je weet niet wat er elders omvalt. Wat begon als een logische wijziging, kan onverwacht zorgen voor fouten op plekken waar je niet eens aan dacht. Daardoor sluipt er een zekere terughoudendheid in het team, liever niets veranderen dan het risico lopen dat een cruciaal proces stilvalt. Die onderlinge afhankelijkheid maakt de software kwetsbaar en zorgt ervoor dat zelfs kleine verbeteringen aanvoelen als een sprong in het diepe.
Die zorgen nemen we weg door gecontroleerd en veilig te werken. We maken altijd snapshots, zodat we op elk moment kunnen terugkeren naar een situatie waarin de software aantoonbaar goed werkte. Daarnaast werken we met duidelijke omgevingen: een lokale ontwikkelomgeving voor wijzigingen, een testomgeving om alles grondig te controleren en een productieomgeving voor dagelijks gebruik. Waar nodig voegen we ook een pre-productieomgeving toe, waarin een selecte groep van jouw medewerkers of klanten al met de nieuwe versie werkt.
3. Afhankelijkheid van één leverancier of persoon
Iedereen kent het gevoel wel, je bent bang dat je vast komt te zitten aan één partij of persoon die als enige begrijpt hoe jouw maatwerk software werkt, waardoor je weinig grip hebt en nauwelijks kunt schakelen als er iets verandert. Dat voelt riskant, omdat jouw bedrijfsvoering dan afhankelijk wordt van iemand buiten jouw controle.
Mede daardoor kiezen wij bewust voor het gebruik van het Laravel-framework: een zeer populair en breed gedragen framework dat door duizenden ontwikkelaars en bureaus wereldwijd wordt gebruikt.
Het biedt een duidelijke architectuur, wat helpt bij schaalbaarheid en onderhoudbaarheid. Dat maakt het voor ons relatief eenvoudig om jouw software systeem over te nemen, aan te passen en door te ontwikkelen.
Tot slot werken wij met een team van 17 specialisten aan uiteenlopende softwareoplossingen. Hierdoor loopt ook bij ziekte of afwezigheid van een persoon de ontwikkeling en support gewoon door.
Software is een rem in plaats van een versneller
Wat ooit bedoeld was om werkzaamheden te ondersteunen, kan langzaam veranderen in een bottleneck voor innovatie, veiligheid en groei.
Oude software systemen: het onzichtbare risico
Oude versies van frameworks of 'legacy' software bevatten vaak bekende kwetsbaarheden. Actief ondersteunde projecten ontvangen regelmatig security updates, en indien deze op tijd toegepast worden, is je software tegen deze kwetsbaarheden beschermd. Maar oude versies en projecten die niet meer actief ontwikkeld worden, krijgen deze updates niet meer. Dit zijn niet alleen kwetsbaarheden in de applicatie zelf, maar ook in veelgebruikte libraries/tools, of de PHP of server versie. Het is daarom belangrijk om up-to-date te blijven met je Laravel versie, maar hetzelfde geldt ook voor Symfony, Yii, CakePHP, ZendFramework etc.
Waarom dit gebeurt:
- Software is ooit gebouwd voor een specifieke omgeving / situatie
- Afhankelijkheden van oude libraries, databases of hardware
- Leveranciers zijn verdwenen of niet meer betrokken
- Broncode is slecht gedocumenteerd of nauwelijks overdraagbaar
Als een project te ver achter loopt, kan het door alle structurele wijzigingen moeilijk zijn om te upgraden, en afhankelijk van het oude framework kan het interessant zijn om een refactoring te doen naar bijvoorbeeld Laravel. Refactoring is het het herstructureren van bestaande code om de interne kwaliteit te verbeteren (leesbaarheid, onderhoudbaarheid, efficiëntie) zonder de externe functionaliteit of het gedrag ervan te veranderen. Naast security updates kan dit ook voordelen hebben qua ontwikkelsnelheid en onderhoudbaarheid van de code.
Waarom bedrijven lang wachten met het vernieuwen van oude software
Wellicht zul je jouw situatie herkennen in een van de hiernaast genoemde oorzaken.
Hier lees je direct hoe wij omgaan met deze situaties zodat besluitvorming niet meer hoeft te blijven liggen.
Gebrek aan inzicht
Bij veel oudere applicaties ontbreekt vaak inzicht bij jullie als gebruikers. Documentatie is verouderd of verdwenen, oorspronkelijke ontwikkelaars zijn niet meer betrokken en niemand weet precies hoe onderdelen samenhangen. Daardoor is het lastig in te schatten wat de impact van een update of wijziging zal zijn. Dit is vaak een reden waarom besluitvorming wordt vertraagt.
Angst voor verstoring van primaire processen
Legacy software ondersteunt vaak bedrijfskritische processen. De vrees dat een upgrade of refactoring leidt tot downtime, fouten of stilvallende operaties is vaak een reden die genoemd wordt waardoor organisaties liever niets veranderen dan het risico lopen iets te breken.
Onduidelijke verantwoordelijkheid
Het kan onduidelijk zijn wie binnen de organisatie nu echt verantwoordelijk is voor welk IT onderdeel. IT, management en operatie gaan er soms van uit dat “iemand anders” dit oppakt. Daardoor blijft het onderwerp tussen wal en schip liggen, zonder eigenaar of prioriteit.
Compliance- en validatie-eisen
In sectoren waar software gevalideerd moet worden, zoals zorg, industrie of finance, is aanpassen complex. Elke wijziging kan betekenen dat er opnieuw getest, gevalideerd en gedocumenteerd moet worden. Dit maakt upgrades tijdrovend en kostbaar, waardoor ze worden uitgesteld.
“Het werkt toch nog?”
Zolang de software doet waarvoor deze ooit is gebouwd, voelt vernieuwing niet urgent. Dat de code verouderd is, security risico's bevat of lastig te onderhouden is, weegt vaak minder zwaar dan het feit dat het proces vandaag nog blijft draaien.
Meer dan alleen techniek
Bij verouderde software spelen vaak meer invalshoeken dan alleen techniek en efficiëntie in de operatie. Upgraden kan juridische en organisatorische onderbouwingen hebben. Denk aan hercertificering, compliance met wet- en regelgeving zoals de GDPR, en eisen rondom informatiebeveiliging. Oude software en niet-ondersteunde componenten vormen hierbij een reëel risico: kwetsbaarheden kunnen leiden tot datalekken, boetes en reputatieschade.
Wij zien moderniseren van software daarom niet alleen als een technische keuze, maar zeker ook als een strategische. Tijdig investeren in onderhoud, upgrades of refactoring voorkomt dat technische schuld uitgroeit tot een significant bedrijfsrisico.
“Kan een andere partij onze software wel overnemen?”
Vaak leeft de gedachte dat een andere partij het beheer of de doorontwikkeling van verouderde software lastig kan overnemen. De reden hiervan kan zijn dat documentatie ontbreekt, kennis in hoofden zit van eerdere ontwikkelaars en de technische keuzes niet meer te herleiden zijn. In de praktijk blijkt er vaak meer mogelijk dan je zou verwachten en komt het erop neer dat dit vaak makkelijker te realiseren is dan je denkt. Hieronder lichten wij graag toe hoe wij hier mee omgaan.
De eerste stap is niet vervangen, maar begrijpen
De meeste organisaties denken dat modernisering begint bij “iets nieuws bouwen”.
In werkelijkheid begint het bij inzicht. Wij doen dat als eerste door alle behoeften en functionaliteit samen met jullie in kaart te brengen en vervolgens over te gaan tot een code review. Zie dit als een second opinion op jullie huidige softwaresysteem: een onafhankelijke blik die inzicht geeft in kwaliteit, structuur, risico’s en kansen.
Dit klinkt misschien spannend, maar dat is het niet. Een code review heeft geen enkele impact op de dagelijkse operatie en kan volledig los van de productieomgeving worden uitgevoerd. Het vormt juist een solide fundament voor een eventuele overname van jullie software en de verdere modernisering ervan.
Zonder inzicht in de huidige situatie kun je immers geen weloverwogen besluit nemen.
Wat een code review oplevert
Met een code review brengen we in kaart hoe het huidige softwarepakket functioneert, waar de risico’s zitten en welke mogelijkheden er zijn om veilig verder te bouwen.
Wat Fruitcake onderzoekt:
- Structuur van de code (Onderhoudbaarheid)
- Software versie en dependencies incl een upgrade pad
- Aanwezigheid en kwaliteit van tests
- Aanwezigheid en kwaliteit van Statische Analyse
- Aanwezigheid van legacy code
- Wijze van deployment / Git flow
- Kwaliteit van maatwerk en externe modules
- Security en dataveiligheid
- Concreet overzicht van risico’s en kansen
- Aanbevelingen voor een overname.
Een uitgebreide toelichting per stap vind je op onze code review pagina.
Een code review is waardevol voor meerdere doelgroepen binnen de organisatie.
Voor de directie biedt het helder inzicht in technische risico’s, toekomstscenario’s en onderbouwde keuzes rondom investeren, moderniseren of overnemen van software. Voor marketing kan het concreet maken wat er technisch mogelijk is, waar beperkingen zitten en waar juist versnelling kan worden gerealiseerd in nieuwe features, campagnes of dashboards. Dit is met name bij e-commerce relevant. Voor applicatiebeheerders levert het duidelijkheid en houvast voor het bepalen van concrete vervolgstappen richting het up to date maken van de software systemen.
Van inzicht naar gecontroleerde software-overname
Geen radicale verandering, maar gecontroleerde stappen die bewezen werken.
Kennismaking
We starten altijd met een kennismaking zodat we elkaar leren kennen en op voorhand kunnen inschatten of een overname realistisch is.
Code review
Vervolgens voeren wij een code review uit
Offerte
Aan de hand van de bevindingen in de code review en eventuele aanvullende wensen maken wij een offerte voor de daadwerkelijke overname.
Overname plan
De offerte bevat ook een overnameplan met
- Een planning op weekbasis
- To do’s voor jullie als organisatie
- To do’s voor ons
- Duidelijke afspraken over de support en doorontwikkeling
- Helder inzicht in wat wij nodig hebben van de huidige software leverancier
- Communicatie afspraken waarin staat wie wat communiceert met de huidige aanbieder
Overname
Als we alles hebben wat nodig is (bijv; toegang tot de repo, API documentatie, toegang tot de server, en toegang tot de database indien mogelijk) kunnen wij het project bij ons lokaal installeren en starten aan de werkzaamheden.
We zorgen er samen voor dat er dus geen radicale verandering komt door middel van een big bang, maar we werken tijdens het hele proces met gecontroleerde stappen.
Onderstaande cases gingen jullie al voor:
- 50 plus mobiel
- IXO
- WKK
- VPPipeline
- Residence
- Lion Beddenshop
- Redjepakketje.
Moderniseren zonder alles los te laten
"Moet nu alles op nieuw??" Nee, ten minste niet als dat voor jullie onnodig is. Hieronder lichten wij graag toe waarom onze aanpak in combinatie met het Laravel framework ook voor jullie kan werken.
Oude software hoeft niet per se meteen weg
Bij de modernisering van een bestaand softwaresysteem hoeft de huidige software niet direct volledig vervangen te worden. Vaak kan het bestaande systeem tijdelijk naast nieuwe onderdelen blijven draaien, waardoor de continuïteit gewaarborgd blijft.
Laravel leent zich goed voor modulair opbouwen, koppelen en ontkoppelen en gefaseerde migratie
Laravel is bij uitstek geschikt om software modulair op te bouwen, waardoor onderdelen los van elkaar kunnen worden ontwikkeld en vervangen. Dit maakt het eenvoudig om bestaande functionaliteit te koppelen of juist los te trekken wanneer dat nodig is.
Ook bij een volledig nieuw systeem kunnen goed werkende features vaak worden overgenomen
Zelfs wanneer gekozen wordt voor een volledig nieuw systeem, betekent dit niet dat alles opnieuw bedacht moet worden. Goed werkende en bewezen functionaliteiten uit het huidige systeem kunnen vaak één-op-één of in aangepaste vorm worden overgenomen.
Up-to-date brengen en security issues oplossen als startpunt voor modernisering
In sommige gevallen is het al een grote stap om het bestaande systeem technisch up-to-date te maken en beveiligingsproblemen op te lossen. Dit creëert een stabiele en veilige basis waarop verder gemoderniseerd kan worden.
Begin met inzicht in de software
De meeste risico’s ontstaan niet door technologie, maar door gebrek aan inzicht.
Samen werken aan een toekomstgerichte roadmap
Vragen om nu al over na te denken
- Welke processen zijn écht bedrijfskritisch?
- Waardoor ontstaan de fouten in het systeem?
- Welke risico’s accepteren jullie (nog), en welke niet?
- Wat moet dit platform over 3 jaar kunnen?
- In welke processen valt veel tijdwinst te behalen?
- Wie zijn de gebruikers, kun je deze verdelen in rollen, hoe gebruikt elke rol het systeem?
- Met welke andere systemen communiceert het systeem nu en hoe komt die communicatie tot stand? (bijv API of FTP) Moet het systeem nog met andere software gekoppeld worden binnen de organisatie? Zo ja, dan is het belangrijk om te weten met welk doel deze koppeling gemaakt wordt. Techniek komt later.
Wat krijg je van ons?
Een helder plan
Hoe lang duurt het?
Afhankelijk van de grootte van het system en de bereidbaarheid van de huidige ontwikkelaar duurt een overname traject meestal 1 tot 4 maanden
Wat kost het globaal?
De kosten zijn sterk afhankelijk van jouw situatie, kwaliteit van de software, wensen m.b.t. doorontwikkeling enz. Maar wij zorgen er voor dat je weet waar je aan toe bent voordat we überhaupt beginnen.
Dit traject is voor jou geschikt wanneer:
Bedrijfssoftware cruciaal is voor de processen
Wanneer continuïteit, betrouwbaarheid en schaalbaarheid direct impact hebben op de business.
Je inzicht wilt voordat je beslist
Bijvoorbeeld door analyse of een gefaseerde modernisering in plaats van een big bang
Je een lange termijn partner zoekt
Iemand die meedenkt over groei, onderhoud en doorontwikkeling, en zelf ook beschikt over de capaciteit om met jouw organisatie mee te groeien.
Je bereid bent om te investeren in duurzame software oplossingen
Met aandacht voor kwaliteit, onderhoudbaarheid, security en toekomstbestendigheid.
Integraties met andere systemen steeds belangrijker worden
En flexibiliteit nodig is om nieuwe koppelingen eenvoudig toe te voegen.
Data een steeds grotere rol speelt in besluitvorming
En het huidige systeem hierin onvoldoende ondersteunt.
Dit traject is voor jou minder geschikt wanneer:
Je een ‘quick fix’ zoekt voor een (tijdelijk) probleem
Software modernisering lost structurele problemen op, geen korte pieken of incidenten.
Veruit de meeste operationele processen nog niet specifiek zijn of sterk in ontwikkeling zijn
Automatiseren van onvolwassen processen kan leiden tot het vastzetten van inefficiënties.
De focus vooral ligt op kostenreductie op korte termijn
Modernisering vraagt een initiële investering voordat baten zichtbaar worden.
FAQ Software overname en risico’s
Wat als onze software nog op oude Windows-systemen draait?
Dat is geen enkel probleem. We werken samen naar een situatie toe waarbij jullie software draait op een moderne server. We kijken wat voor jullie de beste oplossing en geven advies. Je bent vrij om de hosting zelf te regelen maar wij kunnen dit ook uit handen nemen.
Kunnen jullie werken zonder documentatie?
Dat is geen probleem. Na het uitvoeren van de code review hebben we de gewenste inzichten die nodig zijn om een eventuele overname in gang te zetten.
Moet alle software opnieuw geschreven/gemaakt worden?
Nee. Zie hier onze toelichting
Wat als blijkt dat moderniseren niet rendabel is?
Als na de code review en het aanbieden van de offerte blijkt dat moderniseren niet rendabel is, denken we mee over alternatieven, zoals een gefaseerde aanpak, vereenvoudigen of het behouden van de huidige oplossing met minimale aanpassingen. Het doel is altijd om een keuze te maken die technisch én financieel verantwoord is.
