Legacy-Modernisierung: Wovon die Kosten des ersten Schritts abhängen

Die Antwort zuerst: Der Zuschnitt entscheidet, nicht die Technik

Die Kosten einer Legacy-Modernisierung lassen sich nicht pauschal nennen, aber eingrenzen. Sie hängen beim ersten Schritt vor allem davon ab, wie sauber sich ein Teilstück aus dem Altsystem abgrenzen lässt: Wie viele Stellen rufen es auf, wem gehören seine Daten, und von welchen anderen Teams hängt die Umstellung ab. Ein gut gewähltes erstes Teilstück kann deutlich weniger kosten als ein schlecht gewähltes, bei derselben Anwendung und demselben Team.

Dieser Artikel richtet sich an Entwicklungs- und IT-Leitungen, die ein Budget für einen ersten, begrenzten Modernisierungsschritt beantragen oder ein Angebot dafür beurteilen müssen. Er nennt die Kostentreiber, zeigt an einem ausgedachten Beispiel, wie zwei Zuschnitte derselben Anwendung auseinanderliegen, und listet auf, was Sie für eine belastbare Schätzung mitbringen sollten. Das Vorgehen selbst, vom Abgrenzen über die Fassade bis zur Umschaltung, beschreibt der Artikel Altsysteme schrittweise ablösen.

Warum ich hier keine Zahl nenne

Im Netz finden Sie Preisspannen für Software-Modernisierung, deren oberes Ende ein Vielfaches des unteren ist. Solche Spannen sind nicht falsch, aber nutzlos: Sie gelten für irgendein System, nicht für Ihres. Eine Zahl, die ohne Blick auf Code, Daten und Team entsteht, ist keine Schätzung, sondern ein Anker. Er setzt Erwartungen, an denen später gemessen wird.

Martin Fowler formuliert das Kriterium für eine sinnvolle Schätzung so: Sie ist wertvoll, wenn sie eine bedeutende Entscheidung unterstützt. Fehlt diese Entscheidung, ist der Aufwand für die Schätzung verschwendet. Martin Fowler: The Purpose of Estimation. Die Entscheidung, die vor dem ersten Schritt ansteht, lautet: Welches Teilstück zuerst, und lohnt sich das? Dafür brauchen Sie keine Zahl aus einem Artikel, sondern eine Bestandsaufnahme Ihres Systems. Deshalb rechne ich Modernisierungsarbeit nach tatsächlichem Aufwand ab und nenne eine Aufwandsschätzung erst, wenn ich das Teilstück gesehen habe. Was ich dafür brauche, steht weiter unten.

Der größte Kostentreiber: der Zuschnitt des ersten Teilstücks

Bevor ein einziger Kostenposten angesehen wird, steht die Frage, welcher Bereich zuerst herausgelöst wird. Dieser Zuschnitt wirkt auf jeden späteren Posten.

Ein Teilstück ist günstig, wenn

• es eine zusammenhängende fachliche Aufgabe erfüllt und nicht quer durch die Anwendung verteilt ist,
• wenige Stellen im Altsystem es aufrufen und diese bekannt sind,
• es eigene Tabellen besitzt, in die sonst niemand schreibt,
• es auf andere Teile des Systems nur lesend zugreift,
• die Fachabteilung seine Regeln kennt und als Abnahmekriterien beschreiben kann.

Ein Teilstück ist teuer, wenn

• seine Logik in gemeinsam genutzten Tabellen, Datenbankprozeduren oder Hilfsklassen steckt,
• viele Oberflächen, Berichte, Importe und Hintergrundaufgaben es aufrufen, manche davon unbekannt,
• es in dieselben Tabellen schreibt wie andere Bereiche,
• seine Regeln nur im Code dokumentiert sind und niemand mehr weiß, warum sie so sind.

AWS warnt ausdrücklich davor, ein System zu früh zu zerlegen, solange die fachlichen Grenzen unklar sind; falsch gesetzte Grenzen sind teuer. Als Kandidaten für den ersten Schritt nennt AWS Bereiche mit eigener Datenhaltung und wenigen Abhängigkeiten. AWS: Strangler Fig Pattern, Issues and considerations. Microsoft empfiehlt, neue Komponenten von Anfang an mit klaren Abgrenzungen zu bauen, damit sie sich in späteren Schritten wieder einzeln ersetzen lassen. Microsoft: Strangler Fig Pattern.

In der Praxis würde ich den ersten Schritt nicht nach dem größten Schmerz wählen, sondern nach dem besten Verhältnis aus Nutzen und Abgrenzbarkeit. Der schmerzhafteste Bereich ist oft auch der am stärksten verflochtene. Er kommt an die Reihe, wenn das Team Fassade, Schnittstelle und Umschaltung einmal geübt hat.

Die Kostenposten im Einzelnen

Die folgende Tabelle geht die Schritte der schrittweisen Ablösung durch und nennt für jeden, was ihn teuer macht und was ihn günstig hält. Welche Posten bei Ihnen ins Gewicht fallen, zeigt erst die Bestandsaufnahme.

Zu einzelnen Posten gibt es belegbare Hinweise, die ich bei jeder Schätzung berücksichtige:

• Fassade und Adapter sind keine kostenlosen Zwischenschichten. Microsoft nennt für den Anti-Corruption Layer ausdrücklich zusätzliche Latenz, einen weiteren Dienst, der gepflegt, überwacht und in Release-Prozesse eingebunden werden muss, sowie die Frage, ob er nach der Migration wieder entfällt. Microsoft: Anti-Corruption Layer Pattern. Für die Fassade gilt dasselbe: Sie darf weder zum einzigen Ausfallpunkt noch zum Engpass werden. Microsoft: Strangler Fig Pattern.
• Der Parallelbetrieb ist Übergangsarchitektur. Microsoft empfiehlt, seinen Nutzen für die Risikominderung gegen die vorübergehenden Infrastrukturkosten abzuwägen. Fowler sieht die Mehrarbeit des Nebeneinanders durch das geringere Risiko und den früheren Nutzen aufgewogen, verschweigt sie aber nicht. Martin Fowler: Strangler Fig Application. Deshalb gehört zu jedem ersten Schritt ein Termin, an dem der alte Teil abgeschaltet wird. Ohne diesen Termin zahlen Sie den Parallelbetrieb dauerhaft.
• Die Umschaltung ist Vorbereitungsarbeit. AWS empfiehlt für die Umschaltung einen Rückfallplan mit vorab definierten Abbruchkriterien, einer Strategie für bereits geänderte Daten und einer Person, die über Reparatur oder Rückweg entscheidet. Dazu kommen Tests vor dem Zeitfenster und eine Prüfung, ob das Team die neue Komponente überwachen kann. AWS: Cutover stage. Diese Arbeit fällt an, bevor das Umschaltfenster überhaupt beginnt, und sie wird in Angeboten gern vergessen.

Der unterschätzte Posten: Abhängigkeiten zu anderen Teams

In den Modernisierungen, an denen ich mitgearbeitet habe, lagen die größten Verzögerungen selten im Code. Sie lagen in Abhängigkeiten zu anderen Teams, die sich nicht schnell genug auflösen ließen: ein Feld in einer fremden Schnittstelle, eine Freigabe für einen Netzwerkzugang, eine Tabelle, die ein anderes Team besitzt und nicht ändern darf, ohne eigene Freigaben einzuholen. Jede dieser Abhängigkeiten kostet nicht nur Arbeitszeit, sondern Wartezeit. Wartezeit, in der das Teilstück halb fertig ist und der Parallelbetrieb läuft.

Das ist keine Eigenheit einzelner Unternehmen. Die Struktur einer Software folgt der Kommunikationsstruktur der Organisation, die sie baut; Modulgrenzen, die über Teamgrenzen laufen, werden kompliziert, wenn die Teams nicht gut zusammenarbeiten. Martin Fowler: Conway’s Law. Für den ersten Schritt heißt das:

1. Abhängigkeiten zu anderen Teams in der Bestandsaufnahme auflisten, mit Namen des Teams und dem konkreten Bedarf. Nicht „ERP-Team einbinden“, sondern „Das ERP-Team muss ein Feld in der Artikelschnittstelle freigeben“.
2. Den ersten Schritt so zuschneiden, dass er möglichst wenige davon braucht. Ein Teilstück, das vollständig in der Hand Ihres Teams liegt, ist der bessere Anfang als eines, das drei Freigaben anderer Abteilungen benötigt.
3. Für die verbleibenden Abhängigkeiten vorab klären, wer liefert und bis wann. Fehlt diese Zusage, würde ich das Teilstück nicht beginnen. Sonst entsteht genau der halb fertige Zustand, der am teuersten ist.

Wenn Sie ein Angebot beurteilen, fragen Sie danach: Welche Abhängigkeiten zu anderen Teams hat der Anbieter gesehen, und was passiert mit dem Aufwand, wenn eine davon nicht rechtzeitig geliefert wird?

Update, Umbau im Bestand oder Herauslösen: Was die Wahl für die Kosten bedeutet

Nicht jeder erste Schritt ist ein Herauslösen. Die Wahl des Weges verschiebt die Kostenposten:

• Update im Bestand. Laufzeit, Framework und Bibliotheken werden auf unterstützte Versionen gehoben, die Struktur bleibt. Es fallen keine Fassade, kein Adapter und keine Datenübernahme an. Die Kosten liegen in der Prüfung, ob das Ergebnis dasselbe tut wie vorher, also in Tests, die oft erst geschrieben werden müssen. Teuer wird es, wenn einzelne Abhängigkeiten das Update blockieren. Welche Blockaden das sind und wie Sie sie erkennen, beschreibt der Artikel Veraltete Software als Sicherheitsrisiko: Update oder Umbau?
• Umbau im Bestand. Ein Modul wird innerhalb der Anwendung sauber abgegrenzt, ohne eigenen Dienst. Fassade und Betrieb entfallen, der Adapter wird zu einer internen Schnittstelle. Das ist meist der günstigste Weg, wenn das Team ohnehin gemeinsam ausliefert und keine unabhängige Bereitstellung braucht.
• Herauslösen als eigene Komponente. Alle Posten der Tabelle fallen an. Dafür kann das Teilstück unabhängig geändert, bereitgestellt und betrieben werden. Das lohnt sich, wenn genau diese Unabhängigkeit das Ziel ist. Ob Microservices das richtige Ziel sind, hängt von Ihrem Betrieb und Ihren Teamgrenzen ab; die Seite Microservices-Entwicklung beschreibt die Voraussetzungen.

Für kleine Anwendungen gilt eine Ausnahme: Wenn ein vollständiger Neubau einfach ist, kann er günstiger sein als jede schrittweise Ablösung, weil Fassade, Adapter und Parallelbetrieb entfallen. Microsoft und AWS nennen das als Grenze des Strangler-Ansatzes. Microsoft: When to use this pattern.

Beispiel: Zwei Zuschnitte für dieselbe Anwendung

Das folgende Beispiel ist fiktiv und dient der Veranschaulichung.

Ein Großhändler betreibt eine selbst entwickelte Anwendung für den Kundenservice. Darin werden Rückfragen zu Lieferungen bearbeitet, Retouren abgewickelt und Gutschriften berechnet. Die Anwendung ist über Jahre gewachsen, das Entwicklungsteam will sie schrittweise erneuern und sucht den ersten Schritt. Zwei Kandidaten stehen zur Wahl.

Kandidat A: die Gutschriftberechnung. Sie verursacht den meisten Ärger, weil jede Änderung an den Regeln Wochen dauert. Die Bestandsaufnahme zeigt: Die Berechnung wird von der Retourenabwicklung, von der Rechnungsstellung und von einem nächtlichen Import aufgerufen. Sie schreibt in dieselbe Tabelle wie die Rechnungsstellung. Die Preisdaten kommen aus dem ERP, dessen Schnittstelle ein anderes Team verantwortet; für ein zusätzliches Feld braucht dieses Team eine eigene Freigabe. Tests gibt es nur für wenige Fälle.

Kandidat B: die Retourenabwicklung. Sie hat eigene Masken, eigene Tabellen und wird nur aus dem Kundenservice heraus genutzt. Sie liest Kundenstammdaten und Lieferungen aus dem Bestand, schreibt aber nur in ihre eigenen Tabellen. Die Gutschrift stößt sie über einen einzigen Aufruf an. Die Fachabteilung kann ihre Regeln aus dem Stand beschreiben.

So liegen die beiden Zuschnitte bei den Kostentreibern auseinander:

Für dieses Beispiel würde ich mit Kandidat B beginnen, obwohl A mehr schmerzt. Das Team übt Fassade, Adapter und Umschaltung an einem Teilstück, das es vollständig in der Hand hat. Nebenbei entsteht die Schnittstelle, über die die Retourenabwicklung die Gutschrift anstößt. Sie ist später der Rand, an dem Kandidat A herausgelöst wird, dann mit einer vollständigen Aufruferliste, Tests für die Gutschriftregeln und einer früh angefragten Freigabe des ERP-Teams.

Was dieses Beispiel nicht liefert: eine Zahl. Wie viel Kandidat B in Ihrer Anwendung kostet, entscheiden Ihr Code, Ihre Daten und Ihr Team. Übertragbar ist nur die Methode: die Treiber je Kandidat nebeneinanderlegen, bevor jemand eine Schätzung abgibt.

Was Sie für eine belastbare Schätzung mitbringen sollten

Eine Aufwandsschätzung wird umso verlässlicher, je mehr davon beim Erstgespräch oder bei der Bestandsaufnahme vorliegt:

• Eine Skizze des Systems: Welche Bereiche gibt es, welche Technik, welche Datenbanken, wie wird ausgeliefert.
• Den Kandidaten für den ersten Schritt und den fachlichen Nutzen, den Sie sich davon versprechen.
• Seine Aufrufer, so vollständig wie möglich: Oberflächen, Berichte, Importe, Hintergrundaufgaben, Schnittstellen nach außen.
• Die Datenhoheit: Welche Tabellen gehören dem Teilstück allein, welche teilt es sich.
• Den Stand der Tests und der Dokumentation, ehrlich.
• Die beteiligten anderen Teams und wer dort entscheidet.
• Den Termin, zu dem der alte Teil abgeschaltet sein soll.

Und wenn Sie Angebote vergleichen, lohnen sich diese Fragen an jeden Anbieter:

• Was genau ist im ersten Schritt enthalten, und was ausdrücklich nicht?
• Wird nach Festpreis oder nach Aufwand abgerechnet, und welche Annahmen stecken in der Schätzung?
• Was passiert mit Aufwand und Termin, wenn ein anderes Team eine Abhängigkeit nicht rechtzeitig liefert?
• Wer betreibt die neue Komponente nach der Umschaltung, und wie wird Ihr Team daran beteiligt?
• Wann wird der alte Teil abgeschaltet, und wer trägt den Parallelbetrieb bis dahin?

Ein Anbieter, der diese Fragen nicht beantworten kann, kennt Ihr System noch nicht gut genug für eine belastbare Aufwandsschätzung.

Wann sich eine schrittweise Modernisierung nicht lohnt

Ein begrenzter Modernisierungsschritt ist nicht immer der richtige Weg. In diesen Fällen würde ich abraten:

• Die Anwendung ist klein. Wenn ein Neubau überschaubar ist, kostet die schrittweise Ablösung mehr als sie spart. Microsoft: When to use this pattern.
• Aufrufe lassen sich nicht abfangen oder der Quellcode ist nicht zugänglich. Dann fehlt die Voraussetzung für Fassade und Umleitung. Microsoft und AWS nennen beides als Ausschlussgrund für das Vorgehen. AWS: Code base access.
• Die Anwendung wird in absehbarer Zeit abgelöst, etwa durch ein Standardprodukt. Dann ist jeder Euro für ihre Modernisierung ein Euro für ein System ohne Zukunft.
• Das Problem ist ein fehlendes Update, keine fehlende Struktur. Wenn sich alle Abhängigkeiten noch aktualisieren lassen, ist das Update im Bestand Routinearbeit für Ihr Team.

Der nächste Schritt

Haben Sie einen Kandidaten für eine schrittweise Software-Modernisierung? Die Seite Software-Modernisierung für bestehende Teams beschreibt, wie ich Ihr Team bei den ersten Schritten unterstützen kann: ein gemeinsamer Blick auf das System, die Wahl des Teilstücks und die Bestandsaufnahme seiner Aufrufer, Daten und Abhängigkeiten. Wenn Sie die Zusammenarbeit fortsetzen möchten, begleite ich anschließend auch die Umsetzung. Ich arbeite dabei in Ihrem Team und rechne nach tatsächlichem Aufwand ab.

Quellen und Einordnung

Die Aussagen zu Fassade, Anti-Corruption Layer, Parallelbetrieb und den Grenzen der schrittweisen Ablösung stützen sich auf die Architekturdokumentation von Microsoft und AWS sowie auf Martin Fowlers Texte zum Strangler Fig Pattern, zum Zweck von Schätzungen und zu Conway’s Law, abgerufen am 11. Oktober 2026. Die Hinweise zu Rückfallplan und Umschaltung stammen aus der AWS-Dokumentation zur Cutover-Phase. Die Beobachtung, dass Abhängigkeiten zu anderen Teams die größten Verzögerungen verursachen, ist meine Projekterfahrung. Die Kundenservice-Anwendung im Beispiel ist ausgedacht und kein Kundenprojekt. Dieser Artikel nennt bewusst keine Preise, Tagessätze oder Personentage. Jede Zahl ohne Bestandsaufnahme wäre geraten.