Unsere dreiteilige Artikel-Serie thematisiert Erfahrungen aus Software Modernisierungsprojekten und beleuchtet verschiedene Aspekte. Alle genannten Beispiele stammen aus realen Cases.
1. Beitrag: Warum gute Software trotzdem zum Risiko wird
3. Beitrag: Keine Big-Bang-Migration
Das Dilemma, das jedes Unternehmen kennt
«Warum sollten wir etwas ändern? Die Software läuft doch.»
Sobald Unternehmen Modernisierung ernsthaft angehen, entsteht ein Zielkonflikt, der sich nicht auflösen lässt, sondern aktiv gesteuert werden muss:
- Das Business fordert neue Features
- Die IT fordert Modernisierung
Beides ist berechtigt. Beides ist notwendig.
Neue Features sichern Wettbewerbsfähigkeit, erfüllen Kundenanforderungen und generieren direkten Mehrwert. Modernisierung hingegen stellt sicher, dass diese Weiterentwicklung überhaupt langfristig möglich bleibt.
Doch in der Praxis bedeutet das:
- Ressourcen müssen aufgeteilt werden
- Prioritäten müssen gesetzt werden
- Und Kompromisse sind unvermeidlich
Genau hier beginnt die eigentliche Herausforderung. Denn während Features sichtbaren Nutzen bringen, bleibt Modernisierung oft im Hintergrund. Sie verbessert die Grundlage, aber nicht unmittelbar das Ergebnis.
Das führt dazu, dass sie im Tagesgeschäft immer wieder zurückgestellt wird. Und genau das ist der Punkt, an dem viele Modernisierungsinitiativen ins Stocken geraten.
Warum Modernisierung immer wieder scheitert
In vielen Projekten sehen wir ein wiederkehrendes Muster: Modernisierung wird erkannt, diskutiert und geplant, jedoch nicht konsequent umgesetzt. Die Gründe dafür sind selten technischer Natur.
- Neue Features haben höhere Priorität
- Der Business-Nutzen ist nicht sofort sichtbar
- Modernisierung wird als «technisches Thema» eingeordnet
Gerade in Organisationen mit starkem Fokus auf kurzfristige Ergebnisse entsteht ein natürliches Bias: Alles, was direkt Wert schafft, wird bevorzugt.
Modernisierung hingegen wirkt indirekt.
Sie reduziert Risiken, verbessert die Grundlage und schafft zukünftige Möglichkeiten, aber sie liefert selten sofort sichtbare Ergebnisse (vergl. Abbildung technical debt impact on productivity im Blogbeitrag Warum gute Software trotzdem zum Risiko wird: Wenn Architektur stabil ist, aber Technologie veraltet.)
Die Folge: Technische Schulden wachsen weiter, während die Fähigkeit zur Weiterentwicklung gleichzeitig sinkt. Und genau das verstärkt das Problem. Denn je länger Modernisierung verschoben wird, desto aufwendiger wird sie.
Mit der richtigen Strategie in die Zukunft
Workshops Software-Modernisierung
In unseren individuellen Workshops zeigen wir Ihnen ganz konkret, welche Strategien und Möglichkeiten sich für die Modernisierung Ihrer Software bieten.
Ein Blick in die Praxis: Parallel statt Stillstand
Im beschriebenen bbv Projekt (siehe Teil 1 der Blogserie) wurde bewusst ein anderer Weg gewählt. Statt die Weiterentwicklung vollständig zu stoppen, lief die Modernisierung parallel zur Feature-Entwicklung.
Das bedeutete konkret:
- Regelmässige Releases während der Migration
- Neue Features und Modernisierung im selben System
- Enge Abstimmung zwischen den beteiligten Teams
Die bestehende Codebase wurde nicht eingefroren oder ersetzt, sondern schrittweise weiterentwickelt.
💡 Infobox: Zwei zentrale Prinzipien der Softwaremodernisierung
Was bedeutet Sprouting?
Beim Sprouting wird ein neues Feature oder ein Teil der Software bereits im Zielbild entwickelt. Also so, wie die zukünftige Architektur aussehen soll. Dieses neue Muster wird anschliessend schrittweise auf weitere Teile der Anwendung übertragen. Die Modernisierung «spriesst» sozusagen organisch in der bestehenden Software.
Was bedeutet Strangler Fig?
Beim Strangler-Fig-Pattern wird das bestehende System nach und nach durch neue Komponenten ersetzt. Neue Funktionen entstehen ausserhalb des Altsystems und übernehmen schrittweise dessen Aufgaben, bis das alte System vollständig abgelöst ist. Das Altsystem wird langsam «umwachsen» und ersetzt.
Warum das wichtig ist
Beide Ansätze vermeiden den risikoreichen Big Bang. Sie ermöglichen eine kontrollierte, schrittweise Modernisierung, unterscheiden sich jedoch darin, ob innerhalb des bestehenden Systems (Sprouting) oder parallel dazu (Strangler Fig) modernisiert wird.
Das Ziel war klar: Das Business sollte nicht stillstehen.
Diese Entscheidung war strategisch wichtig. Ein vollständiger Feature-Stopp über mehrere Monate oder sogar Jahre wäre für den Kunden nicht akzeptabel gewesen. Gleichzeitig war klar: Dieser Ansatz erhöht die Komplexität – sowohl technisch als auch organisatorisch.
Die Realität hinter der Strategie
So sinnvoll dieser Ansatz ist, bringt er erhebliche Herausforderungen mit sich, die in der Planung oft unterschätzt werden.
1. Ressourcenkonflikte
Entwicklungskapazitäten sind immer begrenzt. Um Modernisierung und Weiterentwicklung parallel zu ermöglichen, teilte die Projektleitung das Team gezielt auf:
- Ein Teil arbeitete an der Modernisierung
- Ein anderer Teil setzte neue Features um
Doch auch mit dieser Aufteilung entstehen Zielkonflikte. Denn beide Bereiche greifen auf dieselbe Codebase zu. Änderungen im einen Bereich beeinflussen den anderen. Abstimmung wird zwingend notwendig. Gleichzeitig kann nicht die gleiche Geschwindigkeit wie vor der Modernisierung aufrechterhalten werden. Die Organisation muss akzeptieren, dass sich die Entwicklung temporär verlangsamt.
Services zu Software-Modernisierung
Das Potenzial der Modernisierung nutzen
Steigern Sie die Performance, Sicherheit und Qualität Ihrer Software und entwickeln Sie neue Geschäftsideen.
2. Priorisierung unter Druck
Neue Features haben oft höhere Priorität.
Warum?
- Kunden erwarten sie
- Sie generieren Umsatz
- Sie sind sichtbar
Modernisierung hingegen bleibt im Hintergrund. Ihr Nutzen ist langfristig und damit schwieriger zu vermitteln. Ohne klare Steuerung passiert deshalb fast automatisch Folgendes: Modernisierung wird immer wieder unterbrochen oder verschoben.
Im Projekt wirkte man diesem Risiko aktiv entgegen: durch Planung, Abstimmung und klare Priorisierung. Doch ohne diese Steuerung wäre die Modernisierung nicht vorangekommen.
3. Temporäre Komplexität
Ein besonders wichtiger Punkt aus der Praxis: Während der Migration wird das System nicht einfacher, sondern komplexer.
Im Projekt bedeutete das konkret:
- Alte und neue Architektur existierten gleichzeitig
- Unterschiedliche Technologien wurden parallel genutzt
- Abhängigkeiten mussten kontinuierlich abgestimmt werden
Vereinfacht gesagt: Die Codebase befand sich in einem Übergangszustand, mit zwei Welten gleichzeitig.
Für Entwickler ist das anspruchsvoll:
- Entscheidungen werden komplexer
- Fehlerquellen nehmen zu
- Orientierung wird schwieriger
Diese Phase ist unvermeidbar, aber sie muss bewusst gemanagt werden. Gleichzeitig zeigt sich hier auch eine wichtige Perspektive für das Business: Ein solcher Parallelbetrieb sollte nicht unnötig in die Länge gezogen werden. Je länger zwei Welten gleichzeitig betrieben werden, desto höher sind Komplexität, Aufwand und Risiko.
Beispiel: UI-Modernisierung im Parallelbetrieb
Ein besonders anschauliches Beispiel für diese Komplexität war die UI-Modernisierung. Das bestehende UI basierte auf klassischen ASP.NET-Technologien mit Session Handling, das nicht mehr mit allen Browsern kompatibel war. Ein vollständiger Austausch in einem einzigen Schritt war nicht möglich.
Stattdessen wurde ein schrittweiser Ansatz gewählt:
- Einzelne UI-Komponenten wurden ersetzt
- Neue Komponenten wurden in das bestehende UI integriert
Das führte zwangsläufig zu einem erhöhten Integrationsaufwand. Neue UI-Elemente mussten in eine bestehende Struktur eingebettet werden, die ursprünglich nicht dafür ausgelegt war.
Das Ergebnis:
- höherer technischer Aufwand
- zusätzliche Abstimmungen
- temporär erhöhte Komplexität
Gleichzeitig hatte dieser Ansatz einen entscheidenden Vorteil: Fortschritt war jederzeit sichtbar und kontrollierbar.
Gute Qualität zahlt sich aus
Software Quality Map
Gehen Sie auf Entdeckungsreise durch 80 Themen, wie Sie die Qualität Ihrer Software verbessern können. Quality Map auf und los!
Was Unternehmen unterschätzen
Aus unserer Erfahrung werden drei Aspekte systematisch unterschätzt:
Der Aufwand
Migrationen dauern länger als erwartet. Insbesondere, wenn sie parallel zur Weiterentwicklung erfolgen.
Die organisatorische Komplexität
Modernisierung betrifft nicht nur die IT. Sie erfordert Abstimmung zwischen Entwicklung, Projektmanagement und Business.
Die Notwendigkeit von Feature-Freezes
Bestimmte Schritte lassen sich nicht im laufenden Betrieb umsetzen. Im Projekt war das beispielsweise beim Austausch des OR-Mappers der Fall. Hier musste bewusst eine Phase eingeplant werden, in der keine neuen Features entwickelt wurden. Ohne solche gezielten Stillstände ist nachhaltige Modernisierung nicht möglich.
Erfolgsfaktoren aus der Praxis
Was hat im Projekt funktioniert?
Klare Aufteilung der Teams
Ein dediziertes Modernisierungsteam und ein separates Feature-Team reduzierten Konflikte und ermöglichten Fokus.
Strukturierte Planung
Die Migration wurde nicht ad hoc durchgeführt, sondern schrittweise geplant und umgesetzt.
Enge Abstimmung mit dem Projektmanagement
Die externe Projektleitung koordinierte die Ressourcen und stellte eine reibungslose Abstimmung mit dem Kunden sicher.
Transparente Kommunikation mit dem Business
Es wurde offen kommuniziert, dass es Phasen ohne Feature-Fortschritt geben wird.
Und ganz entscheidend: Die Akzeptanz, dass Modernisierung temporär Einschränkungen bedeutet.
Der entscheidende Punkt: Führung
Der wichtigste Erfolgsfaktor war nicht technischer Natur, sondern organisatorisch. Modernisierung wurde aktiv gesteuert. Das bedeutet konkret:
- Prioritäten wurden bewusst gesetzt
- Ressourcen wurden gezielt bereitgestellt
- Entscheidungen wurden getroffen und getragen
Diese Steuerung erfolgte nicht zufällig, sondern strukturiert, unter Einbindung aller relevanten Stakeholder. Ohne diese Führung wäre das Projekt gescheitert.
Denn ohne klare Entscheidungen gewinnt immer das kurzfristig Sichtbare und Modernisierung bleibt liegen.
Fazit: Modernisierung ist ein Führungsentscheid
Modernisierung ist kein IT-Projekt.
Sie ist ein strategisches Thema, das aktiv gesteuert werden muss.
- Ohne klare Priorisierung auf Management-Ebene scheitert sie
- Ohne Verständnis für den Business Impact wird sie verschoben
- Ohne Ressourcen bleibt sie wirkungslos
Entscheidend ist nicht, ob modernisiert wird, sondern wie konsequent.
Ausblick auf Teil 3: Doch selbst mit der richtigen Organisation bleibt eine zentrale Frage: Wie reduzieren Sie das Risiko Ihrer Modernisierung? Die Antwort liegt nicht in radikalen Umbrüchen, sondern im richtigen Vorgehen.
FAQ
Eine erfolgreiche Softwaremodernisierung erfolgt meist schrittweise und parallel zur laufenden Weiterentwicklung. Statt eines risikoreichen Komplettaustauschs werden einzelne Komponenten nach und nach modernisiert, während gleichzeitig neue Funktionen entwickelt werden. So bleibt das Unternehmen handlungsfähig und kann Innovation und Modernisierung miteinander verbinden.
Viele Modernisierungsinitiativen scheitern nicht an der Technik, sondern an fehlender Priorisierung und Ressourcen. Neue Features haben oft Vorrang, weil ihr Nutzen sofort sichtbar ist. Ohne klare Unterstützung durch das Management werden Modernisierungsmassnahmen immer wieder verschoben, wodurch technische Schulden weiter wachsen.
Das Risiko einer Softwaremigration lässt sich durch ein schrittweises Vorgehen deutlich senken. Bewährte Ansätze wie das Sprouting- oder Strangler-Fig-Pattern ermöglichen es, einzelne Komponenten kontrolliert zu erneuern, statt das gesamte System auf einmal zu ersetzen. Dadurch bleiben Fortschritte sichtbar, Risiken beherrschbar und der laufende Betrieb gesichert.
Kevin Wyden
DAS KÖNNTE SIE AUCH INTERESSIEREN
Keine Big-Bang-Migration: Wie schrittweise Modernisierung Risiken drastisch reduziert
