Um das Potenzial neuer Technologien zu nutzen, muss man bestehende Applikationen anpassen. Damit dabei möglichst viel Quellcode weiterverwendet werden kann, sind die richtige Strategie und ein durchdachter Werkzeugeinsatz entscheidend. Die umfassende Vernetzung und der anhaltende Trend zur Auslagerung jeglicher Infrastruktur in die Cloud erfordern besondere Herangehensweisen beim Aufbau moderner Software-Landschaften. Technologieansätze wie Docker, Microservice oder Responsive User Interface Design betreffen alle Bereiche eines modernen Software-Systems. Dem gegenüber steht der Status quo. Viele Applikationen existieren bereits seit Jahren. Oft sind es noch klassische Desktop- Anwendungen, die über eine Client-Server-Struktur mitei­nander verbunden sind. Sie haben sich bewährt und sind akzeptiert. Doch Wartung und Erweiterung erfordern einen immer grösseren Aufwand, sie werden fehleranfälliger und teuer. 

Eine Software-Migration in Unternehmen erfolgt im Wesentlichen aus den folgenden Gründen:

Jedes Unternehmen muss dabei als Erstes den optimalen Zeitpunkt für die Migration bestimmen. Viele Aufgaben lassen sich noch mit dem Altsystem lösen, viele künftige He­rausforderungen aber nicht mehr. Hinzu kommt, dass sich die Rolle der Informationstechnik, insbesondere der Software, gerade ganz erheblich verändert.

Historisch hat sich IT als technikgetriebener Dienstleister im Sinn eines «Werkzeugs» verstanden. Über viele Zwischenstufen verschiebt sich dieser Fokus mit dem digitalen Wandel hin zur Rolle eines Business-Innovators. Software liefert wichtige Beiträge zur Weiterentwicklung des Geschäftsmodells oder verändert es dauerhaft – und eröffnet die Chance auf echte Wettbewerbsvorteile. Je mehr eine Firma auf die Innovationskraft seiner Software-Systeme angewiesen ist, desto eher sollte sie sich für eine Migration eines Altsystems entscheiden.

Gegen den radikalen Schritt, Applikationen komplett neu zu entwickeln, sprechen der immens grosse Aufwand und die damit einhergehenden Kosten. Alternativ zur Neuentwicklung sind mehrere Szenarien der Software-Migration gängig:

Re-Implementierung: Alle für die Neucodierung notwendigen Informationen werden aus dem Altsystem übernommen. Die Architektur bleibt erhalten, der Quellcode wird neu erstellt, etwa in einer anderen Programmiersprache. Der bisherige grundsätzliche Lösungsansatz bleibt erhalten – dafür muss die Architektur sich aber auch eignen.

Konversion: Daten oder Programme werden automatisiert in die für die Zielumgebung notwendige Form transformiert, teils mittels Reverse Engineering. Darunter versteht man die automatische Überführung des Programmcodes von einer Sprache in eine andere. Aber: Die Entwicklung von Werkzeugen, die für eine qualitativ gute Konversion sorgen, ist aufwendig. Voraussetzung für diesen Ansatz ist zudem ein tiefes Verständnis des Altsystems.

Kapselung: Daten und Programme des Altsystems bleiben in ihrer ursprünglichen Umgebung bestehen, aber von einem sogenannten Wrapper umhüllt. Mittels Schnittstellen wird vom Neusystem aus auf die Dienste des Altsystems zugegriffen. Die Systemschnittstellen werden durch Re-Engineering verändert, der Legacy-Code bleibt bestehen. Eine Kapselung ist oft ökonomisch sinnvoller als eine Konversion. Im Vergleich zu den anderen Strategien ist dieses Vorgehen günstiger und risikoärmer. Voraussetzung ist aber, dass das Altsystem in puncto Funktionalität noch brauchbar ist. Sind Fehlerkorrekturen oder Anpassungen notwendig, müssen diese in der Sprache und Systematik des Altsystems vorgenommen werden.

Eine Alternative zur Software-Migration ist unter Umständen der Einsatz von Standard-Software. Weil sie für einen ano­nymen Markt erstellt worden ist, muss sie an die speziellen Anforderungen der Benutzer angepasst oder auf die betriebliche Ablauforganisation ausgerichtet werden (Customizing). Vorteile gegenüber der Entwicklung von Individual-Software sind geringere Entwicklungs- und Wartungskosten, schnellere Verfügbarkeit und kein Risiko von Fehlentwicklungen. Zudem lassen sich damit auch Anwendungen realisieren, bei denen keine oder nur unzureichende Qualifikationen für eine eigene Entwicklung vorhanden sind. Standard-Software verringert insofern die Abhängigkeit von den Entwicklern.

Standard-Software sollte immer vor anderen Szenarien der Software-Migration geprüft werden. Der technische Fortschritt kann dazu geführt haben, dass sich Ziele, die ursprünglich nur mittels Eigenentwicklung zu erreichen waren, nun über konfigurierbare Software-Bestandteile realisieren lassen.

Eine Software-Migration erfolgt meist nicht für das komplette System, sondern in Form von Teilmigrationen, wobei Teile des Altsystems zunächst oder auf längere Zeit erhalten bleiben. Man unterscheidet vier Arten von Teilmigrationen:

Datenmigration: Die Programme bleiben in der bisherigen Form bestehen. Es werden nur die Daten übertragen. Die Daten können in ein anderes Datenbanksystem auf derselben Systemplattform oder mit unveränderter Datenhaltung auf eine andere Plattform migriert werden. Typisch ist der Austausch des bisherigen Datenbanksystems, weil dessen Leistungsfähigkeit den Ansprüchen nicht mehr genügt oder der Hersteller sein System nicht mehr ausreichend aktualisiert. Für den Nutzer wird diese Art der Migration nicht direkt sichtbar. Dennoch ist sie 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 Programme. 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. Anstoss für eine solche Migration ist in der Regel, dass sich neue Programmfunktionen in der bisherigen Applikation nicht oder nur noch schwer umsetzen lassen, während das System der Datenhaltung selbst zumindest mittelfristig noch als zukunftssicher eingeschätzt wird.

Bedienoberflächenmigration: Hier bleiben Programme und Daten unverändert. Ausgetauscht werden nur die für die Benutzerinteraktion zuständigen Teile der Anwendung, üblicherweise die Benutzerschnittstellen. Diese Art der Migration ist für den Endanwender am meisten sichtbar. Voraussetzung für eine Beschränkung der Migration auf das User Interface ist, dass die restlichen Programmteile (Logik, Datenhaltung) noch in einem akzeptablen technischen Zustand sind.

Systemschnittstellenmigration: Diese Migrationsart findet immer dann Anwendung, wenn ein bestehendes System oder Teile davon mit neuen oder bereits migrierten Systemen kommunizieren müssen und deshalb die Schnittstellen des alten Systems angepasst werden müssen.

Kernaufgabe der Programmmigration ist die Umsetzung des Quellcodes in ein neues Anwendungssystem. Dabei kann es sich um einen Wechsel der Programmiersprache handeln, zum Beispiel VB.NET nach C# oder Java. Denkbar ist auch, dass bei Systemumgebung, Framework oder Klassenbibliotheken vollständig andere Lösungen zum Einsatz kommen.

Die Transformation des Programmcodes gilt als besondere Herausforderung. Oft weisen Altsysteme eine komplexe Businesslogik auf, deren Implementierung viel Aufwand verursacht hat. Eine Neuimplementierung wäre kaum weniger aufwendig und würde viele Ressourcen binden, die dann nicht für das Entwickeln neuer Features zur Verfügung stünden. Ziel ist es daher, Ansätze und Methoden zu finden, mit denen der Quellcode weitgehend automatisch in eine neue Programmiersprache oder ein neues Anwendungssystem transformiert werden kann. Voraussetzung dafür ist, dass die Programmlogik beibehalten werden kann. Ebenso müssen neue und alte Systemumgebung technisch ähnlich funktionieren. Manuelle Nacharbeiten werden aber in der Regel notwendig sein.

Sind die Unterschiede zwischen den Systemen zu gross, gibt es keine Tools zur Konvertierung oder sind Anpassungen an der Programmlogik notwendig, dann muss die Quellcode-Reimplementierung manuell erfolgen. Das ist zwar nicht so aufwendig wie eine vollständige Neuentwicklung, da der «alte» Quellcode gewissermassen als Vorlage dient. Viele Elemente aus der Logik können übernommen werden oder müssen nur etwas angepasst werden. Dennoch ist der gesamte Programmcode neu zu codieren. Die Entwickler müssen in beiden Programmier- und Systemumgebungen über umfassende Kenntnisse verfügen. Ist eine Reimplementierung zu aufwendig, technisch nur schwer umzusetzen oder soll das zu migrierende System nur noch mit einer begrenzten Laufzeit erhalten werden, ist eventuell die beschriebene Kapselung des alten Programmcodes die Lösung.

Unabhängig davon, für welchen Migrationsprozess man sich entscheidet, sind in jedem Fall Werkzeuge erforderlich, um den Prozess zu unterstützen. Neben den typischen Tools für die Software-Entwicklung wie Editoren, Entwicklungsumgebungen und Projektmanagement-Tools, kommen gezielt Werkzeuge für migrationsspezifische Aufgaben zur Anwendung, zum Beispiel für die Durchführung einer Codeanalyse, zur Schätzung des Aufwands, zur Automatisierung der Programmtransformation oder zur Konvertierung von Daten. Es kann sich um eigenständige Tools handeln oder um Erweiterungen für bekannte integrierte Entwicklungsumgebungen.

Microsoft Windows ist nach wie vor die gebräuchlichste Systemumgebung im betrieblichen Umfeld. Auch hier ist der Migrationsdruck aus vielen Gründen gross:

Viele Desktop-Applikationen sind in eine klassische Client-Server-Struktur eingebunden. Die Client-Software wurde dabei einst für unterschiedlichste Windows-Versionen entwickelt, deren Support schon länger beendet ist oder bald abläuft (siehe Tabelle auf Seite xy). Danach gibt es allenfalls noch kostenpflichtige Sicherheits-Updates. Zwar ist die grundsätzliche Bedienung von Windows-Anwendungen über die Jahre gleich geblieben, aber viele neue Funktionen, die heute üblich sind, standen früher nicht zur Verfügung. Ebenso haben sich Design und Aussehen der Bedienoberfläche geändert. Üblich sind heute etwa hochauflösende Monitore und der Einsatz der Software auf unterschiedlichen Geräteklassen. Um diese Anforderungen zu erfüllen, muss eine umfassende Anpassung erfolgen.

Migrationen von Windows-Anwendungen sind allein schon deshalb ein wichtiges Thema, weil auch künftig der Desktops stark im Zeichen von Windows stehen wird. Davon ist Jürgen Bucher überzeugt, Geschäftsführer des Ulmer Unternehmens BS software development, das Anwendungen für Arztpraxen, Labore und Krankenhäuser entwickelt: „Wir gehen davon aus, dass mittelfristig im Business-Umfeld der Windows-Desktop nach wie vor eine entscheidende Rolle spielen wird, sind aber mit unserer Migration hin zu Fire­Monkey-Lösungen auf alle anderslaufenden Entwicklungen vorbereitet», erklärt Bucher. FireMonkey ist ein plattform-übergreifendes GUI-Framework, das es Entwicklern erlaubt, Interfaces zu erstellen, die unter Windows, MacOS, iOS und Android laufen.

Für Business-Windows-Applikationen, die auf der Basis von Delphi und C++-Builder erstellt wurden, gibt es eine effektive Möglichkeit zur Migration von Windows-Anwendungen mit der Entwicklungsumgebung RAD Studio von Embarcadero, bei der möglichst viel Programmcode direkt oder nur geringfügig angepasst weiterverwendet werden soll. RAD Studio bietet dafür zahlreiche Features. «Da wir immer mal wieder auch alte Sonderentwicklungen überarbeiten müssen, ist es für uns sehr wichtig, auch ,veralteten‘ Sourcecode mit neuen Delphi-Versionen öffnen und aktualisieren zu können», betont etwa Jürgen Bucher.

Besonders erwähnenswert ist die Chance, eine bisher nur auf einem Desktop-System laufende Applikation mit vertretbarem Aufwand auch für andere Geräte (Smartphone) und Betriebssysteme (Linux, iOS, Android) zur Verfügung zu stellen. Dabei können oft sehr grosse Teile des Quellcodes für die Businesslogik aus dem Quellcode der Desktop-Applikation übernommen werden. Möglich macht dies das Grafik-Framework FireMonkey, das für alle gewünschten Zielsysteme zur Verfügung steht. «Insbesondere im Hinblick auf die Kompilierung unserer Lösungen für andere Betriebssysteme und Hardware-Plattformen spielt die Migration unserer Lösungen hin zu FireMonkey eine erhebliche Rolle. Sämtliche bestehenden Kernprodukte und alle Neuentwicklungen werden von uns nach FireMonkey migriert», berichtet Jürgen Bucher.

Oft soll bei einer Migration auch die Architektur des Anwendungssystems geändert werden. Typisch ist die Überführung einer Client-Server-Applikation in ein REST-fähiges Software-System mit moderner Microservice-Architektur. Dabei wird die Businesslogik vom lokalen Client (Desktop-Applikation) auf den Server verlagert, die Services stehen über das Netzwerk einer beliebigen Anzahl von Clients zur Verfügung.

Die Implementierung von REST-fähigen Services basiert in der Regel auf ganz anderen technischen Voraussetzungen als Desktop-Applikationen. In diesem Fall müsste die Geschäftslogik eigentlich vollständig neu implementiert werden. Eine effektive Software-Migration sollte dennoch grosse Bestandteile an Quellcode bewahren können.

Liegt die Legacy-Applikation als Delphi- und/oder C++-Quellcode vor, kann das zum Beispiel gelingen, wenn die gesamte Entwicklung in RAD Studio unter dem Einsatz fertiger Komponenten erfolgt. Neuer oder bestehender Delphi- und/ oder C++-Code kann dabei auf den RAD Server transformiert werden. Oft sind keine oder nur minimale Codeanpassungen notwendig, um Backend-Code für Clients über REST/JSON-Endpunkte bereitzustellen.

Das Hosting des RAD Servers kann auf Cloud-Plattformen wie Azure oder AWS oder auf lokalen Servern geschehen (um höhere Anforderungen bei Datenschutz und Datensicherheit zu erfüllen). Folgende Funktionen sind verfügbar:

Ein zweites häufiges Szenario ist der Wechsel auf eine moderne Web-Applikation, denn die bieten eine Reihe von Vorteilen:

Installation: Es ist nur eine In­stallation auf dem Server notwendig. Die Clients greifen über das Netzwerk mit Hilfe eines Browsers auf die Anwendung zu.

Aktualität: Updates werden direkt ohne Eingriffe auf den Clients über den Server installiert.

Multi-User: Mehrbenutzerbetrieb ist meist der Standard. Benutzerkonten sorgen für eine korrekte Zuordnung der Daten.

Systemanforderungen: Web-Applikationen lassen sich auch auf weniger leistungsfähiger Hardware ausführen. Die Applikation läuft also auf dem Server und kann in der Regel von nahezu allen Browsern verwendet werden.

Kosten: Die Wartungs- und Bereitstellungskosten liegen oft um ein Vielfaches unter denen einer Desktop-Anwendung.

Für die Umsetzung von Web-Applikationen gibt es mehrere Strategien, die vor allem davon abhängen, welche Aufgaben vom Client und vom Server übernommen werden. Viele Desktop-Anwendungen wurden mit Visual Basic, C# oder VB.NET und Windows Forms (User Interface) erstellt. Typisch sind oft komplexe Bedienoberflächen mit einer Vielzahl von Dialogen und Steuerelementen. Derartige bestehende Applikationen als Web-Applikationen komplett neu zu erstellen, wäre sehr aufwendig. Dieses Vorgehen wäre auch deshalb wenig wirtschaftlich, da die typischerweise genutzten Technologien ein schnelles Erstellen komplexer Bedienoberflächen nicht unterstützen.

Eine Lösung kann das Framework Wisej sein. Damit gelingt es Entwicklern ohne tiefere Kenntnisse in den Web-Technologien, moderne Web-Applikationen zu erstellen. Alternativ können C# oder VB.NET als Programmiersprache eingesetzt werden, um in Visual Studio zu entwickeln. Mit Hilfe eines grafischen Designers erstellt man dabei das User Interface auf der Basis von Komponenten. Die Vorgehensweise ist den meisten Entwicklern vertraut, denn seit Jahren werden auf die gleiche Weise Desktop-Applikationen erstellt.

Die Komponenten von Wisej sind weitgehend zu Windows- Forms-Komponenten kompa­tibel, einem GUI-Toolkit des .NET-Frameworks von Micro­soft. Das macht Wisey ideal für umfassende Migrationsvorhaben. Oft muss das bestehende Projekt lediglich in der Entwicklungsumgebung Visual Studio geöffnet werden, um einige Anpassungen an der zentralen Projektdatei vorzunehmen. Ist Wisej in Visual Studio installiert, genügt dann ein neuer Build des Projekts, um daraus eine Web-Applikation zu erstellen.

Der Vorteil: Man muss sich keine Gedanken über das Zusammenspiel der Web-Technologien machen und kann sich vollständig auf die Umsetzung seines Geschäftsmodells und eines ansprechenden User Interface kümmern. Selbst eine weitreichende Migration von Desktop-Anwendungen mit komplexen Oberflächen und einer umfassenden Business­logik gelingt in vertretbarer Zeit. Bestehende Codebestandteile können oft komplett übernommen werden, sodass die eingesparten zeitlichen Ressourcen für die Implementierung von neuen Programm-Features verwendet werden können.

Wisej-Web-Applikationen arbeiten themenbasiert und können daher im Design leicht angepasst werden. Über Extensions lassen sich Funktionen erweitern. Wisej unterstützt Microsofts Internet Information Server (IIS), eine Dienstplattform für PCs und Server. Ferner kann man die Applikation auch flexibel über die Cloud bereitstellen, zum Beispiel über Server bei Amazon AWS oder Microsoft Azure. Für besondere Einsatzszenarien ist auch ein Ausführen ohne Server möglich. Mit einem Zusatzmodul kann die Web-Applikation ohne technische Eingriffe als Desktop-Anwendung ausgeführt werden. Damit ermöglicht Wisej ein sogenanntes Dual Deployment (Web, Desktop), das insbesondere für Übergangsszenarien bei einer Migration interessant ist.

Die Migration von Anwendungen ist ein komplexes Themenfeld der modernen Software-Entwicklung. Neben der richtigen Strategie sind eine intensive Planung und ein ausgewählter Werkzeugeinsatz für den Erfolg entscheidend. Eine universelle Strategie und Vorgehensweise kann es nicht geben, dazu ist jedes Projekt zu individuell.

Aktuell typische Aufgaben aus der Praxis, zum Beispiel eine umfassende Modernisierung der Bedienoberfläche für Desktop-Anwendungen oder ein Wechsel der Anwendungsart von einer Desktop-Applikation hin zu einer modernen Web-Anwendung, können sehr effizient erfolgen. Dabei kann es gelingen, sehr hohe Anteile des Quellcodes zu übernehmen oder zu transformieren und somit einen weitgehenden Schutz früher getätigter Investitionen zu gewährleisten.

Die eingesparten Ressourcen kann das Unternehmen schliesslich dazu verwenden, die migrierte Software den modernsten fachlichen Anforderungen gemäss weiterzuentwickeln.