Unsere dreiteilige Artikel-Serie thematisiert Erfahrungen aus Software Modernisierungsprojekten und beleuchtet verschiedene Aspekte. Alle genannten Beispiele stammen aus realen Cases.
- Beitrag: Warum gute Software trotzdem zum Risiko wird
- Beitrag: Modernisieren ohne Stillstand
Die Angst vor der grossen Migration
Viele Unternehmen verbinden Softwaremodernisierung automatisch mit einem grossen, schwer kalkulierbaren Risiko. Sobald das Thema aufkommt, entstehen typische Befürchtungen:
- Lange Projektlaufzeiten
- Hohe Kosten
- Ungewisser Ausgang
Diese Wahrnehmung ist kein Zufall. Sie basiert auf Erfahrungen mit klassischen Transformationsprojekten, bei denen bestehende Systeme vollständig ersetzt wurden. Der gedankliche Ausgangspunkt ist dabei fast immer derselbe: Wenn etwas veraltet ist, muss es neu gebaut werden. Und genau hier liegt das Problem. Denn diese Denkweise führt direkt zum sogenannten «Big Bang»-Ansatz: einer vollständigen Ablösung des bestehenden Systems durch eine neue Lösung.
Die Konsequenzen sind bekannt:
- Das bestehende System wird eingefroren oder nur minimal weiterentwickelt
- Ein neues System wird parallel aufgebaut
- Am Ende erfolgt eine grosse Umstellung
Diese Art von Projekten ist nicht nur technisch anspruchsvoll, sie sind auch organisatorisch und wirtschaftlich hochriskant. Hinzu kommt, dass viele Unternehmen bereits eigene negative Erfahrungen mit Modernisierungsprojekten gemacht haben. Nicht selten wurde in der Vergangenheit schon einmal versucht, ein bestehendes System zu modernisieren, nur um das Projekt später wieder abzubrechen.
Verstärkt wird diese Wahrnehmung zusätzlich durch regelmässige Berichte über gescheiterte IT-Transformationen und eskalierte Grossprojekte in den Medien. Budgetüberschreitungen, jahrelange Verzögerungen oder komplett eingestellte Projekte prägen das Bild vieler Entscheider.
Genau diese Erfahrungen schüren die Angst vor grossen Migrationen und führen häufig dazu, dass notwendige Modernisierung immer weiter hinausgeschoben wird.
Zwei Wege der Modernisierung
Grundsätzlich gibt es zwei Ansätze, wie Software modernisiert werden kann:
1. Big Bang
Die komplette Neuentwicklung und Ablösung des bestehenden Systems. Dieser Ansatz verspricht auf den ersten Blick Klarheit:
- Alte Probleme werden vollständig beseitigt
- Neue Technologien können frei gewählt werden
Doch in der Praxis bringt dieser Ansatz erhebliche Risiken mit sich:
- Lange Entwicklungsphasen ohne sichtbaren Fortschritt
- Hohe Abhängigkeit vom finalen Go-Live
- Schwierige Rückfallebenen bei Problemen
- Hoher Bedarf an fachlichem Know-how und klar definierten Prozessen
Gerade dieser letzte Punkt wird häufig unterschätzt. Bei einer vollständigen Neuentwicklung müssen bestehende Abläufe und Prozesse neu verstanden, beschrieben und umgesetzt werden. In der Praxis zeigt sich jedoch oft, dass dieses Wissen gar nicht vollständig dokumentiert oder bewusst vorhanden ist.
Viele Prozesse existieren nur implizit im bestehenden System. Über Jahre hinweg hat die Software bestimmte Abläufe übernommen, validiert oder automatisiert, ohne dass diese Logik ausserhalb der Anwendung sauber beschrieben wurde. Deshalb hört man in solchen Projekten häufig Aussagen wie: «Es soll einfach funktionieren wie bisher.»
Das Problem dabei: Oft weiss niemand mehr genau, wie «wie bisher» tatsächlich funktioniert.
Auch bei einer schrittweisen Migration spielt dieses Thema eine Rolle. Durch die kontinuierliche Weiterentwicklung innerhalb des bestehenden Systems bleibt jedoch mehr fachlicher Kontext erhalten und das Risiko ist deutlich geringer. Beim Big-Bang-Ansatz konzentriert sich dagegen das gesamte technische und fachliche Risiko auf einen einzigen Moment.
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.
2. Schrittweise Migration
Die kontinuierliche Modernisierung innerhalb der bestehenden Lösung. Statt alles neu zu bauen, wird das bestehende System gezielt weiterentwickelt:
- Komponenten werden schrittweise ersetzt
- Architektur wird kontinuierlich verbessert
- Technologien werden iterativ modernisiert
Dieser Ansatz wirkt auf den ersten Blick weniger spektakulär, ist aber in der Praxis deutlich besser steuerbar. Und genau diesen Weg hat bbv im beschriebenen Projekt (siehe Teil 1 der Blogserie) gewählt.
Der gewählte Weg im bbv Projekt
Im beschriebenen Projekt wurde bewusst auf einen Big-Bang-Ansatz verzichtet. Das bedeutete:
- Es wurde keine neue Anwendung entwickelt
- Das bestehende System wurde nicht vollständig ersetzt
- Die Modernisierung erfolgte innerhalb der bestehenden Codebase
Die bestehende Software blieb also während des gesamten Projekts in Betrieb und wurde parallel weiterentwickelt. Das Ziel war klar: Risiko minimieren und Kontrolle behalten.
Diese Entscheidung war nicht nur technisch motiviert, sondern vor allem strategisch. Ein vollständiger Neuaufbau hätte bedeutet:
- lange Zeit ohne produktiven Mehrwert
- hohe Unsicherheit bis zum finalen Go-Live
- erhebliche Abhängigkeit von einem einzelnen Migrationszeitpunkt
Durch den gewählten Ansatz konnte das Risiko dagegen über die gesamte Projektlaufzeit verteilt werden.
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.
Konkretes Vorgehen
Die Modernisierung erfolgte nicht zufällig oder ad hoc, sondern in klar strukturierten Schritten.
1. Vorarbeiten leisten
Bevor grössere Änderungen vorgenommen wurden, wurde gezielt Vorarbeit geleistet. Ein zentraler Punkt war dabei die Entkopplung von bestehenden Abhängigkeiten. Im Projekt zeigte sich beispielsweise, dass der OR-Mapper über alle Schichten hinweg verwendet wurde – bis ins UI. Diese enge Kopplung machte eine direkte Ablösung viel aufwendiger. Deshalb wurde zunächst die Architektur bereinigt:
- Trennung von Verantwortlichkeiten wurde wieder gestärkt
- Abhängigkeiten wurden reduziert
- Strukturen wurden klarer definiert
Zusätzlich wurde Dependency Injection eingeführt, noch im bestehenden Framework. Das Ziel: Die Grundlage schaffen, um spätere Änderungen überhaupt erst möglich zu machen. Diese Anpassungen waren Teil der Migration und dienten dazu, den späteren Umstieg risikoarm umzusetzen.n.
2. Brückentechnologien nutzen
Ein weiterer wichtiger Schritt war der Einsatz von .NET Standard. Diese Technologie ermöglichte es, Komponenten so zu entwickeln, dass sie sowohl im alten .NET Framework als auch im neuen .NET (Core) genutzt werden konnten. Das hatte einen entscheidenden Vorteil: Die Migration konnte schrittweise erfolgen, ohne vollständigen Bruch.
Statt alles auf einmal umzustellen, konnten einzelne Teile der Anwendung bereits modernisiert werden, während andere noch im alten System liefen. Diese Art von «Brücke» ist ein zentraler Erfolgsfaktor bei evolutionären Modernisierungen.
3. Kritische Komponenten gezielt ersetzen
Ein besonders kritischer Schritt im Projekt war der Austausch des veralteten OR-Mappers. Wichtig dabei: Dieser Austausch wurde nicht zu Beginn durchgeführt. Stattdessen wurde zuerst die notwendige Vorarbeit geleistet:
- Entkopplung der Datenbankobjekte
- Anpassung der Architektur
- Reduktion von Abhängigkeiten
Erst danach wurde der OR-Mapper ersetzt. Das reduzierte das Risiko erheblich. Denn ein gleichzeitiger Austausch der Technologie und der Architektur hätte die Komplexität und das Fehlerrisiko massiv erhöht. Hier zeigt sich ein zentrales Prinzip: Komplexe Veränderungen sollten nicht gleichzeitig, sondern sequenziell durchgeführt werden.
4. UI schrittweise modernisieren
Auch die Modernisierung des UI erfolgte evolutionär. Ein kompletter Austausch war nicht möglich, da das System weiterhin genutzt wurde und gleichzeitig neue Anforderungen erfüllt werden mussten. Deshalb wurde ein Parallelbetrieb etabliert:
- Alte UI-Komponenten blieben bestehen
- Neue Komponenten wurden schrittweise eingeführt
- Beide Welten existierten temporär nebeneinander
Dieser Ansatz erhöhte zwar kurzfristig die Komplexität, ermöglichte aber:
- kontinuierlichen Fortschritt
- kontrollierte Einführung neuer Technologien
- minimales Risiko für den laufenden Betrieb
Warum dieser Ansatz funktioniert
Die Vorteile dieses Vorgehens zeigen sich vor allem in der Risikosteuerung. Gleichzeitig entspricht dieser Ansatz auch der heutigen Realität moderner Softwareentwicklung: Statt grosser Wasserfallprojekte wird iterativ gearbeitet. Änderungen werden schrittweise umgesetzt, kontinuierlich überprüft und laufend verbessert. Genau dieses iterative Vorgehen wurde auch bei der Migration angewendet.
- Kein «Alles-oder-nichts»-Risiko
- Kontinuierliche Releases statt einmaliger Umstellung
- Frühes Feedback aus dem Betrieb
- Probleme werden früh erkannt und behoben
Im Gegensatz zum Big Bang entsteht kein einzelner kritischer Moment, an dem alles funktionieren muss. Stattdessen verteilt sich das Risiko über die gesamte Laufzeit. Das reduziert nicht nur die technische Unsicherheit, sondern auch die organisatorische Belastung.
Ein weiterer wichtiger Punkt: Durch die kontinuierlichen Releases konnten Migrationsteile direkt im produktiven Umfeld getestet werden. Fehler wurden früh erkannt und nicht erst am Ende des Projekts.
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!
Herausforderungen bewusst managen
Natürlich bringt auch dieser Ansatz Herausforderungen mit sich. Diese sollten jedoch nicht als Nachteile verstanden werden, sondern als bewusst steuerbare Aspekte.
- Temporär höhere Komplexität in der Codebase
- Erhöhter Koordinationsaufwand zwischen Teams
- Gezielte Feature-Freezes bei kritischen Schritten
Im Projekt zeigte sich beispielsweise, dass der Austausch des OR-Mappers nicht ohne eine kurze Phase ohne Feature-Entwicklung möglich war. Theoretisch wäre auch ein paralleler Betrieb von zwei OR-Mappern möglich gewesen. Der zusätzliche Aufwand und die höhere Komplexität hätten sich jedoch nicht gelohnt. Nachdem das Layering sauber vorbereitet war, konnte der Austausch in kurzer Zeit umgesetzt werden. Beim UI war die Situation anders, da dessen vollständige Ablösung deutlich länger gedauert hätte.
Solche Phasen sind notwendig und sollten aktiv eingeplant werden. Der entscheidende Unterschied: Diese Risiken sind kontrollierbar. Im Gegensatz zum Big Bang entstehen keine unkontrollierbaren Abhängigkeiten am Projektende.
Lessons Learned aus dem Projekt
Aus dem Projekt lassen sich klare Erkenntnisse ableiten:
- Keine Big-Bang-Migration durchführen
- Vorarbeit reduziert Risiko massiv
- Schrittweise Migration erhöht Steuerbarkeit
- Komplexe Änderungen sollten sequenziell erfolgen
- Frühes Testen im produktiven Umfeld ist entscheidend
Ein weiterer wichtiger Punkt: Die Modernisierung wurde in die bestehenden Releases integriert. Das bedeutet, dass Migration und Weiterentwicklung nicht getrennt wurden, sondern gemeinsam stattfanden. Das erhöhte die Effizienz und reduzierte das Risiko zusätzlicher Integrationsprobleme.
Fazit: Evolution schlägt Revolution
Softwaremodernisierung muss kein Hochrisikoprojekt sein. Mit dem richtigen Vorgehen wird sie planbar, steuerbar und kontrollierbar.
- Risiken werden verteilt statt konzentriert
- Fortschritt wird sichtbar statt verschoben
- Probleme werden früh erkannt statt am Ende eskaliert
Evolution schlägt Revolution.
Die drei zentralen Erkenntnisse aus dem Projekt:
- Veraltete Software ist ein strategisches Risiko
- Modernisierung braucht klare Führung
- Der richtige Ansatz entscheidet über Erfolg oder Misserfolg
Diese Erkenntnisse sind nicht theoretisch, sie basieren auf konkreten Projekterfahrungen. Wenn Sie wissen möchten, wo Ihre Software heute steht und wie eine risikoarme Modernisierung in Ihrem konkreten Kontext aussehen kann, sprechen Sie mit unseren Expert:innen.
Denn entscheidend ist nicht, ob Sie modernisieren. Sondern wann und wie.
FAQ
Bei einer Big-Bang-Migration wird ein bestehendes System vollständig durch eine neue Lösung ersetzt. Die Umstellung erfolgt zu einem festen Zeitpunkt, wodurch sich technische und organisatorische Risiken auf einen einzigen Go-Live konzentrieren. Bei einer schrittweisen Migration werden Komponenten und Technologien hingegen iterativ modernisiert. Das reduziert Risiken, ermöglicht kontinuierliche Releases und sorgt für mehr Kontrolle während des gesamten Projekts.
Das Risiko einer Softwaremodernisierung lässt sich durch ein evolutionäres Vorgehen deutlich reduzieren. Bewährte Methoden sind die schrittweise Entkopplung von Abhängigkeiten, der gezielte Austausch kritischer Komponenten sowie kontinuierliche Tests und Releases. Dadurch werden Probleme früh erkannt und können behoben werden, bevor sie den Geschäftsbetrieb beeinträchtigen.
Schrittweise Migrationen verteilen Risiken über die gesamte Projektlaufzeit und ermöglichen laufendes Feedback aus dem produktiven Betrieb. Unternehmen behalten die Kontrolle, können Prioritäten flexibel anpassen und erzielen bereits während der Modernisierung sichtbare Fortschritte. Dadurch sinkt die Wahrscheinlichkeit von Budgetüberschreitungen, Verzögerungen oder gescheiterten Transformationsprojekten deutlich.
Kevin Wyden
DAS KÖNNTE SIE AUCH INTERESSIEREN
Modernisieren ohne Stillstand: Wie Sie Software erneuern und gleichzeitig weiterentwickeln
