Wie lange laufen VB6-Anwendungen noch? — Support-Status der Laufzeitumgebung und ein praxisnaher Weg zur .NET-Migration

„Bis wann läuft dieses VB6-System eigentlich noch?” — das ist eine der häufigsten Fragen bei Beratungen zu Altsystemen.

Die Antwort ist überraschend eindeutig: Microsoft hat eine offizielle Support-Richtlinie veröffentlicht. Deren Inhalt ist jedoch asymmetrisch – „die Laufzeitumgebung läuft noch eine Weile, aber der entwicklungsseitige Rückhalt ist bereits weg”. Ohne diese Asymmetrie richtig zu verstehen, landet man zwangsläufig bei einem der beiden Extreme: „läuft ja noch, also ist alles in Ordnung” oder „wir müssen sofort alles neu bauen”.

In diesem Blog wurde in „Verlängerung und Migration von VB6-/Access-Geschäftsanwendungen — eine Entscheidungstabelle für Beibehalten, Umhüllen und Ersetzen” die Entscheidung geordnet, wie mit VB6-Assets umzugehen ist. Dieser Artikel setzt dort an: Nachdem (oder um zu) die Entscheidung „ersetzen (migrieren)” getroffen wurde, geht er darauf ein, wie eine Migration von VB6 zu .NET konkret durchgeführt wird.

1. Zunächst das Fazit

• Der Support der VB6-IDE (Entwicklungsumgebung) endete am 8. April 2008. Es gibt keinen unterstützten Weg mehr, um VB6-Anwendungen zu erstellen oder zu pflegen, und Microsoft empfiehlt dringend, sie durch moderne Technologien zu ersetzen.¹
• Die VB6-Laufzeitumgebung hingegen wird unterstützt, „solange die Windows-Version, mit der sie ausgeliefert wird, selbst unterstützt wird”. Die Liste der abgedeckten Betriebssysteme umfasst Windows 11, Windows 10 und Windows Server 2025, und das Ziel ist, dass bestehende Anwendungen einfach weiterlaufen (It Just Works).² Mit anderen Worten: Die Antwort auf „wie lange läuft es noch” lautet – rein für die Ausführung, solange Windows selbst unterstützt wird.
• Dieser Support ist jedoch auf die Behebung schwerwiegender Regressionen und kritischer Sicherheitsprobleme in bestehenden Anwendungen beschränkt. Zudem ist die Laufzeitumgebung ausschließlich 32-Bit und wird unter 64-Bit-Windows nur innerhalb der WOW64-Umgebung unterstützt.²
• Das eigentliche Risiko ist nicht, dass etwas „nicht mehr läuft”, sondern dass man die Fähigkeit verliert, es zu reparieren. Die IDE zu beschaffen und zu erhalten wird jedes Jahr schwieriger, der Herstellersupport für verwendete OCX-Steuerelemente läuft aus, und die Menschen, die noch VB6 schreiben können, gehen in Rente oder wechseln den Job. Alle drei Entwicklungen schreiten unabhängig von der Support-Dauer von Windows selbst voran.
• Es gibt drei grundsätzliche Migrationsansätze: vollständige Neuentwicklung, automatisierte Konvertierung und schrittweise Migration. Als Erstes muss nicht der Ansatz entschieden werden, sondern die Bestandsaufnahme erfolgen – erst den Umfang von Bildschirmen, externen Integrationen, OCX-Steuerelementen und API-Deklarationen erfassen, dann den Ansatz wählen.
• Als Migrationszielsprache wird für alles neu Geschriebene C# empfohlen. Microsoft hat offiziell erklärt, dass VB.NET (Visual Basic) auf einem stabilen Design-Kurs liegt, ohne neue Syntax und ohne Erweiterung auf neue Workload-Typen.³

2. Die genaue Antwort auf „wie lange läuft es noch” — die Support-Richtlinie richtig lesen

Die VB6-Support-Richtlinie von Microsoft erklärt VB6 anhand von drei Komponenten.²

In der Tabelle der abgedeckten Betriebssysteme sind Windows 11, Windows 10 sowie Windows Server 2012 bis 2025 ausdrücklich als „Laufzeitumgebung: unterstützt”, „IDE: nicht unterstützt” gekennzeichnet.²

Es gibt drei zentrale Punkte für das richtige Verständnis.

Erstens ist der Support der Laufzeitumgebung vollständig dem Windows-Lebenszyklus untergeordnet. Es gibt kein eigenständiges Datum namens „Support-Ende der VB6-Laufzeitumgebung” – das Support-Ende der jeweils verwendeten Windows-Version ist unmittelbar die Frist.

Zweitens kommt der eigentliche Inhalt des Supports eher einer Garantie gleich, dass die Dinge „weiterlaufen”, als irgendetwas anderem. Behandelt werden nur schwerwiegende Regressionen (wenn ein Betriebssystem-Update eine bestehende Anwendung beschädigt) und kritische Sicherheitsprobleme – individuelle Untersuchungen oder Funktionsverbesserungen sind nicht enthalten.²

Drittens können VB6-Anwendungen künftig nur noch als 32-Bit-Prozesse existieren. Die Laufzeitumgebung ist ausschließlich 32-Bit und wird auf 64-Bit-Betriebssystemen nur innerhalb der WOW64-Emulationsumgebung unterstützt.² Sobald die Notwendigkeit entsteht, mit einer ausschließlich 64-Bit-fähigen DLL oder einem SDK zu interagieren, kann ein einzelner Prozess die Aufgabe nicht mehr allein bewältigen. Wie man diese Hürde überwindet, haben wir in „Eine COM-Brücken-Fallstudie: Aufruf einer 64-Bit-DLL aus einer 32-Bit-Anwendung” behandelt.

3. „Läuft” und „lässt sich warten” sind unterschiedliche Probleme

Betrachtet man nur die Support-Richtlinie, könnte man meinen: „Es besteht keine Eile.” In der Praxis bricht jedoch die Entwicklungs- und Wartungsumgebung deutlich früher zusammen als die Laufzeitumgebung.

• Die IDE ist nicht zu beschaffen. Die VB6-IDE wird auf aktuellen Betriebssystemen nicht unterstützt, und es wird jedes Jahr schwieriger, einen offiziellen Weg zur Beschaffung und Installation aufrechtzuerhalten. Es ist nicht ungewöhnlich, dass „nur eine einzige Maschine im ganzen Unternehmen” noch in der Lage ist, Korrekturen vorzunehmen.
• Der Herstellersupport für OCX-Steuerelemente von Drittanbietern ist ausgelaufen. Die Support-Richtlinie selbst stellt klar, dass Steuerelemente von Drittanbietern in die Verantwortung des jeweiligen Herstellers fallen.² Häufig sind OCX-Steuerelemente für Tabellen oder Berichte bereits nicht mehr erhältlich, und die Entscheidungslogik, die wir in „Wie man heute mit ActiveX / OCX umgeht” dargelegt haben, lässt sich hier direkt anwenden.
• Die Menschen, die es schreiben können, verschwinden. Das ist kein Problem der Sprachspezifikation, sondern ein Personalproblem. Kaum ein neuer Ingenieur lernt heute VB6, sodass die Zahl der Personen, die die Wartung übernehmen können, stetig sinkt.
• Begleitanforderungen stoßen an die 32-Bit-Grenze. Neue Geräte-SDKs, Authentifizierungsbibliotheken und Cloud-Integrationen setzen zunehmend 64-Bit und .NET voraus, und die Anforderungen, die sich nicht in einen VB6-Prozess integrieren lassen, häufen sich.

Mit anderen Worten: „Wie lange läuft es noch” ist nur die halbe Frage. Die andere Hälfte lautet: „Wird man, wenn die nächste Korrektur nötig wird, noch die Leute und die Umgebung haben, um sie durchzuführen?” Migrationspläne müssen nicht erst nach einem Ausfall aufgestellt werden, sondern solange die Menschen und die Umgebung, die eine Korrektur ermöglichen, noch vorhanden sind.

4. Eine Entscheidungstabelle für Migrationsansätze

Selbst wenn die Entscheidung „ersetzen” gefallen ist, gibt es eine Bandbreite an Vorgehensweisen. Hier ein Überblick über die wichtigsten Ansätze.

Welcher Ansatz gewählt wird, entscheidet sich nicht allein anhand der Codezeilenzahl. Microsoft selbst verweist bei der Migration neben offiziellen Leitfäden auch auf Upgrade- und Migrationspartner (einschließlich Anbietern von Migrationswerkzeugen)¹, sodass die mechanische Konvertierung eine real existierende, praktikable Option ist. Unabhängig vom gewählten Ansatz bleibt jedoch die Bestandsaufnahme aus dem nächsten Kapitel eine gemeinsame Voraussetzung.

Zu beachten ist, dass die praktischen Aspekte der Wahl „Ist-Zustand beibehalten + dokumentieren” (Fixierung der Laufzeitumgebung, Backups, Umgang mit dem Risiko) im vorherigen Artikel zu VB6 / Access behandelt werden.

5. Bestandsaufnahme vor der Migration — was vor dem Anfassen des Codes zu untersuchen ist

Die Genauigkeit der Schätzung und der Wahl des Ansatzes hängt jeweils von der Genauigkeit der Bestandsaufnahme ab. Listen Sie mindestens Folgendes auf.

1. Eine Liste der Bildschirme und Berichte — die Anzahl der Formulare, die tatsächlich genutzten Bildschirme (die Migration ungenutzter Bildschirme ist verschwendeter Aufwand), die Berichtstypen und ihr Ausgabeziel (direkter Druckerausdruck oder über Excel)
2. Eine Liste der externen Integrationen — welche der Technologien ADO/DAO/RDO für die Datenbank verwendet wird und wozu sie eine Verbindung herstellt, Datei-Ein-/Ausgabe, serielle oder Socket-Kommunikation, Aufrufe anderer Systeme
3. Eine Liste der OCX-/ActiveX-/COM-Referenzen — diese lassen sich mechanisch aus den Referenzen der Projektdatei (.vbp) extrahieren. Die Verfügbarkeit jeder Komponente und das Vorhandensein von Alternativen wirken sich direkt auf die Wahl des Ansatzes aus
4. Eine Liste der Win32-API-Deklarationen (Declare-Anweisungen) — klassifizieren Sie jede nach dem Verwendungszweck der API (Drucken, Lesen/Schreiben von INI-Dateien, Fensterbedienung usw.) und ob sie sich durch eine .NET-Standardfunktion ersetzen lässt
5. Geschäftsregeln, die nur im Code existieren — Rundungsverhalten, Stichtage, kundenspezifische Ausnahmen und Ähnliches. Stellen, bei denen „niemand weiß, warum das so geschrieben wurde”, sind genau der Nährboden für Fehler nach der Migration
6. Ob ein Testverfahren vorhanden ist — womit das migrierte Verhalten verglichen wird, um die Korrektheit zu bestätigen. In den meisten Fällen ist der Abgleich mit der Ausgabe des Altsystems (Berichte, CSV, Datenbankinhalte) das praktikabelste Verifizierungsmittel

Diese Bestandsaufnahme ist auch dann nicht umsonst, wenn am Ende keine vollständige Neuentwicklung gewählt wird. Im Gegenteil: Es ist üblich, dass die Ergebnisse der Bestandsaufnahme einen Ansatzpunkt für eine schrittweise Migration offenbaren – etwa „wir dachten, eine vollständige Neuentwicklung sei nötig, aber tatsächlich lässt sich die Kernlogik auf die Datenbankseite verlagern” oder „die Migration nur dieser zehn Bildschirme reicht bereits aus, um die 64-Bit-Hürde zu überwinden”.

6. Wichtige Inkompatibilitäten zwischen VB6 und .NET

VB6 und VB.NET/C# sind weiter voneinander entfernt, als es die Namen vermuten lassen. Ob bei mechanischer Konvertierung oder manueller Neuentwicklung – die folgenden Unterschiede erfordern stets Entwurfsentscheidungen.

Wichtig ist hierbei, sich von der schieren Menge an Inkompatibilitäten nicht so überwältigen zu lassen, dass die vollständige Neuentwicklung als einzige Option erscheint. Im Gegenteil: Die bloße Tatsache, dass die Assets auf der linken Seite dieser Tabelle (VB6) heute noch korrekt funktionieren, ist selbst die beste Spezifikation, die man für die Migration hat. Das alte System parallel als „lebende Spezifikation” laufen zu lassen und die Ausgaben im Verlauf abzugleichen, ist in der Praxis der zuverlässigste Weg.

7. Praxisnahe Muster für die schrittweise Migration

Wenn ohne Betriebsunterbrechung migriert wird, wird die Frage, wie Alt und Neu koexistieren, zum entscheidenden Punkt. Hier drei typische Muster.

7.1 Zuerst die Datenschicht migrieren

Bei diesem Aufbau werden die Daten der VB6-Anwendung zunächst von einer Access-Datei oder einem proprietären Format beispielsweise zu SQL Server migriert, während die VB6-Seite einfach durch Umstellung des Verbindungsziels weiterläuft. Sind die Daten erst einmal modernisiert, können neue Bildschirme (auf der .NET-Seite) schrittweise hinzugefügt werden, die auf dieselbe Datenbank zugreifen. Die konkreten Schritte im Zusammenhang mit Access finden Sie im Kapitel zum Upsizing im vorherigen Artikel.

7.2 Neue Funktionen und Bildschirme in .NET erstellen, verbunden über COM-Interop

Bei diesem Aufbau bleiben die bestehenden VB6-Bildschirme unverändert, während neue Funktionen in .NET erstellt werden, um mit ihnen zu koexistieren. Es gibt zwei Richtungen.

• Komponenten auf der .NET-Seite von VB6 aus aufrufen: Wird eine .NET-Klasse als COM offengelegt, kann VB6 sie als gewöhnliche COM-Komponente referenzieren. Wie man sie auch unter .NET 8 und neuer typisiert offenlegt, haben wir in „Eine .NET-8-DLL typisiert aus VBA aufrufen — dscom und die TLB” erklärt; dieselbe Idee gilt auch, wenn der Aufrufer VB6 statt VBA ist.
• Assets auf der VB6-Seite von .NET aus aufrufen: Eine in VB6 erstellte ActiveX-DLL kann von .NET aus über COM-Interop referenziert werden. Das ist nützlich, wenn die bestehende Logik als Block unverändert erhalten bleiben soll und zunächst nur die Bildschirme auf .NET modernisiert werden. Die 32-Bit-Einschränkung bleibt dabei jedoch bestehen, daher sollte dies als Brücke für die Migrationsphase behandelt werden, nicht als dauerhafte Lösung.

7.3 Prozesse trennen und darüber integrieren

Bringt man Alt und Neu über COM-Interop im selben Prozess unter, stößt man auf Einschränkungen bei der Bitness (32-Bit/64-Bit) und der Ausbreitung von Störungen. Wird eine neue 64-Bit-Funktionalität benötigt, oder sollen Störungen zwischen Alt und Neu isoliert werden, trennt man sie in separate Prozesse und integriert sie über Dateien, Named Pipes, localhost-Kommunikation und Ähnliches. Die Optionen für die Prozessintegration haben wir in „Eine Entscheidungstabelle für Windows-IPC” zusammengefasst, ein konkretes Beispiel für eine 32-Bit→64-Bit-Brücke in der „COM-Brücken-Fallstudie”.

Das allen Mustern gemeinsame Prinzip lautet: „die Grenze zwischen Alt und Neu an einer einzigen Stelle bündeln und das Datenformat, das diese Grenze überschreitet, festlegen”. Vervielfachen sich die Grenzen bildschirm- oder funktionsweise unkoordiniert, frisst der Aufwand der Koexistenzphase den erhofften Nutzen der Migration wieder auf.

8. Die Migrationszielsprache — C# oder VB.NET?

Man neigt zu der Annahme, „von VB6 kommend sei VB.NET die naheliegende Wahl”, aber angesichts der aktuellen Sprachstrategie von Microsoft ist das nicht so einfach.

Die offizielle Sprachstrategie positioniert Visual Basic (VB.NET) als „eine zugängliche und vertraute Sprache, die ein stabiles Design bewahrt”, und erklärt ausdrücklich, dass neue Funktionen grundsätzlich auf Konsum (consumption-only) beschränkt sind, keine neue Syntax hinzugefügt wird und keine Erweiterung auf neue Workload-Typen erfolgt. Gleichzeitig soll die Investition in Kernszenarien wie Windows Forms und Bibliotheken sowie die Verbesserung der Entwicklungserfahrung in Visual Studio fortgesetzt werden.³

Aus Sicht der Migration lässt sich das wie folgt zusammenfassen.

• Auch bei der Wahl von VB.NET funktionieren bestehende Szenarien (WinForms-Geschäftsanwendungen) auf absehbare Zeit problemlos weiter. Für Teams mit vielen VB6-erfahrenen Personen, bei denen die syntaktische Nähe die Lernkosten senkt, ist dies eine vernünftige Wahl.
• Als Grundlage für alles, was künftig neu geschrieben wird, wird jedoch C# empfohlen. Sprache und Ökosystem entwickeln sich weiter, und das Angebot an Beispielen, Bibliotheken und Fachkräften konzentriert sich auf C#. Dies ist eine Entscheidung, um zu vermeiden, dass sich das Problem „keine VB6-Wartungskräfte mehr” in zehn Jahren als Problem „keine VB.NET-Wartungskräfte mehr” wiederholt.
• Als Kompromiss lässt sich auch die Ausgabe des Konvertierungstools in VB.NET übernehmen, während die Neuentwicklung in C# geschrieben wird. In .NET können Assemblies beider Sprachen sich gegenseitig referenzieren, sodass das Mischen von Sprachen an sich kein Hindernis darstellt.

Zur Wahl des UI-Frameworks (WinForms / WPF / WinUI) siehe „Eine Entscheidungstabelle für WinForms, WPF und WinUI”; was bei einer direkten Migration zum aktuellen .NET statt zu .NET Framework zu prüfen ist, siehe die „Checkliste vor der Migration von .NET Framework zu .NET”. Sofern keine Einschränkungen durch referenzierte Bibliotheken bestehen, gibt es keinen guten Grund, bei einer Migration von VB6 bewusst .NET Framework 4.8 als neues Ziel zu wählen.

9. Zusammenfassung

• Die Antwort auf „wie lange läuft VB6 noch” lautet: Die Laufzeitumgebung ist unterstützt, solange Windows selbst unterstützt wird (einschließlich Windows 11). Der Support der IDE endete jedoch bereits 2008, sodass es bereits keinen offiziellen Rückhalt mehr für den Neuaufbau oder die Korrektur des Codes gibt – ein asymmetrischer Zustand.²¹
• Die wahre Frist wird nicht vom Betriebssystem festgelegt, sondern davon, ob die Umgebung und die Menschen, die eine Korrektur ermöglichen, noch vorhanden sind. Stellen Sie den Migrationsplan nicht erst nach einem Ausfall auf, sondern solange das Altsystem noch als „lebende Spezifikation” genutzt werden kann.
• Es gibt drei Ansätze: vollständige Neuentwicklung, automatisierte Konvertierung und schrittweise Migration. Bevor Sie sich für einen entscheiden, nehmen Sie eine Bestandsaufnahme von Bildschirmen, externen Integrationen, OCX-Steuerelementen, API-Deklarationen und Geschäftsregeln vor, die nur im Code existieren.
• Bei Migrationen, die den Betrieb nicht unterbrechen dürfen, lassen Sie Alt und Neu über Datenschicht-Vorrang, COM-Interop oder Prozesstrennung koexistieren – und bündeln Sie die Grenze an einer Stelle.
• Für alles neu Geschriebene wird C# empfohlen. Der stabile Kurs von VB.NET ist offizielle Politik³, und C# hat als Grundlage für die langfristige Wartung einen Vorteil.

Verwandte Artikel

• Verlängerung und Migration von VB6-/Access-Geschäftsanwendungen - eine Entscheidungstabelle für Beibehalten, Umhüllen und Ersetzen
• Wie man heute mit ActiveX / OCX umgeht - eine Entscheidungstabelle für Beibehalten, Umhüllen und Ersetzen
• Eine COM-Brücken-Fallstudie: Aufruf einer 64-Bit-DLL aus einer 32-Bit-Anwendung
• Eine .NET-8-DLL typisiert aus VBA aufrufen - dscom und die TLB
• Checkliste vor der Migration von .NET Framework zu .NET
• Eine Entscheidungstabelle für WinForms, WPF und WinUI
• Was ist VBA - Einschränkungen, Zukunftsaussichten, Fälle, in denen es ersetzt werden sollte, und realistische Migrationsmuster

Verwandte Beratungsbereiche

Die KomuraSoft LLC (合同会社小村ソフト) übernimmt die Bestandsaufnahme bestehender Assets einschließlich VB6 und die Ausarbeitung der Migrationsstrategie, den Entwurf und die Umsetzung von Koexistenzarchitekturen zwischen Alt und Neu über COM-Brücken und Prozesstrennung sowie schrittweise Ersetzungsprojekte hin zu .NET.

• Nutzung bestehender Assets und Migrationsunterstützung
• Überarbeitung und Wartung bestehender Windows-Software
• Windows-App-Entwicklung
• Technische Beratung und Design-Review
• 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.

Laufen VB6-Anwendungen noch unter Windows 11?

Ja, sie fallen in den unterstützten Bereich. Gemäß der Support-Richtlinie von Microsoft bleibt die VB6-Laufzeitumgebung (msvbvm60.dll und zugehörige Dateien) unterstützt, solange die Windows-Version, mit der sie ausgeliefert wird, selbst unterstützt wird. Die Liste der abgedeckten Betriebssysteme umfasst Windows 11, Windows 10 und Windows Server 2025. Dieser Support beschränkt sich jedoch auf die Behebung schwerwiegender Regressionen und kritischer Sicherheitsprobleme in bestehenden Anwendungen. Zudem ist die VB6-Laufzeitumgebung ausschließlich 32-Bit, und unter 64-Bit-Windows wird sie nur innerhalb der WOW64-Kompatibilitätsumgebung unterstützt.

Lässt sich eine Migration von VB6 zu .NET allein mit einem automatisierten Konvertierungstool abschließen?

Man sollte davon ausgehen, dass dies nicht möglich ist. Konvertierungstools können den Aufwand für das Neuschreiben von Bildschirmdefinitionen und einfacher Logik reduzieren, aber Dinge wie die Fehlerbehandlung über On Error, Code, der vom Variant-Typ oder von Standardeigenschaften abhängt, ActiveX-Steuerelemente und Win32-API-Deklarationen erfordern menschliche Entwurfsentscheidungen und Korrekturen. Anstatt die Rohausgabe des Tools direkt in den Produktivbetrieb zu übernehmen, muss das gesamte Projekt einschließlich der 'manuellen Nacharbeit nach der Konvertierung' geschätzt werden, und die Methode zur Verifizierung des konvertierten Ergebnisses – etwa Parallelbetrieb oder Ausgabenvergleich – sollte vorab festgelegt werden.

Sollte als Migrationsziel VB.NET oder C# gewählt werden?

Für alles neu Geschriebene wird C# empfohlen. Die Sprachstrategie von Microsoft positioniert Visual Basic (VB.NET) als Sprache mit stabilem Design und erklärt ausdrücklich, dass keine neue Syntax hinzugefügt und keine Erweiterung auf neue Workload-Typen erfolgen wird. Die Investitionen in bestehende Szenarien wie Windows Forms werden fortgesetzt, sodass VB.NET nicht unbrauchbar wird, aber als Grundlage für Code, der die nächsten zehn Jahre gepflegt werden muss, hat C# – dessen Sprache und Ökosystem sich weiterentwickeln – einen Vorteil bei der Verfügbarkeit von Fachkräften. Teams mit vielen VB6-erfahrenen Entwicklern können angesichts der syntaktischen Nähe durchaus vernünftigerweise den Umweg über VB.NET wählen.

Was sollte vor einer vollständigen Neuentwicklung zuerst geschehen?

Bevor auch nur eine Codezeile geschrieben wird, sollte eine Bestandsaufnahme erfolgen. Konkret: eine Liste der Bildschirme und Berichte, eine Liste der externen Integrationen (Datenbanken, Dateien, serielle Kommunikation, andere Systeme), eine Liste der referenzierten OCX-/ActiveX-Steuerelemente und COM-Komponenten, eine Liste der Win32-API-Deklarationen (Declare-Anweisungen) sowie eine Erhebung der Geschäftsregeln, die nur im Code existieren. Die Ergebnisse dieser Bestandsaufnahme zeigen sehr häufig, dass eine schrittweise Migration – bei der nur ein Teil des Systems herausgelöst oder zunächst die Datenschicht verlagert wird – realistischer ist als eine vollständige Neuentwicklung.

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.