· Tarek El-Sibay · Insights · 6 min read
Migration ohne Big Bang: Wie wir einen Abrechnungsprozess Schritt für Schritt modernisiert haben
Alles auf einmal austauschen und auf das Beste hoffen? Big-Bang-Migrationen scheitern spektakulär – und regelmäßig. Anhand eines realen Projekts zeigen wir, wie eine schrittweise Migration funktioniert: jederzeit zurückrollbar, ohne Downtime und mit eingebautem Qualitätscheck nach jedem Schritt.
Einleitung
Im ersten Teil unserer Serie über Digitalisierung und digitale Souveränität haben wir gezeigt, warum verstreute Excel-Tabellen als Datenhaltung riskant sind und wie eine zentrale, souverän betriebene Lösung aussieht. Einer der fünf Schritte dorthin lautete: „Schrittweise Migration statt Big Bang.”
Dieser Satz klingt unspektakulär – ist aber einer der wichtigsten Erfolgsfaktoren überhaupt. In diesem Artikel zeigen wir an einem unserer ersten Projekte, was konkret dahintersteckt: den kompletten Neuaufbau eines Abrechnungsprozesses inklusive Rechnungserstellung, bei dem wir die Daten Stück für Stück migriert haben, ohne den laufenden Betrieb auch nur einen Tag zu unterbrechen.
Die Ausgangslage: Daten in zwei Welten
Das Projekt begann mit einer anspruchsvollen Aufgabe: Der komplette Abrechnungsprozess eines Unternehmens sollte neu gebaut werden – von der Datenaufbereitung bis zur fertigen Rechnung. Die Ausgangslage der Daten war dabei alles andere als ideal:
Stammdaten lagen nur lokal vor. Die Kundenstammdaten existierten ausschließlich auf lokalen Laufwerken beim Auftragnehmer. Es gab keine zentrale Datenbank, keinen Server, keinen Netzwerkzugriff – nur Dateien auf einzelnen Rechnern.
Transaktionsdaten lagen in Datenbanken. Die eigentlichen Bewegungsdaten, auf deren Grundlage abgerechnet werden sollte, steckten dagegen bereits in Datenbanken. Zwei Datenwelten, die für eine Rechnung zusammenkommen mussten – aber an völlig unterschiedlichen Orten lebten.
Unser Team arbeitete remote. Ein direkter Zugriff auf die lokalen Laufwerke vor Ort war nicht möglich. Bevor wir überhaupt eine Zeile Abrechnungslogik testen konnten, brauchten wir also erst einmal Zugriff auf die Stammdaten.
Der pragmatische Zwischenschritt
Die Lösung war bewusst unspektakulär: Die Stammdaten wurden nach Google Drive exportiert. Unsere Anwendung holte sich die Daten von dort, kombinierte sie mit den Transaktionsdaten aus den Datenbanken – und erzeugte daraus die ersten Rechnungen.
War das der ideale Endzustand? Ganz sicher nicht. Gerade wer Teil 1 dieser Serie gelesen hat, ahnt es: Eine US-Cloud als Datendrehscheibe entspricht nicht dem, was wir unter digitaler Souveränität verstehen. Aber dieser Zwischenschritt hatte einen entscheidenden Vorteil – er funktionierte sofort. Statt monatelang auf die perfekte Infrastruktur zu warten, lief der Abrechnungsprozess von Anfang an produktiv. Und genau das ist der Punkt: Eine Brücke muss nicht schön sein, sie muss tragen – solange, bis die echte Lösung steht. Wichtig ist nur, dass man sie von Anfang an als das behandelt, was sie ist: ein Übergang mit Verfallsdatum, kein Zuhause.
Die schrittweise Migration nach SQL
Von dieser Basis aus begann die eigentliche Arbeit: Nach und nach wanderten einzelne Datenfragmente in eine sauber strukturierte SQL-Datenbank. Nicht alles auf einmal, sondern Fragment für Fragment – jedes für sich fachlich abgegrenzt und einzeln umstellbar.
Möglich machte das eine einfache architektonische Entscheidung: Die Anwendung konnte beide Datenquellen parallel lesen. Für jedes Datenfragment galt zu jedem Zeitpunkt genau eine Quelle als führend – und diese Führung konnten wir pro Fragment umlegen, sobald die Migration dieses Fragments abgeschlossen und geprüft war. Aus dem anfänglichen Google-Drive-Export wurde so Schritt für Schritt eine zentrale, verlässliche Datenhaltung.
Dieses Vorgehen brachte drei Vorteile, die sich in der Praxis als Gold wert erwiesen:
Man konnte jederzeit zurückrollen. Jedes migrierte Fragment ließ sich im Fehlerfall sofort wieder auf die alte Datenquelle zurückschalten. Es gab keinen Punkt ohne Rückkehr – und damit auch keinen Moment, in dem alles auf einer einzigen Umstellung ruhte. Diese Absicherung verändert die Atmosphäre eines Projekts spürbar: Statt mit angehaltenem Atem auf den großen Tag zu warten, arbeitet das Team entspannt an überschaubaren Schritten.
Jeder Schritt war ein eingebauter Test. Nach jeder Migration konnten wir die Ausgaben vergleichen: Erzeugt die Rechnungsgenerierung mit den migrierten Daten exakt dieselben Ergebnisse wie vorher? Bei einem Abrechnungsprozess ist das die härteste Prüfung, die es gibt – eine Rechnung ist entweder korrekt oder sie ist es nicht. So wurde jeder Migrationsschritt automatisch zum Qualitätscheck des Gesamtsystems. Fehler zeigten sich sofort, solange ihre Ursache noch in einem einzigen, kleinen Fragment zu suchen war.
Keine Downtime. Weil jeder Schritt klein genug war, lief der Betrieb durchgehend weiter. Kein Migrationswochenende, kein Stillstand, keine nervösen Blicke auf den Kalender. Die Anwender merkten von der Umstellung im Hintergrund praktisch nichts – abgesehen davon, dass die Daten mit jedem Schritt verlässlicher wurden.
Der Kontrast: Wenn der Big Bang schiefgeht
Wie riskant das Gegenteil ist, zeigt ein Blick nach Großbritannien. Im April 2018 migrierte die TSB Bank ihre gesamte IT – die Konten von 5,2 Millionen Kunden – an einem einzigen Wochenende auf eine neue Plattform. Das Ergebnis: es dauerte 8 Monate bis der Betrieb wieder reibungslos und wie vorher lief. Die britischen Aufsichtsbehörden FCA und PRA verhängten später eine Strafe von 48,65 Millionen Pfund, hinzu kamen rund 32,7 Millionen Pfund Entschädigung für Kunden; die Gesamtkosten des Desasters werden auf mehrere hundert Millionen Pfund geschätzt. Der CEO trat zurück (FCA-Pressemitteilung, Analyse bei BizTech).
Die aufschlussreichste Erkenntnis der Untersuchungen: Es scheiterte nicht an mangelndem Budget oder fehlender Planung – drei Jahre Vorbereitung, Dutzende Spezialdienstleister, mehrere Prüfungen auf Vorstandsebene. Es scheiterte am Format selbst: Alles wechselte auf einen Schlag, ohne realistische Möglichkeit, zurückzurollen. Wenn bei einem Big Bang etwas schiefgeht, geht alles schief – gleichzeitig und vor Publikum.
Zugegeben, die wenigsten Unternehmen betreiben eine Bank. Aber das Muster gilt in jeder Größenordnung: Je mehr auf einen einzigen Umstellungsmoment gebündelt wird, desto größer der Schaden, wenn ein Detail nicht stimmt. Und es stimmt immer irgendein Detail nicht.
Voraussetzungen: Was schrittweise Migration braucht
So einfach das Prinzip klingt – es braucht ein paar Voraussetzungen, die man von Anfang an mitdenken sollte:
Fachlich sinnvolle Fragmente wählen. Die Schritte sollten entlang fachlicher Grenzen geschnitten sein, nicht entlang technischer Bequemlichkeit. Ein gutes Fragment ist für sich verständlich und einzeln prüfbar.
Parallelbetrieb einplanen. Die Anwendung muss alte und neue Datenquelle nebeneinander lesen können. Das ist etwas mehr Entwicklungsaufwand zu Beginn – und genau der Mechanismus, der Rollback und Vergleichstests überhaupt erst ermöglicht.
Vergleiche automatisieren. Der Abgleich der Ausgaben sollte kein manueller Sonderfall sein, sondern ein Knopfdruck. Was man nach jedem Schritt mühelos prüfen kann, prüft man auch wirklich.
Disziplin bei den Zwischenzuständen. Ehrlicherweise gehört auch dazu: Zwischenlösungen wie unser Google-Drive-Export müssen dokumentiert und terminiert werden. Sonst wird aus der Brücke doch noch ein Zuhause – und aus der Migration ein Dauerzustand.
Fazit und Ausblick
Der Big Bang verspricht einen schnellen, sauberen Schnitt – und bündelt dafür das gesamte Risiko in einem einzigen Moment. Die schrittweise Migration verteilt dasselbe Risiko auf viele kleine, prüfbare und umkehrbare Schritte. Man gibt die Illusion des großen Wurfs auf und bekommt dafür etwas Besseres: ein System, das während der gesamten Umstellung funktioniert, und die Gewissheit, dass jeder einzelne Schritt nachweislich korrekt war.
In unserem Projekt hieß das: Vom lokalen Laufwerk über einen pragmatischen Zwischenschritt hin zu einer zentralen SQL-Datenbank – ohne Downtime, ohne Big Bang, mit einer Rechnungsgenerierung, die nach jedem Schritt aufs Neue ihre Korrektheit bewiesen hat.
Wenn Sie vor einer ähnlichen Herausforderung stehen – verstreute Daten, ein Altsystem, das niemand mehr anfassen mag, oder eine Migration, die Sie lieber kontrolliert als spektakulär hinter sich bringen möchten –, sprechen Sie uns gerne an. Hier können Sie schnell und unkompliziert einen Termin buchen.
