Leistung /3
Ihr Kernsystem trägt Aufträge, Bestände und Abrechnung. Genau deshalb rührt es niemand an. Wir tauschen es modulweise aus, und das Tagesgeschäft läuft weiter.
Legacy ist kein Urteil über die Software und schon gar keines über die Menschen, die sie betreuen. Legacy heißt: ein System erfüllt seine Aufgabe, aber jede Änderung daran kostet mehr Zeit, mehr Abstimmung und mehr Mut als die vorige. Irgendwann ist die Sorge vor dem Eingriff der größere Bremsklotz als die Technik selbst.
Wir arbeiten seit 2003 an dieser Stelle. Ein Teil dessen, was heute als Altsystem auf dem Tisch liegt, ist in denselben Jahren entstanden, in denen wir gebaut haben. Wir kennen die Entscheidungen, die dahinterstehen, und in den meisten Fällen waren sie damals richtig.
Diese Seite beschreibt, woran Sie den Zeitpunkt erkennen, welche vier Wege offenstehen und mit welchem Verfahren eine Ablösung ohne Stillstand läuft. Sollten Sie danach zu dem Schluss kommen, dass Ihr System noch einige Jahre trägt, ist das ein brauchbares Ergebnis.
Für den Ort ist die Lage überschaubar: Zu Legacy-Modernisierung in Salzburg findet man derzeit vor allem überregionale Anbieter, die den Bestand nur aus der Ferne kennen. Wir sitzen in der Stadt Salzburg, kommen bei Bedarf in Ihr Haus und sehen uns das System dort an, wo es läuft. Bei gewachsenen Anwendungen zählt das, weil ein erheblicher Teil des Betriebswissens in den Handgriffen der Menschen steckt, die täglich damit arbeiten, und weder im Quelltext noch in der Dokumentation steht.
Fünf Anzeichen aus der Praxis. Keines davon ist ein Versäumnis Ihrer IT. Sie entstehen, weil ein System lange genug nützlich war, um immer weiter belastet zu werden.
Vier von fünf Anzeichen bedeuten nicht, dass Sie sofort handeln müssen. Sie bedeuten, dass die Entscheidung ab jetzt Ihnen gehört und nicht mehr dem Zufall. Das Gegenteil wäre der ungeplante Fall: ein Ausfall, ein Wechsel in der Belegschaft oder eine Anforderung von außen, die keinen Aufschub duldet. Dann entscheidet der Kalender, und das ist regelmäßig die teuerste Variante.
Nicht die Technik setzt die Frist, sondern die Verfügbarkeit der Menschen, die das System verstehen.
Systemwissen hängt in gewachsenen Landschaften an Personen, nicht an Dokumenten. Wer eine Anwendung über fünfzehn Jahre begleitet hat, trägt die Begründungen im Kopf: warum ein Feld doppelt geführt wird, warum ein Auftrag zwei Stati kennt, warum ein bestimmter Nachtlauf nie verändert wurde. Geht diese Person in Pension oder wechselt sie den Arbeitgeber, geht die Begründung mit. Die Software bleibt, ihre Lesbarkeit nicht.
Nachbesetzen ist keine verlässliche Antwort mehr. Statistik Austria hat erhoben, wie es Unternehmen ergeht, die IT-Personal suchen: Von den österreichischen Unternehmen ab zehn Beschäftigten, die 2023 IKT-Fachkräfte gesucht oder es zumindest versucht haben, berichteten zwei von drei über Stellen, die sich nur schwer besetzen ließen. Als häufigsten Grund nannten sie zu wenige Bewerbungen. Rechnet man nicht nur die suchenden, sondern alle Unternehmen einer Größenklasse, steigt der Anteil mit der Betriebsgröße: Von allen Unternehmen ab 250 Beschäftigten meldeten 44 Prozent schwer zu besetzende IKT-Stellen, von jenen mit 50 bis 249 Beschäftigten 14,5 Prozent, von den kleinen mit 10 bis 49 Beschäftigten 3,7 Prozent. Erhebung „IKT-Einsatz in Unternehmen“, Berichtsjahr 2023.
Der deutsche Markt, aus dem viele Bewerbungen kommen, entlastet den österreichischen nicht. Der Bitkom-Studienbericht „Der Arbeitsmarkt für IT-Fachkräfte“ nennt rund 109.000 offene Stellen für IT-Fachkräfte in der deutschen Wirtschaft. 85 Prozent der befragten Unternehmen beklagen den Mangel, 79 Prozent erwarten eine weitere Verschärfung. Erhebungsjahr 2025, befragt wurden 855 Unternehmen ab drei Beschäftigten.
Für Ihr Vorhaben heißt das zweierlei. Erstens ist die Person, die Ihr Altsystem erklären kann, heute noch da und in ein paar Jahren womöglich nicht mehr. Solange sie erreichbar ist, kostet eine Bestandsaufnahme einen Bruchteil dessen, was eine Rekonstruktion aus dem Quelltext kosten würde. Zweitens werden Sie die Modernisierung kaum mit zusätzlichem eigenem Personal stemmen, weil dieses Personal am Markt schwer zu bekommen ist. Der realistische Weg führt über vorhandene Kapazität von außen, kombiniert mit Ihren eigenen Leuten, die den Fachbereich kennen.
Belege
Die Frage lautet selten „alles behalten oder alles neu“. Zwischen diesen Polen liegen zwei Wege, die in der Praxis häufiger tragen als beide Extreme.
Das System bleibt, wie es ist. Sie sichern die Umgebung ab, dokumentieren das vorhandene Wissen und legen fest, wer im Ernstfall was tut. Sinnvoll, wenn die Anwendung fachlich stabil ist und sich absehbar nichts daran ändern soll.
Das Altsystem bleibt im Kern unangetastet und bekommt eine saubere Schnittstelle nach außen. Neue Anwendungen, Auswertungen oder KI-Funktionen greifen darüber zu, statt in die alte Struktur hineinzugreifen.
Ein Bereich nach dem anderen wandert auf eine neue Grundlage, während der Rest weiterläuft. Nach jedem Schritt ist ein Stück Altsystem abgeschaltet und ein Stück Neubau in Betrieb. Der häufigste Weg in unseren Projekten.
Die Anwendung entsteht vollständig neu, die alte läuft bis zur Umstellung weiter. Vertretbar, wenn sich der fachliche Ablauf selbst grundlegend ändert und ein Umbau des Bestands teurer käme als ein Neubau.
Welcher Weg trägt, entscheidet der Zustand Ihres Systems: das Datenmodell, die Zahl der Schnittstellen, das vorhandene Betriebswissen und die fachliche Stabilität des Ablaufs. Wir legen uns deshalb erst nach der Bestandsaufnahme fest und begründen die Empfehlung an dem, was wir im System gesehen haben.
Über eine Modernisierung entscheidet die Umstellung: der Tag, an dem die Fachbereiche mit dem neuen Stand arbeiten sollen. Deshalb steht das Verfahren fest, bevor die erste Zeile entsteht.
Stufe 1
Wir sehen uns an, was tatsächlich läuft: Datenmodell, Schnittstellen, Nachtläufe, die Stellen, an denen im Alltag von Hand nachgeholfen wird. Ergebnis ist ein schriftlicher Befund mit Risiken und einer Empfehlung für einen der vier Wege, dazu ein Vorschlag für den Schnitt des ersten Teilbereichs. Die Bestandsaufnahme beantwortet also die Frage „welcher Weg für dieses Altsystem und womit fangen wir an“. Wer stattdessen wissen will, ob die Struktur eines Systems überhaupt trägt und was sie in den nächsten Jahren kostet, ist beim Architektur-Review richtig.
Stufe 2
Aus dem Befund wird der erste Teilbereich ausgewählt: klein genug, um in wenigen Monaten fertig zu sein, groß genug, um im Betrieb spürbar zu sein. Dazu wird die Grenze definiert, an der Alt und Neu miteinander sprechen.
Stufe 3
Neu und Alt laufen eine definierte Zeit nebeneinander auf denselben Daten. Die Ergebnisse werden verglichen, Abweichungen geklärt, bevor irgendjemand umgestellt wird. Das kostet Zeit und ist genau der Grund, warum die Umstellung später unspektakulär verläuft.
Stufe 4
Umgeschaltet wird bereichsweise, nicht als Gesamtereignis. Für jede Umstellung steht vorher fest, woran wir Erfolg messen, wie lange der alte Stand erreichbar bleibt und wie der Rückweg aussieht. Die Rückfallebene wird vor der Umstellung einmal geprobt, damit im Ernstfall niemand improvisieren muss.
Stufe 5
Abgenommen wird je Stufe, nicht am Ende in einem Block. Dokumentation, Quelltext und Betriebswissen gehen mit. Wer die Software gebaut hat, ist auch in fünf Jahren noch erreichbar.
Dieses Verfahren ist langsamer als eine Umstellung an einem Wochenende, und das ist der Punkt. Jede Stufe hat einen eigenen Nutzen, eine eigene Abnahme und einen eigenen Rückweg. Sie können nach jeder Stufe unterbrechen, das Budget in ein anderes Vorhaben lenken und später weitermachen, ohne dass ein halbfertiger Zustand im Betrieb stehen bleibt.
Warum wir nicht abreißen
Ein Anbieter, der erst seit wenigen Jahren am Markt ist, sieht in einem gewachsenen System vor allem Unordnung. Wir sehen zwanzig Jahre Entscheidungen unter realen Bedingungen: begrenzte Budgets, Termine, Fachbereiche, die zu Recht Ausnahmen wollten. Diese Ausnahmen stehen heute als Sonderfälle im Quelltext, und fast jede davon hatte einen Grund.
Deshalb beginnt bei uns keine Modernisierung mit einer Liste dessen, was falsch gemacht wurde. Sie beginnt mit der Frage, welcher Teil des Bestands weiterhin Wert schafft. Ersetzt wird der Teil, der diesen Wert nicht mehr liefert, und zwar in dieser Reihenfolge und in dieser Begründungspflicht.
Das ist zugleich der Gründungsgedanke des Hauses: veraltete Strukturen und Technologien ersetzen und dabei auf dem bewährten Wissen der Generationen aufbauen. Der Satz steht seit 2003 im Firmenprofil, und er beschreibt bis heute die Reihenfolge, in der wir vorgehen.
Die Fragen, die in Erstgesprächen regelmäßig zuerst kommen.
Das hängt vom gewählten Weg ab. Eine Absicherung des Weiterbetriebs ist in Wochen erledigt. Eine Kapselung mit sauberer Schnittstelle liegt üblicherweise im Bereich weniger Monate. Eine schrittweise Ablösung läuft je nach Umfang über Monate bis Jahre, ist dabei aber in Stufen geschnitten, die einzeln in Betrieb gehen. Verlässlich lässt sich das erst nach einer Bestandsaufnahme sagen, und die dauert bei einem mittelgroßen System wenige Wochen.
Die Daten sind in aller Regel der wertvollste Teil des Altsystems und werden vollständig übernommen. Vor jeder Umstellung läuft eine Übernahme auf Testständen, danach ein Vergleich zwischen altem und neuem Stand. Umgestellt wird erst, wenn die Ergebnisse übereinstimmen. Historische Daten, die im laufenden Betrieb nicht mehr gebraucht werden, bleiben in einem lesbaren Archiv erreichbar.
Für jede Stufe steht vor der Umstellung fest, woran Erfolg gemessen wird und wie der Rückweg aussieht. Der alte Stand bleibt eine vereinbarte Zeit lang betriebsbereit. Weil bereichsweise umgestellt wird und nicht als Gesamtereignis, betrifft ein Rückschritt immer nur einen Bereich und niemals das ganze Haus.
Wir. Geschult wird pro Stufe und kurz vor der jeweiligen Umstellung, nicht Monate vorher am Stück. In der Praxis genügen bei einer schrittweisen Ablösung meist wenige Stunden je Bereich, weil sich für die Anwenderinnen und Anwender jeweils nur ein Ausschnitt ändert.
Es wird geordnet abgeschaltet. Zum Abschluss jeder Stufe halten wir fest, welche Teile des Altsystems außer Betrieb gehen können, welche Daten vorher gesichert werden und welche Lizenzen oder Wartungsverträge damit entfallen. Diese eingesparten Betriebskosten sind bei älteren Systemen oft der Teil der Rechnung, der zuerst vergessen wird.
Nein. Die Bestandsaufnahme ist als eigenständige Leistung buchbar und endet mit einem schriftlichen Befund, der Ihnen gehört. Sie können damit intern weiterarbeiten oder ihn einem anderen Anbieter vorlegen. Uns ist eine belastbare Entscheidungsgrundlage lieber als ein Auftrag, der auf einer Vermutung beruht.
In der Frage, die beantwortet wird. Die Bestandsaufnahme setzt ein konkretes Altsystem voraus und beantwortet, welcher der vier Wege dafür trägt und wie der erste Teilbereich geschnitten wird. Sie ist der erste Schritt einer Ablösung und lässt sich anrechnen, wenn eine folgt. Das Architektur-Review beantwortet eine Frage davor: ob die Struktur eines Systems tragfähig ist, welche Risiken sie birgt und in welcher Reihenfolge sie zu bearbeiten sind. Es setzt kein Altsystem voraus und wird auch für geplante Neubauten beauftragt. Wenn Ihr Altsystem feststeht und die Ablösung Thema ist, beginnen Sie hier. Wenn die Frage lautet, ob überhaupt und in welcher Richtung, beginnen Sie beim Review.
Ein überschaubarer erster Schritt mit festem Ende: Wir sehen uns Ihr Altsystem an und liefern einen schriftlichen Befund mit Risiken, einer Wegempfehlung und dem Schnitt für den ersten Teilbereich. Was danach passiert, entscheiden Sie.
