Softwaremodernisierung

Software modernisieren. Bewährte Prozesse erhalten.

Gewachsene Webanwendungen und Unternehmenssoftware erneuern, ohne die Abläufe zu verlieren, die heute funktionieren.

Ob Refactoring, schrittweise Ablösung oder Neuentwicklung wirtschaftlich trägt, klären wir gemeinsam. KI beschleunigt die Analyse – das Ergebnis verantwortet unser Team.

Kostenloses Erstgespräch, 15 Minuten – erst danach entscheiden Sie, ob ein Software-Audit sinnvoll ist.

Seit 2010 verantworten wir geschäftskritische Systeme für LANXESS · SMS group · Acon Digital

Funktionsumfang bleibt erhalten

Businesslogik und Sonderfälle werden strukturiert erfasst, nicht geraten

Rebuild nur wenn er sich lohnt

Erst Bestandsaufnahme, dann Empfehlung – auch gegen eine Neuentwicklung

Kein Big Bang

Schrittweise Ablösung, Parallelbetrieb und Rückfallverfahren statt Stichtagsumstellung

Ohne bei null anzufangen

Fachlich stark, technisch am Limit

Viele Individualsoftware-Systeme funktionieren fachlich noch hervorragend. Technisch sind sie über Jahre gewachsen: veraltete Frameworks, schwer wartbarer Code, fehlende Tests, alte Abhängigkeiten oder eine Architektur, die jede neue Anforderung teurer macht. Was in solchen Systemen zählt, ist selten der Code – sondern das Wissen, die Prozesse und die Funktionen, die darin stecken.

> 5 Mio. Artikel

Artikel im Katalogsystem verwaltet

SAP-integrierte E-Procurement-Plattform für LANXESS

seit 2014 produktiv

Abgelöstes System trägt bis heute

LANXESS Katalogsystem – ohne erneute Ablösung weiterentwickelt

seit 2010

Erfahrung im Umbau von Bestandssystemen

Ablösung und Umbau gewachsener Systeme im laufenden Betrieb

Einzelergebnisse aus konkreten Projekten, jeweils mit Projekt und Bezugsgröße benannt – keine Durchschnittswerte und keine Zusicherung für andere Vorhaben.

Wann lohnt sich Modernisierung – und für welche Systeme?

Meist ist es nicht ein einzelner Auslöser, sondern eine Häufung. Je mehr der folgenden Punkte zutreffen, desto wahrscheinlicher ist der Betrieb des Bestandssystems teurer als seine Erneuerung.

Die eingesetzte Technologie wird nicht mehr unterstützt oder erhält keine Sicherheitsupdates mehr.
Neue Funktionen werden von Release zu Release teurer, obwohl sie fachlich einfach sind.
Entwickler brauchen lange, um den bestehenden Code zu verstehen – oder trauen sich nicht, ihn zu ändern.
Es gibt kaum automatisierte Tests, jede Änderung muss manuell abgesichert werden.
Sicherheitsupdates lassen sich nicht mehr einspielen, ohne andere Teile zu gefährden.
Die Performance skaliert nicht mehr mit wachsenden Daten- oder Nutzerzahlen.
Das Wissen über das System steckt nur noch bei einzelnen Mitarbeitern oder ist bereits abgewandert.
Die Dokumentation bildet den tatsächlichen Stand der Anwendung nicht mehr ab.

Systemarten, die wir übernehmen

Individuelle Webanwendungen
B2B- und Kundenportale
E-Commerce-Systeme
E-Procurement-Plattformen
SaaS-Anwendungen
Interne Unternehmenssoftware
Systeme ohne aktuelle Dokumentation
Anwendungen mit gewachsenen Sonderlogiken

Ausgangstechnologien, mit denen wir arbeiten

Backend
PHP – auch ältere Symfony-, Laravel- und Zend-Stände sowie gewachsenes Legacy-PHP. Dazu Java / Spring, Node.js und Python.
Frontend
jQuery-basierte Oberflächen, ältere Angular-Versionen, serverseitig gerendertes Templating (Twig, Smarty, JSP).
Datenhaltung
MySQL / MariaDB, PostgreSQL, MS SQL, Oracle – auch gewachsene Schemata ohne Migrationshistorie.
Umsysteme
SAP, weitere ERP- und CRM-Systeme, PIM, Payment-Provider, SSO / Active Directory sowie SOAP- und REST-Altschnittstellen.

Nicht auf der Liste? Entscheidend ist weniger die Ausgangstechnologie als die Frage, ob Quellcode, Datenbank und Schnittstellen zugänglich sind. Unseren Ziel-Stack finden Sie unter Technologien.

Ehrliche Einschätzung zuerst

Rewrite, Refactoring oder Weiterentwicklung?

Nicht jede bestehende Anwendung muss neu gebaut werden. Ein kompletter Rebuild ist eine von mehreren Modernisierungsstrategien – und oft nicht die wirtschaftlichste. Deshalb steht am Anfang eine Bestandsaufnahme, keine Empfehlung.

Weiterentwickeln

Das System trägt noch. Wir bauen gezielt aus und halten die technische Basis stabil.

Beispiel: LANXESS seit 2014

Refactoren

Struktur und Codequalität verbessern, ohne das Verhalten der Anwendung zu verändern.

Unsere Engineering-Standards

Teilweise erneuern

Kritische Bereiche werden Stück für Stück ersetzt, der Rest bleibt zunächst bestehen.

Beispiel: Legacy-Migration

Komplett neu entwickeln

Rebuild auf moderner Basis, mit vollem Funktionsumfang – wenn Flicken teurer wird als Neubau.

Beispiel: Acon Digital
Das prüfen wir vorab, bevor wir einen Weg empfehlen
Architektur und verwendete Technologien
Codequalität und technische Schulden
Datenbank und Datenmodell
Schnittstellen und Fremdsysteme
Vorhandene Funktionen
Tatsächliche Nutzung im Alltag
Automatisierte Tests
Dokumentationsstand
Deployment und Infrastruktur

Die Entscheidung treffen wir gemeinsam mit Ihnen – auf Basis des Software-Audits, nicht auf Basis eines Verkaufsinteresses.

Referenzprojekt

B2B-E-Procurement bei LANXESS: starres Vorsystem abgelöst, seit 2014 produktiv

Der Spezialchemie-Konzern brauchte flexible Einkaufsprozesse, die sein bestehendes starres System nicht abbilden konnte. Wir haben es durch ein individuelles Katalogsystem ersetzt – und betreiben und entwickeln es seitdem weiter.

Ausgangslage

Ein starres Vorsystem ohne die nötige Flexibilität: über fünf Millionen Artikel zu verwalten, purchase-to-pay-Prozesse manuell, keine durchgängige Anbindung an die bestehende SAP-Landschaft.

Vorgehen

Ablösung durch ein individuelles Katalogsystem in iterativer Entwicklung – direkte SAP-Integration mit Kontrakten und Materialnummern, granulares Rechtemanagement, Produktkonfiguration über SmartForms.

Ergebnis

Seit 2014 im produktiven Betrieb, mit 24/7-Monitoring und regelmäßigen Updates kontinuierlich weiterentwickelt. Das System trägt die Einkaufsprozesse bis heute – ohne erneute Ablösung.

> 5 Mio.
Artikel im Katalog
2014
produktiv seit
12 Jahre
kontinuierlich weiterentwickelt
24/7
Monitoring & Support

Dieses Projekt zeigt, dass unsere Ablösungen tragen. Der KI-gestützte Analyse- und Rebuild-Ansatz auf dieser Seite ist neueren Datums – er verkürzt heute vor allem die Phase, in der ein Bestandssystem verstanden werden muss.

Der entscheidende Unterschied

KI verändert den Aufwand einer Modernisierung

Das größte Problem einer Neuentwicklung war jahrelang nicht das Programmieren, sondern das Verstehen: Niemand wusste mehr vollständig, was das alte System eigentlich alles macht. Das Wissen steckt im Quellcode, in Datenbankstrukturen und in den Köpfen einzelner Mitarbeiter – oft solcher, die das Unternehmen längst verlassen haben.

Genau dieser Teil ist heute mit AI-Engineering-Verfahren deutlich beherrschbarer. Der wirtschaftliche Hebel liegt dabei mindestens ebenso sehr im Verstehen bestehenden Codes wie im Generieren neuen Codes.

KI-gestützte Codeanalyse

Große, gewachsene Codebasen werden systematisch erschlossen statt über Monate manuell gelesen.

Reverse Engineering

Aus dem Bestandssystem wird rekonstruiert, was es fachlich tatsächlich leistet.

Ermittlung von Businesslogik

Berechnungen, Freigabewege, Preisregeln und Sonderfälle werden benannt und dokumentiert.

Abhängigkeitsanalyse

Zusammenhänge zwischen Modulen, Datenbankzugriffen und Fremdsystemen werden sichtbar.

Generierung von Tests

Testabdeckung entsteht dort, wo das Altsystem bisher nur manuell geprüft wurde.

Code-Migration & Dokumentation

Wiederkehrende Umbauschritte laufen automatisiert, der Funktionsstand wird schriftlich festgehalten.

KI schreibt Code. Unsere Entwickler verantworten das System.

Architektur, Security, Businesslogik, Reviews und Qualität bleiben menschliche Verantwortung – nachvollziehbar dokumentiert und durch Tests abgesichert. Nicht Prompt rein, Software raus: Jede Zeile, die in Ihr System geht, ist von einem Menschen geprüft und verantwortet.

Werkzeuge im Einsatz:Claude CodeCursorChatGPTAutomatisierte CodeanalyseAI AgentsTestautomatisierung

Unsere Leistung ist nicht ein bestimmtes Tool, sondern das Verfahren dahinter. Wie wir mit Ihrem Quellcode und vertraulichen Daten umgehen, steht in den häufigen Fragen.

Umfang der Übernahme

Wir übernehmen nicht den alten Code. Wir übernehmen seine Businesslogik.

Einen alten Screen kann jeder nachbauen. Der eigentliche Wert steckt in den Regeln dahinter – und die stehen selten in einer Dokumentation, sondern im Quellcode.

Businesslogik

Der eigentliche Kern der Übernahme

Freigaberegeln, Preisberechnungen, Rabattstaffeln, ERP- und SAP-Logik, Sonderfälle und die impliziten Regeln, die nur noch im bestehenden Code stehen. Das ist der Teil, an dem Rebuilds scheitern – und der Teil, den wir zuerst sichern.

Daten

Welche Bestände müssen übernommen, bereinigt oder migriert werden – und in welcher Struktur bilden sie Ihr Geschäft ab.

Schnittstellen

SAP, ERP, CRM, PIM, Payment, SSO und weitere Fremdsysteme, die weiterhin verlässlich bedient werden müssen.

Rollen & Berechtigungen

Welche Rollen, Zugriffsebenen und Freigabewege existieren – und welche davon heute noch gebraucht werden.

Funktionen & Prozesse

Was kann die Anwendung heute, und wie arbeiten Ihre Nutzer tatsächlich damit? Der reale Ablauf zählt, nicht das Handbuch – inklusive der Features, die niemand mehr auf dem Schirm hat.

Oberfläche & Bedienung

Was am bestehenden UI bewährt ist, bleibt vertraut. Was Nutzer seit Jahren ausbremst, verbessern wir gezielt.

Unser Vorgehen

Vom Altsystem zur neuen Anwendung

Vier Phasen, einzeln abnehmbar. Sie sehen nach jeder Phase, wo das Projekt steht – und können nach der Analyse jederzeit neu entscheiden. Für die Details je Phase aufklappen.

01Verstehenca. 2–4 Wochen

Bevor irgendetwas gebaut wird, wird der Bestand erfasst: Was macht das System, wovon hängt es ab, was wird tatsächlich genutzt.

  • Analyse von Quellcode, Anwendung, Datenmodell, Schnittstellen und vorhandener Dokumentation
  • Reverse Engineering: Funktionen und Businesslogik werden strukturiert erfasst und nachvollziehbar dokumentiert
  • Abgleich mit den real gelebten Abläufen Ihrer Mitarbeiter
02Entscheidenca. 1–2 Wochen

Aus der Bestandsaufnahme wird ein Zielbild – inklusive der Empfehlung, welcher Modernisierungsweg wirtschaftlich trägt.

  • Soll-System: Was bleibt unverändert, was wird verbessert, was ersatzlos entfernt
  • Architektur und ein langfristig wartbarer Technologiestack
  • Sequenzierung, Aufwandsrahmen und Risiken pro Schritt
03Umsetzenprojektabhängig

Entwicklung in abnehmbaren Inkrementen, jeweils gegen das Verhalten des Altsystems geprüft.

  • Rebuild oder Umbau durch unsere Entwickler, unterstützt durch KI-gestützte Werkzeuge
  • Funktionaler Vergleich: altes und neues System werden systematisch gegeneinander geprüft
  • Automatisierte Unit-, Integrations- und End-to-End-Tests sichern die Anwendung ab
04Umstellenca. 4–8 Wochen

Die Ablösung läuft schrittweise, nicht an einem Stichtag – mit definierten Rückfallverfahren pro Schritt.

  • Parallelbetrieb: Alt und Neu laufen gemeinsam, bis das neue System nachweislich trägt
  • Datenmigration in kontrollierten Iterationen mit Prüfung der Datenintegrität
  • Schrittweiser Go-live mit vorab definierter Rückfalloption je Umstellungsschritt
  • Übergabe: Dokumentation, Testsuite, Deployment-Pipeline und Einweisung Ihres Teams

Legacy-System ablösen – ohne unnötigen Big Bang

Die erste Frage eines Entscheiders lautet selten „Wie programmiert ihr das?", sondern: Läuft mein bestehendes System währenddessen weiter? Unsere Antwort: schrittweise nach dem Strangler-Pattern, mit klaren Schnittstellen, messbaren Inkrementen und definierten Rückfallverfahren.

Strangler-Pattern

Das neue System wächst um das alte herum und übernimmt Bereich für Bereich – statt es an einem Stichtag zu ersetzen.

Parallelbetrieb

Alt und Neu laufen gleichzeitig. Abweichungen fallen auf, bevor sie Ihre Nutzer betreffen.

Definierte Rückfallverfahren

Vor jedem Umstellungsschritt steht fest, wie zurückgesetzt wird und was das für bereits geänderte Daten bedeutet.

Messbare Inkremente

Jeder Schritt ist einzeln abnehmbar. Sie sehen den Fortschritt, statt auf ein Ergebnis zu warten.

Wo die Grenzen liegen: Ein Rückweg ins Altsystem ist nur so lange vollständig, wie im neuen System noch keine Daten verändert wurden. Ab dem Moment, in dem produktiv geschrieben wird, ist ein Rollback eine Datenfrage und keine Schalterfrage. Genau deshalb legen wir vor jedem Umstellungsschritt fest, bis wohin zurückgesetzt werden kann und was das für die Daten bedeutet.

Warum Legacy-Software modernisieren statt weitere fünf Jahre reparieren?

Der Aufwand steckt bei gewachsenen Systemen selten in der neuen Funktion, sondern im Drumherum: Jede Änderung muss um bestehende Altlasten herumgebaut und manuell abgesichert werden.

Weniger Entwicklungsaufwand

Neue Features müssen nicht mehr um bestehende technische Altlasten herumgebaut werden.

Moderne Technologien

Aktuelle Frameworks, saubere APIs, Container, Cloud-Infrastruktur und automatisierte Deployments.

Bessere Wartbarkeit

Verständliche Architektur, dokumentierter Code und automatisierte Tests statt Spezialwissen einzelner.

AI-ready

Eine saubere Architektur ist Voraussetzung dafür, später KI-Funktionen sinnvoll zu ergänzen.

Was bedeutet Softwaremodernisierung?

Softwaremodernisierung bezeichnet die technische und architektonische Erneuerung bestehender Anwendungen. Nicht die Funktionen ändern sich, sondern die Grundlage, auf der sie laufen: Technologiestack, Architektur, Datenmodell, Schnittstellen, Testbarkeit und Betrieb. International: Application Modernization beziehungsweise Legacy-Modernisierung.

„Legacy" meint dabei nicht nur zwanzig Jahre alte Mainframe-Anwendungen. Auch eine sechs Jahre alte PHP- oder JavaScript-Anwendung kann technische Schulden angesammelt haben, die jede Weiterentwicklung unverhältnismäßig teuer machen. Entscheidend ist nicht das Alter, sondern das Verhältnis von Aufwand zu Ergebnis.

Refactoring

Bestehende Codebasis verbessern: Struktur, Lesbarkeit und Testbarkeit erhöhen, ohne das Verhalten der Anwendung zu verändern.

Replatforming & Migration

Technische Plattform erneuern: neue Laufzeitumgebung, Datenbank, Cloud-Infrastruktur oder Framework-Version – Anwendungslogik bleibt weitgehend bestehen.

Rebuild

Anwendung funktional neu entwickeln: Funktionsumfang und Businesslogik werden übernommen, die Umsetzung entsteht auf moderner Architektur neu.

So starten Sie

Zwei Stufen – Sie entscheiden nach der ersten

Sie müssen sich nicht sofort für ein Audit entscheiden. Der Einstieg ist ein Gespräch, in dem wir klären, ob das Thema für Sie überhaupt trägt.

Stufe 1 · kostenlos

Erstgespräch

15 Minuten, telefonisch oder per Video

  • Sie schildern Ausgangslage, System und den konkreten Anlass
  • Wir sagen offen, ob das Thema zu uns passt – und wenn nicht, warum
  • Erste Einordnung, welcher Modernisierungsweg realistisch infrage kommt
  • Kein Angebot, keine Verpflichtung, keine Vorbereitung nötig
Erstgespräch vereinbaren
Stufe 2 · Festpreis

Software-Audit

Zwei Wochen, definierter Umfang

  • Bewertung von Architektur, Codequalität, Integrationen und Betrieb
  • Priorisierte Risiken und Quick Wins
  • Empfehlung zur passenden Modernisierungsstrategie, mit Begründung
  • Roadmap mit Sequenzierung und Aufwandsrahmen
Audit-Umfang und Preis ansehen

Häufige Fragen zur Softwaremodernisierung

Jens Bohl, Founder und CEO von Onveda

Ihr Ansprechpartner

Jens Bohl

Founder & CEO · 15+ Jahre Plattform-Architektur und Betrieb

Das Erstgespräch führe ich selbst – kein Vertrieb, sondern jemand, der Ihr System danach auch bewerten würde. Wenn Modernisierung in Ihrem Fall nicht der richtige Weg ist, sage ich das im Gespräch.

Ist Modernisierung, Refactoring oder Rebuild sinnvoll?

Starten Sie mit einem kostenlosen 15-Minuten-Gespräch zur Ausgangslage. Wenn es passt, folgt das Software-Audit: Architektur, Codequalität, Integrationen und Betrieb in zwei Wochen bewertet – mit klarer Empfehlung und Roadmap.

Karriere bei Onveda

Anfragen rund ums Arbeiten bei Onveda oder Arbeitsvermittlung

Zum Kontaktformular

Projekt-Anfragen

Plattform-, Integrations- und Run-Anfragen

Allgemeine Anfragen

Anfragen zu allgemeinen Themen

kontakt@onveda.de