Der entscheidende Grund für den Erfolg von VB6 war seine Philosophie der schnellen, sichtbaren Ergebnisse. Wo andere Sprachen umfangreiches Vorwissen und viel Code verlangten, konnte man in VB6 ein Fenster mit Schaltflächen und Eingabefeldern per Maus zusammensetzen und mit wenigen Zeilen zum Leben erwecken. Dieser Ansatz – gestützt auf ein ereignisgesteuertes Modell und die Windows-Komponententechnologie COM – senkte die Einstiegshürde so weit, dass auch Fachanwender und Quereinsteiger funktionierende Software bauen konnten. Genau das erklärt sowohl die enorme Verbreitung als auch einen Teil der heutigen Probleme.
Drei Eigenschaften definieren VB6:
VB6 war in seiner Blütezeit allgegenwärtig. In unzähligen Unternehmen entstanden damit Warenwirtschaftssysteme, Datenbank-Frontends, Steuerungsoberflächen und interne Werkzeuge. Mit der Einführung der .NET-Plattform Anfang der 2000er entschied sich Microsoft jedoch für einen grundlegenden Technologiewechsel: Der Nachfolger Visual Basic .NET war keine Weiterentwicklung im engeren Sinn, sondern eine neue Sprache auf einer neuen Laufzeit, die zu VB6 nicht quellcodekompatibel ist. Damit begann der lange Abschied von VB6, dessen aktive Pflege und Verkauf Microsoft in den Folgejahren einstellte.
Für Unternehmen ist diese Vorgeschichte wichtig, weil sie den heutigen Status erklärt: VB6 ist keine Sprache, in die noch investiert wird, sondern ein technologisches Erbe, das verwaltet werden muss. Wer heute eine VB6-Anwendung betreibt, hält faktisch ein Stück Software aus einer abgeschlossenen Technologiegeneration am Leben – mit allen Konsequenzen für Wartbarkeit, Sicherheit und Zukunftsfähigkeit, die wir in diesem Artikel ausführlich behandeln.
Es klingt paradox: Eine seit Jahren abgekündigte Sprache ist im Mittelstand nach wie vor produktiv im Einsatz. Der Grund ist einfach und nachvollziehbar. Viele VB6-Anwendungen tun schlicht, was sie sollen – seit Jahren stabil, tief in Arbeitsabläufe eingebettet und mit hohem, über die Zeit gewachsenem Fachwissen ausgestattet. Solange eine solche Anwendung läuft und keinen akuten Handlungsdruck erzeugt, verschiebt sich ihre Ablösung in der Prioritätenliste immer wieder nach hinten.
Hinzu kommt, dass eine Neuentwicklung Geld, Zeit und Risiko bedeutet, während der Weiterbetrieb zunächst nichts zu kosten scheint. Diese Rechnung ist jedoch trügerisch: Die Kosten des Weiterbetriebs sind real, nur schlecht sichtbar – sie stecken in wachsenden Wartungsrisiken, in Abhängigkeit von einzelnen Wissensträgern und in der Gefahr, dass die Anwendung eines Tages auf einer neuen Windows-Umgebung nicht mehr läuft. Genau diese verdeckte Rechnung sauber zu machen, ist ein zentrales Ziel dieses Beitrags.
Das ereignisgesteuerte Modell ist das prägende Merkmal von VB6. Statt einen linearen Ablauf von oben nach unten zu programmieren, hinterlegt der Entwickler Code an einzelnen Ereignissen der Oberfläche: Was passiert beim Klick auf eine Schaltfläche, beim Verlassen eines Eingabefeldes, beim Laden eines Fensters. Für die Programmierung grafischer Benutzeroberflächen ist das ein sehr natürlicher Ansatz, weil er dem tatsächlichen Nutzungsverhalten entspricht – der Anwender löst Ereignisse aus, das Programm reagiert.
Die Kehrseite zeigt sich bei größeren Anwendungen. Weil Logik in vielen kleinen Ereignisprozeduren verteilt liegt und in VB6 häufig direkt mit der Oberfläche verwoben wurde, entstehen leicht unübersichtliche Programme, in denen fachliche Abläufe über Dutzende Formulare verstreut sind. Eine klare Trennung von Oberfläche, Geschäftslogik und Datenzugriff war zwar möglich, wurde in der Praxis aber oft nicht konsequent umgesetzt. Genau diese enge Verzahnung macht spätere Wartung und Migration aufwendig.
VB6 ist ohne die Komponententechnologie COM nicht zu verstehen. COM erlaubte es, Funktionalität in wiederverwendbare, registrierte Bausteine zu kapseln und aus verschiedenen Programmen anzusprechen. VB6 nutzte dies intensiv: Steuerelemente, Datenbankzugriffe und Erweiterungen kamen als COM-Komponenten hinzu, und VB6-Programme konnten selbst als COM-Bausteine für andere Anwendungen bereitgestellt werden. Das war eine mächtige Idee der Wiederverwendung.
Zugleich ist COM tief in Windows verankert und stützt sich auf die zentrale Registrierung von Komponenten im System. Das bindet VB6-Anwendungen fest an die Windows-Welt und erzeugt eine Klasse von Betriebsproblemen, die unter dem Stichwort Komponenten- und Versionskonflikte bekannt ist. Diese Abhängigkeit ist einer der Gründe, warum sich VB6-Anwendungen nicht einfach auf andere Plattformen übertragen lassen und warum ihre Modernisierung mehr ist als eine reine Sprachübersetzung.
VB6 kennt Klassen und Objekte und erlaubt damit eine gewisse Strukturierung von Code. Es fehlt jedoch ein zentrales Merkmal moderner objektorientierter Sprachen: die klassische Vererbung, mit der eine Klasse Eigenschaften und Verhalten von einer anderen erbt. Man ordnet VB6 deshalb als objektbasiert ein. Für die damalige Zielsetzung – schnelle Anwendungen mit überschaubarer Komplexität – war das ausreichend, für große, langlebige Systeme mit hohem Wiederverwendungsanspruch ist es eine spürbare Einschränkung.
Für die Migration ist dieser Punkt bedeutsam. Weil Nachfolgesprachen wie VB.NET und C# vollständig objektorientiert sind und auf einer völlig anderen Laufzeit aufsetzen, lässt sich VB6-Code nicht mechanisch übertragen. Vielmehr trifft ein objektbasiertes, ereignisgetriebenes Programm auf eine objektorientierte Welt – ein Umstand, der jede ernsthafte Modernisierung zu einem Stück Umbauarbeit macht und nicht zu einer bloßen Konvertierung.
Der augenfälligste Zug der VB6-Syntax ist ihre Nähe zur natürlichen Sprache. Schlüsselwörter wie Dim, If, Then, For, Next oder End Sub lesen sich beinahe wie Klartext, und die Sprache verzichtet weitgehend auf kryptische Symbole. Variablen werden mit Dim deklariert und mit As einem Typ zugeordnet. Diese Zugänglichkeit war ein Hauptgrund, warum VB6 auch für Menschen ohne formale Informatikausbildung erlernbar war – und warum viele Anwendungen von Fachanwendern und nicht von ausgebildeten Softwareentwicklern geschrieben wurden. Diese Herkunft prägt bis heute die Qualität vieler Bestandsanwendungen.
Das zentrale Bauelement einer VB6-Anwendung ist die Form – ein Fenster, das im visuellen Designer aus Steuerelementen wie Textfeldern, Schaltflächen, Listen und Rastern zusammengesetzt wird. Der Entwickler zieht diese Elemente per Maus auf die Fläche, stellt ihre Eigenschaften in einem Eigenschaftsfenster ein und hinterlegt anschließend Code an ihren Ereignissen. Oberfläche und Verhalten entstehen so unmittelbar nebeneinander, was die Entwicklung enorm beschleunigte und den Charakter von VB6 maßgeblich prägte.
Dieser Ansatz hat eine wichtige Konsequenz für die spätere Wartung. Weil die Oberfläche im Designer als eigenes Format gespeichert wird und der zugehörige Code eng daran hängt, sind Oberfläche und Logik in VB6-Projekten oft schwer voneinander zu trennen. Wer eine Anwendung modernisieren will, muss diese Verzahnung auflösen – die fachliche Logik aus den Formularen herauslösen und in eine saubere Struktur überführen. Das ist machbar, aber genau der Aufwand, den viele bei der Aufwandsschätzung unterschätzen.
VB6 bietet einige Sprachmerkmale, die aus heutiger Sicht kritisch zu sehen sind. Dazu gehört der besonders flexible, aber typunsichere Datentyp, der jeden beliebigen Wert aufnehmen kann und damit Fehler leicht bis in die Laufzeit verschleppt. Ebenso typisch ist die Fehlerbehandlung über Sprunganweisungen, die zwar funktioniert, aber zu schwer nachvollziehbarem Programmfluss führen kann. Und die Möglichkeit, Variablen ohne vorherige Deklaration zu verwenden, verführte in vielen Projekten zu unsauberem Code – auch wenn sich dieses Verhalten abschalten lässt.
Für sich genommen sind das keine dramatischen Mängel, und in disziplinierten Händen ließ sich auch mit VB6 sauberer Code schreiben. In der Praxis wurden diese Mittel jedoch häufig unkritisch genutzt, weil die Sprache eben gerade nicht zu strenger Struktur zwang. Das Ergebnis sind viele Bestandsanwendungen, deren innere Qualität stark schwankt – von solide gebaut bis kaum wartbar. Diese Bandbreite ist der Grund, warum eine ehrliche technische Bewertung am Anfang jeder Modernisierungsüberlegung stehen sollte.
Die Visual-Basic-6-Entwicklungsumgebung vereinte alles Nötige unter einem Dach: den Formulardesigner zum Zusammensetzen der Oberflächen, den Code-Editor, das Eigenschaftsfenster, einen Debugger zum schrittweisen Durchlaufen des Programms sowie Werkzeuge zum Erzeugen ausführbarer Dateien und Installationspakete. Diese Integration war für ihre Zeit vorbildlich und erklärt einen großen Teil der Produktivität: Man konnte eine Idee entwerfen, umsetzen, testen und ausliefern, ohne das Werkzeug zu wechseln.
Aus heutiger Sicht ist genau diese IDE jedoch ein Problem, denn sie ist selbst ein abgekündigtes Produkt aus einer vergangenen Windows-Generation. Sie auf modernen Systemen überhaupt lauffähig zu halten, ist bereits eine Herausforderung, und offizielle Unterstützung gibt es nicht mehr. Wer VB6-Code pflegen muss, hält damit nicht nur die Anwendung, sondern auch das Werkzeug künstlich am Leben – ein doppeltes Altlastproblem, das bei der Bewertung mitgedacht werden muss.
Rund um VB6 entstand ein reiches Ökosystem aus COM- und ActiveX-Komponenten. Zusätzliche Steuerelemente wurden häufig als sogenannte OCX-Dateien bereitgestellt und ließen sich in Projekte einbinden, um Funktionen wie erweiterte Tabellen, Diagramme, Kalender oder Report-Werkzeuge zu ergänzen. Viele dieser Komponenten stammten von Drittanbietern und deckten Spezialaufgaben ab, für die keine eigene Entwicklung nötig war. Diese Komponentenkultur war ein echter Produktivitätshebel.
Sie ist jedoch zugleich eine der größten Modernisierungshürden. Zahlreiche dieser Drittkomponenten werden längst nicht mehr gepflegt, ihre Hersteller existieren teils nicht mehr, und ihre Lauffähigkeit unter aktuellen Windows-Versionen ist unsicher. Kommt eine VB6-Anwendung ohne solche externen Komponenten aus, ist ihre Zukunft deutlich einfacher zu sichern; hängt sie an mehreren nicht mehr verfügbaren OCX-Bausteinen, steigt der Aufwand jeder Modernisierung erheblich. Die Bestandsaufnahme dieser Abhängigkeiten ist daher ein Pflichtschritt.
Beim Datenbankzugriff setzten VB6-Anwendungen typischerweise auf Microsoft-Technologien wie DAO und vor allem ADO, mit denen sich Verbindungen zu Datenbanken herstellen und Daten abfragen und schreiben ließen. Sehr häufig war die Kombination aus VB6 als Oberfläche und einer Microsoft-Access- oder SQL-Server-Datenbank im Hintergrund – ein Muster, das in unzähligen mittelständischen Fachanwendungen bis heute anzutreffen ist. Die Datenhaltung ist bei einer Migration oft der stabilere, leichter zu erhaltende Teil.
Ein eigenes, wiederkehrendes Thema ist die Verteilung. Weil VB6-Anwendungen die Runtime und ihre COM-Komponenten auf dem Zielrechner benötigen und diese im System registriert werden müssen, waren Installation und Aktualisierung fehleranfällig. Konflikte zwischen verschiedenen Versionen gemeinsam genutzter Bibliotheken sind unter dem Stichwort der Bibliotheks-Konflikte bekannt geworden. In modernen Umgebungen mit strengeren Rechte- und Sicherheitsmodellen verschärfen sich diese Verteilungsfragen zusätzlich.
In der Beratungspraxis begegnet uns VB6 selten dort, wo man es vermuten würde, sondern meist an den unauffälligen, aber betriebswichtigen Stellen. Es sind die über Jahre gewachsenen Eigenentwicklungen, die genau auf einen speziellen Betriebsablauf zugeschnitten sind und für die es kein passendes Standardprodukt gibt. Gerade weil sie so genau passen und zuverlässig laufen, fallen sie im Alltag kaum auf – bis eine Änderung ansteht oder die Umgebung sich verändert.
Konkrete Marktzahlen zur Verbreitung von VB6 sind mit Vorsicht zu genießen und veralten schnell; belastbar ist vor allem die Beobachtung, dass VB6-Anwendungen in vielen Branchen des Mittelstands nach wie vor produktiv im Einsatz sind. Für ein einzelnes Unternehmen ist ohnehin nicht die allgemeine Statistik entscheidend, sondern die eigene Landschaft: Welche VB6-Anwendungen gibt es im Haus, wie kritisch sind sie, und wer kann sie noch pflegen? Diese Fragen lassen sich nur durch eine gezielte Bestandsaufnahme beantworten.
Das Überleben von VB6-Anwendungen folgt einer nachvollziehbaren Logik. Erstens funktionieren sie – oft seit vielen Jahren stabil und ohne Anlass zur Änderung. Zweitens steckt in ihnen wertvolles, teils undokumentiertes Fachwissen über konkrete Abläufe, das bei einer Neuentwicklung mühsam rekonstruiert werden müsste. Drittens fehlte bislang der akute Handlungsdruck, während eine Ablösung mit sichtbaren Kosten und Risiken verbunden gewesen wäre.
Diese Beharrungskräfte sind rational, führen aber zu einer gefährlichen Verzögerung. Je länger eine Anwendung unangetastet läuft, desto mehr verblasst das Wissen über ihren Aufbau, desto schwerer wird ihre Weiterentwicklung – und desto härter trifft es das Unternehmen, wenn ein äußerer Anlass die Ablösung plötzlich erzwingt. Das ist der Kern des Legacy-Risikos, das wir in den folgenden Kapiteln systematisch auffächern.
Wichtig ist zunächst eine Unterscheidung, die in der Praxis oft durcheinandergeht: Es gibt einen Unterschied zwischen der VB6-Sprache und -Entwicklungsumgebung einerseits und der VB6-Laufzeitumgebung andererseits. Erstere – also das Werkzeug, mit dem VB6-Programme geschrieben und kompiliert werden – ist ein abgekündigtes Produkt ohne Weiterentwicklung. Die Laufzeitumgebung dagegen, die zum Ausführen bestehender VB6-Programme nötig ist, wurde über einen sehr langen Zeitraum als Bestandteil unterstützter Windows-Versionen mitgeliefert. Beide Aspekte haben unterschiedliche Konsequenzen.
Für die VB6-Sprache und ihre Entwicklungsumgebung gilt: Der reguläre Support ist längst ausgelaufen. Es gibt keine neuen Versionen, keine funktionalen Verbesserungen und keine reguläre Fehlerbehebung mehr. Wer VB6-Code entwickelt oder pflegt, arbeitet mit einem eingefrorenen Werkzeugstand aus einer vergangenen Technologiegeneration. Neue Sprachfeatures, moderne Sicherheitskonzepte oder Anpassungen an aktuelle Betriebssysteme sind für die Entwicklungsseite nicht mehr zu erwarten.
Das bedeutet in der Praxis: Jede inhaltliche Weiterentwicklung einer VB6-Anwendung findet auf einem stillstehenden Fundament statt. Man kann Änderungen vornehmen, solange die Werkzeuge lauffähig gehalten werden – aber man bewegt sich in einer Sackgasse, die keine Zukunftsperspektive mehr eröffnet. Diese Einsicht ist entscheidend für strategische Entscheidungen: Investitionen in den weiteren Ausbau einer VB6-Anwendung sollten wohlüberlegt sein, weil sie in eine Technologie ohne Weiterentwicklung fließen.
Für den reinen Betrieb bestehender Anwendungen ist die Lage etwas günstiger, aber keineswegs sorgenfrei. Die VB6-Laufzeitumgebung wurde über sehr lange Zeit als Teil des Windows-Betriebssystems mitgeliefert und unterstützt, sodass viele VB6-Programme bis heute unter aktuellen Windows-Versionen starten. Das darf jedoch nicht mit einer dauerhaften Garantie verwechselt werden. Der genaue, jeweils aktuelle Support-Status der Laufzeitumgebung sollte unbedingt an der offiziellen Herstellerdokumentation geprüft werden, da sich Support-Zusagen ändern können und an bestimmte Windows-Versionen gebunden sind.
Selbst wenn die Kern-Laufzeit läuft, ist damit nicht gesagt, dass eine komplette VB6-Anwendung funktioniert. Denn die meisten Programme hängen zusätzlich von COM- und ActiveX-Komponenten ab, deren Kompatibilität mit aktuellen Windows-Versionen jeweils gesondert zu prüfen ist. Die praktische Faustregel lautet daher: Verlassen Sie sich nicht auf Vermutungen, sondern testen Sie jede geschäftskritische VB6-Anwendung explizit auf der Zielumgebung, bevor ein Betriebssystem- oder Serverwechsel ansteht.
Das größte und am meisten unterschätzte Risiko ist der schleichende Verlust von Wissen. VB6-Anwendungen entstanden oft vor vielen Jahren, teils von Mitarbeitern, die längst im Ruhestand oder nicht mehr im Unternehmen sind. Dokumentation ist häufig lückenhaft oder fehlt ganz, und das Verständnis für den inneren Aufbau der Software konzentriert sich nicht selten auf eine einzige Person. Fällt dieser Wissensträger aus, wird selbst eine kleine Änderung zum Risiko – im schlimmsten Fall traut sich niemand mehr an die Anwendung heran.
Verschärft wird dies durch den schrumpfenden Arbeitsmarkt für VB6-Kompetenz. Neue Entwickler werden nicht mehr in dieser Technologie ausgebildet, und erfahrene VB6-Fachkräfte gehen nach und nach in den Ruhestand. Die Folge ist eine doppelte Verknappung: Das interne Wissen erodiert, und externe Unterstützung wird teurer und schwerer zu finden. Wer heute eine kritische VB6-Anwendung betreibt, sollte diese personelle Abhängigkeit als reales Betriebsrisiko einstufen und aktiv gegensteuern.
Beim Thema Sicherheit ist zu unterscheiden zwischen der Sprache und ihrem Umfeld. Da für die VB6-Entwicklungswerkzeuge keine regulären Aktualisierungen mehr erscheinen, werden dort auftretende Probleme nicht mehr durch den Hersteller behoben. Ein größeres praktisches Risiko geht jedoch von den eingebundenen, teils sehr alten Drittkomponenten aus: Nicht mehr gepflegte COM- und ActiveX-Bausteine können Schwachstellen enthalten, für die es keine Korrekturen mehr gibt. Ebenso kritisch sind veraltete Datenzugriffs- und Systembibliotheken, auf denen viele Anwendungen aufsetzen.
Hinzu kommt, dass ältere Anwendungen häufig nicht nach heutigen Sicherheitsmaßstäben entworfen wurden – etwa im Umgang mit Zugangsdaten, in der Absicherung von Datenbankzugriffen oder in der Rechtevergabe. In einer zunehmend vernetzten und regulierten IT-Landschaft ist das ein Faktor, der nicht ignoriert werden darf. Wo eine VB6-Anwendung mit sensiblen Daten arbeitet oder mit anderen Systemen kommuniziert, gehört ihr Sicherheitszustand ausdrücklich auf den Prüfstand.
Ein technisch besonders greifbares Risiko ergibt sich aus der Entwicklung der Windows-Umgebung selbst. VB6 erzeugt 32-Bit-Anwendungen; eine native 64-Bit-Kompilierung ist nicht vorgesehen. In der Praxis laufen 32-Bit-Programme auf 64-Bit-Windows zwar über eine Kompatibilitätsschicht, doch ergeben sich immer wieder Probleme an den Rändern – etwa bei der Anbindung von Treibern, bei 64-Bit-Datenbanktreibern oder beim Zusammenspiel mit anderen, ausschließlich in 64 Bit vorliegenden Komponenten. Solche Konstellationen können dazu führen, dass eine bislang stabile Anwendung nach einem Umgebungswechsel plötzlich nicht mehr funktioniert.
Allgemeiner formuliert: VB6-Anwendungen sind eng an eine bestimmte Windows-Umgebung gebunden, und jeder größere Wechsel – ein neues Betriebssystem, ein neuer Server, eine Virtualisierung, geänderte Sicherheitsrichtlinien – ist ein potenzieller Bruchpunkt. Dieses Risiko ist tückisch, weil es lange schlummert und dann durch ein von außen kommendes Ereignis schlagartig akut wird. Genau deshalb sollte die Ablösung nicht erst dann geplant werden, wenn der Umgebungswechsel bereits vor der Tür steht.
Grundsätzlich stehen drei Wege offen. Das bewusste Weiterbetreiben ist für stabile, unkritische Anwendungen mit geringer Änderungshäufigkeit eine legitime Zwischenlösung – allerdings nur, wenn Risiken, Zuständigkeiten und ein Notfallplan geklärt sind und der Weg nicht mit Nichtstun verwechselt wird. Die Migration überführt die bestehende Anwendung in eine moderne Zielplattform, wobei fachliche Logik und Bewährtes erhalten bleiben sollen. Die Neuentwicklung baut die Anwendung von Grund auf neu, meist auf einer modernen Architektur und oft mit erweitertem Funktionsumfang.
Welcher Weg der richtige ist, hängt von der einzelnen Anwendung ab: von ihrer Geschäftskritikalität, ihrem Zustand, ihrer Größe und davon, wie sehr sich die fachlichen Anforderungen seit ihrer Entstehung verändert haben. Für eine kleine, saubere Anwendung, die im Kern gut passt, kann eine Migration nach VB.NET der pragmatische Weg sein. Für eine große, gewachsene Anwendung, deren Anforderungen sich stark gewandelt haben, ist eine Neuentwicklung – etwa in C# und gegebenenfalls mit Web-Oberfläche – häufig die nachhaltigere Investition.
Für die Migration existieren Werkzeuge, die VB6-Code teilweise automatisiert in VB.NET überführen. Solche Konverter können den Einstieg erleichtern und mechanische Arbeit abnehmen, sie haben aber klare Grenzen. Weil VB6 objektbasiert und ereignisgetrieben ist, die .NET-Welt dagegen objektorientiert, führt eine reine Konvertierung oft zu Code, der zwar kompiliert, aber unschöne Altstrukturen einfach in die neue Umgebung verschleppt. Nicht mehr verfügbare Drittkomponenten lassen sich zudem nicht automatisch ersetzen und müssen ohnehin von Hand angegangen werden.
In unseren Projekten hat sich daher ein zweistufiger Blick bewährt: Eine automatisierte Konvertierung kann sinnvoll sein, um schnell auf eine unterstützte Plattform zu kommen und akuten Handlungsdruck zu nehmen. Die eigentliche Modernisierung – saubere Trennung von Oberfläche, Logik und Datenzugriff, Ablösung veralteter Komponenten, gegebenenfalls neue Architektur – ist dagegen echte Ingenieurarbeit, die sich nicht automatisieren lässt. Wer den ersten Schritt mit dem zweiten verwechselt, riskiert, das Legacy-Problem nur auf eine neue Plattform zu verschieben.
Unabhängig vom gewählten Zielweg empfiehlt sich ein schrittweises, risikoarmes Vorgehen. Es beginnt mit einer verlässlichen Bestandsaufnahme und endet mit einem kontrollierten Umstieg – statt mit einem riskanten Rundumschlag, bei dem eine geschäftskritische Anwendung in einem großen Sprung ersetzt wird.
Am Anfang steht immer eine ehrliche Bestandsaufnahme. Viele Unternehmen wissen gar nicht genau, wie viele VB6-Anwendungen bei ihnen laufen, wie kritisch diese sind und wer sie noch pflegen kann. Eine schlichte Übersicht – welche Anwendungen existieren, welchen Zweck erfüllen sie, wie geschäftskritisch sind sie, in welchem Zustand befinden sie sich und wovon hängen sie ab – ist die wertvollste erste Investition. Sie kostet wenig, schafft aber die Grundlage für jede weitere Entscheidung und verwandelt ein diffuses Unbehagen in eine steuerbare Aufgabe.
Wichtig ist dabei, nicht nur auf die Technik zu schauen, sondern auch auf die menschliche Seite: Wer kennt die jeweilige Anwendung, und was passiert, wenn diese Person nicht mehr verfügbar ist? Diese Wissensfrage ist oft dringlicher als die rein technische Bewertung, weil sich fehlendes Wissen kurzfristig kaum ersetzen lässt. Wo eine kritische Anwendung an einem einzigen Kopf hängt, sollte die Sicherung dieses Wissens Vorrang haben – notfalls unabhängig von der Frage einer späteren Migration.
Nicht jede VB6-Anwendung muss – oder sollte – sofort abgelöst werden. Der Schlüssel liegt in einer nüchternen Priorisierung entlang zweier Achsen: Wie hoch ist das Risiko (schlechter Zustand, kritische Abhängigkeiten, drohender Umgebungswechsel, fehlendes Wissen), und wie hoch ist der Geschäftswert oder die Kritikalität der Anwendung? Anwendungen mit hohem Risiko und hoher Kritikalität gehören nach vorn in die Warteschlange, während stabile, unkritische Programme bewusst und dokumentiert weiterlaufen dürfen.
Diese Priorisierung verhindert zwei typische Fehler: den blinden Aktionismus, bei dem knappe Ressourcen in die Ablösung unwichtiger Anwendungen fließen, und das gefährliche Aussitzen, bei dem gerade die riskanten, kritischen Anwendungen liegen bleiben, bis ein äußeres Ereignis die Entscheidung erzwingt. Ein einfaches Risiko-Wert-Portfolio ist ein wirksames Steuerungsinstrument, das sich auch ohne großen Aufwand pflegen lässt und Entscheidungen nachvollziehbar macht.
Wenn eine Ablösung ansteht, sollte sie als geplante Modernisierung und nicht als Notoperation erfolgen. Der günstigste Zeitpunkt für die Planung ist, bevor der Handlungsdruck akut wird – also solange die Anwendung noch stabil läuft und Wissen verfügbar ist. Wer die Ablösung frühzeitig und mit Augenmaß angeht, kann sie in verkraftbare Schritte zerlegen, das vorhandene Fachwissen sichern und die Gelegenheit nutzen, veraltete Strukturen und offene Wünsche gleich mit zu adressieren.
Ebenso wichtig ist, aus den Fehlern der Vergangenheit zu lernen: Die neue Lösung sollte so gebaut, dokumentiert und verantwortet werden, dass sie nicht in einigen Jahren selbst zur unwartbaren Altlast wird. Klare Zuständigkeiten, saubere Trennung von Oberfläche, Logik und Daten, nachvollziehbare Dokumentation und eine bewusste Wahl zukunftsfähiger Technologien sind die beste Versicherung dagegen, dass sich die VB6-Geschichte mit einer anderen Technologie wiederholt.
