Legacy-Modernisierung: sechs Strategien im Vergleich

Sie haben eine Liste Ihrer Altsysteme, und bei jedem einzelnen steht dieselbe Frage: Was machen wir jetzt damit? Neu bauen? Umziehen? Einfach so lassen?

Für diese Frage gibt es ein Raster, das sich seit Jahren bewährt hat. Es heißt 6R-Modell und kennt sechs mögliche Antworten. Das Problem daran: Fast alles, was darüber geschrieben wird, dreht sich um Cloud-Migration und große Serverlandschaften. Wenn Ihr Altsystem aber eine Access-Datenbank ist oder ein Excel-Tool mit Makros, hilft Ihnen das wenig.

Hier stehen die sechs Wege, übersetzt auf die Systeme, die in deutschen Unternehmen wirklich herumliegen. Wie Sie überhaupt zu Ihrer Liste kommen, steht in Legacy-Systeme ablösen.

Die sechs Wege

Das Modell stammt von Gartner und wurde durch Amazon bekannt. Die englischen Namen fangen alle mit R an, daher der Name. Sie begegnen Ihnen in jeder Präsentation, deshalb stehen sie hier in Klammern dabei.

Behalten (Retain)

Sie ändern nichts. Das klingt nach Drückebergerei, ist aber oft die richtige Antwort. Das Excel-Tool im Controlling, das seit sechs Jahren fehlerfrei läuft und viermal im Jahr geöffnet wird, muss niemand anfassen.

Behalten heißt allerdings nicht ignorieren. Schreiben Sie auf, wer zuständig ist, und sorgen Sie dafür, dass die Datei gesichert wird. Sonst haben Sie in zwei Jahren dasselbe Problem, nur ohne den Kollegen, der es noch verstanden hat.

Umziehen (Rehost)

Die Anwendung bleibt, wie sie ist, und wechselt nur den Ort. Vom alten Server auf eine virtuelle Maschine, vom Netzlaufwerk in eine SharePoint-Bibliothek. Im Rechenzentrum ist das ein gängiger Weg, weil er schnell geht und wenig kostet.

Bei Werkzeugen aus den Fachbereichen bringt reines Umziehen dagegen selten etwas. Das Problem ist da nämlich nicht der Ort, sondern die Anwendung selbst. Eine Access-Datei wird nicht dadurch besser, dass sie auf einem neueren Server liegt. Wer nur umzieht, hat danach dieselben Schwierigkeiten an einer anderen Adresse.

Untendrunter tauschen (Replatform)

Die Oberfläche bleibt, darunter tauschen Sie etwas aus. Das ist bei Fachbereichslösungen der interessanteste Weg, und das beste Beispiel dafür ist Access.

Sie verlagern nur die Tabellen auf einen SQL Server und verbinden die vorhandenen Masken damit. Microsoft liefert dafür ein kostenloses Werkzeug, den SQL Server Migration Assistant. Der übernimmt Tabellen, Daten und einfache Abfragen. Und, das ist der entscheidende Punkt: Formulare, Berichte und VBA fasst er gar nicht erst an. Genau deshalb funktioniert dieser Weg. Die Leute im Fachbereich arbeiten am Montag mit denselben Masken weiter wie am Freitag.

Umsonst ist das nicht. Abfragen und VBA-Abläufe brauchen Anpassungen, Rechte müssen neu gedacht und alles getestet werden. Aber Sie lösen damit auf einen Schlag die Probleme, an denen Access im Mehrbenutzerbetrieb typischerweise scheitert.

Kaufen (Repurchase)

Sie werfen die Eigenentwicklung weg und kaufen ein Fertigprodukt. Manchmal heißt dieser Weg auch Replace.

Das lohnt sich immer dann, wenn Ihr selbstgebautes Werkzeug etwas tut, was tausend andere Firmen auch brauchen. Urlaubsanträge, Zeiterfassung, Reisekosten. Dafür gibt es fertige Produkte, und Ihr Prozess ist mit ziemlicher Sicherheit nicht so besonders, wie alle glauben. Wo die Grenze verläuft, haben wir in Build vs. Buy durchgerechnet.

Neu bauen (Refactor)

Sie bauen die Anwendung von Grund auf neu, meist auf einer anderen Technologie. Im Microsoft-Umfeld heißt das oft: aus der Access-Datenbank wird eine Model-driven App auf Dataverse, aus dem Excel-Tool eine Power App.

Das Ergebnis ist am Ende das beste, und der Weg dorthin ist der längste. Ob er sich lohnt, entscheidet sich selten am Projektbudget, sondern an den Lizenzen, die Sie danach nicht mehr zahlen. Dazu weiter unten die Rechnung.

Abschalten (Retire)

Sie schalten das System ab und ersetzen es durch nichts.

Das ist der günstigste Weg von allen und der, an den am seltensten jemand denkt. Dazu weiter unten mehr.

Die sechs Wege im Vergleich

Die Spalte, die in solchen Tabellen meistens fehlt, sind die laufenden Kosten. Und die drehen das Bild: Neu bauen hat den höchsten Aufwand, senkt danach aber oft die Lizenzkosten auf null. Kaufen ist umgekehrt, dort tauschen Sie Wartungsaufwand gegen Gebühren pro Nutzer, die mit der Zeit steigen. Wer nur auf die Spalte Aufwand schaut, entscheidet sich systematisch falsch.

Was Neubauen wirklich kostet

Neu bauen gilt als der teure Weg. Für den Bau selbst stimmt das, und zwei Dinge machen ihn regelmäßig noch teurer als geplant.

Das erste ist eine Zwickmühle. Um alten Code sicher umzubauen, brauchen Sie automatische Tests. Um solche Tests schreiben zu können, müssen Sie den Code aber erst umbauen. Beides gleichzeitig geht nicht, und beides nacheinander dauert länger, als irgendwer eingeplant hat.

Das zweite sind die Sonderfälle. In zehn Jahren gewachsener Logik stecken Dutzende Ausnahmen, die niemand mehr erklären kann. Der Rabatt für einen bestimmten Kunden. Die Rundung, die im Dezember anders funktioniert. Solche Dinge stehen in keiner Beschreibung, sondern nur im alten Code. Beim Neubau fallen sie hinten runter und tauchen wieder auf, wenn sich jemand beschwert.

Nur hört die übliche Rechnung genau hier auf. Sie zählt, was der Umbau kostet, und lässt weg, was das Weitermachen kostet. Und der größte Posten dabei sind fast immer die Lizenzen.

Ein Beispiel: Sie haben eine Canvas App, die einen Premium-Konnektor benutzt, etwa auf eine SQL-Datenbank oder eine eigene Schnittstelle. Damit braucht jeder Nutzer eine Power Apps Premium Lizenz. Die kostet nach aktueller Liste rund 17 Euro im Monat bei Jahresvertrag. Bei 150 Nutzern sind das gut 31.000 Euro im Jahr. Jedes Jahr, und die Preise sind in den letzten Runden nicht gefallen.

Über fünf Jahre stehen da über 150.000 Euro für eine App, die vielleicht in drei Wochen gebaut wurde. Gegen diese Summe sieht ein Neubau, der die Lizenzpflicht auflöst, plötzlich sehr vernünftig aus. Was in Ihrem Fall zusammenkommt, können Sie in unserem Lizenzkosten-Rechner durchspielen, und in Lizenzkosten senken stehen die üblichen Hebel.

Rechnen Sie deshalb nicht den Bau gegen null, sondern über drei bis fünf Jahre gegen das, was Sie sonst weiterzahlen. Ein Neubau ist richtig, wenn die laufenden Lizenzen ihn in wenigen Jahren tragen. Oder wenn die Programmiersprache keine Sicherheitsupdates mehr bekommt, wichtige Bibliotheken nicht mehr gepflegt werden, das Datenmodell zu Ihrem heutigen Prozess nicht mehr passt oder jede kleine Änderung unverhältnismäßig teuer geworden ist. Trifft nichts davon zu, gibt es meist einen günstigeren Weg. Den grundsätzlichen Vergleich haben wir in Build vs. Buy durchgerechnet.

Abschalten wird am meisten unterschätzt

In jeder gewachsenen Systemlandschaft gibt es Anwendungen, die niemand mehr benutzt. Der Bericht, den seit 2019 keiner geöffnet hat. Das Tool für einen Prozess, den es so nicht mehr gibt. Die Datenbank aus einem Projekt, das nie zu Ende geführt wurde.

Diese Systeme kosten trotzdem Geld: Lizenzen, Server, Sicherungen, und jedes Mal Aufmerksamkeit, wenn jemand die Landschaft aufräumen will. Abschalten spart das alles auf einen Schlag, ohne dass Sie Ersatz bauen müssen.

Warum passiert es trotzdem so selten? Weil sich niemand traut. Die Sorge ist immer dieselbe: Was, wenn doch jemand damit arbeitet? Diese Sorge lässt sich auflösen. Schauen Sie sich an, wer wann zuletzt zugegriffen hat, fragen Sie im Fachbereich nach, und schalten Sie das System erst einmal nur ab, ohne etwas zu löschen. Meldet sich vier Wochen lang niemand, war die Antwort klar. Was Sie an Daten trotzdem aufheben müssen, steht in Legacy-Systeme ablösen unter Etappe 5.

Welcher Weg zu welchem System passt

Gehen Sie die Fragen der Reihe nach durch und hören Sie beim ersten Ja auf.

Benutzt es niemand mehr? Dann abschalten.

Läuft es, beschwert sich keiner, und wäre ein Ausfall verkraftbar? Dann behalten, aber einen Verantwortlichen benennen und die Sicherung prüfen.

Gibt es ein Fertigprodukt, das genau diese Aufgabe erledigt, und ist Ihr Prozess dabei nichts Besonderes? Dann kaufen.

Sind die Masken in Ordnung und stört Sie nur, was darunter passiert, also Geschwindigkeit, Datenmenge, gleichzeitige Nutzer? Dann tauschen Sie den Unterbau.

Ist der Prozess ein echter Vorteil gegenüber Ihrem Wettbewerb und das System technisch am Ende? Dann neu bauen.

Bleibt nur der Ort das Problem? Dann umziehen. Das kommt seltener vor, als man denkt.

Kommen Sie bei einem System nicht weiter, fehlt Ihnen meistens nicht der Weg, sondern die Bewertung davor. Wie wichtig ist das System wirklich, in welchem Zustand ist es, und wie viele Leute verstehen es noch? Genau das schauen wir uns in unserem Technical Health Check an.

Meistens brauchen Sie mehrere Wege gleichzeitig

Ein häufiger Fehler ist, sich für einen Weg zu entscheiden und ihn dann über die ganze Landschaft zu ziehen. Dann wird entweder viel zu viel neu gebaut oder viel zu wenig aufgeräumt.

In der Praxis sieht ein Programm eher so aus: Von dreißig Anwendungen werden acht abgeschaltet, weil sie keiner mehr braucht. Zwölf bleiben, wie sie sind, bekommen aber endlich einen Verantwortlichen. Sechs bekommen einen neuen Unterbau. Drei ersetzen Sie durch ein Fertigprodukt. Und eine einzige, nämlich die, an der Ihr Geschäft wirklich hängt, bauen Sie neu.

Diese eine bekommt dann auch die Aufmerksamkeit, die sie braucht, weil Sie sich nicht gleichzeitig mit neunundzwanzig anderen beschäftigen. Wenn Sie beim Neubau auf Power Apps oder Dataverse gehen, lohnt vorher ein Blick auf die Lizenzfrage, siehe Dynamics 365 vs. Power Apps.

Wie Aliru unterstützt

Wir gehen Ihre Anwendungen einzeln durch und sagen Ihnen bei jeder, welcher der sechs Wege passt und warum. Dabei schlagen wir auch dann den günstigen Weg vor, wenn der teure für uns mehr Umsatz bedeuten würde. Wo neu gebaut werden muss, machen wir Umsetzung und Betrieb aus einer Hand, so wie in IT-Landschaft betreiben lassen beschrieben. Ein guter Einstieg ist unser Workshop, oder Sie sprechen direkt mit uns über Ihre Systemlandschaft.