Unsere dreiteilige Artikel-Serie thematisiert Erfahrungen aus Software Modernisierungsprojekten und beleuchtet verschiedene Aspekte. Alle genannten Beispiele stammen aus realen Cases.
2. Beitrag: Modernisieren ohne Stillstand
3. Beitrag: Keine Big-Bang-Migration
Läuft doch – oder?
«Warum sollten wir etwas ändern? Die Software läuft doch.»
Diesen Satz hören wir in nahezu jedem zweiten Modernisierungsprojekt bei bbv. Und er ist nachvollziehbar. Systeme, die über viele Jahre stabil betrieben wurden, vermitteln Sicherheit. Sie sind etabliert, die Prozesse sind eingespielt, die Anwender kennen die Abläufe. Aus Sicht des Business scheint alles unter Kontrolle zu sein.
Gerade bei Software, die über Jahre gewachsen ist und zuverlässig funktioniert, entsteht schnell das Gefühl, dass Veränderungen mehr Risiko als Nutzen bringen. Jede Anpassung bedeutet potenziell Aufwand, Unsicherheit und Kosten, während der Status quo scheinbar keine Probleme verursacht.
Doch genau diese Stabilität ist trügerisch.
Denn während die Software im operativen Betrieb weiterhin funktioniert, verändert sich das Umfeld kontinuierlich. Und oft schneller, als es im Alltag sichtbar wird. Technologien entwickeln sich weiter, Plattformen werden ersetzt, Browser ändern ihr Verhalten, und Softwarehersteller wie Microsoft setzen neue Standards und lassen alte Technologien auslaufen.
Diese Veränderungen passieren unabhängig davon, ob ein Unternehmen aktiv handelt oder nicht. Die Folge: Ein System kann gleichzeitig stabil laufen und strategisch längst zum Risiko geworden sein.
Und genau dieser Moment ist besonders kritisch, weil das Problem nicht offensichtlich ist, aber bereits Wirkung entfaltet.
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: Wenn «gut gebaut» nicht mehr reicht
In einem konkreten bbv Projekt war die Ausgangslage technisch eigentlich vielversprechend:
- Grundsätzlich saubere Layered Architektur
- Klare Trennung zwischen UI, Business-Logik und Datenzugriff
- Über Jahre gewachsene, stabile Funktionalität
Aus architektonischer Sicht gab es wenig zu kritisieren. Die Struktur war nachvollziehbar, die Verantwortlichkeiten klar getrennt, und die Software erfüllte die Qualitätsanforderungen.
Und trotzdem war das System faktisch nicht mehr zukunftsfähig.
Warum?
Weil zentrale technologische Bausteine veraltet oder sogar abgekündigt waren, und damit die Weiterentwicklung blockierten.
- Ein eingesetzter OR-Mapper wurde nicht mehr weiterentwickelt
- Die Anwendung nutzte WCF – eine Technologie, die im modernen .NET-Ökosystem keine Rolle mehr spielt
- Ein Upgrade vom .NET Framework auf moderne .NET-Versionen war blockiert
Diese Kombination führte dazu, dass selbst grundlegende technologische Weiterentwicklungen nicht mehr möglich waren, ohne tief in die bestehende Struktur einzugreifen. Das System war architektonisch solide, aber technologisch isoliert.
Und genau das ist ein typisches Muster in vielen Unternehmen: Die Software ist «gut gebaut», aber auf einer technologischen Basis, die nicht mehr mit der Realität Schritt hält.
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.
Architektur vs. Technologie: Zwei unterschiedliche Lebenszyklen
Ein zentraler Denkfehler in vielen Organisationen ist die Gleichsetzung von Architekturqualität und Zukunftssicherheit. Doch diese beiden Dinge folgen unterschiedlichen Lebenszyklen.
Eine gute Architektur ist darauf ausgelegt, langfristig stabil zu bleiben. Sie definiert Prinzipien, Strukturen und Verantwortlichkeiten, die über Jahre hinweg Bestand haben können.
Technologien und Frameworks hingegen unterliegen deutlich schnelleren Innovationszyklen. Sie werden weiterentwickelt, ersetzt oder vollständig abgelöst. Das bedeutet:
- Architektur ist langlebig
- Technologien und Frameworks haben kurze Innovationszyklen
- Eine saubere Architektur vereinfacht das Aktualisieren von Technologien und Frameworks
Ein System kann also architektonisch hervorragend gebaut sein, und trotzdem technologisch veralten. Im beschriebenen Projekt war genau das der Fall. Die Architektur war nicht das Problem. Sie war sogar ein stabiler Ausgangspunkt für die Modernisierung. Die Herausforderung lag in den verwendeten Technologien, die nicht mehr weiterentwickelt wurden oder nicht mehr mit aktuellen Plattformen kompatibel waren.
Diese Differenz ist entscheidend für Entscheider:
Es reicht nicht, dass eine Software «gut gebaut» ist.
Sie muss auch technologisch anschlussfähig bleiben.
Wenn Abhängigkeiten zur Blockade werden
Besonders kritisch wurde im Projekt die Abhängigkeit vom veralteten OR-Mapper. Auf den ersten Blick handelt es sich dabei um eine technische Komponente im Hintergrund. Doch ihre Auswirkungen waren weitreichend:
- Der OR-Mapper wurde nicht mehr gepflegt
- Es gab kaum Dokumentation
- Know-how war schwer verfügbar
- Und vor allem: Er war nicht kompatibel mit modernen .NET-Versionen
Das führte dazu, dass eine eigentlich sinnvolle Modernisierung, nämlich der Wechsel auf eine aktuelle .NET-Version, nicht möglich war, ohne diesen Baustein zu ersetzen.
Theoretisch hätte man den OR-Mapper selbst weiterentwickeln können, etwa durch einen Fork des bestehenden Repositories. In der Praxis ist das jedoch kaum realistisch, da der Aufwand enorm wäre und entsprechendes Spezialwissen erforderlich ist.
Das Ergebnis: Ein einzelner technischer Baustein blockierte die gesamte Modernisierung.
Noch problematischer war die enge Kopplung innerhalb der Anwendung. Die Datenbankobjekte wurden über alle Schichten hinweg verwendet – bis ins UI. Diese Objekte enthielten sogar Metainformationen, die im UI gesetzt wurden. Das führte dazu, dass:
- Änderungen schwer isolierbar waren
- Ein Austausch des OR-Mappers tiefgreifende Anpassungen erforderte
- Architekturprinzipien wie klare Schichtentrennung faktisch unterlaufen wurden
Technische Schulden waren damit nicht nur vorhanden, sie waren strukturell in der Anwendung verankert. Und genau das macht ihre Behebung so aufwendig.
Wenn externe Faktoren plötzlich Druck erzeugen
Solange ein System intern «noch funktioniert», werden solche Probleme oft toleriert oder bewusst zurückgestellt. Doch irgendwann kommen externe Faktoren ins Spiel und verändern die Situation schlagartig.
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!
Im konkreten Projekt waren es gleich mehrere:
1. Browser-Inkompatibilität
Die Anwendung funktionierte nur mit dem Internet Explorer. Da moderne Browser das verwendete Session-Handling nicht mehr unterstützten, entstand ein unmittelbares Risiko für den operativen Betrieb.
Mit der Ablösung des Internet Explorers durch moderne Browser war klar: Dieses Problem würde nicht von selbst verschwinden.
2. Plattformwechsel bei Microsoft
Mit der Einführung von .NET (ehemals .NET Core) hat Microsoft einen grundlegenden technologischen Wandel vollzogen.
Zentrale Technologien wie WCF wurden dabei nicht weitergeführt oder nur eingeschränkt unterstützt. Anwendungen, die stark auf diese Technologien setzten, konnten nicht einfach migriert werden.
3. Unklare Lebenszyklen
Das .NET Framework wird zwar noch unterstützt, erhält jedoch kaum neue Features. Gleichzeitig ist unklar, wann genau der Support endet.
Für Unternehmen bedeutet das:
- Sie wissen, dass sie handeln müssen
- Aber nicht genau, bis wann
Diese Unsicherheit ist besonders kritisch. Denn Modernisierung ist kein kurzfristiges Projekt – sie braucht Zeit, Planung und Ressourcen. Und genau diese Zeit fehlt, wenn der Druck von aussen plötzlich steigt.
Der schleichende Business Impact
Viele der beschriebenen Probleme sind zunächst technischer Natur. Doch ihre Auswirkungen werden im Alltag sehr schnell geschäftsrelevant.
Im Projekt zeigte sich das unter anderem in folgenden Punkten:
- Neue Features konnten nicht mehr effizient umgesetzt werden
- Entwickler mussten mehr Zeit in Workarounds investieren
- Die Einarbeitung neuer Entwickler wurde deutlich aufwendiger
- Die Weiterentwicklung insgesamt verlangsamte sich
Ein besonders anschauliches Beispiel war der eingesetzte OR-Mapper. Da er kaum dokumentiert und wenig verbreitet war, konnten neue Entwickler nicht auf bestehendes Wissen zurückgreifen. Sie mussten sich die Funktionsweise selbst erarbeiten, ohne Unterstützung durch Community, Dokumentation oder etablierte Best Practices.
Das führt zu:
- längeren Einarbeitungszeiten
- höherem Risiko bei Änderungen
- sinkender Produktivität
Gleichzeitig hatte auch das UI direkte Auswirkungen auf die Anwender:
Da moderne Browser nicht vollständig unterstützt wurden, entstand ein reales Risiko für die Nutzbarkeit der Anwendung.
Ein veraltetes UI bringt in der Regel auch eine schlechtere Usability mit sich. Funktionen sind weniger intuitiv, Abläufe komplizierter und Interaktionen fehleranfälliger.
Die Folge: Benutzer machen häufiger Fehler, was wiederum zu Mehraufwand im Betrieb und in der Entwicklung führt, etwa durch Supportanfragen, Korrekturen oder zusätzliche Absicherungen im System.
Und genau hier wird aus einem technischen Problem ein Business-Thema.
Der gefährlichste Moment: Wenn Handlungsdruck entsteht
Das grösste Risiko entsteht nicht durch die Existenz technischer Schulden. Sondern durch den Zeitpunkt, an dem sie kritisch werden. Wenn Modernisierung zu spät angegangen wird, passiert Folgendes:
- Der Handlungsspielraum schrumpft
- Migration muss unter Zeitdruck erfolgen
- Risiken steigen massiv
Unternehmen geraten dann in eine Situation, in der sie nicht mehr strategisch entscheiden können, sondern reagieren müssen.
Im beschriebenen Projekt wurde bewusst früh reagiert. Der Impuls zur Modernisierung kam aus der Entwicklung mit dem klaren Ziel, den technologischen Wandel proaktiv anzugehen und nicht abzuwarten, bis externe Zwänge entstehen.
Das ist ein entscheidender Unterschied.
Denn frühes Handeln bedeutet:
- mehr Optionen
- bessere Planbarkeit
- geringeres Risiko
Fazit: Stabilität ist kein Zukunftsversprechen
Unsere Erfahrung aus zahlreichen bbv Projekten zeigt klar:
- Systeme werden nicht plötzlich kritisch – sie entwickeln sich schrittweise dorthin
- Technologische Abhängigkeiten sind oft der eigentliche Risikotreiber
- «Funktioniert noch» ist kein valides Entscheidungskriterium
Stabilität im Betrieb ist wichtig, aber sie darf nicht mit Zukunftssicherheit verwechselt werden.
Wer früh handelt, hat Optionen.
Wer wartet, hat irgendwann nur noch Zwänge.
Ausblick auf Teil 2: Doch selbst wenn der Handlungsbedarf erkannt ist, beginnt die eigentliche Herausforderung erst: Wie modernisieren Sie Ihre Software, ohne Ihr Business auszubremsen?
FAQ
Ein Warnsignal ist, wenn Ihre Software zwar stabil läuft, aber auf veralteten Technologien oder Frameworks basiert. Schwierigkeiten bei Updates, fehlender Hersteller-Support, steigender Wartungsaufwand oder Probleme bei der Integration neuer Funktionen sind typische Hinweise darauf, dass eine Softwaremodernisierung sinnvoll wird.
Veraltete Technologien können Innovationen ausbremsen, Sicherheitsrisiken erhöhen und die Weiterentwicklung von Software erschweren. Wenn Frameworks, Bibliotheken oder Plattformen nicht mehr unterstützt werden, steigt das Risiko von Inkompatibilitäten, Fachkräftemangel und ungeplanten Modernisierungsprojekten unter Zeitdruck.
Der beste Zeitpunkt ist, bevor akuter Handlungsdruck entsteht. Unternehmen sollten ihre Anwendungen regelmässig hinsichtlich Technologie-Stack, Abhängigkeiten und Zukunftsfähigkeit bewerten. Wer frühzeitig modernisiert, profitiert von mehr Planungssicherheit, geringeren Risiken und niedrigeren Kosten als bei einer erzwungenen Migration.
Kevin Wyden
DAS KÖNNTE SIE AUCH INTERESSIEREN
Modernisieren ohne Stillstand: Wie Sie Software erneuern und gleichzeitig weiterentwickeln
