Legacy-Modernisierung & Cloud-Migration
Ein Altsystem, das nur noch zwei Leute verstehen, Releases, die Wochen dauern, Server, die niemand mehr anfassen will: Das ist der typische Ausgangspunkt einer Legacy-Software-Modernisierung. Von Olching aus begleiten wir Unternehmen in München und im Umland dabei, solche Systeme schrittweise zu modernisieren und in die Cloud zu migrieren. Dafür entwickeln wir eine Zielarchitektur, die zu Ihrem Team passt. Statt einer Umstellung an einem Stichtag (Big Bang) laufen alt und neu parallel.
Kurz gesagt
Legacy-Software-Modernisierung bedeutet bei uns, ein gewachsenes, geschäftskritisches System Schritt für Schritt auf eine wartbare Architektur und in die Cloud zu bringen, während es weiterläuft. Wir erstellen Bestandsaufnahme und Migrationsplan, bauen automatisierte Pipelines, Container und per Code beschriebene Umgebungen (Infrastruktur als Code) auf und migrieren Komponente für Komponente mit Rückfallplan. Das Angebot richtet sich an mittelständische Unternehmen und IT-Leitungen, deren Software teuer im Betrieb, riskant bei Änderungen oder abhängig von wenigen Personen geworden ist.
Für wen
Aus der Praxis unseres Gründers: Bei einem Premium-Automobilhersteller hat er als Solution Architect und technischer Leiter den Shift-to-Cloud eines Legacy-Diagnosesystems verantwortet, hin zu einer microservice-basierten Plattform auf Google Cloud mit CI/CD in Azure DevOps, Docker, Kubernetes und Terraform, die über 15.000 Nutzer pro Monat bedient.
Die Kennzahlen stammen aus Projekten, die unser Gründer in verantwortlicher Rolle bei Herstellern und Zulieferern umgesetzt hat, nicht im Auftrag von Amperbytes AI.
Leistungen im Detail
Wir erfassen Komponenten, Datenbestände, Schnittstellen und versteckte Abhängigkeiten wie nächtliche Jobs, Dateiübergaben oder Netzlaufwerke. Für jeden Teil entscheiden wir mit Ihnen: migrieren, neu bauen, durch Standardsoftware ersetzen oder abschalten. Ergebnis ist ein Plan mit Reihenfolge, Risiken, Abnahmekriterien und den Kostentreibern, auf dessen Basis Sie entscheiden können.
Microservices dort, wo Teile unabhängig geliefert oder skaliert werden müssen, ein modularer Monolith dort, wo er reicht. Datenhaltung, Identitäten, Netzwerk, Sicherheit und Betrieb halten wir als dokumentiertes Zielbild fest. Architekturentscheidungen schreiben wir mit Begründung auf, damit Ihr Team sie später nachvollziehen und bei Bedarf revidieren kann.
Fehlt Dokumentation, lesen wir den Code. Coding-Assistenten helfen uns, unbekannte Codebasen schneller zu verstehen, die Ergebnisse prüfen wir am System. Bevor wir etwas ändern, halten wir das bestehende Verhalten mit Tests fest, sogenannten Charakterisierungstests. So bemerken wir, wenn eine Migration Ergebnisse verändert, die niemand spezifiziert, aber alle erwartet haben.
Funktionen wandern nacheinander auf die neue Plattform, das Altsystem läuft weiter. Anfragen leiten wir schrittweise um und vergleichen Ergebnisse und Kennzahlen zwischen alt und neu, bevor wir mehr Last umlegen. Jede Etappe hat einen Rückfallweg. Abgeschaltet wird ein Teil des Altsystems erst, wenn die vereinbarten Kriterien erfüllt sind, nicht an einem festen Stichtag.
Pipelines für Build, Tests und Deployment (CI/CD, Continuous Integration und Continuous Delivery), etwa in Azure DevOps. Anwendungen in Docker-Containern, betrieben mit Kubernetes. Umgebungen als Code beschrieben mit Terraform (Infrastruktur als Code), statt von Hand konfiguriert. Das ist keine Zugabe zur Migration, sondern ihre Voraussetzung: Nur reproduzierbare Umgebungen und automatisierte Deployments machen den Parallelbetrieb beherrschbar und Releases zur Routine.
Observability heißt, dass Sie den Zustand des Systems jederzeit sehen: Logs, Metriken und Alarme bauen wir von der ersten Etappe an mit, zum Beispiel mit Grafana und Kibana, damit Sie Probleme sehen, bevor Nutzer sie melden. Am Ende steht eine Übergabe mit Betriebshandbuch und gemeinsamen Einsätzen, damit Ihr Team die Plattform selbst betreiben kann. Auf Wunsch begleiten wir den Betrieb weiter.
Ratgeber
Ob ein System modernisiert werden muss, zeigt sich an seinem Betrieb, nicht an seinem Baujahr. Kritisch wird es, wenn mehrere dieser Signale zusammenkommen:
Trifft nur ein Punkt zu, reicht oft eine gezielte Maßnahme, zum Beispiel eine Pipeline für automatisierte Deployments. Treffen drei oder mehr zu, lohnt sich ein strukturierter Blick auf das Gesamtsystem, etwa mit einem Architektur-Review als erstem Schritt.
Entscheidend ist nicht, ob migriert wird, sondern womit Sie anfangen. Wir halten uns an drei Regeln:
Für jede Komponente gibt es mehrere Wege: unverändert umziehen, samt Plattform verlagern, auf die Zielplattform anpassen, umbauen, durch Standardsoftware ersetzen, stilllegen oder bewusst vorerst behalten. Für die schrittweise Ablösung eignet sich das Strangler-Fig-Muster: Neue Komponenten umwachsen das Altsystem Stück für Stück, bis es abgeschaltet werden kann. Wann welcher Weg passt, beschreibt unser Beitrag Software modernisieren oder neu entwickeln.
| Fallstrick | Woran Sie ihn erkennen | So gehen wir vor |
|---|---|---|
| Verteilter Monolith | Services lassen sich nur gemeinsam ausrollen, weil sie dieselbe Datenbank teilen | Im Zielbild legen wir fachliche Schnitte und Datenhoheit je Service fest, bevor die erste Komponente umzieht |
| Vergessene Abhängigkeiten | Nach der Umstellung fehlen Exporte, Druckaufträge oder Dateiübergaben | Bestandsaufnahme vor Ort mit einer Datenflussliste, die Sie abnehmen |
| Datenmigration als Schlussakt | Der Probelauf mit echten Daten findet erst kurz vor der Umstellung statt | Ab der Fundament-Phase läuft in jeder Etappe ein automatisierter Probelauf der Datenmigration mit |
| Endloser Parallelbetrieb | Das Altsystem bleibt stehen, obwohl die neue Plattform die Arbeit längst übernommen hat | Abschaltkriterien je Etappe stehen im Plan und sind Teil der Abnahme |
| Cloud ohne Kostenkontrolle | Die erste Monatsrechnung überrascht | Kostenmodell im Plan, Kostenzuordnung je Umgebung sowie Budgets und Alarme ab dem Fundament |
Weitere Risiken und allgemeine Gegenmaßnahmen stehen im Abschnitt „Risiken und wie Sie sie begrenzen“ unseres Beitrags Software modernisieren oder neu entwickeln.
Aus der Praxis unseres Gründers: Beim Shift-to-Cloud eines Legacy-Diagnosesystems war er als Solution Architect für die Zielarchitektur der microservice-basierten Plattform verantwortlich.
Eine perfekte Dokumentation brauchen Sie nicht. Hilfreich sind diese Punkte, auch als Stichworte:
Ist das Altsystem eher eine gewachsene Excel- oder Access-Lösung als eine klassische Anwendung, lohnt ein Blick in unseren Beitrag zum Ablösen von Excel und Access.
Qualität
Vorgehen
System, Daten, Schnittstellen, Betrieb und die Menschen verstehen, die es heute am Laufen halten.
2 bis 3 Wochen
Zielarchitektur, Migrationsreihenfolge, Abnahmekriterien, Kostenmodell und Risiken, als Entscheidungsgrundlage für Sie.
2 bis 4 Wochen
Pipelines, Container-Plattform, Infrastruktur als Code und Monitoring aufbauen, bevor die erste Funktion umzieht.
je nach Ausgangslage einige Wochen
Komponente für Komponente mit Parallelbetrieb, Ergebnisvergleich und Rückfallweg.
nach Umfang
Altsystem stilllegen, Daten archivieren, Betrieb übergeben oder weiter begleiten.
2 bis 4 Wochen
Vor Ort
Altsysteme im Mittelstand hängen selten nur an einem Server. Sie lesen Dateien von Netzlaufwerken, drucken Etiketten, sprechen mit Maschinen oder Waagen und tauschen Daten per nächtlichem Export mit dem ERP-System. Viele dieser Abhängigkeiten stehen in keiner Dokumentation, sondern sind nur vor Ort und im Gespräch mit den Kolleginnen und Kollegen zu finden, die das System seit Jahren betreuen. Deshalb führen wir die Bestandsaufnahme nach Absprache gern bei Ihnen durch, in München wie im Landkreis Fürstenfeldbruck, in dem unser Sitz in Olching liegt. Die weitere Umsetzung läuft dann überwiegend remote.
Software und KI im Landkreis FürstenfeldbruckIhr Nutzen
Technologien und Methoden
Praxisbeispiele
Die Kennzahlen stammen aus Projekten, die unser Gründer in verantwortlicher Rolle bei Herstellern und Zulieferern umgesetzt hat, nicht im Auftrag von Amperbytes AI.
Cloud · Automotive
Legacy-Diagnosesystem in eine Microservice-Plattform auf Google Cloud überführt, mit CI/CD, Containern und Terraform. Praxisbeispiel unseres Gründers.
MES · Hausgerätefertigung
Cloud-Plattform auf Google Cloud und Firebase für Produktionssteuerung und Firmware-Flashing in der Fertigungslinie. Praxisbeispiel unseres Gründers.
Wissen
Software · 8 Min. Lesezeit
Excel oder Access ablösen: Warnsignale, Optionen von Standardsoftware bis Individualsoftware und ein Umstieg mit Datenmodell, Rechten und Parallelbetrieb.
Software · 9 Min. Lesezeit
Software modernisieren oder neu entwickeln? Die 7R, Lift and Shift vs. Refactoring und das Strangler-Fig-Muster, mit Entscheidungstabelle.
Häufige Fragen
Legacy-Software ist ein gewachsenes System, das geschäftskritisch ist, sich aber nur noch mit hohem Aufwand oder Risiko ändern lässt, etwa wegen veralteter Technik, fehlender Tests oder fehlender Dokumentation. Modernisierung heißt, dieses System auf eine wartbare Architektur und eine zeitgemäße Betriebsplattform zu bringen, ohne die fachlichen Funktionen zu verlieren. Die Cloud ist dabei oft das Ziel, aber kein Selbstzweck.
Das hängt davon ab, wie gut die fachliche Logik im Altsystem ist, wie viel davon noch gebraucht wird und wie viel Wissen im Code steckt, das nirgendwo sonst dokumentiert ist. Eine Neuentwicklung auf der grünen Wiese unterschätzt diese versteckte Logik leicht. Die Optionen und Muster wie das schrittweise Ablösen haben wir in einem eigenen Beitrag ausführlich verglichen.
Software modernisieren oder neu entwickeln: die Optionen im Vergleich
Bestandsaufnahme sowie Zielbild und Plan dauern zusammen meist vier bis sieben Wochen. Danach folgt das technische Fundament. Die Dauer der eigentlichen Migration hängt von der Zahl der Komponenten und Schnittstellen ab und wird im Plan je Etappe festgelegt. Weil das Altsystem weiterläuft, liefert schon die erste Etappe Nutzen, nicht erst das Projektende.
Nein. Microservices lohnen sich, wenn Teams unabhängig liefern müssen oder Teile sehr unterschiedlich skalieren. Für viele mittelständische Systeme ist ein sauber geschnittener modularer Monolith in Containern der bessere Schritt, weil er weniger Betriebsaufwand erzeugt. Wir empfehlen, was zu Größe und Erfahrung Ihres Teams passt.
Nicht zwingend. Die Wahl hängt von Ihrer bestehenden IT-Landschaft, Ihren Datenschutz- und Standortanforderungen und dem Wissen Ihres Teams ab. Weil wir auf Container, Kubernetes und Terraform setzen, bleibt die Anwendung weitgehend portabel, auch in ein Rechenzentrum in Deutschland oder in Ihren eigenen Serverraum. Die Plattformpraxis unseres Gründers liegt auf Google Cloud, mit CI/CD in Azure DevOps. Beides können wir auch in Ihrem Projekt einsetzen, entschieden wird nach Ihren Anforderungen.
Die größten Kostentreiber sind die Zahl der Schnittstellen zu anderen Systemen, Umfang und Qualität der Altdaten, fehlende Tests und Dokumentation sowie die Anforderungen an Verfügbarkeit während der Umstellung. Auch die Frage, wie viel Ihr Team selbst übernimmt, verändert den Aufwand deutlich. Eine belastbare Schätzung geben wir nach der Bestandsaufnahme, nicht vorher.
Das kommt bei Legacy-Systemen häufig vor. Wir erschließen den Code systematisch, auch mit Coding-Assistenten, und sichern das bestehende Verhalten mit Tests ab, bevor wir etwas ändern. Die verbliebenen Fachanwender sind dabei oft die wichtigste Quelle, weil sie wissen, was das System tatsächlich leisten muss.
Ja. Ein Architektur-Review klärt in kurzer Zeit, wie es um Struktur, Risiken und technische Schulden Ihres Systems steht und welche Optionen realistisch sind. Das Ergebnis können Sie für eine Migration mit uns, mit Ihrem Team oder mit einem anderen Dienstleister nutzen.
Direkter Kontakt
Sie sprechen direkt mit unserem Gründer
Gründer und Solution Architect: iSAQB CPSA · Certified ScrumMaster · M.Sc. Wirtschaftsingenieurwesen. Olching bei München, Termine vor Ort nach Absprache.
Passende Leistungen
Eine Bewertung Ihrer Software von außen, zeitlich begrenzt: Qualitätsziele, Risiken mit Prioritäten, Zielbild und die nächsten Schritte, bevor Sie investieren.
Interne Tools, Web-Anwendungen und Schnittstellen zu ERP und MES, die Ihren Ablauf abbilden. Dokumentiert, getestet und übergabefähig.
Externer Solution Architect oder Interim Product Owner für Ihr Softwarevorhaben: Zielarchitektur, Roadmap, Backlog und fachliche Führung des Teams, auf Zeit und mit geplanter Übergabe.
Beschreiben Sie uns kurz, was es tut und woran es hakt. Wir sagen Ihnen, wie ein Weg zur Modernisierung ohne Stillstand aussehen kann und womit Sie anfangen sollten.