Visual Basic 6 ist offiziell seit über zwei Jahrzehnten Geschichte. Trotzdem läuft erstaunlich viel davon weiter: Werkzeuge in der Fertigung, Auftragsverwaltungen, Branchenlösungen im Mittelstand. Sie tun, was sie sollen. Aber jede Windows-Aktualisierung wird zum Risiko, und die Laufzeitumgebung wird nur noch geduldet, nicht gepflegt.
Wir überführen VB6-Anwendungen dorthin, wo sie wieder eine Zukunft haben: nach C#/.NET, wenn der Desktop bleiben soll, oder ins Web, wenn der Schritt jetzt sowieso ansteht.
Der erste Schritt: Automatisiertes Code-Assessment →
Warum VB6 jetzt zum Problem wird
VB6 läuft auf Windows 11 nur noch im Kompatibilitätsmodus. Das funktioniert – bis es das nicht mehr tut. Microsofts Zusagen zur Laufzeitunterstützung sind kein Versprechen auf ewig, und jedes größere Windows-Update kann eine Abhängigkeit brechen, die vorher klaglos lief.
Dazu kommt das Personalproblem. VB6-Entwickler gehen in Rente, und es kommen keine nach. Wer heute noch eine VB6-Anwendung pflegt, sitzt auf Wissen, das nicht ersetzbar ist, sobald die Person geht.
Der Vorteil von VB6: die Nähe zu C#
VB6 zu migrieren ist oft einfacher, als Kunden befürchten. Der Grund liegt in der Verwandtschaft der Sprachen. Vieles in VB6 lässt sich nahezu eins zu eins nach C# übertragen – die grundlegenden Konstrukte, der Programmfluss, die Struktur. Das macht die Migration nach C#/.NET berechenbar und sauber, statt zu einem kompletten Neuschreiben zu werden.
Diese Nähe nutzen wir bewusst. Wo eine direkte Entsprechung existiert, übertragen wir sie. Wo VB6 veraltete Muster nutzt, modernisieren wir gezielt – aber ohne die Logik unnötig umzubauen.
Die Datenfrage: von DAO/Access zu Entity Framework Core
VB6-Anwendungen hängen sehr häufig an einer Access-Datenbank, angesprochen über DAO. Das ist ein typisches Muster und einer der heikelsten Teile der Migration, weil hier oft Datenqualität und undokumentierte Annahmen aufeinandertreffen.
Wir überführen den Datenzugriff von DAO auf Entity Framework Core. Das bedeutet: ein sauberes, typsicheres Datenmodell statt loser Recordsets, mit klar definierten Beziehungen und nachvollziehbaren Abfragen. Die Bestandsdaten werden dabei übernommen und bereinigt.
Desktop behalten oder ins Web gehen?
Diese Entscheidung treffen wir gemeinsam mit Ihnen, abhängig davon, wie die Anwendung genutzt wird.
- Nach C#/.NET (Desktop): Wenn die Anwendung an Arbeitsplätze gebunden ist, auf lokale Hardware zugreift oder offline laufen muss, ist ein moderner Desktop-Client der richtige Weg.
- Ins Web (Laravel + React): Wenn ortsunabhängiger Zugriff, mehr Nutzer oder mobile Bedienung gefragt sind, lohnt der Sprung ins Web direkt mit.
Es gibt keine pauschal richtige Antwort. Im Assessment klären wir, was zu Ihrem tatsächlichen Einsatz passt.
Wie wir vorgehen
- Analyse. Wir kartieren Forms, Module, Klassen und vor allem den Datenzugriff.
- Architektur. Zielentscheidung Desktop oder Web, Datenmodell für EF Core.
- Umsetzung. Near-1:1-Übertragung nach C#, gezielte Modernisierung wo nötig.
- Datenmigration. Von Access/DAO auf das neue, saubere Modell.
- Qualitätssicherung. Funktionsabnahme gegen das Verhalten der Altanwendung.
Vertiefung
- VB6 zu C# migrieren – wie die Code-Übertragung konkret aussieht.
- Desktop-Anwendung ins Web bringen – wenn statt eines neuen Clients eine Web-App das Ziel ist.
Verwandte Technologien
VB6 kommt selten allein. In vielen Unternehmen koexistiert es mit anderen Windows-Desktop-Technologien aus derselben Ära. Wenn bei Ihnen auch Delphi oder Access/VBA läuft, betrachten wir die Landschaft als Ganzes. Diese Systeme teilen sich oft Daten und Logik – eine abgestimmte Modernisierung verhindert, dass man dieselbe Brücke zweimal baut.
Häufige Fragen
Müssen wir uns sofort zwischen Desktop und Web entscheiden? Nein. Diese Entscheidung fällt nach dem Assessment, wenn klar ist, wie die Anwendung wirklich genutzt wird.
Unsere Daten liegen in einer alten Access-Datei. Ist das ein Problem? Das ist der Normalfall bei VB6 und für uns Routine. Wir überführen den Zugriff auf Entity Framework Core und bereinigen die Daten dabei.
Wie nah kommt der neue Code an das alte Verhalten? Funktional bilden wir das bestehende Verhalten ab und prüfen es in der Abnahme gegen die Altanwendung. Technisch wird der Code modern, fachlich bleibt er vertraut.