Cloud-Modernisierung
Wir entscheiden mit euch, was umgebaut wird — und bauen es Welle für Welle um.
Beratung und Umsetzung für Teams, deren Systeme älter sind als die Anforderungen an sie: Architekturentscheidung, Migrationsplan und schrittweiser Umbau im laufenden Betrieb.
Ob Neubau oder Umbau, entscheiden wir an eurem Code und an eurem Betrieb — nicht an einer Referenzarchitektur. Und wir sagen es, wenn der günstigste Weg heißt, ein System so zu lassen, wie es ist.
ZUM PLATFORM ASSESSMENTWarum Modernisierung liegen bleibt
Modernisierung scheitert selten an der Technik. Sie scheitert an einer Entscheidung, die niemand treffen möchte: Was wird umgebaut, in welcher Reihenfolge, und was bleibt vorerst so, wie es ist.
Solange diese Entscheidung offen bleibt, wächst das Risiko auf beiden Seiten. Das bestehende System wird im Betrieb teurer, und der geplante Neubau wird größer, weil er inzwischen alles können soll.
Am Ende steht häufig ein Rewrite neben dem Tagesgeschäft — und ein Zustand, in dem zwei Systeme gepflegt werden, ohne dass eines davon abgeschaltet wird.
Woran ihr merkt, dass es so weit ist
Sechs Auslöser, mit denen Teams auf uns zukommen. Je mehr davon zutrifft, desto weniger hilft eine weitere Zielbild-Diskussion.
- Eine fachlich kleine Änderung zieht Tests und Abstimmungen durch das halbe System.
- Der Betrieb hängt an Laufzeiten oder Datenbankversionen, für die es keine Sicherheitsupdates mehr gibt.
- Die Infrastrukturkosten steigen, und niemand kann sie einer Anwendung oder einem Produkt zuordnen.
- Ein Rechenzentrumsvertrag, eine Lizenz oder eine Nachweispflicht setzt ein Datum, das nicht verhandelbar ist.
- Neue Anforderungen an Anbindung, Last oder Datenhaltung passen nicht mehr in die bestehende Struktur.
- An einen Teil des Systems geht niemand mehr heran, weil die Person, die ihn gebaut hat, das Unternehmen verlassen hat.
Rewrite oder schrittweiser Umbau
Wir beginnen nicht mit einer Zielarchitektur, sondern mit der Frage, welcher Weg das Geschäft am wenigsten unterbricht. Die Antwort lautet öfter Umbau als Neubau.
Schrittweiser Umbau — der Normalfall
Die bestehende Fachlogik bleibt in Betrieb, während einzelne Teile abgelöst werden. Der Umbau ist nach jeder Welle anhaltbar, und jede Welle liefert für sich einen Nutzen.
Rewrite — die Ausnahme
Ein Neubau lohnt sich, wenn die Fachlichkeit ohnehin neu geschrieben wird, das alte System nicht mehr erweiterbar ist und ein Abschalttermin feststeht. Fehlt eine dieser Bedingungen, wird der Rewrite teurer als der Umbau.
Nichts ändern — auch ein Ergebnis
Manche Systeme laufen stabil, ändern sich kaum und binden wenig Aufwand. Dann ist Modernisierung die falsche Investition, und genau das steht dann im Ergebnis.
Microservices sind ein Ergebnis, keine Vorgabe
Ein Schnitt in eigenständige Services lohnt sich, wenn mehrere Teams unabhängig voneinander ausliefern müssen. Betreut ein Team das System, ist ein sauber geschnittener Monolith die günstigere Antwort.
Welcher Weg der richtige ist, hängt am Zustand des Systems und an eurer Organisation. Wir legen die Optionen mit Aufwand, Risiko und Folgekosten nebeneinander und empfehlen eine — die Entscheidung bleibt bei euch.
Was wir übernehmen
Sieben Arbeitsschritte, die in einer Modernisierung zusammengehören. Welche davon nötig sind, hängt vom Ausgangspunkt ab; wir sagen vor dem Angebot, welche wir für verzichtbar halten.
Architekturentscheidung
Wir bewerten Schnitt, Abhängigkeiten und Datenmodell des bestehenden Systems und schreiben auf, welche Option welchen Aufwand und welches Risiko bedeutet — mit einer Empfehlung, nicht mit einer Liste.
Migrationsplanung
Welche Daten, Schnittstellen und Nutzergruppen wann umziehen, welcher Parallelbetrieb dafür nötig ist und wie der Rückweg aus jeder einzelnen Welle aussieht.
Lieferreihenfolge
Die Reihenfolge richtet sich nach Risiko und Nutzen: zuerst das, was den Betrieb entlastet oder eine Abschaltung ermöglicht — nicht das technisch Reizvollste.
Plattform-Anforderungen
Was die Zielumgebung können muss, damit der Umbau trägt: Laufzeit, Datenhaltung, Netzwerkgrenzen, Auslieferungsweg und Observability. Erst danach ist die Frage nach dem Anbieter beantwortbar.
Risikoreduktion vor dem ersten Umbau
Bevor etwas verschoben wird, entsteht ein Netz darunter: automatisierte Tests auf den fachlich kritischen Pfaden, reproduzierbare Umgebungen und ein Deployment, das sich zurückrollen lässt.
Betriebskontinuität
Der laufende Betrieb hat Vorrang. Umschaltungen laufen über Parallelbetrieb, Feature-Schalter und geplante Fenster, und jeder Schritt hat einen Rückweg, der vorher geprobt wurde.
Befähigung eures Teams
Wir arbeiten in euren Repositories und über eure Reviews. Am Ende kennt euer Team die neuen Teile, weil es sie mitgebaut hat — nicht, weil es eine Schulung dazu gab.
Was am Ende vorliegt
Was ihr behaltet, wenn die Zusammenarbeit endet — unabhängig davon, wie weit der Umbau zu diesem Zeitpunkt gekommen ist:
- Ein Architekturentscheid im Repository, mit den verworfenen Optionen und dem Grund für die Verwerfung.
- Ein Migrationsplan mit Wellen, Abhängigkeiten, Abnahmekriterien und Abbruchpunkten.
- Ein Risiko-Register: was beim Umbau schiefgehen kann, was das für den Betrieb bedeutet und was dagegen eingebaut wurde.
- Automatisierte Tests auf den fachlich kritischen Pfaden, lauffähig in eurer Pipeline.
- Runbooks für Umschaltung und Rückweg — geprobt, nicht nur geschrieben.
- Eine Liste dessen, was bewusst nicht modernisiert wurde, mit Begründung und einem Datum für die nächste Prüfung.
Diese Ergebnisse liegen bei euch im Repository und in eurem Wiki, nicht in einem Ordner bei uns. Sie sind auch dann noch brauchbar, wenn ihr den Umbau mit jemand anderem zu Ende bringt.
So läuft eine Zusammenarbeit
Vier Schritte, in dieser Reihenfolge. Nach dem ersten könnt ihr abbrechen und behaltet trotzdem eine Entscheidungsgrundlage, mit der ihr weiterarbeiten könnt.
Assessment
Fester Umfang, festes Ergebnis: Wir sehen uns Code, Betrieb und Auslieferung selbst an und legen die Optionen mit Aufwand und Risiko nebeneinander.
Entscheidung
Ihr entscheidet, welcher Weg gegangen wird. Wir sagen vorher, welchen wir für den falschen halten, und begründen es schriftlich.
Erste Welle
Der erste Schritt geht in Produktion, bevor der zweite geplant wird. Jede Änderung läuft über einen Pull Request, den jemand aus eurem Team liest.
Übergabe
Betriebsübernahme, Dokumentation und der Rest des Plans in einer Form, mit der euer Team ohne uns weiterarbeitet.
Zusammenarbeitsmodelle
Vier Wege in die Zusammenarbeit. Welcher passt, entscheidet sich im Assessment oder im Fit-Check; die Seiten dahinter nennen Umfang, Dauer und Preis im Detail.
Zuerst analysieren
Wenn noch offen ist, was der Umbau kosten und bringen würde: eine Analyse mit festem Umfang, die mit einer priorisierten Roadmap endet.
Zuerst der Weg in die Produktion
Wenn nicht die Anwendung der Engpass ist, sondern der Weg dorthin: Pipelines, Umgebungen und Betrieb zuerst, Umbau danach.
Zielumgebung aufbauen
Wenn feststeht, wohin modernisiert wird, die Zielumgebung aber noch nicht existiert — mit festem Start- und Endtermin.
Umbau über mehrere Wellen
Begleitung über mehrere Monate mit festen Tagen pro Woche, wenn der Umbau neben dem Tagesgeschäft läuft. Umfang und Laufzeit legen wir pro Fall fest.
Was ihr überprüfen könnt
Auf dieser Seite steht keine Zahl aus einem Kundenprojekt. Frühere Modernisierungen wurden nicht so gemessen, dass sie hier etwas belegen würden — und wir rechnen nichts hoch.
Hier stünde eine Kennzahl: Laufzeit einer Welle, Betriebskosten vor und nach dem Umbau, Fehlerrate im Parallelbetrieb. Es gibt keine belastbare. Sobald ein Kunde eine Messung freigibt, steht sie hier — vorher nicht.
Referenzen
Woran wir gearbeitet haben, beschrieben ohne Kennzahlen, weil wir keine erhoben haben.
Liefermodell
Wer die Arbeit macht, wer sie liest und bei wem die Lieferverantwortung bleibt.
Fachartikel
Wie wir über Modernisierung, Migration und Architekturentscheidungen denken — öffentlich und in voller Länge nachlesbar.
Passende Fallstudien
Fallstudien zu dieser Leistung, mit Kontext, Eingriff und Übergabe. Jede erscheint erst, wenn der Kunde die Veröffentlichung schriftlich freigegeben hat.
Zu dieser Leistung ist noch keine Fallstudie veröffentlicht. Die erste ist in Arbeit und wartet auf die Freigabe des Kunden.
Was nicht enthalten ist
Modernisierung endet nicht dort, wo das Angebot aufhört. Diese fünf Anfragen sagen wir ab — lieber vor der Entscheidung als mitten in der zweiten Welle.
Rund-um-die-Uhr-Betrieb, Rufbereitschaft und SLA-gebundene Betriebsverantwortung
Wir bauen Plattformen und übergeben sie betriebsfähig. Den Betrieb selbst übernehmen wir nicht — das kann ein Managed-Service-Provider zusagen, wir nicht.
Projekte ohne eigenes Entwicklungsteam
Wissenstransfer ist fester Bestandteil jeder Zusammenarbeit. Ohne Team, das übernimmt, wird daraus dauerhaftes Outsourcing — ein Modell, das wir nicht anbieten.
Transformationsprogramme mit vielen parallelen Workstreams
Ab etwa vier gleichzeitigen Strängen braucht es eine Delivery-Organisation. Wir arbeiten in kleiner Besetzung; alles andere hieße, fremde Köpfe dazuzukaufen.
Festpreis für eine Gesamttransformation, bevor jemand hineingesehen hat
Eine ungeprüfte Legacy-Landschaft zu bepreisen ist Raten. Wir schätzen nach einer kurzen Analyse — und sagen auch, wenn sich der Umbau nicht lohnt.
ERP-Modulberatung, Customizing und ABAP-Entwicklung
Cloud-native Engineering rund um eine bestehende ERP-Landschaft machen wir. Im Modul selbst arbeiten besser Leute, die den ganzen Tag nichts anderes tun.
Häufige Fragen zur Modernisierung
Müssen wir dafür auf Microservices umstellen?
Nein. Ein Schnitt in Services lohnt sich, wenn mehrere Teams unabhängig ausliefern müssen. Wo das nicht der Fall ist, empfehlen wir einen aufgeräumten Monolithen und schreiben auf, warum.
Kann der Umbau parallel zum Tagesgeschäft laufen?
Ja, und anders geht es in der Praxis selten. Deshalb ist jede Welle so geschnitten, dass sie für sich in Produktion gehen kann und einen geprobten Rückweg hat.
Was passiert, wenn wir mitten im Umbau abbrechen müssen?
Dann läuft das System weiter. Wir modernisieren so, dass nach jeder Welle ein betreibbarer Zustand steht — kein Zwischenstand, der erst mit dem nächsten Schritt funktioniert.
Wir wollen in die Cloud. Reicht ein Umzug der virtuellen Maschinen?
Wenn ein Rechenzentrumsvertrag ausläuft, kann ein Umzug der richtige erste Schritt sein. Als Ziel taugt er selten: Er verschiebt Kosten und ändert nichts daran, wie schwer sich das System ändern lässt.
Wer entscheidet über die Zielarchitektur?
Ihr. Wir liefern die Optionen mit Aufwand, Risiko und Folgekosten sowie eine begründete Empfehlung. Die Entscheidung und ihre Begründung werden dokumentiert und bleiben nachlesbar.
Braucht es dafür ein eigenes Entwicklungsteam?
Ja. Wer das System danach ändert, muss beim Umbau dabei gewesen sein — sonst entsteht ein zweites System, das niemand im Haus kennt. Ohne dieses Team wird daraus dauerhaftes Outsourcing.
Modernisiert ihr auch Systeme, die nicht in die Cloud gehen?
Ja. Ein Teil der Arbeit — Schnitt, Tests, Auslieferungsweg, Übergabe — ist unabhängig davon, wo das System läuft. Wo ein Rechenzentrum die bessere Wahl ist, sagen wir das vor dem Angebot.
Lohnt sich der Umbau?
Das Assessment beantwortet die Frage mit festem Umfang: Optionen, Aufwand, Risiko und eine Empfehlung, die ihr auch ablehnen könnt.