Software ist heute ein wichtiger Teil vieler Unternehmen. Die Technologie entwickelt sich kontinuierlich weiter und die Entwicklungszyklen werden dabei immer kürzer. Um konkurrenzfähig zu bleiben, müssen Unternehmen in der Lage sein, Schritt mit der laufenden technologischen Entwicklung zu halten. Zwangsläufig steht jedes Unternehmen vor der Frage: Eine Softwaremigration durchführen oder das Anwendungssystem neu erstellen? 

Eine vollständige Neuentwicklung eines komplexen Softwaresystems ist i. d. R. sehr aufwendig, zeit- und kostenintensiv. Alternativ zur Neuentwicklung werden gängige Szenarien der Softwaremigration geprüft:

• Re-Implementierung: In diesem Fall bleibt die Architektur des Systems erhalten, der Quellcode wird jedoch neu erstellt, etwa unter Einsatz einer neuen Programmiersprache. Es gibt eine wichtige Voraussetzung: Die grundsätzliche Struktur der ursprünglichen Lösung muss weiterhin geeignet sein. Die Neucodierung basiert darauf, dass alle dafür notwendigen Informationen aus dem Altsystem übernommen werden. Gegenüber der vollständigen Neuentwicklung bleibt also der bisherige Lösungsansatz erhalten.
   
• Konversion: In diesem Fall geht es um eine automatisierte Transformation der Daten bzw. Programme in die für die Zielumgebung notwendige Form. Voraussetzung ist das Verständnis des Altsystems. Diese Transformation wird teilweise mittels Reverse Engineering-Techniken erreicht. Darunter versteht man die automatische Überführung des Programmcodes von einer Sprache in eine andere. Einschränkend muss dazu gesagt werden, dass dieses Vorgehen meist nur bedingt automatisiert erfolgen kann. Oft sind Anpassungen an vielen Stellen des Programmcodes notwendig, d. h. es ist größtenteils nicht mit einer „Übersetzung“ von einer in eine andere Programmiersprache getan.

• Kapselung: Hier bleiben die Daten und Programme des Altsystems in ihrer ursprünglichen Umgebung bestehen. Diese werden von einem sogenannten Wrapper umhüllt und geeignete Zugriffsschnittstellen werden implementiert. Auf diese Art und Weise kann man über das Neusystem auf die Dienste des Altsystems zugreifen. Die Kapselung ist, im Gegensatz zur Konversion, oft die ökonomisch sinnvollere Methode der Weiterverwendung. Die Systemschnittstellen werden durch ein Reengineering verändert und der Legacy-Code bleibt unverändert. Im Vergleich zu anderen Strategien ist dieses Vorgehen kostengünstiger und im Risiko kleiner. Voraussetzung ist jedoch, dass das Altsystem hinsichtlich der Funktionalität noch brauchbar ist. Sind Fehlerkorrekturen oder Anpassungen notwendig, müssen diese in der Programmiersprache und Systematik des Altsystems vorgenommen werden.

Migrationsprojekte sind i. d. R. komplexe Vorhaben, die aus unterschiedlichen Perspektiven beurteilt werden. Vor allem geht es um die Abwägung der Alternativen:

„Lohnt sich eine Migration oder ist die Neuentwicklung sinnvoller?“

Es ist wichtig zu beachten, dass die Entscheidung zwischen Migration und Neuentwicklung von vielen Faktoren abhängt, einschließlich der Komplexität der vorhandenen Software, der vorhandenen technischen Schulden, den Geschäftsanforderungen und des verfügbaren Budgets.
Oft ist eine Migration kostengünstiger, da viele Teile der benötigten Funktionalität bereits vorhanden sind und nur aktualisiert oder angepasst werden müssen. Anpassung und Überarbeitung können meist auch zeitnah erledigt werden. Die Neuentwicklung einer Software erfordert dagegen viel Zeit für die Aufgaben der Planung, des Entwurfs, der Entwicklung, des Testen und der Bereitstellung. 

Wenn das Team, das an der ursprünglichen Softwareentwicklung beteiligt war, noch verfügbar ist, kann dieses Fachwissen für eine Softwaremigration von unschätzbarem Wert sein. Auch Anwender*innen, welche die Software einsetzen, müssen sich bei einer migrierten Software nicht an eine völlig neue, komplett geänderte Benutzeroberfläche oder Funktionalität gewöhnen. Auf diese Weise kann die Akzeptanz der Anpassung erhöht werden. Bei guter Planung der Migrationsschritte kann die Ausfallzeit minimiert werden, da viele Teile der Software bereits funktionieren und nach der Übernahme in das migrierte System lediglich aktualisiert werden müssen. Erfahrungen und Erkenntnisse aus der vorhandenen Software dienen als eine gute Basis für die Durchführung. In der Praxis hat sich eine hybride Herangehensweise bewährt, bei der Teile der Software migriert und andere Teile neu entwickelt werden. 

Arten der Softwaremigration

Entscheidet man sich für eine Softwaremigration, so ist eine gute Planung von entscheidender Bedeutung. Welche Teile und in welchem Umfang sollen migriert werden? Soll eine komplexe Systemmigration vorgenommen werden oder geht es nur um eine Teilmigration? Die Systemmigration ist umfassend und komplex. Hier sind alle Ebenen des Anwendungssystems betroffen. Bei einer Teilmigration unterliegen nur einige Teile des Systems der Anpassung. 

Die folgenden Ausführungen gehen auf die relevanten Aufgaben von Teilmigrationen genauer ein:

• Datenmigration: Die Programme bleiben in der bisherigen Form bestehen. Es werden nur die Daten vom Alten in das Neusystem übertragen. Die Daten können in ein anderes Datenbanksystem auf derselben Systemplattform oder auch mit unveränderter Datenhaltung auf eine andere Plattform übertragen werden. Ein typischer Anwendungsfall liegt vor, wenn das bisher verwendete Datenbanksystem durch ein anderes ausgetauscht werden soll. Welche Gründe können diesen Schritt notwendig machen? Zum Beispiel kann die Leistungsfähigkeit den aktuellen Ansprüchen nicht mehr genügen. Vielleicht aktualisiert auch der Hersteller das System nicht mehr, sodass Fehlerbereinigungen bzw. Sicherheitsupdates nicht mehr vorgenommen werden. Wichtig: Für die Nutzer*innen wird diese Art der Migration nicht direkt sichtbar. Dennoch ist diese Form der Softwaremigration gerade bei einem erheblichen Anstieg der zu verwaltenden Daten oft notwendig.
   
• Programmmigration: Die Daten bleiben unverändert im vorhandenen Datenhaltungssystem, zum Beispiel in der gewählten SQL-Datenbank. Es erfolgt eine Migration der Anwendungsprogramme. Diese können in eine andere Sprache in der gleichen Umgebung, in derselben Sprache in eine andere Umgebung oder in eine andere Sprache in eine andere Umgebung migriert werden. Der Grund einer solchen Migration ist i. d. R., dass sich neue Programmfunktionen in der bisherigen Applikation nicht oder nur noch erschwert umsetzen lassen. Der technische Fortschritt hat dazu geführt, dass Applikationen zu aktuellen Zeitpunkten mit anderen Methoden und Techniken erstellt werden, als es dies zum Erstellungszeitraum des Altsystems der Fall war. Um die Zukunftsfähigkeit des Softwaresystems zu erhalten, muss man dieses jedoch an die technische Weiterentwicklung anpassen. Das System der Datenhaltung gilt jedoch noch mindestens mittelfristig als zukunftssicher, wenn man hier aktuell keine Änderungen vornehmen möchte. Inwieweit die Nutzer*innen von der Migration betroffen sind, hängt davon ab, ob dieses Vorgehen Auswirkungen auf die Benutzeroberfläche hat und ob Funktionen des Systems geändert werden, hinzukommen oder entfallen.
   
• Benutzeroberflächenmigration: Bei dieser Migrationsart bleiben die Programme und die Daten unverändert. Ausgetauscht werden die Programmteile, welche für die Benutzerinteraktion zuständig sind, üblicherweise also die Benutzerschnittstellen. Diese Art der Migration ist für die Endanwender*innen am meisten sichtbar. Im Sinne eines umfassenden „Faceliftes“ kann eine Auffrischung der Applikation erreicht werden. Voraussetzung für eine Beschränkung der Migration auf das User Interface ist es, dass die restlichen Programmteile – d. h. die Programmlogik, das System der Datenhaltung usw. – noch in einem akzeptablen technischen Zustand sind. Eine Benutzeroberflächenmigration kann beispielsweise auch zu einer Änderung der Anwendungsart führen. Dabei können Desktop-Applikationen zu Web-Anwendungen migriert werden oder eine Software wird auch für die Nutzung auf mobilen Endgeräten fit gemacht. Eine Benutzeroberflächenmigration umfasst daher vornehmlich auch Aspekte einer Programmmigration. Der Schwerpunkt liegt jedoch darauf, dass man die Oberfläche transformieren möchte.
   
• Schnittstellenmigration: Diese Migrationsart findet immer dann Anwendung, wenn ein bestehendes System oder Systemteile mit neuen oder bereits migrierten Systemen kommunizieren müssen, d. h. die Schnittstellen des alten Systems müssen angepasst werden, um hier für Kompatibilität zu sorgen.

Vom Desktop ins Web

Dieser Abschnitt betrachtet einen typischen Anwendungsfall der Softwaremigration in der Praxis. Viele Migrationsprojekte, welche als Desktopapplikationen gestartet sind, haben das Ziel, daraus eine Web-Applikation zu machen.

Webapplikationen gewinnen immer mehr Interesse in vielen Bereichen. Ihre Vorteile sind eindeutig und leicht nachvollziehbar. Sie können plattformunabhängig und ohne Installation in jedem Browser und auf jedem Gerät ausgeführt werden. Die Installation und die laufende Wartung erfolgen zentral auf dem Server oder über einen Cloud-Dienst. Die Clients greifen über das Netzwerk mit Hilfe eines Browsers auf die Anwendung zu. Updates werden direkt über den Server installiert und es bedarf keiner Eingriffe auf die Clients bei der Aktualisierung. Ein Mehrbenutzerbetrieb ist i. d. R. bei Webapplikationen Standard. Die Benutzerkonten sorgen für eine korrekte Zuordnung der Daten. Man kann Webapplikationen auch auf weniger leistungsfähiger Hardware ausführen, d. h. die Applikation läuft auf dem Server und kann i. d. R. von nahezu allen Browsern verwendet werden. Die Wartungs- und Bereitstellungskosten von Webanwendungen liegen meist um ein Vielfaches unter denen einer Desktopanwendung.

Oftmals werden Webanwendungen als sogenannte Single Page Applikationen (SPA) erstellt. Hier kommt lediglich ein einziges HTML-Dokument zum Einsatz. Innerhalb des Dokumentes werden neue oder veränderte Daten dynamisch geladen. Die Aktualisierung der Darstellung erfolgt dann zum Beispiel auf der Basis einer DOM-Manipulation. Das Ergebnis sind reaktionsfreudige Anwendungen, welche in Fragen der User-Experience allen Anforderungen an ein modernes Softwaresystem genügen.

Toolunterstützung

Die Softwaremigration stellt keine einfache Aufgabe dar. Eine Toolunterstützung ist daher unverzichtbar. Für den skizzierten Fall einer Migration von einer Desktop- zu einer Web-Applikation wird in diesem Abschnitt das Szenario einer Toolunterstützung vorgestellt. 

Speziell geht es um Desktopanwendungen für das Betriebssystem Windows, welches mit dem Grafikframework Windows Forms und den Programmiersprachen C# bzw. Visual Basic .NET unter Verwendung des .NET-Frameworks erstellt wurden. Dieser Technology-Stack wurde in vielen Anwendungen genutzt. Als Migrationstool kann das Web-Framework Wisej.NET, welches speziell für die Migration und Erstellung von Unternehmensanwendungen konzipiert wurde, eingesetzt werden. Es erlaubt die Entwicklung von Webanwendungen mit einem Ansatz, welcher den Windows Forms-Anwendungen ähnlich ist. Auch hier erfolgt die Programmierung mithilfe von C# oder optional mit Visual Basic .NET. Ein zentrales Merkmal dieses Frameworks ist seine umfangreiche Komponentenbibliothek, die eine breite Palette von Steuerelementen zur Verfügung stellt.

Die Gestaltung der Benutzeroberfläche erfolgt während der Entwicklungsphase mithilfe eines grafischen Designers, der in Visual Studio integriert ist. Dies beschleunigt und vereinfacht die Erstellung von Webanwendungen erheblich. Für alle relevanten grafischen Steuerelemente einer bestehenden Windowsform-Applikation gibt es eine modernisierte und neu gestaltete Entsprechung mit einem fast identischen Funktionsumfang, gleichen Eigenschaften, Methoden und Ereignissen. Diese Analogie vereinfacht den Migrationsprozess und führt dazu, dass einfache Dialogfelder ohne weitere Anpassungen direkt übernommen werden können. Anpassungen der Funktion und des Designs können über neue, leistungsfähige Steuerelemente erreicht werden. 

Ein weiteres bedeutendes Feature ist das Konzept des Echtzeit-Updates, das eine schnelle Aktualisierung der Benutzeroberfläche ermöglicht, ohne dass die gesamte Seite neu geladen werden muss. Verkürzt und stark vereinfacht könnte man es so ausdrücken, dass man die Anwendungslogik bei der Softwaremigration vom Client auf den Server verlagert. Das Framework sorgt dann dafür, dass die ursprüngliche .NET-Anwendung auf dem Server ausgeführt wird und die Clients über den Browser diese aufrufen können. 

Die Unterscheidung zwischen der Server- und der Clientseite gestaltet sich folgendermaßen:

• Serverseite: Im Wisej.NET-Framework übernimmt der Server die zentrale Rolle, indem er die Kommunikation zwischen dem Client (dem Browser) und der Anwendung steuert. Der Server empfängt Anfragen vom Client, führt den entsprechenden Code aus und schickt die aktualisierte Benutzeroberfläche zurück zum Client. Außerdem verwaltet der Server den Anwendungszustand und speichert Informationen über die aktuelle Benutzersitzung. Die Ausführung der .NET-Anwendung erfolgt auf dem Server.
   
• Clientseite: Der Client bezieht sich hier auf den Webbrowser. Er repräsentiert die Benutzeroberfläche, verarbeitet Nutzerinteraktionen und sendet Anfragen an den Server. In dieser Sphäre werden hauptsächlich HTML, CSS und JavaScript verarbeitet. Die Verbindung zwischen Client und Server wird über Websocket- oder HTTP-Verbindungen hergestellt, um Echtzeitaktualisierungen zu ermöglichen (siehe Abbildung).