Woran erkennen Sie, dass Software zum Risiko wird?
Legacy-Software ist nicht einfach alte Software. Viele Systeme laufen seit Jahrzehnten zuverlässig. Zum Problem werden sie, wenn Änderungen langsam und riskant werden oder die technische Basis wegbricht. Typische Warnsignale:
- Die Plattform verliert die Herstellerunterstützung: Am 10. November 2026 endet der Support für .NET 8 und .NET 9, für Windows Server 2016 endet der erweiterte Support am 12. Januar 2027, für SQL Server 2016 endete er bereits am 14. Juli 2026. Das ältere .NET Framework 4.8 wird dagegen so lange unterstützt wie die Windows-Version, auf der es läuft.
- Das Wissen über das System steckt in wenigen Köpfen, Dokumentation fehlt.
- Kleine Änderungen dauern Wochen, weil niemand die Folgen abschätzen kann und automatisierte Tests fehlen.
- Neue Anforderungen wie Schnittstellen, mobile Nutzung oder die E-Rechnung lassen sich kaum umsetzen.
- Sicherheitsprüfungen finden Schwachstellen, die sich ohne grundlegenden Umbau nicht beheben lassen.
- Die Antwortzeiten werden mit wachsenden Datenmengen spürbar schlechter.
Ein einzelnes Signal ist noch kein Grund für ein großes Projekt. Treffen mehrere zu, sollten Sie eine Bestandsaufnahme planen, bevor ein Ausfall die Entscheidung erzwingt.
Neu bauen, umbauen oder ablösen? Die Strategien von Rehost bis Replace
Für die Modernisierung haben sich englische Begriffe eingebürgert. Sie gehen auf die „fünf R“ des Analysehauses Gartner von 2010 zurück, AWS hat die Liste später für Cloud-Migrationen auf sechs und dann sieben erweitert. Für Unternehmenssoftware sind vor allem diese Optionen relevant:
| Strategie | Was passiert | Aufwand | Wann sinnvoll |
|---|---|---|---|
| Rehost | Anwendung zieht unverändert auf neue Server oder eine neue Virtualisierung um | gering | Hardware oder Betriebssystem am Ende, Code in Ordnung |
| Replatform | kleine Anpassungen, etwa neue Datenbankversion oder Laufzeitumgebung | gering bis mittel | Plattform veraltet, Architektur trägt noch |
| Refactor | Code wird Schritt für Schritt aufgeräumt und auf aktuelle Technik gehoben, Funktionen bleiben gleich | mittel | Fachlogik ist wertvoll, Technik veraltet |
| Rebuild | Neuentwicklung mit moderner Architektur, fachlich auf Basis des Altsystems | hoch | Anforderungen stark verändert, Code nicht mehr wartbar |
| Replace | Ablösung durch Standardsoftware | mittel bis hoch (Einführung, Migration) | Ablauf ist inzwischen Standard, gutes Produkt verfügbar |
| Retire oder Retain | abschalten oder bewusst weiterbetreiben | gering | Funktion wird nicht mehr gebraucht oder ist stabil und abgeschottet |
Rehost und Replatform sind schnell erledigt und verschaffen Zeit, etwa wenn ein Server oder ein Betriebssystem ausläuft. Sie ändern aber nichts daran, dass Änderungen am Code langsam und riskant bleiben. Refactor und Rebuild lösen genau dieses Problem, brauchen dafür mehr Zeit und ein Team, das die Fachlogik versteht.
Die Wahl muss nicht für das ganze System gelten. Häufig wird die Datenbank aktualisiert, der Kern refaktoriert, ein Randmodul durch Standardsoftware ersetzt und ein veralteter Bericht abgeschaltet. Ob für einen Teil Standardsoftware passt, beantwortet unser Beitrag Individualsoftware oder Standardsoftware.
Das Strangler-Fig-Muster: modernisieren ohne Stichtag
Der Softwarearchitekt Martin Fowler hat dieses Vorgehen 2004 nach der Würgefeige benannt. Sie keimt in der Krone eines Wirtsbaums, umschließt ihn mit ihren Wurzeln und steht am Ende allein da. Übertragen auf Software sieht das so aus:
- Vor das Altsystem kommt eine Fassade, etwa ein API-Gateway oder eine Weiterleitungsschicht, über die alle Aufrufe laufen.
- Eine erste, gut abgrenzbare Funktion wird im neuen System gebaut. Die Fassade leitet die passenden Aufrufe dorthin um.
- Alt und neu laufen parallel, Daten werden zwischen beiden synchronisiert.
- Funktion für Funktion wandert ins neue System, jede einzeln getestet und bei Problemen zurücknehmbar.
- Hat das Altsystem nichts mehr zu tun, wird es abgeschaltet.
Der Vorteil: Nutzen entsteht früh, jedes Teilstück ist klein und beherrschbar, und ein Fehler betrifft nicht das ganze Unternehmen. Der Preis ist eine Übergangsarchitektur mit Synchronisation, die nach dem Projekt wieder entfällt.
So ist unser Team bei der Modernisierung einer gewachsenen Handelsplattform für einen Finanzdienstleister vorgegangen: Der Kern wurde schrittweise in einzelne Dienste überführt, parallel zum Altsystem und mit Synchronisation in beide Richtungen, ohne den laufenden Betrieb zu gefährden. Das neue System läuft 10- bis 100-mal schneller als das alte.
Risiken bewerten, bevor Sie entscheiden
Wie riskant eine Modernisierung wird, lässt sich vorab recht gut einschätzen. Bewerten Sie jedes System oder Modul anhand dieser Kriterien:
| Kriterium | Geringes Risiko | Hohes Risiko |
|---|---|---|
| Geschäftskritikalität | Ausfall von Stunden verkraftbar | Umsatz oder Produktion hängen direkt daran |
| Dokumentation und Tests | aktuelle Dokumentation, automatisierte Tests | keine Tests, Wissen nur bei Einzelnen |
| Fachlogik | bekannt und beschrieben | über Jahre gewachsen, viele Sonderfälle im Code |
| Schnittstellen | wenige und dokumentiert | viele, teils undokumentiert, Partner betroffen |
| Datenqualität | sauber, eindeutige Schlüssel | Dubletten, Altlasten, Freitextfelder |
| Plattform | noch unterstützt | Support beendet, Sicherheitslücken offen |
| Team | Entwickler verfügbar | ursprüngliche Entwickler nicht mehr erreichbar |
Je mehr Kriterien in der rechten Spalte landen, desto wichtiger ist ein schrittweises Vorgehen mit Rückfallmöglichkeit. Bei einer Plattform ohne Support hilft oft ein Zwischenschritt: das System erst abschotten und überwachen, dann modernisieren. Welche Lücken ein Altsystem tatsächlich hat, zeigt ein Schwachstellenscan oder Penetrationstest.
Datenmigration: der unterschätzte Teil
Code lässt sich neu schreiben, Daten müssen vollständig und korrekt übernommen werden. In der Praxis bewährt sich:
- Datenanalyse und erste Testmigration gleich zu Projektbeginn, nicht kurz vor dem Livegang.
- Felder, Formate, Dubletten und Sonderfälle systematisch erfassen. Altsysteme enthalten oft Fachlogik in den Daten selbst, etwa Kennzeichen, deren Bedeutung nur ein Mitarbeiter kennt.
- Die Migration als Skript automatisieren und mehrfach durchspielen, jede Runde mit Abgleich von Anzahlen und Summen.
- Stichproben von Anwendern prüfen lassen, die die Daten aus dem Alltag kennen.
- Die Umstellung festlegen: Zeitpunkt, Datenstand, Reihenfolge, Rückfallplan und wer die Freigabe erteilt.
- Altdaten, die nicht migriert werden, archivieren. Steuerlich relevante Unterlagen müssen nach § 147 AO je nach Art sechs, acht oder zehn Jahre aufbewahrt werden und für eine Betriebsprüfung maschinell auswertbar bleiben. Ein abgeschaltetes Altsystem ohne lesbaren Export hilft dann niemandem.
Hängt das Altsystem an ERP, Shop oder Partnern, gehören die Schnittstellen in denselben Plan. Worauf es dabei ankommt, beschreibt der Beitrag zu ERP-Schnittstellen.
Schritt für Schritt zur Modernisierung
- Code, Datenbanken, Schnittstellen, Betrieb, Nutzer und Abhängigkeiten erfassen.
- Ziele klären: Geht es um Sicherheit, Kosten, Geschwindigkeit, neue Funktionen oder Unabhängigkeit von einzelnen Personen?
- Den Betrieb absichern: Backups und Wiederherstellung prüfen, Überwachung einrichten und für kritische Abläufe Tests schreiben, die das heutige Verhalten festhalten.
- Die Strategie je Modul festlegen und nach Aufwand und Risiko bewerten.
- Ein abgegrenztes Modul mit spürbarem Nutzen als Pilot modernisieren und daraus lernen.
- Schrittweise migrieren, jeweils mit Parallelbetrieb und Abgleich.
- Das Altsystem abschalten und Übergangslösungen zurückbauen.
Typische Fehler bei der Modernisierung
- Großer Neubau mit einem Stichtag: Jahre ohne Nutzen, am Ende eine riskante Umstellung, bei der alles gleichzeitig funktionieren muss.
- Alles eins zu eins nachbauen: Auch Funktionen, die niemand mehr nutzt, werden neu entwickelt. Eine Auswertung der tatsächlichen Nutzung spart oft einen erheblichen Teil des Umfangs.
- Versteckte Regeln übersehen: Sonderfälle, die über Jahre in den Code gewandert sind, fallen erst im Betrieb auf. Tests, die das heutige Verhalten festhalten, machen sie früh sichtbar.
- Datenmigration zum Schluss: Sie wird dann zum Engpass und verschiebt den Livegang.
- Anwender zu spät beteiligt: Wer täglich mit dem System arbeitet, kennt die Abläufe besser als jede Dokumentation.
- Altsystem nie abgeschaltet: Ohne festen Plan für die Abschaltung laufen beide Systeme dauerhaft parallel, mit doppelten Kosten für Betrieb und Lizenzen.
Wie Unite2Link bei der Modernisierung hilft
Unser Team übernimmt bestehende Systeme, analysiert Code, Daten und Betrieb, sichert zuerst den laufenden Betrieb ab und modernisiert dann schrittweise. Am Anfang steht eine Bestandsaufnahme mit einer klaren Empfehlung je Modul, auf deren Grundlage Sie entscheiden. Wir sagen Ihnen auch, wenn Ablösen durch Standardsoftware oder bewusstes Weiterbetreiben die bessere Wahl ist. Abgerechnet wird nach Aufwand: Techniker ab 80 Euro, Ingenieur ab 120 Euro pro Stunde, netto. Mehr unter Individuelle Software und in unseren Projekten.