EXECUTIVE SUMMARY
Eine alte Benutzeroberfläche, eine selten gewordene Programmiersprache oder fehlende Cloud-Anbindung sind ernstzunehmende Signale. Sie beweisen jedoch noch nicht, dass eine vollständige Neuentwicklung die beste Lösung ist. In gewachsener Individualsoftware steckt häufig jahrzehntelang verdichtetes Prozesswissen. Wer dieses System vollständig ersetzt, ersetzt deshalb nicht nur Code, sondern muss Regeln, Daten, Ausnahmen und betriebliche Routinen neu entdecken. Die verantwortungsvollere erste Entscheidung lautet meist: zuerst verstehen, dann entscheiden.
TECHNOLOGY STRATEGY
Warum eine komplette Neuentwicklung
oft die falsche erste Entscheidung ist
Montagmorgen, 8:30 Uhr. Im Besprechungsraum sitzen Geschäftsführung, IT-Leitung und die wichtigsten Fachbereiche. Auf dem Bildschirm steht ein Satz: „Unsere Software ist über zwanzig Jahre alt.“ Wenige Minuten später folgt die scheinbar logische Konsequenz: „Dann entwickeln wir eben alles neu.“
Der Satz klingt entschlossen. Er verspricht einen klaren Schnitt, moderne Technik und das Ende jahrelanger Kompromisse. Doch zu diesem Zeitpunkt ist eine der teuersten Entscheidungen des Projekts bereits gefallen – obwohl häufig noch niemand genau weiß, was eigentlich ersetzt werden soll.
Der folgenschwere Reflex: Aus „alt“ wird „komplett neu“
Der Wunsch nach einem Neustart ist verständlich. Alte Anwendungen sehen oft nicht mehr zeitgemäß aus. Sie basieren vielleicht auf Visual Basic 5 oder 6, Delphi, PowerBuilder oder einer historisch gewachsenen Datenbank. Moderne Schnittstellen fehlen, neue Entwickler sind schwer zu finden und jede Änderung fühlt sich aufwendiger an als sie sein sollte.
Das Problem beginnt, wenn diese Symptome mit einer Diagnose verwechselt werden. Eine veraltete Oberfläche bedeutet nicht zwangsläufig, dass auch die Geschäftslogik wertlos ist. Fehlende APIs bedeuten nicht, dass der Kern des Systems ersetzt werden muss. Und eine alte Programmiersprache sagt zunächst nur etwas über die technische Plattform aus – nicht über die Qualität der darin abgebildeten Abläufe.
Alt ist eine Zustandsbeschreibung, keine Strategie.
Bevor eine Anwendung ersetzt wird, muss geklärt werden, welche Teile tatsächlich ein Risiko darstellen und welche Teile zuverlässig Wert schaffen.
Eine komplette Neuentwicklung wird oft als sauberste Lösung wahrgenommen. In Wirklichkeit ist sie die Variante mit dem größten Veränderungsumfang. Oberfläche, Architektur, Datenzugriff, Schnittstellen, Bedienlogik und häufig auch Prozesse werden gleichzeitig neu gestaltet. Genau diese Gleichzeitigkeit macht den vermeintlich klaren Neustart so schwer kontrollierbar.
Die bestehende Software ist das digitale Gedächtnis des Unternehmens
Individualsoftware entsteht selten in einem einzigen Projekt. Sie wächst über Jahre. Ein wichtiger Kunde verlangt eine Sonderregel. Eine gesetzliche Änderung muss kurzfristig umgesetzt werden. Ein manueller Arbeitsschritt wird automatisiert. Eine Schnittstelle zu einer Maschine, einem Lieferanten oder einem Abrechnungssystem kommt hinzu. Fehler werden behoben, Prozesse beschleunigt und Ausnahmen ergänzt.
Jede dieser Änderungen enthält eine fachliche Entscheidung. Viele davon wurden nie vollständig dokumentiert. Das ursprüngliche Lastenheft beschreibt den heutigen Zustand nur noch teilweise. Die damaligen Entwickler sind möglicherweise im Ruhestand, und langjährige Mitarbeiter können zwar erklären, wie sie mit dem System arbeiten, aber nicht immer, warum bestimmte Regeln existieren.
Damit wird die Anwendung selbst zur maßgeblichen Dokumentation. Ihr Quellcode, ihre Datenstrukturen und ihr Verhalten enthalten Wissen über Preise, Freigaben, Fristen, Prioritäten, Plausibilitätsprüfungen, Produktionsabläufe und Kundenvereinbarungen. Eine Neuentwicklung muss dieses Wissen nicht nur „übertragen“. Sie muss es zunächst entdecken, verstehen, bewerten und korrekt nachbilden.
Software altert technisch. Das darin gespeicherte Geschäftswissen verliert dadurch nicht automatisch seinen Wert.
Besonders gefährlich sind unscheinbare Sonderfälle. Sie betreffen vielleicht nur zwei Prozent aller Vorgänge, verhindern dort aber teure Fehler. In einer Neuentwicklung erscheinen sie in der Analysephase schnell als Randthemen – bis sie nach dem Produktivstart fehlen.
Die unterschätzte Rechnung einer Neuentwicklung
Bei der Budgetplanung wird häufig zuerst über Entwicklungsaufwand gesprochen. Doch Programmierung ist nur ein Teil der Gesamtrechnung. Eine belastbare Neuentwicklung umfasst mindestens Prozessaufnahme, Fachkonzept, Architektur, Umsetzung, Tests, Datenmigration, Schulung, Parallelbetrieb und Stabilisierung.
Die Darstellung zeigt keine absoluten Kosten, sondern typische Risikofelder. Der schwer planbare Aufwand liegt häufig außerhalb der reinen Programmierung.
Hinzu kommen betriebliche Kosten, die in Angeboten kaum sichtbar werden: Fachmitarbeiter fehlen in ihrem Tagesgeschäft, weil sie Workshops und Tests begleiten. Erfahrene Anwender prüfen neben ihrer regulären Arbeit neue Funktionen. Fehler in der Übergangsphase verursachen Rückfragen, manuelle Korrekturen oder Verzögerungen. Und solange das neue System noch nicht stabil ist, muss das alte häufig parallel weiterbetrieben werden.
Eine Neuentwicklung kann deshalb technisch im Budget liegen und wirtschaftlich trotzdem deutlich teurer werden als geplant. Das gilt besonders dann, wenn der Umfang erst im Projektverlauf sichtbar wird.
Wo Projekte wirklich scheitern
Große Softwareprojekte scheitern selten daran, dass Entwickler keine Eingabemaske bauen können. Die kritischen Fragen sind fachlicher und organisatorischer Natur: Sind alle Regeln bekannt? Sind Entscheidungen rechtzeitig verfügbar? Können reale Daten zuverlässig migriert werden? Ist der neue Prozess unter Zeitdruck tatsächlich praktikabel? Und stimmen die Erwartungen von Geschäftsführung, Fachbereichen und IT überein?
Big - Bang - Neuentwicklung
Alle wesentlichen Komponenten werden gleichzeitig ersetzt. Erkenntnisse entstehen spät, Abhängigkeiten werden erst während der Umsetzung sichtbar.
Hohe VeränderungsdichteAnalyse und schrittweise Modernisierung
Kritische Risiken werden zuerst abgesichert. Neue Komponenten liefern früh Nutzen und können im laufenden Betrieb validiert werden.
Kontrollierbare LernschritteDer Unterschied liegt nicht zwingend in der Qualität der beteiligten Entwickler. Er liegt in der Reihenfolge der Entscheidungen. Ein Big Bang verlangt, dass sehr viele Annahmen früh richtig sind. Eine schrittweise Modernisierung schafft dagegen Zwischenstände, aus denen das Unternehmen lernen kann.
Bei einer Bestandsaufnahme zeigt sich häufig: Nicht „die Software“ ist das Problem. Kritisch sind einzelne Komponenten – etwa ein nicht reproduzierbarer Build, veraltete Datenbanktreiber, fehlende Schnittstellen oder ein Schlüsselpersonen-Risiko. Diese Themen lassen sich gezielt behandeln, ohne den gesamten fachlichen Kern aufzugeben.
Modernisierung ist kein Festhalten am Alten
Modernisierung wird manchmal missverstanden als Versuch, eine überholte Anwendung künstlich zu verlängern. Eine gute Modernisierungsstrategie tut das Gegenteil: Sie trennt wertvolle Geschäftslogik von technischen Begrenzungen und erneuert das System dort, wo der Nutzen am größten ist.
Das kann bedeuten, zunächst Quellcode und Build-Prozess abzusichern, eine aktuelle Datenbankplattform einzuführen, APIs um bestehende Funktionen zu legen oder neue Weboberflächen für ausgewählte Arbeitsplätze bereitzustellen. Später können Module neu geschrieben, mobile Anwendungen ergänzt und externe Dienste integriert werden.
Verstehen
Geschäftswert, Risiken und Abhängigkeiten sichtbar machen.
Absichern
Quellcode, Builds, Daten und Betrieb stabilisieren.
Entkoppeln
Schnittstellen schaffen und technische Grenzen lösen.
Erneuern
Module nach Priorität modernisieren oder ersetzen.
Der laufende Betrieb bleibt dabei nicht automatisch risikofrei, aber die Veränderung wird in beherrschbare Einheiten zerlegt. Jede Stufe kann fachlich geprüft werden. Investitionen lassen sich priorisieren, und Nutzen entsteht früher.
Wann eine komplette Neuentwicklung trotzdem richtig ist
Eine seriöse Bewertung darf Modernisierung nicht zum Dogma machen. Es gibt Situationen, in denen eine Neuentwicklung die bessere Entscheidung ist. Das kann der Fall sein, wenn das Geschäftsmodell grundlegend wechselt, die vorhandene Architektur zentrale Anforderungen nicht mehr erfüllen kann oder der fachliche Kern der Altanwendung nur noch geringe Relevanz besitzt.
Auch dauerhaft nicht beherrschbare Sicherheitsrisiken, fehlende Betriebsfähigkeit oder extrem hohe Änderungsaufwände können für einen Neustart sprechen. Entscheidend ist jedoch, dass diese Gründe durch eine Analyse belegt werden. „Die Software ist alt“ reicht als Begründung für eine weitreichende Investitionsentscheidung nicht aus.
Der Executive - Entscheidungsrahmen
Vor einer Grundsatzentscheidung sollte die Geschäftsführung fünf Fragen belastbar beantworten können:
- Welchen messbaren Geschäftswert liefert die bestehende Anwendung heute?Welche Umsätze, Abläufe, Kundenbeziehungen oder Produktionsschritte hängen von ihr ab?
- Welche Risiken sind tatsächlich technisch – und welche organisatorisch?Eine seltene Programmiersprache, fehlende Dokumentation und ein einzelner Wissensträger erfordern unterschiedliche Maßnahmen.
- Welche Geschäftsregeln sind dokumentiert?Was müsste bei einer Ablösung erst aus Code, Daten und Anwenderwissen rekonstruiert werden?
- Welcher Nutzen soll in den nächsten zwölf bis 24 Monaten entstehen?Eine klare Priorisierung verhindert, dass ein Großprojekt viele Ziele verfolgt, aber lange keinen Nutzen liefert.
- Kann ein Pilot die wichtigste Annahme prüfen?Ein klar abgegrenzter Modernisierungsschritt liefert oft mehr Entscheidungsqualität als monatelange theoretische Planung.
Erst wenn diese Fragen beantwortet sind, lässt sich sinnvoll zwischen Weiterbetrieb, Stabilisierung, Modernisierung, Teilersatz und kompletter Neuentwicklung unterscheiden.
Die wichtigste Entscheidung wird häufig zu früh getroffen
Eine komplette Neuentwicklung kann richtig sein. Sie ist jedoch selten die verantwortungsvollste erste Entscheidung. Denn bevor ein Unternehmen alles ersetzt, sollte es wissen, welchen Wert es besitzt, wo die tatsächlichen Risiken liegen und welche Teile der Anwendung bereits zuverlässig funktionieren.
Der bessere Ausgangspunkt ist eine strukturierte Bestandsaufnahme: Technik, Daten, Geschäftslogik, Betrieb, Abhängigkeiten und Wissen. Daraus entsteht kein pauschales Plädoyer für alte Software, sondern eine belastbare Entscheidungsgrundlage.
Gute Software wird nicht daran gemessen, wie modern ihr Quellcode ist. Sondern daran, welchen Beitrag sie jeden Tag zum Unternehmenserfolg leistet.
Die entscheidende Frage lautet deshalb nicht: „Wie alt ist unsere Software?“ Sondern: „Welchen geschäftlichen Wert besitzt das darin gespeicherte Wissen – und wie führen wir diesen Wert sicher in die Zukunft?“
NÄCHSTER SCHRITT
Erst verstehen. Dann investieren.
Der kostenlose Software Health Check liefert eine erste strukturierte Einordnung. Für eine konkrete Situation können Sie außerdem ein 30-minütiges kostenloses Erstgespräch vereinbaren.