Das alte System funktioniert noch, aber wie lange?

Das Dilemma, das keiner lösen will

Dein ältestes System ist wahrscheinlich zwischen 10 und 20 Jahre alt. Es funktioniert. Aber jedes Update dauert länger. Fachleute werden knapp. Die Betriebskosten steigen jedes Jahr.

Gleichzeitig weiss jeder: Es ist furchtbar riskant, dieses System anzufassen. Es ist mit hunderten Prozessen verzahnt. Wenn etwas schiefgeht, stoppt das Geschäft.

Das ist das Legacy-Dilemma: Teure Maintenance oder teurer und unsicherer Change.

(Die meisten Unternehmen wählen Option drei: Augen zu und hoffen. Das funktioniert. Bis es nicht mehr funktioniert.)

Was Legacy-Systeme wirklich kosten

Die meisten Unternehmen unterschätzen die Kosten dramatisch. Sie schauen auf das IT-Budget und denken: "500.000 Franken pro Jahr für ein kritisches System - das ist doch okay."

Das ist nicht die ganze Wahrheit.

Die direkten Kosten

Hardware-Support für alte Systeme. Teure Lizenzen für proprietäre Plattformen. Backup und Recovery, das Spezialwissen braucht.

Die versteckten Kosten

Entwickler, die alte Technologien wie COBOL kennen, verdienen 30-50% mehr als der Durchschnitt. Fehlersuche dauert länger, weil weniger Menschen das System verstehen. Dokumentation, die entweder veraltet oder nicht existent ist.

Die Opportunitätskosten

Das ist der grösste Posten, der meistens übersehen wird.

Dein Entwickler-Team verbringt 60% seiner Zeit damit, das Legacy-System am Laufen zu halten. Das bedeutet: 60% weniger Zeit für neue Features.

Wenn eine neue Anforderung kommt, dauert die Integration drei Monate. Bei einem modernen System wären es drei Wochen.

Junior-Entwickler wollen nicht an COBOL arbeiten. Dein Recruiting wird schwieriger.

Rechne alles zusammen: Dein Legacy-System kostet dich nicht 500.000 Franken pro Jahr. Es kostet dich wahrscheinlich über eine Million.

Die drei Optionen

Es gibt genau drei strategische Wege. Keiner ist universell richtig. Alle haben Vor- und Nachteile.

Option 1: Migration

Du nimmst das System, wie es ist, und verschiebst es auf eine neue Plattform. Von On-Premise zu Cloud. Von alter Hardware zu moderner Infrastruktur. Die Geschäftslogik bleibt gleich - nur die Technologie darunter ändert sich.

Wann das Sinn macht: Das System ist technologisch veraltet, aber die Architektur ist solide. Du willst die Betriebskosten senken, ohne alles neu zu schreiben.

Kosten: Typischerweise 30-50% dessen, was ein Neuaufbau kosten würde. Zeitrahmen: 6-18 Monate.

Option 2: Ersatz

Das alte System wird komplett ersetzt. Entweder durch eine gekaufte Standardlösung (SAP, Salesforce) oder durch einen kompletten Neuaufbau.

Wann das Sinn macht: Die Architektur ist kaputt. Deine Geschäftsprozesse haben sich fundamental verändert. Du brauchst neue Fähigkeiten, die das alte System nicht kann.

Kosten: Die teuerste Option. Zeitrahmen: 18-36 Monate für einen Neuaufbau.

Option 3: Beibehaltung

Du behältst das System, aber machst es schmerzloser. Optimierung, besseres Monitoring, Sicherheits-Patches. Vielleicht versteckst du es hinter modernen APIs, sodass neue Systeme damit reden können.

Wann das Sinn macht: Das System ist stabil. Es gibt keine grossen Anforderungen für Erweiterung. Du hast nicht das Budget für Migration oder Neuaufbau.

Kosten: Kurzfristig die günstigste Option. Aber die Opportunitätskosten bleiben.

Wie du entscheidest

Die Frage ist nicht: Was ist die beste Option? Die Frage ist: Was ist die beste Option für dich?

Vier Fragen, die du dir stellen solltest:

Wie kritisch ist das System? Wenn es ausfällt, stoppt das Geschäft? Dann bist du risikoavers - lieber Migration als Neuaufbau.

Wie ist die Architektur? Solide Basis, nur alte Technologie? Migration. Zerbrochene Architektur mit hundert Patches? Eher Ersatz.

Wie oft brauchst du neue Features? Häufig neue Requirements? Dann ist der Innovationsstau teuer. Stabile, selten ändernde Requirements? Beibehaltung kann funktionieren.

Wie sieht dein Budget aus? Grosses Investitionsbudget? Ersatz ist realistisch. Kleines Budget, aber grosser Leidensdruck? Migration ist der Kompromiss.

Der häufigste Fehler

Der grösste Fehler, den wir sehen: Nichts tun und hoffen.

"Das System läuft doch noch. Warum sollten wir es anfassen?"

Das Problem: Die Zeit arbeitet gegen dich.

Mit jedem Jahr werden die Betriebskosten höher. Mit jedem Jahr finden weniger Entwickler die Technologie interessant. Mit jedem Jahr wird die Sicherheit fragwürdiger.

Irgendwann geht dein bester Experte in Rente. Oder wechselt den Job. Und plötzlich versteht niemand mehr, wie das System wirklich funktioniert.

Das ist der Punkt, an dem es teuer wird. Wirklich teuer.

Der zweitgrösste Fehler: Das ganze System ersetzen, wenn eine Migration gereicht hätte. Neuaufbauten sind riskant, teuer und dauern lang. Wenn die Architektur solide ist, ist Migration fast immer der bessere Weg.

Wenn es schiefgeht

Legacy-Modernisierung ist riskant. Aber Risiken sind managebar, wenn du sie früh erkennst.

Die grössten Probleme, die wir sehen:

Versteckte Abhängigkeiten. Das System hängt von hundert kleinen Dingen ab, die niemand dokumentiert hat. Lösung: Dependency Mapping früh im Projekt. Wer nutzt welche Daten? Welche Systeme sind abhängig?

Performance-Degradation. Das neue System ist langsamer als das alte. Lösung: Baseline-Messungen vor der Migration. Performance-Tests unter Last, bevor du live gehst.

Datenverlust. Bei der Migration gehen Daten verloren oder werden beschädigt. Lösung: Mehrere trockene Durchläufe. Datenvalidierung nach jeder Migration.

Scope Creep. Am Anfang war es eine Migration, jetzt wird ein Neuaufbau daraus. Lösung: Strikte Scope-Definition. Nur Migration, keine neuen Features. Änderungen müssen genehmigt werden.

Der Punkt

Legacy-Systeme sind nicht per se schlecht. Sie sind oft zuverlässig, stabil, bewährt. Das Problem ist: Sie werden teurer, während die Welt um sie herum sich verändert.

Es gibt keine universelle Antwort. Manche Systeme sollten migriert werden. Manche sollten ersetzt werden. Manche sollten behalten werden - vorläufig, mit klugem Management.

Das Schlimmste, was du tun kannst, ist nichts tun. Das Zweitschlimmste ist: Das ganze System ersetzen, wenn eine Migration genügt hätte.

Die richtige Entscheidung? Die, die zu deiner Situation passt. Nicht zu irgendeiner generischen Best Practice.

Der erste Schritt ist immer der gleiche: Ein ehrliches Gespräch. Was kostet uns das wirklich? Was sind unsere Optionen? Und wie lange können wir noch warten?

Danach wird es konkret.

Du hast ein Legacy-System, das dir Kopfschmerzen macht? Wir machen Assessments für Schweizer Unternehmen - ehrlich, pragmatisch, mit klaren Empfehlungen. Sprich mit uns.