Lebensverlängerung und Migration von VB6-/Access-Business-Apps — Eine Entscheidungstabelle für Behalten, Umhüllen oder Ersetzen

„Ein Teil unseres Kernsystems läuft noch auf VB6“, oder „das Kontobuch, das wir in Access gebaut haben, trägt tatsächlich den Betrieb einer ganzen Abteilung“ – in der Beratung kleiner und mittlerer Unternehmen tauchen diese beiden Situationen immer noch mit bemerkenswert hoher Häufigkeit auf. Was sie gemeinsam haben, ist, dass die Person, die die Sache ursprünglich gebaut hat, das Unternehmen meist schon verlassen hat und niemand genau erklären kann, warum es noch funktioniert. Und doch läuft es weiter, ohne kaputtzugehen, sodass es unweigerlich in der Prioritätenliste nach unten rutscht.

Auf diesem Blog haben wir bereits einzelne technische Themen behandelt, etwa was COM / ActiveX / OCX sind, die Entscheidungstabelle Behalten/Umhüllen/Ersetzen für ActiveX / OCX sowie die Einschränkungen und Zukunft von VBA. Dieser Artikel verengt den Fokus auf die zwei größten Legacy-Bestände, die noch weit verbreitet in japanischen kleinen und mittleren Unternehmen zu finden sind – VB6-Anwendungen und Microsoft-Access-Business-Apps – und stellt einen praxistauglichen Leitfaden zusammen, um zu entscheiden, ob man sie unverändert belässt, ihre Lebensdauer verlängert, indem man nur einen Teil davon umhüllt, oder sie ersetzt. Der Entscheidungsrahmen folgt derselben Dreifachwahl „Behalten / Umhüllen / Ersetzen“, die im ActiveX-/OCX-Artikel verwendet wurde, aber da sich das Thema unterscheidet, unterscheidet sich auch der Inhalt der Risiken, sodass sich dieser Artikel auf die für VB6 und Access spezifischen Fragen konzentriert.

1. Das Wichtigste zuerst

• Die Unterstützung für die VB6-IDE und die Entwicklungsumgebung selbst endete offiziell im April 2008. Es gibt keinen offiziellen Weg mehr für neue Entwicklung oder Änderungen.¹
• Andererseits funktioniert die VB6-Laufzeitumgebung (msvbvm60.dll und Verwandte) weiter, solange die Windows-Version, mit der sie ausgeliefert wird, unterstützt wird. Die Annahme, dass „eine bestehende VB6-App auf unterstütztem Windows mehr oder weniger weiterläuft“, gilt heute noch, ist aber vollständig dem eigenen Support-Lebenszyklus von Windows untergeordnet.¹
• VB6 ist ausschließlich 32-Bit; es gibt keine native 64-Bit-Kompilierung. Auf 64-Bit-Betriebssystemen läuft es innerhalb von WOW64, der 32-Bit-Kompatibilitätsschicht.¹ In dem Moment, in dem Sie mit einer nur-64-Bit-DLL, einem SDK oder einer COM-Komponente interagieren müssen, kann ein einzelner Prozess die gesamte Aufgabe nicht mehr bewältigen.
• Die „Access Database Engine“ (ACE), die Access-Dateien im Format .mdb / .accdb liest und schreibt, hat dieselbe 32-Bit-/64-Bit-Einschränkung. Auf einem gegebenen Rechner kann nur eine Bitbreite installiert werden, und sie muss mit der Bitbreite von Office übereinstimmen.² Seit Office 2019 / Microsoft 365 hat die Standardinstallation auf 64-Bit gewechselt, sodass Access-Apps und ActiveX-Steuerelemente, die auf der alten Annahme von 32-Bit aufgebaut wurden, plötzlich aufhören können zu funktionieren, sobald ein Rechner ausgetauscht wird.³⁴
• Dass mehrere Personen gleichzeitig eine gemeinsam genutzte .accdb aus einem Netzwerkordner öffnen, ist in der Praxis heute noch üblich, bleibt aber ein Risikofaktor für Beschädigung und Leistungseinbußen. Schreibvorgänge über das Netzwerk können zu Datenbeschädigung führen, wenn die Verbindung instabil wird.⁵ Wächst die Größe des Kontobuchs oder die Zahl gleichzeitiger Benutzer, ist es Zeit, ein Upsizing auf etwas wie SQL Server zu erwägen.
• Die Entscheidungsachse ist dieselbe wie bei ActiveX / OCX: Ist dieser Bestand lediglich ein Bildschirm, oder ist er eine Grenze, die auch Geschäftslogik und Daten hält? Ist er stabil und in sich geschlossen, behalten Sie ihn. Möchten Sie nur einen Teil davon modernisieren, umhüllen Sie ihn. Wenn UI- oder Laufzeiteinschränkungen das Geschäft aktiv zurückhalten, ersetzen Sie ihn.

2. Wo VB6 heute steht — die Laufzeitumgebung lebt, aber die Entwicklung hat keine Rückendeckung mehr

Beginnen wir mit den Fakten. Microsoft erklärte am 8. April 2008, dass „die Visual-Basic-6.0-IDE (und die Visual-Studio-6.0-IDE) nicht mehr unterstützt wird“, und stellte damit klar, dass es keinen offiziellen Weg mehr gibt, VB6-Anwendungen zu bauen oder zu warten, und empfahl nachdrücklich die Migration zu moderner Technologie.¹

Gleichzeitig stellt dieselbe Ankündigung auch fest, dass die VB6-Laufzeitumgebung weiterhin unterstützt bleibt, solange die Windows-Version, mit der sie ausgeliefert wird, unterstützt wird. Von bestehenden VB6-Apps wird erwartet, dass sie auf unterstützten Windows-Versionen „einfach funktionieren“, aber der Umfang der Unterstützung beschränkt sich auf die Behandlung schwerwiegender Regressionen und kritischer Sicherheitsprobleme.¹ Anders gesagt können Sie auf die minimale Erwartung zählen, dass „es nicht kaputtgehen sollte, wenn es auf einem neueren Windows installiert wird“, aber es gibt keine Unterstützung im Sinne von „jemand fügt Funktionen hinzu oder untersucht einzelne Probleme, wenn Sie in Schwierigkeiten geraten“.

Ein weiterer Punkt, der in der Praxis zählt, ist, dass die VB6-Laufzeitumgebung eine reine 32-Bit-Datei ist und auf 64-Bit-Betriebssystemen nur innerhalb von WOW64, der 32-Bit-Emulationsumgebung, unterstützt wird.¹ Das bedeutet, dass „eine VB6-App künftig nur als 32-Bit-Prozess weiterleben kann“. In dem Moment, in dem Sie ein nur-64-Bit-Mess-SDK oder eine neue Kryptografie-Bibliothek verwenden möchten, können Sie diese grundsätzlich nicht direkt in den VB6-Prozess laden. In der Praxis ist der einzige Weg über diese Mauer, „sie in einen separaten Prozess auszulagern und zu interoperieren“ – und der konkrete Aufbau, der in „Eine COM-Brücke, die eine 64-Bit-DLL aus einer 32-Bit-App aufruft“ beschrieben wird, lässt sich unverändert übernehmen. Beim Überbrücken von einer VB6-App aus ist der Gedanke derselbe: Beschränken Sie die 64-Bit-Funktionalität auf einen Out-of-Process-COM-Server oder eine Helfer-EXE, und lassen Sie die VB6-Seite einfach hineinrufen.

Die meisten VB6-Apps tragen ActiveX-/OCX-Steuerelemente als Bildschirmkomponenten. Die Entscheidung Behalten/Umhüllen/Ersetzen für diese Komponenten selbst wird ausführlich in „Wie sollte man ActiveX / OCX heute behandeln?“ behandelt – ziehen Sie das für die einzelnen in eine VB6-App eingebetteten Steuerelemente heran. Dieser Artikel konzentriert sich auf die übergeordnete Entscheidung, wie die VB6-Anwendung als Ganzes zu behandeln ist.

3. Wo Access heute steht — Dateiformate, ACE-Bitbreite und die Realität gemeinsam genutzter Ordner

3.1 .mdb / .accdb und die ACE-Bitbreite

Access-Daten werden in Dateien im Format .mdb (das alte Format) oder .accdb (2007 und später) gespeichert, und die Laufzeitkomponente, die sie liest und schreibt, ist die Access Database Engine (ACE, der Nachfolger von Jet). Ein Bitbreiten-Mismatch-Problem taucht in der Praxis ständig auf. Der alte Jet-OLE-DB-Anbieter ist nur in einem 32-Bit-Build verfügbar, und während ACE sowohl in 32-Bit- als auch 64-Bit-Builds verfügbar ist, kann auf einem gegebenen Rechner nur eine Bitbreite installiert werden, und sie muss mit der Bitbreite von Office auf diesem Rechner übereinstimmen.² Visual Studio hat dasselbe Problem: Da Visual Studio 2022 und höher als 64-Bit-Prozess laufen, sind Fälle dokumentiert, in denen Datentools, die sich auf den 32-Bit-Access-Anbieter verlassen, sich nicht mehr verbinden können.⁶

Erschwerend kommt eine Änderung im Standard von Office hinzu. Office 2010 bis 2016 installierte standardmäßig den 32-Bit-Build, aber ab Office 2019 und Microsoft 365 wechselte die Standardinstallation auf den 64-Bit-Build.³ Hinzu kommt, dass ein 64-Bit-Office-Prozess keine 32-Bit-Binärdateien laden kann, sodass bestehende 32-Bit-ActiveX-Steuerelemente und COM-Add-Ins unter 64-Bit-Office schlicht nicht funktionieren.⁴ Anders gesagt wird der übliche Vorfall „wir haben dieselbe Access-App jahrelang problemlos genutzt, und dann hörte sie nach einem PC-Austausch plötzlich auf zu funktionieren“ meist durch den Wechsel der Standard-Bitbreite von Office in Kombination damit verursacht, dass ACE und alle eingebetteten Steuerelemente mit diesem Wechsel nicht Schritt gehalten haben. Das Fehlerbehebungsverfahren für diese Problemklasse wird in „Warum ActiveX unter Office 2024/Microsoft 365 aufhört zu funktionieren, und wie man das prüft“ dargelegt.

3.2 Das Risiko des Mehrbenutzerzugriffs auf gemeinsam genutzten Ordnern

Ein weiterer klassischer Access-App-Aufbau ist, dass mehrere Personen gleichzeitig eine einzelne, in einem gemeinsam genutzten Ordner gespeicherte .accdb öffnen. Im kleinen Maßstab kann das jahrelang störungsfrei laufen, ist aber ein von Natur aus prekärer Aufbau. Schreibvorgänge über ein Netzwerk sind dokumentiert als potenziell Schreibfehler oder Dateibeschädigung verursachend, wenn die Verbindung instabil wird,⁵ und es gibt seit Langem dokumentierte Fälle, in denen Access Datenträger-/Netzwerkfehler meldet, wenn der Zugriff auf einen Dateiserver verzögert wird oder eine Zeitüberschreitung auftritt.⁷ Der Keim der Beschädigung hier – gleichzeitiger Zugriff auf eine gemeinsam genutzte Datei – ähnelt strukturell den Konkurrenzmustern, die in den „Grundlagen der Ausschlusssteuerung für dateibasierte Integration“ dieses Blogs behandelt werden. Access verfügt über eingebaute Ausschlusssteuerung über eine Sperrdatei (.laccdb), aber je mehr „zu Instabilität neigende Verbindungen“ Sie hinzufügen – Laptops über Wi-Fi, Fernarbeit über VPN, erneutes Verbinden nach dem Ruhezustand –, desto höher steigt die Vorfallsrate.

Der Standard-Ausweg, sobald die Zahl gleichzeitiger Benutzer wächst oder die Verarbeitung schwerer wird, ist, Access-Tabellen zu SQL Server oder Azure SQL zu verschieben und Access sie als verknüpfte Tabellen referenzieren zu lassen. Mit einem Tool wie dem SQL Server Migration Assistant (SSMA) migrieren Sie die Access-Tabellen und ersetzen dann die ursprünglichen Access-Tabellen durch Verknüpfungen zu den migrierten Tabellen – die Bildschirme (Formulare, Berichte, Abfragen) bleiben exakt wie sie sind, und nur die Daten wandern zu einem robusteren Back-End.⁸ Verknüpfte Tabellen bringen jedoch ihre eigenen Probleme nach der Migration mit sich: Aggregationsverarbeitung kann langsamer werden (hängt eine Abfrage von Funktionen ab, die der Server nicht ausführen kann, zieht Access die gesamte Tabelle lokal herunter, bevor sie verarbeitet wird), und das Verhalten der AutoNumber-Spalte ändert sich – Situationen, die manchmal erfordern, Abfragen durch Pass-Through-Abfragen oder Sichten zu ersetzen.⁸ Es wird auch seit Langem empfohlen, Access-Anwendungen in eine „Back-End“-Datenbank mit den Tabellen und eine „Front-End“-Datenbank mit den Formularen, Abfragen und Makros aufzuteilen.⁹ Der entscheidende Punkt hier ist, dass das Aufteilen allein nicht genügt. Die korrekte Konfiguration ist, nur das Back-End (Tabellen) im gemeinsam genutzten Ordner zu belassen und das Front-End auf den eigenen Rechner jedes Benutzers zu kopieren, sodass jede Person es von ihrer lokalen Kopie aus ausführt. Belassen Sie das Front-End als eine einzelne, gemeinsam genutzte Ordnerdatei, die alle gleichzeitig öffnen, hat das Aufteilen das Risiko nicht tatsächlich beseitigt – Sie haben immer noch mehrere Personen, die gleichzeitig Bildschirme, Abfragen und Makros gegen eine gemeinsam genutzte Datei lesen und schreiben, was Probleme wie sich verschlechternde Öffnungsverzögerungen und Konflikte bei jeder Designänderung verursacht. Ob Sie einen Aufbau mit gemeinsam genutztem Ordner verlängern oder sich in Richtung SQL Server bewegen – der erste Kontrollpunkt ist, ob sowohl „das Back-End gemeinsam nutzen“ als auch „das Front-End lokal auf jedem Rechner platzieren“ bereits vorhanden sind.

4. Entscheidungstabelle

Ordnet man VB6- und Access-Apps nach Nutzungsmuster und Risikofaktor, ergeben sich die folgenden Entscheidungen.

Als Ergänzung: „Umhüllen“ bedeutet in dieser Tabelle meist, zunächst nur die Daten oder nur die Grenze zu modernisieren, während die Bildschirme und das Bedienungsgefühl vorerst unverändert bleiben. Betrachten Sie es nicht als vollständigen Neubau auf einmal, sondern als vorübergehenden Landepunkt, um zuerst die risikoreichsten Teile anzugehen.

Um die Tabelle zu verwenden, grenzen Sie zunächst die Zeile „Ziel“ ein und prüfen Sie dann, ob Ihre Situation zur Spalte „Nutzung / Risikofaktor“ passt. Wichtig ist, dass Sie selbst bei derselben VB6-App frei sind, die Entscheidung pro Zeile oder pro Funktion aufzuteilen – ein Bildschirm könnte behalten werden, eine andere Funktion umhüllt. Fassen Sie alles zusammen als „es ist eine VB6-App, also alles gleich behandeln“, ziehen Sie am Ende auch wirklich stabile Teile in den Aufwand hinein und lassen ihn aufblähen.

5. Die Entscheidungstabelle nach Szenario anwenden

Wendet man die Entscheidungstabelle tatsächlich auf reale Beratungsfälle an, tendiert sie dazu, sich auf grob drei Muster zuzuspitzen.

Szenario 1: Eine rein interne VB6-Bestandsverwaltungs-App mit kleinen Änderungswünschen. Sind die Zielrechner auf eine Handvoll festgelegt und berührt die App niemals das Netzwerk, neigt die Entscheidungstabelle zu „Behalten“. Die praktische Arbeit hier besteht lediglich darin, die Risikominderungsmaßnahmen aus Abschnitt 7 (Backups, Dokumentation, Festlegen der Laufzeitumgebung) stetig aufzubauen. Sofern keine echte Motivation zur Migration zu .NET besteht, geht die Kosten-Nutzen-Rechnung oft nicht auf.

Szenario 2: Ein über mehrere Abteilungen hinweg gemeinsam genutztes Access-Kontobuch mit wachsender Benutzerzahl. Eine sehr häufige Beratungsanfrage betrifft eine Access-App, die vor einigen Jahren von zwei oder drei Personen genutzt wurde, aber durch Abteilungsfusionen oder Geschäftsausweitung auf etwa zehn gleichzeitige Benutzer angewachsen ist. Hier neigt die Entscheidungstabelle zu „Umhüllen“. Prüfen Sie zunächst, ob das Back-End gemeinsam genutzt wird und das Front-End lokal auf jedem Rechner bereitgestellt ist (Abschnitt 3.2); ist das nicht der Fall, teilen und stellen Sie zuerst neu bereit. Zeigen sich dann Anzeichen von Beschädigung oder Leistungseinbußen (längere Öffnungszeiten, verbleibende .laccdb-Dateien mit nie freigegebenen Sperren und Ähnliches), wechseln Sie dazu, die Tabellen zu SQL Server zu migrieren und sie aus Access als verknüpfte Tabellen zu referenzieren.⁸ Da die Bildschirme fast vollständig unverändert bleiben können, können Sie die Datenschicht härten, während Sie die Umschulungskosten der Benutzer niedrig halten.

Szenario 3: Eine geschäftskritische VB6-App, deren Entwickler das Unternehmen verlassen hat, mit der Forderung, sie ins Web zu verlagern. Existiert der Quellcode, aber niemand kann ihn anfassen, und besteht nun die Forderung, von außerhalb des Unternehmens darauf zuzugreifen, neigt die Entscheidungstabelle zu „Ersetzen“. Je zentraler die App jedoch für das Geschäft ist, desto riskanter wird eine in einem Schritt durchgeführte vollständige Neuschreibung. Dem Verfahren aus Abschnitt 9 zu folgen – beginnend mit einer Bestandsaufnahme der Geschäftslogik und dem Herausarbeiten wirkungsarmer, unabhängiger Funktionalität zuerst – und über eine gestufte Migration vorzugehen, ist der realistische Weg.

6. Häufige Antimuster

Bevor Sie die Entscheidungstabelle anwenden, lohnt es sich, zunächst die Fehlermuster zu teilen, die in Projekten zur Lebensverlängerung und Migration von VB6/Access wiederholt auftauchen, und zu prüfen, ob Sie derzeit in eines davon verfallen.

Die zwei häufigsten Übeltäter in dieser Liste sind, eine Bitbreiten-Nichtübereinstimmung unangetastet zu lassen und die Benutzerzahl eines gemeinsam genutzten Ordners ungeprüft wachsen zu lassen. Beide teilen das Merkmal, dass es keine Probleme sind, die „heute kaputtgehen“ – sie treten erst zutage, wenn irgendein unausweichlicher Auslöser schließlich eintritt, etwa eine Rechnerauffrischung oder Wachstum der Benutzerzahl.

7. Realistische Risikominderung, wenn Sie sich fürs Behalten entscheiden

Sich für das unveränderte Behalten zu entscheiden, ist oft die realistische Wahl, und daran ist an sich nichts falsch. Aber je länger Sie mit „es funktioniert, also nicht anfassen“ fortfahren, desto mehr häuft sich das Risiko an, dass niemand die zugrunde liegenden Annahmen erklären kann. Zumindest sollten Sie Folgendes handhaben:

• Generationsweise Backups mechanisch durchführen. Da Access’ .accdb in sich geschlossen in einer einzigen Datei ist, kann bereits das einfache tägliche Erstellen generationsweiser Backups eine beträchtliche Anzahl von Vorfällen abfedern. Bewahren Sie für VB6-Apps den gesamten Quellcode-Satz (.vbp, .frm, .bas, .cls) zusammen mit den abhängigen OCXs, DLLs und Registrierungsinformationen auf.
• Die Annahmen der Laufzeitumgebung dokumentieren, als Absicherung gegen das Fehlen eines Nachfolgers. Erfassen Sie das unterstützte Betriebssystem, die Office-Bitbreite und die erforderlichen Laufzeitumgebungen/abhängigen DLLs/Registrierungsschritte, zumindest ausführlich genug, dass jemand herausfinden kann, „was zu prüfen ist, wenn es auf einem neuen PC aufhört zu funktionieren“.
• Die Laufzeitumgebung bewusst festlegen. Da automatische Updates von Windows oder Office die Bitbreite oder Standardeinstellungen ändern und Vorfälle auslösen können (Abschnitt 3.1), geben Sie den Zielrechnern eine separate Update-Richtlinie und rollen Sie Updates erst aus, nachdem sie verifiziert wurden.
• Einen Rauchtest für eine saubere Umgebung vorbereiten. Halten Sie vor der Bereitstellung auf einem neuen Rechner ein Verfahren bereit, um zu bestätigen, dass Installation, Registrierung, Start und die wichtigsten Vorgänge in einer frischen Umgebung funktionieren – das verringert die bei jeder Bereitstellung verlorene Zeit für „es sollte funktionieren, tut es aber nicht“.
• Aufrufstellen an einer Stelle konsolidieren. Statt VB6-COM-Aufrufe oder Access-Referenzen auf verknüpfte Tabellen über die gesamte App zu verstreuen, macht das so weit wie möglich Eingrenzen der Einstiegspunkte klar, wo man ansetzen soll, wenn man die Dinge irgendwann umhüllt oder ersetzt.

Als VB6-spezifischer Hinweis erwägen Sie auch, die Entwicklungsmaschine selbst zu bewahren. Die IDE-Installationsmedien und -Lizenz, Entwicklerversionen aller für den Build benötigten externen Steuerelemente (OCX) sowie Notizen zum Build-Verfahren sind Bestände, die sich noch leichter verstreuen als die Laufzeitumgebung. Sind derzeit keine Änderungen geplant, erweitert das Aufbewahren einer einzigen Umgebung (etwa ein Snapshot einer virtuellen Maschine), in der der Build reproduziert werden kann, Ihre Optionen erheblich, sobald eine kleine Korrektur nötig wird.

Möchten Sie bestehende Windows-Software warten und ändern, ohne sie zu beschädigen, fällt das unter Änderung und Wartung bestehender Windows-Software.

8. Realistische Optionen beim Umhüllen

„Umhüllen“ ist der Ansatz, den alten Bestand innerhalb einer engen Grenze zu beschränken, während der Umgebung eine neue Schnittstelle präsentiert wird. Für VB6 und Access läuft das im Allgemeinen auf die folgenden drei Muster hinaus.

(a) Eine VB6-COM-Komponente aus .NET über COM-Interop aufrufen. Wird ein in VB6 geschriebenes Klassenmodul als ActiveX-DLL (oder als EXE, falls Out-of-Process) verfügbar gemacht, kann es aus .NET über COM-Interop aufgerufen werden. Da die VB6-Seite 32-Bit bleibt, stößt der Aufruf aus einer 64-Bit-.NET-App auf dieselbe in Abschnitt 2 besprochene Bitbreiten-Mauer. Ob Sie den Aufrufer auf 32-Bit ausrichten oder als Out-of-Process-COM-Server auf einen 32-Bit-Prozess beschränken, lässt sich durch einfaches Umdrehen des in „Eine COM-Brücke, die eine 64-Bit-DLL aus einer 32-Bit-App aufruft“ beschriebenen Aufbaus lösen. Zu den Grundlagen von COM selbst siehe „Was sind COM / ActiveX / OCX?“

(b) Die VBA-Logik von Access schrittweise zu .NET / dem Web migrieren. Manche Access-Apps haben Geschäftslogik dicht hinter ihren Formularen gepackt, während andere größtenteils nur Dateneingabe und Listenansichten sind – oft existieren beide Muster innerhalb derselben App. Ein realistischer Ansatz ist, zuerst die VBA-Module zu inventarisieren, die reine Berechnungs- und Validierungslogik, die nicht von anderen Systemen abhängt, in eine .NET-Klassenbibliothek herauszuarbeiten und Access dazu zu bringen, sie über COM oder eine dazwischenliegende Web-API aufzurufen. Die Einschränkungen von VBA selbst und wie weit Sie es in VBA belassen sollten, werden ausführlich in „Was ist VBA? Einschränkungen, seine Zukunft, und wann man es ersetzen sollte“ dargelegt.

(c) Nur die UI zuerst ersetzen, Daten und Logik intakt lassen. Dreht sich die Hauptbeschwerde um ein veraltetes, langsames oder von außerhalb des Unternehmens nicht nutzbares Access-Formular, ist eine Option, die Datenschicht (Tabellen zu SQL Server verschoben) und die Logik unverändert zu lassen und nur die UI durch moderne Web- oder Desktop-Technologie zu ersetzen. Kombiniert mit der Umstellung auf verknüpfte Tabellen wie in Abschnitt 3.2 ermöglicht das einen übergangsweisen Parallelbetrieb, bei dem „die Daten in SQL Server liegen, und sowohl die alte UI (Access) als auch die neue UI dieselben Daten betrachten“. Koppelt Access’ VBA jedoch UI und Logik eng aneinander, kann diese Trennungsarbeit selbst erst fortschreiten, nachdem die in (b) beschriebene Bestandsaufnahme zuerst durchgeführt wurde.

Diese drei Optionen im Überblick:

Möchten Sie zuerst die Grenzstruktur oder Migrationsrichtung besprechen, fällt das unter Nutzung und Migrationsunterstützung bestehender Bestände; für eine Designprüfung vor der Implementierung ist es Technische Beratung und Designprüfung.

9. Wie man beim Ersetzen vorgeht

Sie wählen das Ersetzen, wenn UI- oder Bitbreiteneinschränkungen das Tempo des Geschäfts direkt zurückhalten, oder wenn das Fehlen eines Entwicklers die Wartung selbst untragbar macht. Statt direkt in eine vollständige Neuschreibung zu starten, verringert das Befolgen dieser Reihenfolge Vorfälle:

1. Die Datenmigration zuerst verifizieren. Migrationen wie Access → SQL Server beinhalten Unterschiede, die sich erst im Nachhinein zeigen – Unterschiede bei der Vergabe von AutoNumber-Werten, Abhängigkeiten von Funktionen, die nur auf der Access-Seite existieren, fehlende eindeutige Indizes und Ähnliches.⁸ Schließen Sie umfassende Round-Trip-Tests der Migration und der Geschäftsszenarien gegen eine Kopie der Produktionsdaten ab, bevor Sie zur Produktionsumstellung übergehen.
2. Die Geschäftslogik inventarisieren. Gehen Sie die Formulare/Module von VB6 und die VBA/Makros/Abfragen von Access funktionsweise durch und unterscheiden Sie „lediglich ein Bildschirm“ von „eine Grenze, die auch Spezifikationen hält“. Diese Unterscheidung erfolgt genauso wie bei ActiveX / OCX, aber bei VB6 und Access ist das über Jahre des Betriebs angehäufte Geschäftswissen selbst ein Bestand, was die Ermittlung von Natur aus zeitaufwändiger macht.
3. Über gestufte Migration vorgehen (das Strangler-Muster). Statt alle Funktionalität auf einmal zu ersetzen, arbeiten Sie zuerst die risikoärmste, unabhängigste Funktionalität in das neue System heraus und lassen Sie die alte und neue App für einen festgelegten Zeitraum parallel laufen. Funktion für Funktion klarzustellen, welche der alten oder neuen Daten maßgeblich sind, und die Bedingungen für das Ende der Parallelbetriebsphase im Voraus festzulegen, sind die Mindestanforderungen, um zu verhindern, dass dieser Ansatz zusammenbricht.
4. UI-Komponenten oder Bildschirmlayout zuerst zu ersetzen, erleichtert die Dinge später. Verwendet eine VB6-App ActiveX / OCX als UI-Komponenten, erleichtert das Ersetzen nur dieser Komponenten durch moderne Steuerelemente zuerst die Aufwandsschätzung für die spätere vollständige Ablösung. Zu einzelnen Entscheidungen siehe „Wie sollte man ActiveX / OCX heute behandeln?“
5. Eine Möglichkeit zur Beobachtung während der Parallelbetriebsphase vorbereiten. Während die alte und neue App parallel laufen, bereiten Sie Protokolle oder einen Abgleichmechanismus vor, mit dem Sie vergleichen können, welcher Prozess welche Ergebnisse erzeugte. Fahren Sie mit der Umstellung ohne jegliches Beobachtungsmittel fort, riskieren Sie, einen Vorfall – „nach dem Wechsel zum neuen System stimmten die Zahlen nicht mehr überein“ – erst Monate später zu bemerken.

Für einen Dienst, der alles von der Inventarisierung der Spezifikationen alter Windows-Apps bis zum gestuften Ersetzen abdeckt, siehe Windows-App-Ablösung (japanische Seite).

10. Checkliste für den Einstieg in die Migration

Eine Bestandsaufnahme in der folgenden Reihenfolge durchzuführen, bevor Sie die Entscheidungstabelle (Abschnitt 4) anwenden, verkürzt die Zeit bis zur Festlegung einer Richtung erheblich.

1. Die Ziele aufzählen. Listen Sie VB6s .exe / .dll / .ocx und Access’ .mdb / .accdb nach Name, Version und Speicherort auf.
2. Nutzungsmuster bestätigen. Prüfen Sie die Zahl der Benutzer, ob gleichzeitiger Zugriff stattfindet, ob es aus einem gemeinsam genutzten Ordner läuft, und ob die Nutzung täglich oder monatlich erfolgt.
3. Die Annahmen der Laufzeitumgebung bestätigen. Identifizieren Sie die unterstützte Windows-Version, die Office-Bitbreite und ob die erforderlichen Laufzeitumgebungen, abhängigen DLLs und COM-Registrierungen vorhanden sind (Abschnitte 2–3).
4. Bestätigen, wo die Daten liegen und wie groß sie sind. Erfassen Sie für Access die Dateigröße, Anzahl der Tabellen, Anzahl der Datensätze und Wachstumsrate – das bildet die Grundlage für die Entscheidung, ob zu SQL Server gewechselt werden soll.
5. Die Komplexität der Geschäftslogik abschätzen. Verschaffen Sie sich anhand der Zeilenzahl der VBA-Module, der Anzahl der Makros, der Anzahl der Formulare sowie der Anzahl der Formulare/Klassenmodule auf VB6-Seite einen groben Eindruck vom Aufwand der Bestandsaufnahme.
6. Bestätigen, ob Backup- und Wiederherstellungsverfahren existieren. Jedes Ziel ohne vorhandene Backups oder bei dem noch nie tatsächlich eine Wiederherstellung versucht wurde, muss das vor allem anderen ansprechen, noch vor der eigentlichen Entscheidung.
7. Die bisherigen Ergebnisse auf die Entscheidungstabelle anwenden. Sobald die Ziele und Nutzungsmuster geordnet sind, prüfen Sie sie gegen die Tabelle in Abschnitt 4 und entscheiden Sie funktionsweise vorläufig, ob es zu Behalten, Umhüllen oder Ersetzen neigt.

Überspringen Sie dieses Verfahren, führt das tendenziell später zu einer Situation, in der der Aufwand aufgebläht ist, ohne dass jemand erklären kann, was ihn tatsächlich erschwert hat.

11. Zusammenfassung

Das Erste, worauf man bei der Entscheidung zum Umgang mit VB6/Access schauen sollte, ist nicht „wie alt ist es“, sondern die folgenden drei Punkte:

• Verstehen Sie korrekt, dass VB6 eine reine 32-Bit-Laufzeitumgebung ist, die ihre IDE-Rückendeckung verloren hat (Abschnitt 2)?
• Haben Sie berücksichtigt, dass Access’ ACE und ActiveX an die Bitbreite von Office gebunden sind und dass der Betrieb im gemeinsam genutzten Ordner riskanter für Beschädigung wird, je mehr gleichzeitiger Zugriff stattfindet (Abschnitt 3)?
• Können Sie erkennen, ob der betreffende Bestand lediglich ein Bildschirm ist, oder eine Grenze, die auch Geschäftslogik und Daten hält (die Entscheidungstabelle in Abschnitt 4)?

Sind diese drei Punkte geklärt, ergibt sich der Weg nach vorn ganz natürlich: „Behalten“ Sie es, legen Sie die Laufzeitumgebung fest und vernachlässigen Sie nicht Backups und Dokumentation (Abschnitt 7); „umhüllen“ Sie es, schützen Sie Daten und Logik über eine 32-/64-Bit-Brücke oder einen gestuften Umzug zu .NET/dem Web (Abschnitt 8); „ersetzen“ Sie es, verifizieren Sie die Datenmigration und inventarisieren Sie zuerst die Geschäftslogik (Abschnitt 9). VB6 und Access sind keine Bestände, die man wahllos wegwerfen sollte, nur weil sie alt sind – sie sind physische Speicher jahrelang angehäuften Geschäftswissens. Aber Sie können die Hausaufgabe, die nötig ist, um weiterhin mit ihnen zu leben – Festlegen der Laufzeitumgebung, Grenzstrukturierung, Verifizierung von Migrationen –, nicht unbegrenzt vermeiden. Wir empfehlen, mit der Bestandsaufnahme in der Checkliste aus Abschnitt 10 zu beginnen.

Verwandte Artikel

• Was ist VBA? Einschränkungen, seine Zukunft, und wann man es ersetzen sollte — Realistische Migrationsmuster
• Wie sollte man ActiveX / OCX heute behandeln? — Eine Entscheidungstabelle für Behalten, Umhüllen oder Ersetzen
• Was sind COM / ActiveX / OCX? — Die Unterschiede erklärt und wie sie zusammenhängen
• Warum ActiveX unter Office 2024/Microsoft 365 aufhört zu funktionieren, und wie man das prüft
• Eine COM-Brücke, die eine 64-Bit-DLL aus einer 32-Bit-App aufruft
• Grundlagen der Ausschlusssteuerung für dateibasierte Integration — Bewährte Verfahren für Dateisperren und atomare Claims

Verwandte Beratungsleistungen

Die Komura Software LLC übernimmt die Inventarisierung und Ordnung der Migrationsrichtung bestehender Bestände einschließlich VB6 und Access, Lebensverlängerungsdesign einschließlich 32-Bit-/64-Bit-Brücken sowie die Planung und Umsetzung gestufter Ablösungen.

• Nutzung und Migrationsunterstützung bestehender Bestände
• Windows-App-Ablösung (japanische Seite)
• Änderung und Wartung bestehender Windows-Software
• Technische Beratung und Designprüfung
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wird VB6 noch unterstützt? Läuft meine VB6-App auf modernem Windows weiter?

Die Unterstützung für die VB6-IDE und die Entwicklungsumgebung endete offiziell im April 2008, es gibt also keinen offiziellen Weg mehr für neue Entwicklung oder Änderungen. Die VB6-Laufzeitumgebung (msvbvm60.dll und Verwandte) bleibt jedoch unterstützt, solange die Windows-Version, mit der sie ausgeliefert wird, unterstützt wird, sodass erwartet wird, dass bestehende VB6-Apps auf unterstütztem Windows weiterlaufen. Der Umfang dieser Unterstützung beschränkt sich auf schwerwiegende Regressionen und kritische Sicherheitsprobleme. Beachten Sie, dass VB6 ausschließlich 32-Bit ist – es gibt keine native 64-Bit-Kompilierung, und auf 64-Bit-Betriebssystemen läuft es innerhalb der WOW64-Kompatibilitätsschicht.

Warum funktioniert meine Access-App nach einem PC-Austausch nicht mehr?

Die übliche Ursache ist eine Nichtübereinstimmung der Office-Bitbreite. Die Access Database Engine (ACE) kann pro Rechner nur in einer Bitbreite installiert werden, und diese muss mit der Bitbreite von Office übereinstimmen. Office 2010 bis 2016 installierte standardmäßig 32-Bit, aber ab Office 2019 und Microsoft 365 wechselte der Standard auf 64-Bit – und ein 64-Bit-Office-Prozess kann keine 32-Bit-Binärdateien laden, sodass bestehende 32-Bit-ActiveX-Steuerelemente und COM-Add-Ins einfach aufhören zu funktionieren. Eine auf der alten 32-Bit-Annahme aufgebaute Access-App kann daher in dem Moment ausfallen, in dem ein Rechner mit standardmäßig installiertem Office aufgefrischt wird.

Ist es sicher, wenn mehrere Benutzer eine Access-Datenbank in einem Netzwerkordner gemeinsam nutzen?

Es kann jahrelang störungsfrei im kleinen Maßstab laufen, ist aber ein von Natur aus prekärer Aufbau: Schreibvorgänge über das Netzwerk können die Datei beschädigen, wenn die Verbindung instabil wird, und instabile Verbindungen wie Wi-Fi-Laptops oder VPN-Fernarbeit erhöhen die Vorfallsrate. Teilen Sie die App zumindest so auf, dass nur das Back-End (Tabellen) im gemeinsam genutzten Ordner liegt und jeder Benutzer eine lokale Kopie des Front-Ends (Formulare, Abfragen, Makros) ausführt – eine einzelne Front-End-Datei gemeinsam zu nutzen beseitigt das Risiko nicht. Wächst die Zahl gleichzeitiger Benutzer oder das Datenvolumen, ist der Standard-Ausweg die Migration der Tabellen zu SQL Server und deren Referenzierung aus Access als verknüpfte Tabellen, wodurch die Bildschirme unverändert bleiben.

Sollte ich eine Legacy-VB6- oder -Access-Anwendung behalten, umhüllen oder ersetzen?

Die Schlüsselfrage ist, ob der Bestand lediglich ein Bildschirm ist oder eine Grenze, die auch Geschäftslogik und Daten hält. Ist er stabil und in sich geschlossen – Rechner und Windows-Version fest, wenige Änderungswünsche –, ist das Behalten mit Backups, Dokumentation und einer festgelegten Laufzeitumgebung oft die realistische Entscheidung. Umhüllen Sie, wenn Sie nur einen Teil davon modernisieren müssen, etwa die Überbrückung zu einem nur-64-Bit-SDK über einen separaten Prozess, oder das Verschieben von Access-Tabellen zu SQL Server bei gleichzeitigem Beibehalten der Formulare. Ersetzen Sie, wenn UI- oder Laufzeiteinschränkungen das Geschäft aktiv zurückhalten oder kein Entwickler es warten kann – und selbst dann über eine gestufte Migration vorgehen, mit zuerst verifizierter Datenmigration, statt einer einmaligen vollständigen Neuschreibung.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.