Manuel Bach, MSc · Stand: Oktober 2026
Software-Modernisierung bedeutet, eine bestehende Anwendung so zu erneuern, dass sie wieder sicher, wartbar und an heutige Abläufe angepasst ist, ohne wichtige Daten oder Fachwissen zu verlieren. Bei überschaubaren Altsystemen ist ein sauberer Neubau mit Datenübernahme häufig sinnvoller als eine aufwendige Sanierung des bestehenden Systems. Ein Altsystem erkennen Sie meist daran, dass mehrere Probleme gleichzeitig auftreten, aktuelle Sicherheitsanforderungen nicht mehr erfüllt werden und wichtiges Wissen nur noch bei einzelnen Personen liegt.
Fast jedes Unternehmen kennt sie: die Anwendung, die seit Jahren zuverlässig ihren Dienst tut, die alle kennen und die trotzdem niemand mehr gerne anfasst. Eine Datenbank aus den Nullerjahren, ein Programm eines Herstellers, den es längst nicht mehr gibt, oder ein Werkzeug, das nur auf einem bestimmten Rechner im Büro funktioniert. Noch läuft alles irgendwie, aber allen Beteiligten ist klar, dass dieser Zustand nicht ewig halten wird.
Woran Sie erkennen, dass eine Software modernisiert werden sollte, welche Möglichkeiten es zwischen Sanierung und Neubau gibt und mit welchen Kosten Sie rechnen müssen, erfahren Sie hier. Zwei Beispiele aus unserer Praxis zeigen außerdem, wie eine Modernisierung konkret aussehen kann. Unser Blick ist dabei bewusst pragmatisch: Es geht nicht um groß angelegte Konzerntransformationen, sondern um Anwendungen, die einzelne Abteilungen oder Prozesse im Alltag am Laufen halten.
Was ist Software-Modernisierung?
Software-Modernisierung ist der Oberbegriff für Maßnahmen, mit denen eine bestehende Anwendung technisch und fachlich auf einen aktuellen Stand gebracht wird. Das kann von der Aktualisierung einzelner Komponenten über die Migration auf eine neue Plattform bis hin zu einer vollständigen Neuentwicklung mit Übernahme der vorhandenen Daten reichen.
In der Praxis lassen sich drei Ebenen unterscheiden:
- die technische Modernisierung, etwa bei Programmiersprache, Frameworks oder Sicherheitsstandards,
- die architektonische Modernisierung, zum Beispiel der Wechsel von einer Desktop-Anwendung zu einer Webanwendung,
- und die fachliche Modernisierung, bei der auch bestehende Abläufe hinterfragt werden.
Diese Ebenen greifen häufig ineinander. Wer eine alte Anwendung neu aufsetzt, stellt fast automatisch die Frage: „Warum machen wir das eigentlich so?“ Deshalb ist Software-Modernisierung oft auch eine Chance, Prozesse zu vereinfachen.
Der Begriff Legacy-Software beschreibt dabei Anwendungen, die weiterhin gebraucht werden, technisch oder organisatorisch aber an ihre Grenzen stoßen. Das Alter allein ist nicht entscheidend. Auch eine vergleichsweise junge Anwendung kann zum Altsystem werden, wenn sie nicht mehr wartbar ist oder niemand mehr genau weiß, wie sie funktioniert.
Woran erkennen Sie, dass Ihre Software veraltet ist?
Die folgenden Anzeichen begegnen uns in Modernisierungsprojekten besonders häufig. Wenn mehrere Punkte auf Ihre Anwendung zutreffen, lohnt es sich, über eine Modernisierung nachzudenken:
- Es gibt nicht den einen großen Fehler, sondern viele kleine Probleme, an die sich das Team längst gewöhnt hat.
- Aktuelle Sicherheitsanforderungen werden nicht mehr erfüllt, etwa weil Berechtigungen, Protokollierung oder Nachvollziehbarkeit fehlen.
- Hersteller, Plattform oder Betriebssystem werden nicht mehr unterstützt.
- Die Anwendung läuft nur auf bestimmten Rechnern und muss lokal installiert werden.
- Das System ist seit vielen Jahren unverändert und der zugrunde liegende Code wurde lange nicht gepflegt.
- Es fehlen Schnittstellen, Daten müssen manuell exportiert und an anderer Stelle wieder importiert werden.
Praxisbeispiel: Wenn ein Mitarbeiter die Schnittstelle ist
Wie ungewöhnlich gewachsene Abläufe sein können, zeigte sich bei einem unserer Kundenprojekte. Das Projektteam berichtete von einer bestehenden Schnittstelle, die jede Nacht Daten von einer Website abrufen und in eine Fachdatenbank übertragen sollte. Diese Schnittstelle sollte bei der Modernisierung unbedingt erhalten bleiben.
Um die technische Umsetzung zu klären, nahmen wir Kontakt mit dem zuständigen Techniker auf. Auf unsere Frage, wie die Schnittstelle funktioniere, antwortete er nach einer kurzen Pause: „Ich bin die Schnittstelle.“
Tatsächlich gab es keine vollständig automatisierte Datenübertragung. Der Techniker rief die Quelldaten mithilfe von cURL ab, extrahierte die benötigten Informationen aus dem HTML und übertrug sie anschließend manuell in eine SQL-Datenbank.
s-team entwickelte daraufhin eine strukturierte, dateibasierte Schnittstelle über CSV und SFTP. Diese überträgt die benötigten Daten seit rund sechs Jahren automatisiert auf einen Kundenserver. Dort übernimmt ein kundenseitiges Skript den Import in die Datenbank.
Ein direkter Zugriff auf das Zielsystem war aus Sicherheitsgründen nicht möglich. Durch die Zusammenarbeit beider Seiten entstand dennoch eine zuverlässige Lösung, die den bisherigen manuellen Prozess ablöste.
- Wichtiges Wissen liegt nur bei einer einzelnen Person.
- Der ursprüngliche Hersteller oder Entwickler ist nicht mehr erreichbar.
- Fehler treten auf, ohne dass Ursache oder Auswirkungen nachvollzogen werden können.
- Neue Anforderungen lassen sich nur mit großem Aufwand oder gar nicht mehr umsetzen.
Kurz gesagt: Häufig fehlt auch ein zuverlässiger Ansprechpartner, der die Anwendung kennt und ihren stabilen Betrieb sowie die langfristige Weiterentwicklung sicherstellen kann.
Diese Anzeichen betreffen nicht nur klassische Access-Datenbanken. Auch alte Webportale, komplexe Excel-Dateien mit Makros, Branchenlösungen kleinerer Hersteller oder interne Eigenentwicklungen eines ehemaligen Kollegen können irgendwann zu einem Altsystem werden.
Modernisieren oder neu entwickeln?
Diese Entscheidung hat großen Einfluss auf Kosten, Risiko und Ergebnis. Bei sehr großen und komplexen Systemen kann eine schrittweise technische Sanierung sinnvoll sein. Bei überschaubaren Anwendungen einer Abteilung ist dagegen ein Neubau mit Datenübernahme häufig der sauberere Weg.
Eine Sanierung des bestehenden Systems ist eher sinnvoll, wenn:
- der Quellcode vollständig vorhanden und verständlich ist,
- die verwendete Technologie weiterhin unterstützt wird,
- das vorhandene Team das System gut kennt,
- die fachlichen Abläufe weitgehend gleich bleiben sollen.
Ein Neubau ist meist sinnvoller, wenn:
- der Quellcode fehlt oder kaum noch wartbar ist,
- die Plattform oder Technologie abgekündigt wurde,
- sich die Geschäftsprozesse deutlich verändert haben,
- alte Fehler und Umwege nicht übernommen werden sollen.
Unsere Erfahrung zeigt: Bei überschaubaren Altsystemen ist ein Neubau oft die bessere Wahl. Die Anforderungen sind grundsätzlich bekannt, weil die alte Anwendung sie bereits abbildet. Die bestehenden Daten können übernommen werden, während technische Altlasten und bekannte Fehler außen vor bleiben. Wichtig ist dabei die Reihenfolge: zuerst die Abläufe verstehen, dann die Daten analysieren und erst danach über die technische Umsetzung entscheiden. Wer direkt mit der Technik beginnt, läuft Gefahr, die alte Anwendung einfach mit neuen Werkzeugen nachzubauen.
Beispiel 1: Das AUVA-Arbeitsstoffverzeichnis
Das Arbeitsstoffverzeichnis der AUVA wird heute von rund 40.000 Unternehmen in Österreich genutzt, um gefährliche Arbeitsstoffe zu dokumentieren. Vor der Neuentwicklung durch s-team gab es eine Vorgängeranwendung, die viele typische Merkmale eines Altsystems aufwies.
Die technisch veraltete und zunehmend fehleranfällige Vorgängeranwendung arbeitete mit einem proprietären Dateiformat. Nutzer mussten ihre Arbeitsdateien bei jeder Bearbeitung hoch- und anschließend wieder herunterladen. Ging eine Datei verloren oder wurde der Download vergessen, konnten auch die gespeicherten Daten verloren gehen. Zusätzlich erschwerten technische Probleme, etwa Fehler im Browser-Cache, die Nutzung und Wartung.
s-team hat die bestehende Anwendung deshalb vollständig ersetzt. Die neue Lösung wurde als Webanwendung mit zentraler Datenhaltung, Berechtigungssystem, Protokollierung und modernem Interface aufgebaut. Bestehende Nutzerdaten wurden übernommen, indem ein eigener Import gebaut wurde, der die proprietäre Arbeitsdatei entschlüsseln und auslesen konnte. Dadurch hatten Benutzer:innen die Möglichkeit, ihre bisherige Arbeitsdatei im neuen System hochzuladen und mit ihren Daten weiterzuarbeiten. Dieser Prozess war pro Benutzer:in nur einmalig notwendig, da anschließend alle Daten sicher im Datenbank-Cluster von s-team gespeichert waren. Heute wird das Arbeitsstoffverzeichnis auf unserer Infrastruktur betrieben und laufend weiter betreut. Das Projekt zeigt gut, warum bei technisch überholten Anwendungen ein sauberer Neubau sinnvoller sein kann als eine fortlaufende Reparatur der alten Basis.
Beispiel 2: Die Praktikums-Verwaltungsdatenbank (PVD)
Nicht jedes Modernisierungsprojekt beginnt mit einer veralteten Anwendung. Manchmal besteht die Herausforderung darin, einen über Jahre gewachsenen, überwiegend manuellen Prozess durch eine zentrale Softwarelösung zu ersetzen. Im Gesundheitsbereich meldeten mehrere Universitäten, Fachhochschulen und Pflegeschulen ihre Praktikanten bei denselben Kliniken und Pflegeeinrichtungen in Niederösterreich für vorgeschriebene Praktika an. Die Abstimmung erfolgte über E-Mail, Excel-Tabellen und Telefon. Personen wurden mehrfach angelegt, Termine überschnitten sich und ein zentraler Überblick fehlte.
Die Praktikums-Verwaltungsdatenbank für den NÖGUS hat diese Abläufe zusammengeführt. Heute verwaltet sie Praktika für 27 Kliniken, 78 Pflegeeinrichtungen und rund 19.400 Auszubildende (Student:innen, Schüler:innen). Über Schnittstellen zu den Hochschulsystemen können Studierende direkt übernommen werden, statt sie mehrfach neu anzulegen. Die spätere Anbindung einer weiteren Fachhochschule war ein zusätzliches Projekt im Umfang von rund 5.000 Euro. Das Projekt zeigt, wie sich gewachsene Verwaltungsabläufe zentralisieren und anschließend schrittweise um zusätzliche Schnittstellen erweitern lassen.
Wie läuft eine Software-Modernisierung ab?
Ein Modernisierungsprojekt bei s-team folgt in der Regel sechs Schritten:
- Bestandsaufnahme – Wir sehen uns die bestehende Anwendung gemeinsam mit den Personen an, die täglich damit arbeiten. Dabei klären wir, was tatsächlich genutzt wird, welche Funktionen historisch gewachsen sind und wo die größten Probleme liegen.
- Datenanalyse – Wir prüfen, welche Daten vorhanden sind, wo sie liegen, in welcher Qualität sie vorliegen und welche Abhängigkeiten bestehen. Häufig zeigt sich erst dabei, dass mehrere Datenquellen miteinander verbunden werden müssen.
- Konzept und Angebot – In den meisten Fällen gibt es kein fertiges Lastenheft. Wir erstellen deshalb ein Konzept mit Funktionsumfang, Etappen und Preisrahmen. Kleine und mittlere Projekte bieten wir bevorzugt als Pauschale an.
- Neubau in Etappen – Die neue Anwendung entsteht schrittweise. Zuerst wird der wichtigste Kern umgesetzt, danach folgen Erweiterungen.
- Datenmigration und Parallelbetrieb – Bestehende Daten werden per Mapping in die neue Struktur übernommen. Falls das Altsystem währenddessen weiter genutzt wird, planen wir einen Parallelbetrieb ein.
- Go-live, Betrieb und Wartung – Nach der Umstellung übernehmen wir auf Wunsch Hosting, Betrieb und Applikationswartung auf unserer Server-Hardware in Wien. Mehr dazu finden Sie im Ratgeber Softwarewartung und Betrieb.
Besonders häufig unterschätzt wird die Datenmigration. Alte Felder müssen neuen Strukturen zugeordnet, Dubletten bereinigt und unterschiedliche Datenquellen zusammengeführt werden. Ein weiterer wichtiger Punkt ist der Datenschutz. Löschkonzepte, Rollen und Berechtigungen sowie die Frage, ob Datenschutzverantwortliche eingebunden werden müssen, sollten von Anfang an berücksichtigt werden. Wo die Daten später gespeichert werden und wer darauf zugreifen kann, erklären wir im Ratgeber Datenstandort Österreich.
Was kostet es, alte Software zu modernisieren?
Die Kosten hängen vom Umfang der bestehenden Anwendung, der Datenmigration, den benötigten Schnittstellen und den neuen Anforderungen ab. Für eine erste Orientierung unterscheiden wir drei typische Größenordnungen.
Kleine Projekte: 5.000 bis 10.000 Euro pauschalDazu gehören beispielsweise ein Zusatzmodul, eine einzelne Schnittstelle oder ein Werkzeug, das einen bestehenden Excel-Prozess ersetzt. Die Umsetzung dauert meist wenige Tage bis einige Wochen. Ein Beispiel ist die Anbindung einer zusätzlichen Fachhochschule an die Praktikumsdatenbank.
Mittlere Projekte: 50.000 bis 80.000 Euro Hierunter fällt typischerweise die Ablösung einer bestehenden Abteilungsanwendung durch eine Webanwendung mit eigener Datenbank, Berechtigungen, Datenmigration und ein bis zwei Schnittstellen. Beispiele sind Katasteranwendungen oder Dokumentationswerkzeuge wie der Lichtpunktkataster der Stadtgemeinde Klosterneuburg.
Große Projekte: ab etwa 400.000 EuroDabei handelt es sich um Systeme mit vielen Nutzergruppen, umfangreichen Schnittstellen und einer langen Entwicklungsgeschichte. Solche Projekte entstehen häufig über mehrere Jahre und sind selten der direkte Einstieg für Neukunden.
Die meisten Modernisierungsprojekte bei s-team beginnen klein oder mittel, oft mit einer Abteilung, einem Prozess oder einem konkreten Altsystem. Später kann die Anwendung über Wartung und Weiterentwicklung ausgebaut werden. Eine ausführliche Erklärung der Preisrahmen, Stundensätze und Kostentreiber finden Sie im Ratgeber Ablauf, Dauer und Kosten von Individualsoftware.
Für die von uns eingesetzten Open-Source-Komponenten fallen in der Regel keine laufenden Lizenzgebühren pro Nutzer oder Modul an. Sie bezahlen Entwicklung, Hosting, Betrieb und gegebenenfalls Weiterentwicklung.
Was ist mit KI und Cloud-Migration?
Software-Modernisierung wird heute häufig mit Begriffen wie KI-Transformation oder Cloud-Migration verbunden. Bei sehr großen Systemen mit Millionen Zeilen Code können automatisierte Analysewerkzeuge tatsächlich hilfreich sein. Bei einer überschaubaren Anwendung einer Abteilung ist jedoch meist etwas anderes entscheidend: Die bestehenden Abläufe müssen verstanden, die Daten sauber übernommen und die neue Lösung sinnvoll aufgebaut werden.
Bei s-team laufen modernisierte Anwendungen auf eigener Server-Hardware in einem Wiener Rechenzentrum. Dadurch profitieren Sie von einer zentral betriebenen Webanwendung und wissen gleichzeitig, wo Ihre Daten gespeichert werden. Künstliche Intelligenz setzen wir ausschließlich lokal und zur Unterstützung bei der Codeentwicklung ein, nicht für personenbezogene oder vertrauliche Kundendaten.
Welche Risiken hat eine Software-Modernisierung?
Das größte Risiko liegt oft im fehlenden Wissen über die fachliche Logik des bestehenden Systems. Manche Regeln sind nicht dokumentiert, bestimmte Funktionen werden nur selten genutzt oder wichtige Abläufe hängen von einzelnen Personen ab.
Weitere Risiken entstehen durch unvollständige Daten, unerwartete Abhängigkeiten zu anderen Systemen oder unzureichend getestete Schnittstellen. Deshalb sollten kritische Funktionen frühzeitig identifiziert, Datenübernahmen geprüft und die späteren Nutzer in die Tests einbezogen werden.
Entscheidend ist, dass die modernisierte Anwendung die bestehenden Aufgaben zuverlässig erfüllt und neue Anforderungen langfristig besser unterstützt.
Wann ist eine Modernisierung nicht sinnvoll?
Wenn ein Standardprodukt Ihre Anforderungen bereits gut erfüllt, ist eine individuelle Neuentwicklung meist nicht notwendig. Buchhaltung, klassische CRM-Funktionen oder viele Aufgaben der Warenwirtschaft sind typische Beispiele für Bereiche, in denen es bereits ausgereifte Lösungen gibt.
Individualsoftware wird dort interessant, wo wichtige Anforderungen von den Möglichkeiten bestehender Produkte abweichen oder das aktuelle System die tatsächlichen Abläufe nicht mehr sinnvoll unterstützt. Wie Sie diese Entscheidung treffen können, erklären wir im Vergleich Individualsoftware oder Standardsoftware.
Wie geht es weiter?
Wenn Sie mehrere Punkte aus der Checkliste wiedererkennen, ist der nächste Schritt eine gemeinsame Bestandsaufnahme. Sie zeigen uns die bestehende Anwendung und erläutern, wie sie heute genutzt wird. Wir prüfen die wichtigsten Abläufe, Daten und technischen Rahmenbedingungen und geben Ihnen eine erste Einschätzung, ob eher eine Sanierung oder ein Neubau sinnvoll ist und in welcher Größenordnung sich das Projekt bewegt. Ein fertiges Lastenheft brauchen Sie dafür nicht.
Mehr über unsere Arbeitsweise erfahren Sie auf der Seite Individuelle Softwareentwicklung. Wenn Sie lieber mit einem Unternehmen sprechen möchten, das bereits ein ähnliches Projekt umgesetzt hat, stellen wir auf Wunsch den Kontakt zu ausgewählten Referenzkunden her. Eine Übersicht finden Sie unter Referenzen, ein Erstgespräch können Sie über die Kontaktseite vereinbaren.
Erstgespräch · kostenlos und unverbindlich
Ist Ihre Software reif für die Ablöse?
Beschreiben Sie kurz, welche Anwendung Sie modernisieren möchten. Wir melden uns innerhalb eines Werktags mit einem Terminvorschlag.
- Terminvorschlag innerhalb eines Werktags
- Ehrliche Einschätzung, auch wenn Standardsoftware besser passt
- Entwicklung, Hosting und Betrieb aus einer Hand in Wien
Rufen Sie gerne auch unsere Kunden an, wir stellen den Kontakt her.
Danke, Ihre Anfrage ist bei uns.
Wir melden uns innerhalb eines Werktags mit einem Terminvorschlag. Wenn es eilt, rufen Sie uns an: +43 1 934 35 23.
Häufige Fragen
Was ist Legacy-Software?
Legacy-Software ist eine Anwendung, die weiterhin benötigt wird, technisch oder organisatorisch aber an ihre Grenzen stößt. Typische Merkmale sind nicht mehr unterstützte Plattformen, fehlende Schnittstellen, veraltete Sicherheitsfunktionen und Wissen, das nur noch bei einzelnen Personen vorhanden ist. Das Alter allein entscheidet nicht darüber, ob eine Anwendung als Legacy-System gilt.
Ist Access noch zeitgemäß?
Für kleine, klar begrenzte Anwendungen kann Microsoft Access weiterhin ausreichend sein. Sobald mehrere Personen gleichzeitig arbeiten, differenzierte Berechtigungen notwendig werden, Zugriffe nachvollziehbar sein müssen oder mehrere Standorte auf dieselben Daten zugreifen sollen, stößt eine klassische Access-Lösung jedoch schnell an ihre Grenzen. In solchen Fällen ist eine zentrale Webanwendung häufig die bessere Lösung. Bestehende Daten können dabei übernommen werden.
Kann man mit Excel eine Datenbank erstellen?
Excel ist in erster Linie eine Tabellenkalkulation und keine klassische Datenbank. Für einfache Datensammlungen kann es gut funktionieren, bei komplexeren Anwendungen fehlen jedoch Funktionen wie zentrale Berechtigungen, verlässlicher Mehrbenutzerbetrieb, strukturierte Datenprüfung und Schnittstellen. Viele Unternehmen arbeiten trotzdem jahrelang mit umfangreichen Excel-Konstruktionen, bis Fehler, Doppelerfassungen und manuelle Arbeitsschritte zum Problem werden. Bei großen Datenmengen und komplexen Berechnungen kann Excel außerdem deutlich langsamer werden. Wie stark sich das auswirkt, hängt unter anderem vom Aufbau der Datei, den verwendeten Funktionen und den verfügbaren Systemressourcen ab
Was kostet Software-Modernisierung?
Kleine Projekte wie ein Zusatzmodul oder eine Schnittstelle liegen bei etwa 5.000 bis 10.000 Euro pauschal. Die Ablösung einer Abteilungsanwendung ist meist ein mittleres Projekt, dessen Preis insbesondere vom Funktionsumfang, der Datenmigration und den erforderlichen Schnittstellen abhängt. Große, über Jahre gewachsene Systeme beginnen bei etwa 400.000 Euro.
Modernisieren oder neu entwickeln?
Ob eine bestehende Anwendung modernisiert oder neu entwickelt werden sollte, hängt vor allem vom technischen Zustand, der Wartbarkeit und den fachlichen Anforderungen ab. Bei überschaubaren Altsystemen ist ein Neubau mit Datenübernahme häufig sinnvoll. Bei größeren Systemen mit tragfähiger technischer Basis kann eine schrittweise Modernisierung wirtschaftlicher sein.
Wie lange dauert eine Modernisierung?
Kleine Projekte dauern meist wenige Tage bis Wochen. Die Ablösung einer Abteilungsanwendung mit Datenübernahme dauert häufig mehrere Monate. Entscheidend sind vor allem der Umfang, die Qualität der vorhandenen Daten und die Zahl der Schnittstellen. Durch eine Umsetzung in Etappen kann der wichtigste Teil der neuen Anwendung oft bereits genutzt werden, während weitere Funktionen noch ergänzt werden.
Was passiert mit meinen alten Daten?
Vor der Migration werden die bestehenden Daten analysiert und bei Bedarf bereinigt. Anschließend werden sie über ein definiertes Mapping in die neue Datenstruktur übernommen. Falls das Altsystem während der Entwicklung weiter genutzt wird, kann ein Parallelbetrieb notwendig sein, bevor die endgültige Datenübernahme erfolgt. Datenschutz, Löschkonzepte und Berechtigungen werden dabei von Anfang an berücksichtigt.
Quellen
- s-team IT solutions: Workshop-Ergebnisse Tag 2 vom 10.09.2026, Content-Update Spoke 5 (intern, Philip Tropper)
- AUVA: Arbeitsstoffverzeichnis, https://www.auva.at/ (Referenzprojekt, Freigabe laut Workshop)
- NÖGUS: Praktikums-Verwaltungsdatenbank (Referenzprojekt, Eckdaten aus dem Strategiedokument v1.0)
- Gartner Glossary: Legacy Application, https://www.gartner.com/en/information-technology/glossary/legacy-application-or-system
- Sistrix: Suchvolumen „software modernisierung“ Österreich, September 2026 (intern)