Wenn ein Softwareprojekt kippt, liegt es selten an der Oberfläche und fast nie am Framework. Es liegt an den Daten. Im Projektplan steht die Migration als schmaler Balken kurz vor dem Start — in der Praxis ist sie das Arbeitspaket mit den meisten Unbekannten, weil vorher niemand genau weiß, was zwanzig Jahre Systemnutzung in den Tabellen hinterlassen haben. Dieser Beitrag beschreibt, was bei der Übernahme von Altdaten tatsächlich passiert und welche Entscheidungen Sie als Auftraggeber selbst treffen müssen.
Warum die Migration regelmäßig unterschätzt wird
Der Denkfehler steckt im Wort: Migration klingt nach Transport, nach A wird zu B. Tatsächlich ist es eine Übersetzung zwischen zwei Weltbildern — das alte System bildet die Prozesse von vor zwanzig Jahren ab, das neue soll die von morgen tragen. Zwischen beiden Modellen gibt es keine automatische Entsprechung, sondern hunderte fachliche Entscheidungen.
Dazu kommt eine Aufwandsverteilung, die jede Schätzung sprengt: Der Regelfall läuft schnell, die Ausnahmen kosten die Zeit. Die Mehrheit der Datensätze geht in einem Durchlauf durch; der kleine Rest aus Altfällen, Sonderkonstruktionen und halb erfassten Vorgängen verschlingt den Großteil des Budgets — und wer pauschal schätzt, bevor jemand die Bestandsdaten angesehen hat, schätzt genau diesen Rest nicht mit. Deshalb gehört die Datenanalyse als eigenes, früh terminiertes Arbeitspaket in den Plan — vor jeden Festpreis für die Migration. Wie wir Projekte in Phasen schneiden, zeigt unsere Prozessseite.
Ehrlich gesagt braucht nicht jeder Bestand eine Migrationsstrecke. Bei wenigen hundert Sätzen in einem einzigen Objekt ist die geordnete Nacherfassung durch die Fachabteilung oft schneller, günstiger und im Ergebnis sauberer als jede Automatik. Dann sollten Sie dieses Arbeitspaket gar nicht beauftragen.
Was im Altsystem tatsächlich steckt
Jeder gewachsene Datenbestand zeigt dieselben Muster. Kein Vorwurf, sondern normale Folge davon, dass Systeme länger leben als die Konventionen, mit denen sie gefüllt wurden:
- Dubletten — derselbe Kunde dreimal, minimal anders geschrieben, mit Historie an allen drei Sätzen.
- Freitext als Ersatzdatenmodell — im Bemerkungsfeld stehen Kondition, Zuständigkeit und Sonderabsprache, jeder Bearbeiter in eigener Schreibweise.
- Fehlende Pflichtangaben — das Feld wurde erst später verpflichtend, alles davor ist leer.
- Umgedeutete Spalten — ein altes Feld wird seit Jahren für einen anderen Zweck genutzt; die Bedeutung hängt am Erfassungsdatum.
- Karteileichen in Auswahllisten — Statuswerte, die niemand mehr erklären kann, aber noch an aktiven Vorgängen hängen.
- Schäden aus früheren Umzügen — Platzhalterdaten, kaputte Umlaute, abgeschnittene Felder.
Entscheidend ist, diese Befunde zu zählen statt zu bewerten: Wie viele Sätze sind betroffen, welche Prozesse hängen daran, was passiert im neuen System, wenn der Wert fehlt? Ein Analysebericht mit Mengen ist die Grundlage jeder weiteren Entscheidung.
Mapping-Workshops: mit dem Fachbereich, nicht mit der Feldliste
Ein Mapping ist keine technische Übung, auch wenn es wie eine Tabelle aussieht. Jede Zuordnung ist eine fachliche Aussage über die Bedeutung eines Werts. Bewährt hat sich ein Termin pro Datenobjekt — Kunde, Auftrag, Artikel, Patient — mit den Menschen, die diese Daten täglich anfassen. Nicht nur mit der Abteilungsleitung: Die Sonderregeln kennen die Sachbearbeiter.
Dokumentiert wird je Feld: Quelle, Ziel, Umwandlungsregel, verantwortliche Person, offene Fragen. Der wichtigste Teil betrifft Daten, die im neuen Modell keinen Platz haben. Dafür gibt es fünf mögliche Antworten:
| Entscheidung | Sinnvoll, wenn … | Der Preis dafür |
|---|---|---|
| Unverändert übernehmen | im Tagesgeschäft aktiv gebraucht | Altlasten wandern mit |
| Umwandeln, strukturieren | Inhalt wichtig, Form untauglich | Regelaufwand plus Nacharbeit |
| Verdichtet übernehmen | nur Summen oder Endzustände nötig | Einzelbelege fehlen künftig |
| Archivieren | Aufbewahrung ja, Zugriff nein | Archiv muss lesbar bleiben |
| Nicht übernehmen | kein fachlicher, kein rechtlicher Bedarf | braucht schriftliche Freigabe |
Diese Tabelle ist der Kern des Migrationskonzepts. Wer sie ausfüllt, hat die Migration im Griff; wer sie umgeht, verschiebt die Diskussion in die Woche des Umstiegs.
Testläufe, Zählproben, Abgleichsberichte
Eine Migration wird nicht einmal ausgeführt, sondern geübt. Planen Sie mehrere vollständige Probeläufe auf einer Kopie der echten Bestandsdaten ein, nicht auf künstlichen Testdaten — die haben genau die Eigenschaften nicht, um die es geht.
Der Nachweis erfolgt über Zählproben, nicht über Gefühl. Maschinell verglichen und vorab festgelegt werden: die Anzahl der Sätze je Objekt, Summen über alle betragsführenden Felder, die Verteilung auf Statuswerte, die Anzahl der Verknüpfungen zwischen Objekten. Das Ergebnis ist ein Abgleichsbericht, der Zeile für Zeile sagt: erwartet, angekommen, Differenz, Ursache. Eine erklärte Differenz ist in Ordnung, eine unerklärte ist ein Abbruchgrund.
Die fachliche Sichtprüfung kommt gezielt dazu: Jeder Fachbereich benennt vorab seine schwierigsten Fälle — den Kunden mit der Sonderkondition, den Vorgang mit drei Reklamationen, den ältesten offenen Auftrag. Sie werden nach jedem Lauf einzeln nachgesehen; Zufallsstichproben beweisen nichts. Die Freigabe der Migration gehört zudem als eigenes Abnahmekriterium in den Vertrag, nicht in die allgemeine Abnahme der Software.
Cut-over: Stichtag, Einfrierfenster, Rückfallebene
Der Umstieg ist kein Datum, sondern ein Ablaufplan im Stundenraster mit einem Namen hinter jedem Schritt. Drei Bausteine entscheiden, ob er beherrschbar bleibt.
Das Einfrierfenster. Ab einem festgelegten Zeitpunkt wird im Altsystem nicht mehr geschrieben, sonst migrieren Sie einen bewegten Bestand. Für dieses Fenster brauchen die Fachbereiche ein Ersatzverfahren und — wichtiger — eine verabredete Regel, wie die in dieser Zeit entstandenen Vorgänge danach nachgetragen werden. Genau hier entstehen die Datenlücken, die man Monate später sucht.
Die Rückfallebene. Definieren Sie vorab einen Abbruchpunkt mit Uhrzeit und Kriterium: Stimmen die Abgleichszahlen bis Sonntagabend nicht, wird zurückgerollt. Dazu gehört ein geprüftes Backup und die Zusicherung, dass das Altsystem sofort wieder produktiv laufen kann, einschließlich Lizenzen und Schnittstellen. Ohne diesen Teil ist es kein Plan, sondern eine Hoffnung.
Die Delta-Migration. Zieht sich die Umstellung über Wochen, wird der Grundbestand vorab übertragen und danach nur die Veränderung. Das setzt verlässliche Änderungszeitstempel im Altsystem voraus. Fehlen sie, gibt es kein Delta, sondern nur den vollen Neuabgleich — prüfen Sie das früh, denn es bestimmt die Strategie. Ein echter Parallelbetrieb ist die teuerste Variante: doppelte Erfassung, zwei Wahrheiten, und die Frage, welche gilt.
Archivieren statt mitnehmen — und Fristen mitdenken
„Wir nehmen erst mal alles mit“ klingt nach Sicherheit und ist meistens die teuerste und schlechteste Entscheidung. Teurer im Projekt, weil jede Altlast eine Regel braucht. Teurer im Betrieb, weil das neue System Datenmüll mitschleppt. Schlechter im Ergebnis, weil die Qualität von der schwächsten übernommenen Charge bestimmt wird: Suchtreffer voller Karteileichen und Auswertungen, denen niemand traut.
Die tragfähige Alternative ist ein bewusst gesetzter Datenhorizont für den Produktivbestand — offene Vorgänge plus begrenzte Historie — und ein Archiv für alles Ältere: als lesbarer Export, Auswertungsdatenbank oder Dokumentenarchiv. Die entscheidende Einsicht: Aufbewahrungspflichten verlangen, dass Unterlagen über Jahre lesbar und prüfbar bleiben. Sie verlangen nicht, dass diese Daten im neuen Produktivsystem bearbeitbar sind.
Umgekehrt gilt: Personenbezogene Daten, für die es keinen Zweck mehr gibt, sollten nicht mitwandern. Eine Migration ist der beste Anlass, Löschregeln zu klären, weil man jeden Bestand ohnehin einmal in der Hand hat. Welche Fristen und Rechtsgrundlagen konkret gelten, stimmen Sie mit Ihrer steuerlichen und rechtlichen Beratung ab — das ist eine Prüfung im Einzelfall und keine Frage, die ein Entwicklungsteam entscheidet.
Verantwortlichkeiten: wer migriert, wer gibt frei
Die Rollenverteilung ist einfach, wird aber selten ausgesprochen. Der Dienstleister baut die Migrationsstrecke, dokumentiert die Regeln, liefert die Abgleichsberichte und weist Fehler aktiv aus, statt sie zu glätten. Die Datenhoheit bleibt beim Kunden: Er entscheidet fachlich über das Mapping, benennt pro Datenobjekt eine verantwortliche Person, prüft die Ergebnisse und erteilt die Freigabe.
Das ist keine Vertragsformalie, sondern sachlich zwingend: Kein externes Team kann wissen, ob ein Statuswert noch gebraucht wird oder ob im Bemerkungsfeld eines Altkunden eine gültige Zusage steht. Wo Echtdaten für Testläufe das Haus verlassen, braucht es zudem den vertraglichen Rahmen zur Auftragsverarbeitung, möglichst wenige Kopien und eine verbindliche Löschung nach Projektende.
Und der ehrliche Teil: Wenn im Unternehmen niemand Zeit hat, Mapping und Freigabe zu tragen, ist das Projekt nicht startbereit. Diese Rolle kann kein Dienstleister übernehmen — sie lässt sich nur verschieben, und dann landet sie im Cut-over-Wochenende.
Fazit: Migration ist eine Inventur, kein Transport
Datenmigration scheitert nicht an Technik, sondern an unterlassenen Entscheidungen. Was trägt, ist unspektakulär: früh analysieren statt pauschal schätzen, fachlich mappen statt Felder verbinden, mehrfach testen und mit Zahlen belegen, den Umstieg mit Rückfallebene planen und weniger mitnehmen, als technisch möglich wäre. Welche Strategien es gibt, ein Altsystem überhaupt abzulösen, behandeln wir in einem eigenen Beitrag im Blog. Wenn Sie vor einer Umstellung stehen, sehen Sie sich unsere Leistungen an oder schreiben Sie uns über die Kontaktseite.
Häufige Fragen
Wie viel Aufwand sollte man für die Datenmigration einplanen?
Seriös lässt sich das erst nach einer Analyse der Bestandsdaten sagen. Verlässlich ist nur die Reihenfolge: erst Datenanalyse mit Mengenangaben, dann Konzept und Mapping, dann eine Aufwandsschätzung. Pauschale Angaben vor dem ersten Blick in die Daten sind Platzhalter.
Sollten wir wirklich nicht alle Altdaten übernehmen?
In den meisten Fällen nicht. Sinnvoll ist ein definierter Datenhorizont für den Produktivbestand plus ein lesbares Archiv für alles Ältere. Aufbewahrungspflichten verlangen Lesbarkeit und Prüfbarkeit, nicht die Bearbeitbarkeit im neuen System.
Woran erkennen wir, dass eine Testmigration erfolgreich war?
An dokumentierten Zählproben: Satzzahlen je Objekt, Summen der Betragsfelder, Verteilung der Statuswerte und Anzahl der Verknüpfungen, jeweils vor und nach dem Lauf. Jede Differenz braucht eine Erklärung. Ein Eindruck aus einer zufälligen Stichprobe genügt nicht.
Wer haftet, wenn nach der Umstellung Daten fehlen?
Das hängt von der Vereinbarung ab, deshalb sollte die Rollenteilung im Vertrag stehen: Der Dienstleister verantwortet Migrationsstrecke, Dokumentation und Abgleichsberichte, der Kunde die fachliche Entscheidung über das Mapping und die Freigabe je Datenobjekt.
