VB6- of Delphi-applicatie vervangen: zo bouw je slim na

Veel bedrijven werken nog dagelijks met een applicatie die ooit is gebouwd in Visual Basic 6, Delphi, een vroege versie van .NET of FoxPro. Het systeem doet wat het moet doen en de mensen die ermee werken kennen het door en door. Toch groeit het ongemak: de ontwikkelaar is met pensioen, een Windows-update geeft vreemde foutmeldingen en niemand durft nog iets aan te passen. Wie een VB6 applicatie vervangen wil, zit met een lastige vraag. Hoe stap je over zonder de kennis en werkwijze te verliezen die in die software zit? In dit artikel leggen we uit waar de risico's zitten en hoe slim software nabouwen een veilige route biedt.

Waarom is een VB6- of Delphi-applicatie een risico?

Een applicatie op een verouderde ontwikkelomgeving is een risico omdat de techniek eronder niet meer wordt onderhouden, terwijl de rest van je IT wel doorontwikkelt. Microsoft ondersteunt de ontwikkelomgeving van Visual Basic 6 al lang niet meer. De runtime draait nog op huidige Windows-versies, maar dat geldt niet automatisch voor alle losse componenten, stuurprogramma's en koppelingen van derden waar zo'n applicatie op leunt. Voor Delphi, oude .NET-versies en FoxPro speelt een vergelijkbaar verhaal.

Beveiliging

Oude applicaties zijn gebouwd in een tijd waarin andere eisen golden. Wachtwoorden staan soms leesbaar in een configuratiebestand, de database is vaak via een gedeelde netwerkmap bereikbaar en er is geen logboek van wie wat heeft gewijzigd. Beveiligingsupdates voor gebruikte componenten komen er niet meer. Dat maakt het lastig om aan te tonen dat je zorgvuldig met bedrijfs- en klantgegevens omgaat.

Compatibiliteit met Windows

Elke nieuwe versie van Windows of Office is een spannend moment. Een printerstuurprogramma, een rapportagecomponent of een koppeling met Excel kan zomaar stoppen. Vaak zie je dan dat een paar pc's bewust op een oude versie blijven staan, alleen om die ene applicatie te laten werken. Thuiswerken of werken op een laptop of tablet is meestal niet mogelijk zonder omwegen zoals een remote desktop.

Ontwikkelaars vinden

Het lastigste risico is menselijk. Er zijn steeds minder ontwikkelaars die VB6, Delphi of FoxPro beheersen en willen onderhouden. Vaak is er nog precies één persoon die de broncode kent. Valt die weg, dan staat het bedrijf stil bij de eerste fout. Meer daarover lees je in ons artikel over afhankelijk zijn van één ontwikkelaar.

Wanneer moet je een VB6 applicatie vervangen?

Je moet een VB6 applicatie vervangen voordat een storing of een vertrekkende ontwikkelaar je dwingt, dus op een moment dat je zelf kiest. Signalen dat dat moment is aangebroken:

• kleine aanpassingen duren lang of worden niet meer uitgevoerd;
• medewerkers houden naast de applicatie eigen Excel-lijsten bij;
• de applicatie werkt alleen op specifieke pc's of via een omweg;
• er zijn wensen voor koppelingen, mobiel gebruik of klanttoegang die niet te realiseren zijn;
• niemand weet precies meer welke regels er in de code zitten.

Herken je meerdere punten, dan is het verstandig om de vervanging te plannen. In ons artikel over verouderde bedrijfssoftware vervangen lees je hoe je die afweging maakt.

Wat betekent slim nabouwen voor een oude applicatie?

Het betekent dat we jullie eigen applicatie opnieuw bouwen op moderne techniek, met behoud van functies, werkwijze en data. Het bestaande systeem is de specificatie. Alles wat in jaren is gegroeid aan schermen, uitzonderingen en rekenregels is waardevolle kennis. Die gooien we niet weg, die leggen we vast en bouwen we opnieuw op.

Het voordeel is dat gebruikers hun werk herkennen. De velden, stappen en volgorde voelen vertrouwd, ook al draait alles in de browser. Dat maakt de overstap veel rustiger dan bij een standaardpakket waarin je je werkwijze moet aanpassen aan de software. Pas als de basis staat, kijken we samen wat beter kan.

Hoe verloopt het nabouwen naar een webapplicatie?

Het nabouwen naar een webapplicatie verloopt in vaste stappen, van inventarisatie tot doorontwikkeling.

1. Inventarisatie. We lopen met de gebruikers door de applicatie, scherm voor scherm. Waar de broncode beschikbaar is, lezen we die mee om rekenregels en uitzonderingen boven water te krijgen.
2. Datamodel. We brengen de bestaande database in kaart en ontwerpen een schoon datamodel dat dezelfde informatie bevat.
3. Bouwen in delen. We bouwen per module of proces, zodat gebruikers vroeg kunnen testen.
4. Naast elkaar draaien. Oud en nieuw kunnen tijdelijk naast elkaar draaien. Zo vergelijk je uitkomsten en stap je pas over als het klopt.
5. Optimaliseren. Na de overstap pakken we verbeteringen op: koppelingen, automatisering, toegang voor klanten of leveranciers.

Wil je weten wat een webapplicatie anders maakt dan desktopsoftware, lees dan ook een webapplicatie laten maken.

Welke techniek gebruiken we voor de nieuwe applicatie?

We kiezen per project de techniek die past, meestal een webapplicatie met Next.js en React aan de voorkant en Supabase of Xano als backend. Beide backends zijn stabiel en volwassen en bieden een echte database, gebruikersbeheer en een API voor koppelingen. Welke het wordt, hangt af van jullie situatie. Het verschil leggen we uit in Supabase of Xano. Kijk voor onze aanpak ook bij applicatie-ontwikkeling.

Belangrijk: de code en de data zijn van jullie. Daarmee voorkom je dat je over tien jaar weer vastzit aan één leverancier of één persoon.

Wat gebeurt er met de data uit de oude applicatie?

De data uit de oude applicatie gaat volledig mee naar het nieuwe systeem. Databases uit VB6-, Delphi- of FoxPro-applicaties zijn vaak Access-bestanden, dBase-tabellen of een oudere SQL Server. We lezen die uit, schonen dubbele of onvolledige records op en zetten alles over naar de nieuwe structuur. Tijdens het naast elkaar draaien migreren we meerdere keren, zodat de laatste overzetting een geoefende stap is. Hoe dat precies werkt, lees je in data migreren naar nieuwe software. Werk je met een Access-database als front-end, dan is een Access-applicatie vervangen ook relevant.

Waar hangen tijd en kosten af?

Tijd en kosten hangen vooral af van de omvang en complexiteit van de bestaande applicatie. Factoren die meewegen:

• het aantal schermen, rapporten en processen;
• hoeveel rekenregels en uitzonderingen in de code verstopt zitten;
• of de broncode beschikbaar en leesbaar is;
• de kwaliteit en omvang van de data;
• gewenste koppelingen met andere systemen.

Een uitgebreidere uitleg vind je in ons artikel over software laten nabouwen: kosten en doorlooptijd.

Hoe begin je met het vervangen?

Je begint met een gesprek en een korte inventarisatie van de huidige applicatie. Daarna weet je welke delen kritisch zijn, welke volgorde logisch is en wat er bij de overstap komt kijken. Met slim software nabouwen houd je de kennis die in je oude applicatie zit en krijg je een systeem waar je weer jaren mee vooruit kunt. Neem contact met ons op om jullie applicatie samen door te lopen.