Oude software. Eerst begrepen, dan vernieuwd.
Je systeem draait al jaren en doet zijn werk. Maar niemand weet nog precies hoe, en elke wijziging voelt als een gok. We brengen eerst in kaart wat je software echt doet. Daarna moderniseren we stap voor stap, met bewijs dat er niets verandert wat niet mag veranderen.
De meeste legacyprojecten gaan niet mis op techniek. Ze gaan mis op de volgorde.
Men begint met herschrijven voordat duidelijk is wat het oude systeem doet. Of er is geen vangnet dat laat zien wanneer het nieuwe systeem anders rekent. Twintig jaar systemen van anderen overnemen leerde ons één volgorde die standhoudt: eerst begrijpen, dan besluiten, dan pas bouwen, altijd met een test die bewijst dat het gedrag niet veranderde.
Daarom verkopen we het plan vóór de bouw. Het plan is één opdracht met vijf stappen. Bouwen begint pas als jij ervoor getekend hebt.
Vijf stappen. Elke stap levert iets op dat je houdt.
Eén opdracht, een vaste scope, en na elke stap een resultaat waarbij je kunt stoppen, bijsturen of doorgaan. De oude code wordt nooit aangeraakt: analyse en nieuwe code staan apart.
- STAP 1Wat ligt er? We beginnen met vijf vragen die de code zelf niet beantwoordt: wat valt binnen de scope, kan het systeem bij ons gebouwd en getest worden, is er een eigen build-straat, zijn er eerdere pogingen geweest en wat mag niet worden aangeraakt. Daarna controleren we of alles compleet is. Je weet vooraf wat ontbreekt.Readiness-rapport
- STAP 2Wat doet het? We brengen omvang, complexiteit, technische schuld en beveiliging in beeld. Je krijgt een interactieve kaart van je systeem: welke onderdelen elkaar aanroepen, waar data vandaan komt en hoe een gebruiker door de belangrijkste processen loopt.Kaart van het systeem
- STAP 3Welke regels zitten erin? De kennis over tarieven, voorwaarden en berekeningen zit vaak alleen nog in de code. We halen die regels eruit en schrijven ze op in gewone taal, met een verwijzing naar de exacte plek in de code. Jouw mensen toetsen ze. Daarmee heb je documentatie die klopt, ook als je nooit migreert.Regels, met bron
- STAP 4Wat is het plan? Op basis daarvan maken we het moderniseringsplan: doelarchitectuur, fasering en een gedragscontract dat vastlegt wat het nieuwe systeem moet blijven doen. Een plan dat je stuurgroep kan goedkeuren. Er wordt pas gebouwd als jij tekent.Plan om te tekenen
- STAP 5Bouwen met bewijs Voor we iets veranderen, leggen we het huidige gedrag vast in tests. Het nieuwe systeem moet daarlangs. Zo zie je zwart op wit dat het hetzelfde rekent. Welke van de drie routes hieronder we nemen, bepaalt het plan.Zelfde gedrag, bewezen
Het plan bepaalt de route. Niet onze voorkeur.
Upgraden.
Dezelfde techniek, een nieuwe versie, zoals .NET Framework naar het huidige .NET. Je code blijft, we lossen alleen op wat tussen de versies breekt. We migreren eerst één onderdeel volledig en gebruiken die lessen voor de rest.
Stap voor stap vervangen.
Eén onderdeel tegelijk, terwijl het oude systeem gewoon blijft draaien. Geen big bang, geen nacht waarin alles tegelijk over moet. Eerst de tests die het huidige gedrag vastleggen, dan het nieuwe onderdeel, dan het bewijs dat beide hetzelfde doen.
Opnieuw bouwen.
Een nieuwe architectuur, gebouwd vanuit de regels die we uit je oude systeem haalden, op een fundament dat van jou blijft. Met acceptatietests die vanaf dag één laten zien of het klopt, en twee momenten waarop jij akkoord geeft.
Blijkt een upgrade toch het grootste deel van de code te raken, dan zeggen we dat en kiezen we samen een andere route.
Eén opdracht voor het plan. Of eerst overnemen.
Het moderniseringsplan. Van “wat doet het” naar een plan dat je directie kan tekenen.
De vijf stappen hierboven voor één systeem: gereedheid, kaart, regels, plan, en de tests die het huidige gedrag vastleggen. Je krijgt een voorstel met een vaste prijs voor de vijf stappen. Het bouwen daarna krijgt zijn eigen voorstel, per route.
Vraag het plan aanBeheer en doorontwikkeling. We nemen het systeem over van je leverancier of van de ontwikkelaar die vertrok.
Stap 1 tot en met 3 als overdrachtsdossier: architectuur, afhankelijkheden, regels met bron, securitybevindingen. Op die basis houden we het systeem stabiel en veilig, maken we het veiliger terwijl het draait, en ontwikkelen we het door, voor een vast beheertarief in het voorstel. We zijn zelf de inkomende én de vertrekkende partij geweest.
Beheer en doorontwikkelingJe oude systeem blijft onaangeroerd. Je data blijft waar ze is.
De analyse is zo goed als wat er in de code staat.
De volledige lijst krijg je bij de intake. Dit is de korte versie, zodat je weet waar je naar moet zoeken vóór het eerste gesprek. Nooit productiedata.
Zes signalen die je herkent.
Migraties die standhielden.
Ons eigen fundament, Entry, is in een ervan ontstaan.
Van een low-code-platform naar .NET
Een parkeervergunningensysteem dat zijn low-code-platform was ontgroeid, maar er niet vanaf kon. We bouwden het opnieuw en migreerden het naar .NET. De bouwstenen die we onderweg schreven, werden Entry, ons opensourcefundament.
Lees de case Case · FOSIMHerbouwd om te blijven draaien
Een verkeerssimulatie die Rijkswaterstaat gebruikt voor grote infrastructuurprojecten en onderzoek. We namen hem over van de TU Delft en bouwden hem deels opnieuw, zodat hij op actuele systemen draait. Het simulatiemodel zelf bleef intact, en de software kan later naar de browser.
Lees de case Case · NT2 OnlineGemoderniseerd en doorontwikkeld
Een online leeromgeving die eerst gemoderniseerd moest worden voordat ze verder kon groeien: de uitgever leverde de lesmethodes en content, we investeerden in de techniek.
Lees de caseVier vragen die altijd eerst komen.
Moeten we alles vervangen?
Zelden. Begrijp het eerst en vervang dan het deel dat het meeste pijn doet. Een systeem dat stabiel en begrepen is kan nog jaren mee. Het doel is dat je het weer kunt veranderen, niet dat je nieuwe software hebt.
Wat als de broncode weg is?
Dan is het draaiende systeem de specificatie. We leggen het gedrag van buitenaf vast (schermen, database, koppelingen) en bouwen daartegen. Dat duurt langer, en we zijn open over de delen die van buitenaf niet te zien zijn.
Hoe gaan we om met de huidige leverancier?
We schuiven aan bij de gesprekken met je leverancier, of nemen ze over. De meeste overdrachten gaan beter zodra er aan jouw kant iemand met verstand van techniek aan tafel zit. Werkt de leverancier niet mee, dan beginnen we met wat jij zelf in handen hebt: een export van de database en de draaiende applicatie. Broncode helpt, maar is geen voorwaarde.
Wat kost het om erachter te komen?
Het plan is één opdracht met een vaste scope en een voorstel met een vaste prijs voor de vijf stappen. Het bouwen daarna krijgt zijn eigen voorstel, per route, en aan het eind van elke fase beslis jij of we doorgaan.
Laat ons het systeem zien waar iedereen omheen werkt.
Vertel waarop het draait, hoe oud het is en wie het nog begrijpt. We kijken samen wat er ligt, wat het doet en welke route past. Daarna beslis je over de volgende stap.
Van oud systeem naar nieuw, sinds 2006