VB6 läuft 2026 noch, doch der Build ist das Risiko

Eine VB6-Anwendung, die unter Windows 11 startet, hat genau eine eng begrenzte Sache bewiesen: Ihre aktuelle ausführbare Datei findet genug von ihrer Laufzeitumgebung, um zu starten. Sie hat nicht bewiesen, dass sich die Anwendung neu bauen, reparieren, auf einem sauberen Rechner installieren oder nach einem Festplattenausfall wiederherstellen lässt. Das sind getrennte Fähigkeiten, und die meisten lang betriebenen VB6-Systeme haben nur die erste getestet.

Das gefährliche Datum ist nicht der Tag, an dem Windows die EXE nicht mehr ausführt. Es ist der Tag, an dem der letzte Rechner mit dem richtigen Compiler, Service Pack, den passenden OCX-Dateien, Typbibliotheken, Registry-Einstellungen, dem richtigen Quellstand, Installer-Projekt, Datenbanktreiber und Wissen des Bedieners nicht mehr startet. Dann kann eine fachliche Änderung von einer Zeile zum Wiederherstellungsprojekt werden. Betrachten Sie die laufende Anwendung als Beweismaterial, das gesichert werden muss, nicht als Beweis dafür, dass kein Problem besteht.

Laufzeitunterstützung macht die VB6-Entwicklung nicht unterstützt

Microsoft unterstützt die zentrale VB6-Laufzeit weiterhin auf unterstützten Windows-Versionen, aber nicht die VB6-IDE. Dieser Unterschied erklärt, warum alte Anwendungen weiterlaufen und ihre Wartung dennoch jedes Jahr schwieriger wird. Microsofts Support Statement für Visual Basic 6.0 nennt It Just Works als Kompatibilitätsziel für bestehende Anwendungen. Dasselbe Dokument sagt, dass die Entwicklung mit der IDE seit 2008 nicht mehr unterstützt wird, und empfiehlt den Ersatz von VB6-Anwendungen durch moderne Technik.

Der Umfang dieser Unterstützung ist außerdem enger, als viele Führungskräfte annehmen. Microsoft beschränkt die Pflege der Laufzeit auf schwerwiegende Regressionen und kritische Sicherheitsprobleme in bestehenden Anwendungen. Das ist keine Zusage, dass ein alter Installer, ein Steuerelement eines Drittanbieters, ein aufgegebener Datenbankprovider oder der Compiler auf jedem künftigen Arbeitsplatz funktioniert. Microsoft unterscheidet die mit Windows ausgelieferten Kerndateien der Laufzeit, unterstützte erweiterte Dateien, die eine Anwendung selbst verteilen muss, nicht unterstützte Dateien und Komponenten von Drittanbietern unter den Bedingungen ihrer jeweiligen Hersteller.

Ein grüner Windows-Kompatibilitätstest beantwortet die technische Frage deshalb nicht. Er sagt, dass diese Binärdatei mit dieser Sammlung von Abhängigkeiten während dieses Tests lief. Er sagt nichts darüber, ob der Quellcode diese Binärdatei noch erzeugt. Eine kompilierte Anwendung kann jahrelang stabil bleiben, während die Änderbarkeit unbemerkt verschwindet.

Bei einer Bestandsaufnahme verwende ich vier getrennte Zustände: lauffähig, installierbar, baubar und erklärbar. Lauffähig heißt, dass eine vorhandene Installation startet. Installierbar heißt, dass sich die Anwendung aus kontrollierten Medien auf einem sauberen, unterstützten Windows-Abbild einrichten lässt. Baubar heißt, dass kontrollierter Quellcode eine nachvollziehbare Binärdatei erzeugt. Erklärbar heißt, dass das Team die externen Systeme, Dateiformate und Fachregeln kennt. Wer alle vier Zustände unterstützt nennt, versteckt genau das Risiko, das die Prüfung aufdecken soll.

Die EXE braucht weit mehr als MSVBVM60.dll

Eine typische VB6-EXE hängt von der 32-Bit-Laufzeit, der COM-Registrierung, ActiveX-Steuerelementen, Datenzugriffsprovidern, Konfiguration außerhalb des Repositorys und Annahmen über den Host-Rechner ab. Die tatsächliche Menge ist oft größer als die Liste in der Projektdatei, weil VB6-Code Objekte über ProgID erzeugt, Plugins nach Konvention lädt, Hilfsprogramme startet und Pfade aus Registry oder INI-Dateien liest.

Beginnen Sie an der kompilierten Grenze. VB6 erzeugt normalerweise nativen 32-Bit-Code oder P-Code, und auch die Laufzeitdateien bleiben 32-Bit. Unter 64-Bit-Windows läuft der Prozess in WOW64. Jede prozessintern geladene DLL oder OCX braucht daher einen kompatiblen 32-Bit-Build. Ein unter einem ähnlichen Namen registrierter 64-Bit-Ersatz erfüllt die Anforderung eines 32-Bit-COM-Clients nicht. Die Bitbreite gehört zur Schnittstelle, auch wenn sie im Quellcode nirgends steht.

Berücksichtigen Sie danach die COM-Identität. VB6-Projekte verweisen über GUID, Version und Klassenidentität auf Typbibliotheken und Komponenten. Die Registry ordnet diese Identitäten einem physischen Server zu. Eine OCX neben die EXE zu kopieren, registriert sie nicht zwingend. Der falsche registrierte Build kann eine Anwendung reparieren und zugleich eine andere beschädigen. Einstellungen zur Binärkompatibilität im VB6-Projekt bestimmen außerdem, ob eine neu gebaute DLL Klassen- und Schnittstellen-IDs für ihre Aufrufer bewahrt. Ein unvorsichtiger Build kann sauber kompilieren und trotzdem jeden Client aussperren.

Der Datenzugriff bringt eine weitere Schicht. Anwendungen können ADO, DAO, RDO, ODBC-DSNs, Jet-Datenbanken, proprietäre Datenbankclients oder erst zur Laufzeit zusammengesetzte Providernamen verwenden. Eine Verbindungszeichenfolge im Quellcode ist nur ein Teil der Abhängigkeit. Rechnerweite DSNs, Aliase, Clientbibliotheken, Zertifikate und Dienstkonten können vollständig außerhalb der Versionsverwaltung liegen. Gebietsschema-Einstellungen beeinflussen mitunter Dezimalzahlen, Datumswerte und Sortierung. Druckertreiber können den Seitenumbruch von Berichten verändern. Alte Desktopsoftware macht den Zustand des Arbeitsplatzes gern zum Zustand der Anwendung.

Prüfen Sie schließlich die scheinbar unwichtigen Dateien: .vbp, .vbw, .res, .frx, .ctl, .ctx, .dsr, .pag, Installer-Skripte und Kompatibilitätsbinärdateien. Einer Formulardatei ohne passende .frx können eingebettete Bilder oder Steuerdaten fehlen. Ein Projekt mit einem Verweis auf eine Binärkompatibilitäts-DLL auf dem Laufwerk eines Entwicklers kann neue COM-Identitäten erzeugen, wenn diese Datei weg ist. Quellcode allein ist kein Build-Archiv.

Windows 11 trägt eine 32-Bit-Kompatibilitätsinsel

VB6-Anwendungen laufen unter aktuellem 64-Bit-Windows, weil Microsoft die Kernlaufzeit ausliefert und testet und Windows mit WOW64 eine Umgebung für 32-Bit-Prozesse bereitstellt. Dahinter steckt bewusste Kompatibilitätsarbeit, nicht die Rückkehr von VB6 als aktuelle Entwicklungsplattform. Laufzeit, IDE und jede externe Komponente haben verschiedene Eigentümer und Unterstützungsstände.

WOW64 erklärt auch mehrere verwirrende Pfade. Ein 32-Bit-Prozess, der auf das Systemverzeichnis zugreift, kann umgeleitet werden, und die 32-Bit-COM-Registrierung erscheint über den 32-Bit-Registry-Pfad. Administratoren, die das 64-Bit-regsvr32 für eine 32-Bit-OCX verwenden, erhalten einen Fehler oder registrieren die falsche Komponentenumgebung. Auf einem 64-Bit-System liegt das 32-Bit-Registrierungswerkzeug normalerweise unter SysWOW64, trotz des Namens. Diese historische Bezeichnung hat schon viele Wartungsfenster verschwendet.

Kopieren Sie nicht wahllos DLLs in Systemverzeichnisse, bis das Programm startet. Das verändert den globalen Rechnerzustand, ohne festzuhalten, welcher Anwendung die Datei gehört, welche Version gewonnen hat und wie sich das Ergebnis wiederholen lässt. Paketieren Sie genau die weiterverteilbaren Abhängigkeiten, zu deren Verteilung Sie berechtigt sind, installieren Sie sie nachvollziehbar und testen Sie auf einem sauberen Abbild. Braucht die Anwendung ein nicht unterstütztes Steuerelement eines Drittanbieters, gehört das als Migrationsbedingung in die Dokumentation. Die Unterstützung der Kernlaufzeit deckt es nicht ab.

Serverbereitstellungen brauchen eine weitere Prüfung. Microsofts Support Statement beschränkt die dort aufgeführte Unterstützung von Windows Server auf 64-Bit-Ausgaben und schließt Server Core für VB6 aus. Eine Desktop-EXE, die unter WOW64 auf einer vollständigen Serverinstallation läuft, gehört deshalb nicht automatisch in ein kopfloses Server-Core-Abbild. Die unterstützte Host-Grenze muss in der Bereitstellungsakte der Anwendung stehen.

Erstellen Sie das Abhängigkeitsverzeichnis aus Belegen

Ein brauchbares Abhängigkeitsverzeichnis verbindet statische Referenzen, Rechnerzustand und beobachtetes Verhalten. Keine dieser Quellen reicht allein. Projektdateien zeigen deklarierte Referenzen, die Registry zeigt die Auflösung auf dem Build-Rechner, und die Laufzeitbeobachtung findet spät gebundene Objekte und externe Prozesse. Sichern Sie alle drei, solange der bekannte gute Rechner funktioniert.

Führen Sie auf dem Build-Rechner diese Befehle in PowerShell aus und speichern Sie die Ausgaben zusammen mit dem Quellcode-Abzug:

Get-ChildItem -Recurse -Include *.vbp,*.mak |
  Select-String -Pattern '^(Reference|Object)=' |
  ForEach-Object { '{0}:{1}:{2}' -f $_.Path,$_.LineNumber,$_.Line } |
  Set-Content declared-com-references.txt

Get-ChildItem -Recurse -Include *.vbp |
  ForEach-Object { Get-FileHash $_.FullName -Algorithm SHA256 } |
  Export-Csv project-hashes.csv -NoTypeInformation

Get-CimInstance Win32_Product |
  Select-Object Name,Version,Vendor |
  Export-Csv installed-products.csv -NoTypeInformation

Die erste Ausgabe enthält für jede deklarierte Zeile Reference= oder Object= die Quelldatei und Zeilennummer. Die zweite liefert einen Hash für jede Projektdatei. Die Produktliste ist unvollständig, weil nicht jede Abhängigkeit den Windows Installer nutzt, bietet aber einen Vergleichspunkt. Führen Sie Win32_Product nicht wiederholt auf Produktionsrechnern aus, denn der Aufruf kann Konsistenzprüfungen des Installers auslösen. Hier geht es um eine einmalige Erfassung auf dem isolierten Build-Arbeitsplatz.

Ergänzen Sie Metadaten für jede tatsächlich referenzierte DLL und OCX: ursprünglicher Pfad, SHA-256-Hash, Datei- und Produktversion, Signaturgeber, Architektur, Lizenzquelle und Weiterverteilungsstatus. Exportieren Sie die einschlägigen 32-Bit-COM-Registry-Einträge erst, nachdem Sie jede GUID aus dem Projekt aufgelöst haben. Erfassen Sie Versionen von Datenbankclients, ODBC-Treiber und DSNs, Umgebungsvariablen, Schriftarten, Regionseinstellungen, Druckertreiber, geplante Aufgaben, Freigaben und Dienstkonten. Geheimnisse gehören in den Secret Store, nicht in das Verzeichnis. Dort stehen Name und Eigentümer des Geheimnisses, aber nicht sein Wert.

Beobachten Sie dann einen repräsentativen Durchlauf mit einem Werkzeug für Datei- und Registry-Aktivität. Testen Sie Start, Anmeldung, eine normale Transaktion, Importe, Exporte, Berichte, Drucken, Fehlerbehandlung und Beenden. Vergleichen Sie beobachtete Datei-, Registry-, Netzwerk- und Prozesszugriffe mit dem deklarierten Bestand. Jede spät gebundene ProgID, Hilfs-EXE, jedes Netzlaufwerk und jedes beschreibbare Installationsverzeichnis, das nur zur Laufzeit erscheint, gehört in das Verzeichnis.

Beenden Sie die Arbeit mit einer Installation im Reinraum. Beginnen Sie mit einem kurzlebigen, unterstützten Windows-Abbild, installieren Sie nur dokumentierte Voraussetzungen, richten Sie die Anwendung ein und führen Sie den Abnahmepfad aus. Muss ein Entwickler ein Steuerelement von einem alten Arbeitsplatz holen oder einen nicht dokumentierten Registrierungsbefehl erinnern, ist die Anwendung noch nicht installierbar. Dokumentieren Sie die Lücke, statt das Abbild von Hand zu reparieren und den Test für abgeschlossen zu erklären.

Wenn der letzte Build-Rechner stirbt, reicht Quellcode nicht

Fällt der einzige nachweislich funktionierende Build-Rechner aus, verliert das Team eine aufgelöste Umgebung und nicht bloß einen Computer. Für den Wiederaufbau muss es herausfinden, welche Compiler-Medien und Service Packs eingesetzt wurden, welche Komponenten lizenziert waren, wie Referenzen aufgelöst wurden, welche Binärkompatibilitätsdateien COM-Identitäten festhielten, welche Vor- und Installer-Schritte liefen und ob das Repository den Quellstand der Produktion enthält.

Das erste Symptom erscheint meist bei einer dringenden Änderung. Eine Steuerregel, ein Endpunkt, Zertifikat, eine Kennwortrichtlinie der Datenbank oder ein Dateiformat ändert sich. Ein Entwickler installiert die IDE in einer virtuellen Maschine, öffnet das Projekt, bestätigt einige Dialoge über fehlende Referenzen, ersetzt ein nicht verfügbares Steuerelement und kompiliert erfolgreich. Die neue EXE startet und geht in Produktion. Später scheitert ein selten verwendetes Formular, weil das Ersatz-Steuerelement Eigenschaften anders serialisiert, oder ein COM-Client kann eine neu gebaute Klasse wegen geänderter Schnittstellenidentität nicht erzeugen. Erfolgreiche Kompilierung wurde mit Verhaltensgleichheit verwechselt.

Lizenzierte ActiveX-Steuerelemente erschweren die Wiederherstellung weiter. Manche brauchen Designzeit-Lizenzeinträge, um in der IDE zu laden, obwohl die kompilierte Anwendung mit einer Laufzeitlizenz arbeitet. Der Hersteller kann verschwunden und die Aktivierung abgeschaltet sein. Das Kopieren einer installierten OCX kann die Lizenz verletzen oder Registry-Daten auslassen. Kein technischer Trick ersetzt fehlende Rechte. Klären Sie Eigentum und Weiterverteilungsbedingungen, solange Beschaffungsunterlagen und Erinnerungen noch vorhanden sind.

Ein Abbild des Build-Arbeitsplatzes hilft, ist aber keine vollständige Antwort. Abbilder enthalten verborgenen Zustand, Zugangsdaten, ein Schadsoftware-Risiko und ein Betriebssystem, das irgendwann nicht mehr sicher ans Netz darf. Sie beweisen auch nicht, dass ein sauberer Checkout baut. Bewahren Sie ein beschränkt zugängliches Abbild als Beleg und Notbrücke auf, und erstellen Sie danach einen skriptgesteuerten, isolierten Build aus kontrollierten Eingaben. Wenn der Build ohne Abbild nicht reproduzierbar ist, gehört genau das ins Risikoregister.

Dekompilierung ist eine Rettungstechnik für den Notfall, kein Ersatz für Versionsverwaltung. Native Binärdateien verlieren Namen und Struktur, P-Code bietet andere Möglichkeiten der Wiedergewinnung, und keiner der beiden Wege stellt Kommentare, Build-Skripte, ursprüngliche Formulare oder Entwurfsabsicht zuverlässig wieder her. Vielleicht lässt sich genug Verhalten zur Fehleranalyse retten. Eine geplante Modernisierung darf nicht von der Hoffnung abhängen, aus der Binärdatei wieder das ursprüngliche Projekt zu erzeugen.

Sichern Sie den Build vor jeder Anwendungsänderung

Der sicherste erste Schritt besteht darin, den aktuellen Build einzufrieren und zu reproduzieren, ohne diese Arbeit mit Funktionen oder Migrationsänderungen zu vermischen. Sie brauchen eine Basis, an der sich Eingaben, Toolchain, Ausgaben und Verhalten vergleichen lassen. Wer Code während der Rekonstruktion der Umgebung ändert, zerstört den Bezugspunkt.

Sichern Sie diese Dinge als ein kontrolliertes Paket:

1. Den vollständigen Repository-Stand einschließlich Formularressourcen, Installer-Quellen und Referenzen für Binärkompatibilität.
2. Installationsmedien, Service Packs, weiterverteilbare Steuerelemente, Lizenzbelege und Prüfsummen.
3. Eine Rechnerinventur und ein beschränkt zugängliches Abbild des bekannten guten Arbeitsplatzes.
4. Genaue Build-Befehle, Projektreihenfolge, Symbole für bedingte Kompilierung und Paketierungsschritte.
5. Hashes der Produktionsbinärdateien und einen signierten Nachweis, welcher Build wo bereitgestellt ist.

Führen Sie nun in einer isolierten virtuellen Maschine einen sauberen Checkout und Build aus. Lassen Sie den Netzwerkzugriff abgeschaltet, sofern ihn keine dokumentierte Build-Eingabe erfordert. Vergleichen Sie Ausgabedateien, exportierte COM-Schnittstellen und Installer-Inhalte. Wegen Zeitstempeln und Compiler-Metadaten ist bytegenaue Gleichheit nicht immer möglich. Definieren Sie daher vor der Abnahme, was Gleichheit bedeutet. Prüfen Sie mindestens Dateiversionen, Abhängigkeiten, Klassenidentitäten und Verhalten in der Abnahmesuite.

Führen Sie für jeden Versuch einen kleinen Build-Datensatz. Er kann als JSON, CSV oder signiertes Textdokument vorliegen, sollte aber Quellrevision, Kennung des Umgebungsabbilds, Hashes von Werkzeugen und Abhängigkeiten, Befehle, Bediener, Zeitstempel, Ausgabe-Hashes und Testergebnis enthalten. Es geht um Nachvollziehbarkeit. Ein anderer Entwickler muss auch sechs Monate später erkennen können, was eine EXE erzeugt hat, ohne den damaligen Ersteller zu fragen.

Hängen Sie die gerettete VM nicht in das normale Firmennetz und nennen Sie das Betriebssicherheit. Eine nicht unterstützte IDE und alte Installer von Drittanbietern vergrößern die Angriffsfläche. Alte Datenbankclients können Protokolle verlangen, die längst hätten abgeschaltet werden sollen. Isolieren Sie den Build, übertragen Sie Ein- und Ausgaben kontrolliert, prüfen Sie Artefakte, entfernen Sie dauerhafte Zugangsdaten und protokollieren Sie Zugriffe. Das verschafft Zeit, macht aber eine nicht unterstützte Toolchain nicht gesund.

Das Alter allein bestimmt nicht den Migrationstermin

Die Priorität einer VB6-Anwendung ergibt sich aus Wiederherstellbarkeit, Änderungsdruck und Folgen eines Ausfalls, nicht aus ihrem Alter. Zwei im selben Jahr kompilierte Programme können gegensätzliche Entscheidungen verdienen. Ein schreibgeschütztes Nachschlagewerk auf einem isolierten Arbeitsplatz lässt sich vielleicht eindämmen. Ein Auftragserfassungsprogramm mit wöchentlichen Regeländerungen und direkten Produktionsschreibvorgängen sollte womöglich vor der nächsten Funktionsanfrage ersetzt werden.

Bewerten Sie zuerst die Wiederherstellbarkeit. Kann das Team das freigegebene Paket auf einem sauberen, unterstützten Windows-Abbild installieren? Kann es den eingesetzten Stand aus einem sauberen Checkout bauen? Sind jedes Steuerelement, jede Lizenz und jeder Datenbankprovider erfasst? Kann mehr als eine Person die Freigabe ausführen? Ein Nein beim sauberen Build erhöht die Dringlichkeit selbst ohne gemeldete Fehler, weil die Dauer der nächsten Änderung unbekannt ist.

Bewerten Sie danach den Änderungsdruck. Zählen Sie echte Anforderungen an Codeänderungen, nicht allgemeine Unzufriedenheit. Zertifikatswechsel, API-Änderungen, Steuerregeln, Authentifizierungsanforderungen, Datenbank-Upgrades und neue Dateiformate belasten alle dieselbe schrumpfende Toolchain. Ein Funktionsrückstand zählt, doch eine verpflichtende externe Änderung mit festem Termin wiegt schwerer. Die Anwendung kann fachlich fertig sein und trotzdem auf erzwungene Änderungen der umliegenden Systeme treffen.

Die Folgen brauchen konkrete Ausfallbilder. Fragen Sie, was passiert, wenn die Anwendung einen Tag lang nicht startet, falsch rechnet, eine Transaktion verliert oder nach dem Austausch eines Arbeitsplatzes nicht installierbar ist. Benennen Sie den manuellen Ersatz und testen Sie ihn mit der aktuellen Menge. Ein Wiederanlaufplan, der von einem ausgeschiedenen Mitarbeiter oder einer ungeöffneten Schachtel Installationsmedien abhängt, lässt sich nicht seriös kalkulieren.

Auch die Sicherheitsexposition verändert die Entscheidung. Ein lokales Werkzeug, das kontrollierte Dateien liest, trägt ein anderes Risiko als ein Client, der Dokumente aus dem Internet annimmt, mit weitreichenden Datenbankrechten verbindet oder veraltete Netzwerkprotokolle braucht. Bezeichnen Sie nicht jede VB6-Software allein wegen der Sprache als unsicher. Verfolgen Sie Eingaben, Rechte, Abhängigkeiten und Netzwerkpfade. Die nicht unterstützte IDE gehört unabhängig vom Einsatzort der Anwendung in eine isolierte Build-Umgebung.

Ich dokumentiere die Entscheidung mit Eigentümer, Belegdatum und Auslöser statt mit einem vagen roten Status. Eine Eindämmung kann gültig bleiben, bis das Host-Betriebssystem aus der Unterstützung fällt, eine Komponentenlizenz nicht verlängert werden kann, der saubere Build scheitert oder eine benannte Integration eine inkompatible Änderung ankündigt. Prüfen Sie genau diese Auslöser. So vermeiden Sie sowohl hektische Neuentwicklungen als auch den häufigeren Fehler, dass sich eine vorläufige Ausnahme endlos verlängert, ohne dass jemand das Risiko zeichnet.

Der Kostenvergleich muss mehr als Entwicklerstunden enthalten. Rechnen Sie alte Abbilder, beschränkte Netzzonen, seltenes Komponentenwissen, manuelle Bereitstellung, Störungsbehebung und verzögerte Fachänderungen ein. Beim Ersatz gehören Datenabgleich, Parallelbetrieb, Schulung, Umstellung und Außerbetriebnahme dazu. Eine ehrliche Rechnung kann trotzdem für Eindämmung sprechen. Sie darf die Arbeit am Altsystem nicht verschwinden lassen, nur weil sie im Betrieb statt im Projektbudget anfällt.

Die realistischen Auswege haben verschiedene Risikoprofile

Es gibt fünf vertretbare Wege. Der richtige hängt von Änderungshäufigkeit, betrieblicher Exposition und beobachtbarem Verhalten ab. Unverändert lassen ist nur dann eine Entscheidung, wenn die EXE eine begrenzte Restlebensdauer hat, der Build wiederherstellbar ist, der Host kontrolliert wird und der Fachbereich den Ausfallplan akzeptiert. Betrieb aus Gewohnheit ist keine solche Entscheidung.

Virtualisierung bewahrt eine alte Umgebung und kann sie vom Wechsel der Arbeitsplätze trennen. Sie eignet sich für wenig veränderte interne Werkzeuge, besonders bei geringer Hardwarebindung. Zugleich friert sie alte Schwächen, Lizenzbedingungen und Betriebswissen in einem Abbild ein. Virtualisierung schützt die Verfügbarkeit beim Austausch eines Laptops. Sie modernisiert die Anwendung nicht und stellt Herstellerunterstützung nicht wieder her.

Eine API vor dem VB6-System kann direkte Datenbankzugriffe verringern und neuen Clients eine stabile Grenze geben. Das funktioniert, wenn das alte Programm bereits aufrufbare Geschäftsoperationen bietet oder sich über einen kontrollierten Adapter steuern lässt. Es funktioniert schlecht, wenn die Automatisierung von UI-Zeitabläufen, modalen Dialogen, gemeinsamen Dateien oder globalem Rechnerzustand abhängt. UI-Automatisierung ist eine vorläufige Brücke mit festem Enddatum, keine Integrationsarchitektur.

Beim schrittweisen Ersatz wandert jeweils eine abgegrenzte Fähigkeit. Das kann das Bereitstellungsrisiko senken, wenn Modulgrenzen echt sind und das Team alte und neue Pfade parallel ausführen kann. Sind die Grenzen nur auf einem Diagramm vorhanden, entstehen dagegen Jahre mit doppelten Schreibvorgängen, COM-Interop, doppelten Regeln und Abgleichen. Schneiden Sie Schritte um beobachtbare Geschäftstransaktionen, nicht um Quellordner.

Eine vollständige Neuentwicklung ist gerechtfertigt, wenn das System eng gekoppelt ist, der Build zerfällt, die Zielarchitektur das Betriebsmodell ändert oder zwei Systeme in der Übergangszeit teurer sind als das Umstellungsrisiko. Der übliche Einwand lautet, dass Neuentwicklungen verborgene Fachregeln verlieren. Das stimmt, wenn das Team den Quellcode als Spezifikation behandelt und nur Normalfälle testet. Mit aufgezeichnetem Verhalten, Daten und Randfällen als ausführbarem Vergleichsmaßstab lässt sich eine Neuentwicklung dagegen vertreten.

Von automatischer Konvertierung Zeile für Zeile rate ich ab. Sie ist beliebt, weil sie den Umfang scheinbar erhält und einen messbaren Umwandlungsgrad liefert. Meist trägt sie globalen Zustand, Desktop-Kopplung und zufälliges Datenbankverhalten in eine neue Sprache und ergänzt Interop-Klebstoff an den gescheiterten Stellen. Das Ergebnis ist eine alte Architektur, die sich schwerer untersuchen lässt, weil sich ihre vertraute Laufzeitsemantik geändert hat. Erhalten Sie das Verhalten, nicht die alte Anordnung von Dateien und Formularen.

Aufgezeichnetes Verhalten ist der Migrationsvertrag

Ein Migrationstest sollte fachliche Auswirkungen an einer Transaktionsgrenze vergleichen, nicht bloß Bildschirme oder Rückgabewerte von Funktionen. Erfassen Sie für jeden repräsentativen Vorgang die normalisierte Anfrage, Ausgangsdaten, einschlägige Konfiguration, externe Antworten, Datenbankänderungen, erzeugte Dateien, Nachrichten und das sichtbare Ergebnis. Spielen Sie denselben Fall gegen den Ersatz und vergleichen Sie die Folgen, nachdem Sie veränderliche Felder wie Zeitstempel und generierte Kennungen entfernt haben.

Ein kompakter Paritätsfall kann so aussehen:

{
  "case": "invoice-credit-partial",
  "input": {"invoice_id": 4812, "amount": "37.50"},
  "expected": {
    "status": "partially_credited",
    "ledger_delta": "-37.50",
    "document_type": "credit_note"
  }
}

Der Fallname ist weniger wichtig als seine Herkunft. Halten Sie fest, welcher Produktionsablauf ihn geliefert hat, entfernen Sie personenbezogene Daten, versionieren Sie den Testdatensatz und halten Sie den Vergleich deterministisch. Wählen Sie normale und unbequeme Fälle: leere Zeichenfolgen gegenüber Nullwerten, gebietsspezifische Dezimalzahlen, Schalttage, doppelte Übermittlungen, Zeitüberschreitungen, Teilausfälle und Wiederholungen. VB6-Anwendungen kodieren Fehlerbehandlung oft in Ereignisreihenfolge und gemeinsamem Zustand. Testen Sie daher auch Folgen statt nur einzelne Operationen.

Golden-Master-Tests allein können Fehler bewahren. Ordnen Sie Abweichungen als beabsichtigte Korrektur, harmlose Darstellungsdifferenz, fehlendes Verhalten oder Testfehler ein. Ein fachlich Verantwortlicher muss beabsichtigte Änderungen genehmigen, denn Entwickler können beim Lesen des Codes nicht entscheiden, ob eine ungewöhnliche Buchungsregel versehentlich entstand. Bewahren Sie das ursprüngliche Ergebnis neben der genehmigten neuen Erwartung auf, damit die Entscheidung prüfbar bleibt.

Produktionsverkehr bietet bessere Abdeckung als erfundene Unit-Fälle, sofern er rechtmäßig und sicher aufgezeichnet werden kann. CodeHero verwendet einen Paritätstest mit aufgezeichnetem Produktionsverkehr und modernisiert dabei die Architektur, statt den Quellcode zu transliterieren. Das Prinzip gilt unabhängig vom Anbieter: Erfassen Sie echte Benutzeranforderungen, bereinigen Sie sie, spielen Sie sie erneut ab und vergleichen Sie dauerhafte Auswirkungen.

Wählen Sie das Ziel an der Systemgrenze

Das Ziel sollte Bereitstellungs-, Fehler- und Eigentumsgrenzen folgen, nicht einer Mode bei Programmiersprachen. Eine Desktop-Anwendung, die hauptsächlich Eingaben prüft und eine zentrale Datenbank anspricht, kann zu einem TypeScript-Client mit Diensten und Postgres werden. Ein rechenintensives Modul kann Rust für einen kleinen numerischen Kern rechtfertigen. Für einen Transaktionsdienst mit überschaubarer Nebenläufigkeit und Betrieb kann Go passen. Das sind Entwurfsentscheidungen, keine automatischen Ersetzungen für VB6-Syntax.

Zeichnen Sie zuerst die aktuelle Ausführungsgrenze. Markieren Sie Arbeiten auf dem Benutzerrechner, Arbeiten nahe der Datenbank, Integrationen mit geordneten Aufrufen und Ausgaben, die für nachgelagerte Verbraucher bytekompatibel bleiben müssen. Entscheiden Sie, wo Identität, Autorisierung, Wiederholungslogik und Prüfprotokolle liegen. Wenn zwei Ersatzkomponenten dieselbe Datenbanktransaktion teilen und gemeinsam bereitgestellt werden müssen, bringt ihre Bezeichnung als getrennte Dienste nur einen neuen Netzwerkfehler, keine Unabhängigkeit.

Die Datenmigration braucht dieselbe Disziplin wie der Code. Bewahren Sie Kennungen, Dezimalgenauigkeit, Zeichencodierung, Nullverhalten und historische Statuswerte, bevor Sie das Schema verbessern. Führen Sie Abgleichsabfragen über Summen und Zustandsübergänge aus, nicht nur über Zeilenzahlen. Schreibt die alte Anwendung aus vielen Formularen direkt in Tabellen, legen Sie eine kontrollierte Schreibgrenze um dieses Verhalten, bevor Sie Eigentum aufteilen.

Für ein System, das VB6 schnell verlassen muss, liest CodeHero den gesamten Quellbaum, schreibt ihn in Go, Rust und TypeScript mit Postgres um, wo es passt, und liefert jedes Projekt in weniger als 30 Tagen. Ob Sie diesen Weg oder Ihr eigenes Team wählen, verlangen Sie dieselben Belege: eine reproduzierbare Quellbasis, ausdrückliche Architekturentscheidungen und Paritätsergebnisse aus aufgezeichnetem Verhalten.

Warten Sie nicht auf eine Betriebssystemversion, die Ihnen die Entscheidung abnimmt. Windows-Kompatibilität kann die EXE am Leben halten, während Build-Wissen, Komponentenrechte und Mitarbeitererfahrung verschwinden. Beweisen Sie jetzt einen sauberen Build, erstellen Sie das Abhängigkeitsverzeichnis und zeichnen Sie echte Transaktionen auf. Entscheiden Sie dann über Eindämmung, schrittweisen Ersatz oder Neuentwicklung, solange das laufende System noch genau zeigen kann, was sein Ersatz leisten muss.