Classic ASP moderniseren zonder big bang

Een applicatie die niemand meer durft aan te raken

Het begint vaak met één zin in een eerste gesprek: "Hij doet het nog, maar we weten niet hoe lang nog." Achter die zin zit een Classic ASP-applicatie die al twintig jaar trouw zijn werk doet. Er worden orders in verwerkt, klanten in bijgehouden en rapportages uit gedraaid. Het hele bedrijf leunt erop.

Tegelijk weet niemand meer precies hoe hij werkt. De ontwikkelaar die hem ooit bouwde is al jaren weg. Documentatie is er nauwelijks. Elke Windows- of IIS-update voelt als een gok, en Microsoft heeft aangekondigd dat VBScript, de taal waarin het geheel geschreven is, wordt uitgefaseerd. Wie een kleine wijziging wil, hoort: "Liever niet, straks valt er iets om."

Zo'n situatie kennen we goed. En het eerste wat we dan doen is iets wat veel mensen niet verwachten: we stellen voor om níet alles in één keer opnieuw te bouwen.

Waarom de grote herbouw zo verleidelijk is (en zo vaak misgaat)

De logische reactie op een verouderd systeem is: weg ermee, we beginnen opnieuw. Een nieuw project, een nieuwe planning, over een jaar staat er iets moderns.

In de praktijk loopt dat anders. Een applicatie van twintig jaar oud zit vol met regels die nergens staan opgeschreven. Een korting die alleen geldt voor klanten van vóór 2012. Een veld dat leeg moet blijven omdat een ander systeem anders vastloopt. Een rapport dat één persoon op de financiële afdeling elke maand gebruikt. Die regels kom je pas tegen als het nieuwe systeem live gaat en iemand zegt: "Maar dit deed hij vroeger altijd."

Daarbij zien gebruikers bij een grote herbouw maandenlang niets. Als het nieuwe systeem dan eindelijk klaar is, herkennen ze het niet. Het voelt als iets wat ze is overkomen in plaats van iets wat ze mee hebben gemaakt.

Eerst luisteren, dan pas bouwen

Daarom beginnen we met begrijpen wat er staat. We lezen de oude code en de database door, maar belangrijker nog: we praten met de mensen die er dagelijks mee werken. Welke schermen gebruik je echt? Waar erger je je aan? Wat zou je missen als het er morgen niet meer was?

Vaak blijkt een flink deel van de applicatie in de loop der jaren overbodig geworden. Schermen die niemand meer opent, functies die door een ander pakket zijn overgenomen. Wat overblijft is kleiner en overzichtelijker dan iedereen dacht. Dat alleen al geeft lucht.

Klein beginnen, snel iets laten zien

Daarna kiezen we samen één afgebakend onderdeel om mee te beginnen. Bij voorkeur iets wat vaak gebruikt wordt en waar de pijn voelbaar is, zoals een overzichtsscherm of een invoerformulier. Dat bouwen we opnieuw met Lovable, op een moderne database.

Omdat Lovable ons helpt om snel werkende schermen neer te zetten, staat er binnen enkele dagen iets wat de klant zelf kan proberen. Geen ontwerp op papier, maar echte software met echte gegevens. Dat moment is belangrijk. Het gesprek verandert van "hoe gaat het eruitzien?" naar "dit knopje moet daar, en dit veld mag weg."

De klant beslist mee, elke week

Vanaf dat moment werken we in korte iteraties. Elke iteratie levert een werkend stuk op. De klant kijkt ernaar, geeft feedback, en samen bepalen we wat de volgende stap wordt.

Dat klinkt eenvoudig, maar het maakt een groot verschil. De klant hoeft niet vooraf een dik eisenpakket te schrijven en dan een jaar te wachten. Prioriteiten mogen onderweg verschuiven. Blijkt iets minder belangrijk dan gedacht? Dan schuiven we het naar achteren. Komt er een nieuw idee bij? Dan nemen we het mee in de volgende ronde. Zo wordt het nieuwe systeem iets van de mensen die ermee moeten werken.

Snel over, zonder lange overlap

Een veelgehoord advies is om oud en nieuw lange tijd naast elkaar te laten draaien. Wij kiezen liever voor het tegenovergestelde: zo snel mogelijk live met het nieuwe systeem, en het oude daarna uitfaseren. Bij voorkeur zonder overlap.

De reden is praktisch. Twee systemen die tegelijk in gebruik zijn, moeten dezelfde gegevens bevatten. Die gegevens heen en weer synchroniseren is in zo'n traject vaak de grootste uitdaging, en een bron van fouten die niemand ziet aankomen. Liever steken we die energie in één goede, zorgvuldig geteste datamigratie en een duidelijk overstapmoment.

Daarom beginnen we compact. Eerst de kernfunctionaliteit waar het bedrijf op draait, en die moet blijven werken zoals mensen gewend zijn. Zodra dat staat, gaan we live en kunnen we snel door naar nieuwe, moderne mogelijkheden.

De techniek van toen hoeft niet de werkwijze van nu te zijn

Bij het doorlichten van een oude applicatie zien we iets wat bijna altijd terugkomt: veel werkt zoals het werkt omdat de techniek van toen dat dicteerde, niet omdat het de handigste manier was. Een formulier dat over drie pagina's verspreid is omdat het anders te traag werd. Een export naar Excel omdat er geen andere manier was om gegevens te delen. Een nachtelijke verwerking omdat het overdag te zwaar was.

Die gewoonten nemen we niet blind mee. We maken onderscheid tussen wat écht kernfunctionaliteit is en wat een overblijfsel van oude techniek is. Het eerste blijft ongemoeid; het tweede halen we er zo snel mogelijk uit. Zo wordt het nieuwe systeem niet een kopie van het oude, maar een verbetering ervan.

Niet de oude risico's in een nieuw jasje

Snel bouwen is mooi, maar een nieuw systeem moet ook veilig zijn. Voordat een onderdeel live gaat, controleren we wie welke gegevens mag zien, of invoer goed wordt gecontroleerd en of de gebruikte bibliotheken geen bekende lekken bevatten. Zo voorkomen we dat het nieuwe systeem dezelfde zwakke plekken krijgt als het oude, alleen dan met een modernere buitenkant.

Wat het uiteindelijk oplevert

Aan het eind van zo'n traject staat er een applicatie die weer onderhoudbaar is. Wijzigingen zijn geen gok meer, maar gewoon werk. Er is geen afhankelijkheid meer van verouderde servers en VBScript. Koppelingen met andere systemen, of later met AI, zijn ineens goed te doen.

En misschien het belangrijkste: de gebruikers herkennen het eindresultaat, omdat ze het zelf mee hebben vormgegeven.

Een lopend verhaal

Dit is geen theorie. We passen deze aanpak op dit moment toe bij een klant die van zijn Classic ASP-applicatie af wil. Het traject loopt nog, en elke week komt het nieuwe systeem een stap dichter bij livegang. Meer daarover lees je in ons portfolio.

Herken je jezelf in het begin van dit verhaal? Heb je ook een applicatie die nog werkt, maar die niemand meer durft aan te raken? Neem contact met ons op. Dan kijken we samen waar je het beste kunt beginnen.