Wann sollte eine geschäftskritische VB6 - Anwendung modernisiert werden?

Nicht das Alter entscheidet, sondern das Risiko

Eine VB6-Anwendung ist nicht allein deshalb schlecht, weil ihre technische Basis alt ist. In vielen Unternehmen laufen solche Systeme seit Jahren zuverlässig und bilden Abläufe ab, die mit Standardsoftware nur schwer oder gar nicht zu ersetzen wären. Das eigentliche Risiko entsteht dort, wo die Anwendung nicht mehr beherrschbar ist: wenn niemand einen reproduzierbaren Build erstellen kann, Komponenten fehlen, Schnittstellen nur noch durch Erfahrungswissen verstanden werden oder Änderungen zunehmend zum Glücksspiel werden.

Deshalb sollte die erste Frage nicht lauten: „Wie schnell können wir VB6 ersetzen?“ Sinnvoller ist: „Wie sicher können wir dieses System heute betreiben, ändern und im Störungsfall wiederherstellen?“ Erst diese Bestandsaufnahme liefert eine belastbare Grundlage für eine Modernisierungsentscheidung.

Sechs Warnsignale, die man ernst nehmen sollte

1. Der Build ist nicht reproduzierbar. Der Quellcode ist vorhanden, aber es ist unklar, welche Entwicklungsumgebung, OCX-/COM-Komponenten, Bibliotheken und Versionen benötigt werden. Ein Rechnerdefekt kann dann aus einer funktionierenden Anwendung ein akutes Betriebsrisiko machen.

2. Quellcode und produktive Version passen nicht zusammen. Besonders kritisch wird es, wenn niemand sicher sagen kann, ob aus dem vorhandenen Repository tatsächlich die aktuell eingesetzte EXE erzeugt werden kann.

3. Einzelne Komponenten sind nicht mehr beschaffbar. Alte Controls, Druckertreiber, Datenbanktreiber oder proprietäre Schnittstellen können eine ansonsten stabile Anwendung plötzlich blockieren.

4. Das Wissen liegt bei einer Person. Kennt nur ein Entwickler Tabellenstrukturen, Sonderfälle und Schnittstellen, besteht neben dem technischen ein organisatorisches Risiko.

5. Änderungen werden immer gefährlicher. Kleine Anpassungen benötigen unverhältnismäßig viel Testaufwand, weil Seiteneffekte nicht abschätzbar sind oder automatisierte Tests fehlen.

6. Die Umgebung verhindert notwendige Weiterentwicklung. Neue Betriebssysteme, Security-Anforderungen, APIs oder Datenbankversionen lassen sich nur noch mit Workarounds anbinden.

Vor der Migration kommt die Sicherung

Bevor eine Modernisierung geplant wird, sollte der bestehende Zustand technisch gesichert werden. Dazu gehören vollständiger Quellcode, verwendete Bibliotheken und Komponenten, Datenbankschemata, Konfigurationsdateien sowie eine dokumentierte Entwicklungs- und Build-Umgebung. Idealerweise wird zusätzlich geprüft, ob sich die produktive Version aus diesem Bestand tatsächlich reproduzieren lässt.

Dieser Schritt klingt unspektakulär, ist aber oft der wichtigste. Eine gesicherte und nachvollziehbare Ausgangslage nimmt Zeitdruck aus späteren Entscheidungen. Sie ermöglicht, das bestehende System zunächst stabil weiterzubetreiben, während Modernisierungsschritte geplant und getestet werden.

Die Anwendung in fachliche Bereiche zerlegen

Eine gewachsene VB6-Anwendung ist selten ein homogener Block. Meist gibt es stabile Kernfunktionen, problematische Randbereiche, Schnittstellen, Reports, Import-/Exportfunktionen und Funktionen, die kaum noch genutzt werden. Diese Bereiche sollten getrennt bewertet werden.

Für jeden Bereich sind vier Fragen hilfreich: Wie geschäftskritisch ist er? Wie häufig ändert er sich? Wie hoch ist sein technisches Risiko? Und wie stark ist er mit anderen Teilen gekoppelt? Daraus entsteht eine Priorisierung. Ein instabiler Importdienst kann dringender sein als eine große, aber seit Jahren unverändert funktionierende Stammdatenmaske.

Vier realistische Modernisierungswege

Stabilisieren und weiterbetreiben: Wenn die Anwendung fachlich passt und technisch beherrschbar ist, kann eine abgesicherte Weiterführung wirtschaftlich sinnvoll sein. Dazu gehören Versionsverwaltung, dokumentierter Build, Backups und Wissenstransfer.

Kapseln: Kritische Altkomponenten können hinter klar definierten Schnittstellen weiterlaufen, während neue Funktionen außerhalb von VB6 entstehen. Das reduziert Abhängigkeiten, ohne sofort den gesamten Kern anzufassen.

Schrittweise ersetzen: Gut abgegrenzte Module werden nacheinander modernisiert. Der Vorteil: Nutzen und Risiko bleiben kontrollierbar, und die Fachlogik kann anhand des laufenden Systems überprüft werden.

Komplett neu entwickeln: Auch das kann richtig sein – aber erst dann, wenn fachliche und technische Gründe dafür sprechen. Eine Neuentwicklung nur wegen des Alters der Programmiersprache ist keine ausreichende Begründung.

Die wichtigste Kennzahl ist nicht das Alter

Entscheidend ist die Beherrschbarkeit. Eine 20 Jahre alte Anwendung mit vollständigem Quellcode, reproduzierbarem Build, dokumentierter Datenbank und mehreren Wissensträgern kann ein geringeres Unternehmensrisiko darstellen als ein fünf Jahre altes System ohne Dokumentation und ohne nachvollziehbare Deployment-Prozesse.

Fazit

VB6 ist ein Anlass zur Bestandsaufnahme, aber kein automatisches Todesurteil für eine Anwendung. Wer zuerst Quellcode, Build, Abhängigkeiten, Daten und Fachlogik sichert, kann anschließend sachlich entscheiden. Häufig ist eine Kombination aus Stabilisierung und schrittweiser Modernisierung wirtschaftlicher und risikoärmer als ein Big Bang.

Genau dafür ist der Legacy Software Check von DÜCHTING.SYSTEMS gedacht: eine konkrete Anwendung technisch einordnen, Risiken sichtbar machen und daraus einen priorisierten, realistischen Modernisierungsfahrplan (Roadmap) ableiten.