Dein Altsystem verarbeitet noch heute Bestellungen, Zahlungen oder Kundendaten, wird aber mit jedem Jahr unzuverlässiger und teurer in der Wartung, während die Dokumentation weiter veraltet. Es lässt sich trotzdem nicht einfach abschalten: Der Betrieb läuft weiter, während du migrierst.

Wir migrieren in überschaubaren, überprüfbaren Schritten, mit laufendem Betrieb als fester Randbedingung von Anfang an. Ein kompletter Neubau von Grund auf klingt zwar sauber, dauert aber oft so lange, dass die Produkt-Roadmap währenddessen stillsteht - und auch Liegenlassen kostet, jeden Monat mehr, in Wartungsstunden, in Risiko, in entgangenen Möglichkeiten.

Drei Situationen kommen uns dabei am häufigsten unter. Die erste: ein System, zu dem im Unternehmen kaum noch Wissen existiert, weil die Menschen, die es gebaut haben, längst nicht mehr da sind. Die zweite: mehrere Plattformen nebeneinander, weil jede Marke oder jeder Standort über die Jahre ihre eigene Lösung bekommen hat, mit doppeltem Entwicklungsaufwand als Folge. Die dritte: ein System, das zusätzlich strenge regulatorische Vorgaben erfüllen muss, sodass jede Änderung eine zweite, formale Prüfung durchläuft. Die Arbeit beginnt in allen drei Fällen mit einem genauen Blick auf das, was tatsächlich da ist, noch vor der ersten Zeile Code.

Sechs Bausteine für deine Migration

• Discovery als Lieferobjekt: Wir kartieren die bestehenden Datenflüsse und rekonstruieren undokumentierte Teile deines Systems, bevor überhaupt migriert wird. Dazu gehören Schnittstellen und Datenbankschemata ebenso wie die Business-Logik, die oft nur noch im Kopf einzelner Mitarbeiter existiert. Das Ergebnis ist ein eigenständiges Lieferobjekt: ein Systeminventar, das für sich allein schon Wert hat, selbst wenn die Migration danach pausiert oder auf einen späteren Zeitpunkt verschoben wird.
• Plattformauswahl und Anbieterbewertung: Wir bewerten mögliche Zielplattformen und Anbieter nach einer festen, anbieterneutralen Methodik, unabhängig von einzelnen Herstellerinteressen. Kriterien wie Integrationsaufwand, Lizenzkosten über mehrere Jahre, die Größe des verfügbaren Entwicklerpools und die Reife der Community fließen dabei ebenso ein wie die technische Passgenauigkeit zu deinem Anwendungsfall. Eine begründete Empfehlung samt der Argumente dahinter steht am Ende, damit die Entscheidung auch intern trägt.
• Strangler-Fig-Migration: Neue Dienste entstehen parallel zum bestehenden System. Sie übernehmen Stück für Stück dessen Aufgaben, bis das Altsystem schrittweise verschwindet. Beide Systeme laufen über denselben Zeitraum hinweg nebeneinander, Anfragen wandern schrittweise vom alten zum neuen Dienst. Der endgültige Umschalter fällt erst, wenn sich der neue Dienst unter echter Last bewährt hat.
• Service-Extraktion aus Monolithen: Wir lösen einzelne Dienste aus dem Monolithen heraus und beginnen dabei mit den Modulen, die die größten Probleme verursachen, sei es durch häufige Ausfälle, hohen Wartungsaufwand oder Kopplungen, die jede Änderung riskant machen. Jeder extrahierte Dienst bekommt eine eigene Schnittstelle und lässt sich unabhängig vom Rest weiterentwickeln, testen und ausrollen.
• Datenabgleich und Zustandsmigration: Wir decken Qualitätsprobleme in den Altdaten auf und beheben sie, bevor Zustände vollständig in das neue System wandern. Über Jahre sammeln sich doppelte Datensätze und veraltete Formate an, dazu stille Inkonsistenzen - oft unbemerkt, weil das alte System sie klaglos verarbeitet hat. Nur geprüfte und bereinigte Daten wandern in die neue Umgebung, damit sich alte Fehler dort nicht wiederholen.
• Compliance-orientierte Neuarchitektur: Regulatorische Vorgaben fließen von Anfang an in die Architektur ein. Das gilt besonders für Branchen mit strenger Aufsicht, etwa im Finanzwesen, wo neben Prüfpfaden und Datenresidenz auch Zugriffskontrollen von der ersten Designentscheidung an mitgedacht werden müssen. Die Architektur selbst verhindert so schon die Probleme, die eine nachträgliche Anpassung sonst verursachen würde, und Prüfungen durch Aufsichtsbehörden laufen ruhiger ab.

Sechs Projekte aus der Praxis

• Einzelhandelsgenossenschaft (Europa): Medienplattform trotz fehlender Dokumentation per Reverse Engineering vollständig erschlossen.
• Multi-Marken-E-Commerce-Unternehmen: Migration von OXID zu Shopware, doppelte Entwicklungsarbeit um 70 Prozent reduziert.
• Kreditplattform (Schweiz): Neuarchitektur vollständig an die FINMA-Vorgaben angepasst, Zeitrahmen von acht Wochen eingehalten.
• roadsurfer: Live nach 20 Tagen, Buchungen und Umsatz im ersten Jahr verdoppelt, Flotte um 40 Prozent gewachsen, seit 2019 fortlaufende Zusammenarbeit.
• Senior Aerospace Thailand (SAT): Frühere Anbieter blieben erfolglos, wir steigerten die operative Effizienz um 400 Prozent und führten die Lösung in wenigen Wochen ein.
• SaaS-Anbieter für Kundencommunitys (München): Infrastrukturkosten um 75 bis 80 Prozent gesenkt, Deployment-Zeit auf teils sechs Stunden gedrückt (vorher: zwei Wochen).

Zwei Wochen Analyse, dann Phasen

Diese zwei Wochen sind bewusst knapp bemessen, damit die Analyse nicht selbst zum Projekt wird. Ein vollständiges Systeminventar und eine Risikobewertung sind das Ergebnis, die gemeinsame Grundlage für Technik und Zeitplan, Budget eingeschlossen. Die eigentliche Migration läuft danach in klar abgegrenzten Phasen, jede mit einem eigenen Go/No-Go-Kriterium, an dem sich zeigt, ob der nächste Schritt beginnt. Wir legen diese Kriterien gemeinsam mit dir fest, bevor die erste Phase startet, damit am Ende jeder im Team weiß, woran Erfolg gemessen wird und wer die Entscheidung trifft. Regelmäßige, kurze Abstimmungen ersetzen dabei lange Statusberichte: Alle Beteiligten sehen denselben aktuellen Stand, technische wie fachliche. Eine kurze schriftliche Übergabe schließt außerdem jede Phase ab: Sie hält fest, was geändert wurde und warum - und beschreibt, wie sich der Schritt im Notfall zurückrollen lässt. Diese Dokumentation wandert direkt in eine gemeinsame, für alle zugängliche Wissensbasis. Der Plan bleibt dabei veränderbar: Wir passen ihn an, wenn sich unterwegs ein besserer Weg zeigt, etwa weil eine Abhängigkeit komplizierter ist als angenommen oder sich ein Geschäftsprozess während der Migration selbst ändert. Genau dafür sind die Phasengrenzen da: Sie geben Raum für eine bewusste Korrektur und verhindern, dass eine einmal getroffene Entscheidung stur weiterverfolgt wird.

Drei Wege, loszulegen

Der Discovery Workshop dauert drei bis zehn Tage. Darin prüfen wir dein Altsystem und seine Abhängigkeiten - und schätzen die Risiken einer Migration ein. Du bekommst danach ein Systeminventar und eine Roadmap, dazu eine Kostenschätzung, bevor irgendetwas verpflichtend wird. Der Umfang richtet sich nach der Größe und Komplexität des Systems: Ein einzelner Service braucht weniger Zeit als eine Systemlandschaft mit Dutzenden Abhängigkeiten und mehreren Teams, die jeweils ihr eigenes Stück davon kennen. Das ist oft der naheliegendste erste Schritt für Teams, die schon einmal einen Modernisierungsversuch verloren haben.

Das Neuausrichtungsprojekt läuft ab drei Monaten, im Schnitt etwa ein halbes Jahr, abhängig davon, wie viele der sechs Bausteine zum Einsatz kommen und wie groß das System ist. Ein Entwicklungsteam bleibt über die gesamte Projektlaufzeit eingebunden und liefert laufend funktionsfähige Zwischenergebnisse - sichtbaren Fortschritt in jeder einzelnen Woche. Du siehst dadurch in jeder Phase, was fertig ist und was als Nächstes kommt, inklusive der Stellen, an denen sich der Plan seit dem letzten Update verändert hat.

Beratung auf Abruf gibt es für Migrationen, die du selbst führst. Wir stehen bereit, wenn dein eigenes Team an einer bestimmten Stelle feststeckt, etwa bei einer einzelnen technischen Entscheidung, einem Architektur-Review oder einer zweiten Meinung vor einem wichtigen Go/No-Go. Der Umfang orientiert sich am tatsächlichen Bedarf: mal eine einzelne Sitzung, mal eine begleitende Rolle über mehrere Wochen einer kritischen Phase hinweg.

Anhand deines Ausgangspunkts entscheidest du, welches Format passt. Wer noch nicht weiß, wie hoch Aufwand und Risiko wirklich sind, startet am besten mit dem Discovery Workshop. Das Neuausrichtungsprojekt passt besser, wenn die Richtung schon feststeht und es Umsetzungskraft über Monate hinweg braucht. Für Teams, die ihre Migration ohnehin selbst führen, reicht oft schon punktuelle Beratung an den Stellen, an denen internes Wissen an seine Grenzen stößt.