Datenmigration im Softwareprojekt: Planung, Risiken und DSGVO

Bei einer Softwareeinführung steht die neue Anwendung im Rampenlicht – doch über Erfolg oder Scheitern entscheidet häufig ein weniger sichtbarer Teil: die Datenmigration. Sämtliche Bestandsdaten aus dem Altsystem müssen vollständig, korrekt und rechtskonform in die neue Lösung überführt werden. Unterschätzte Migrationen führen zu verschobenen Terminen, fehlerhaften Datensätzen und im schlimmsten Fall zu einem Systemstart, bei dem zentrale Informationen fehlen. Dieser Leitfaden zeigt, wie eine Datenmigration methodisch geplant wird, welche Risiken lauern und welche Datenschutzpflichten Sie beachten müssen.

Warum Datenmigration so kritisch ist

Daten sind das Gedächtnis eines Unternehmens: Kundenstammdaten, Verträge, Bestellhistorien, Belege. Gehen sie beim Umzug verloren oder werden sie verfälscht, betrifft das unmittelbar das Tagesgeschäft. Anders als Programmierfehler, die sich meist nachträglich beheben lassen, sind Datenverluste oft irreversibel, wenn das Altsystem bereits abgeschaltet wurde. Hinzu kommt: Migration ist selten ein simples Kopieren. Alt- und Neusystem strukturieren Daten unterschiedlich, Felder passen nicht eins zu eins zusammen, und über Jahre gewachsene Datenbestände enthalten Dubletten, Lücken und Inkonsistenzen. Genau deshalb verdient die Migration einen eigenen Projektstrang mit eigenem Zeit- und Testbudget.

Erschwerend kommt hinzu, dass die Verantwortung für die Datenqualität oft nicht klar zugeordnet ist. Die Agentur kennt die neue Software, aber nicht die fachliche Bedeutung jedes Feldes im Altsystem – dieses Wissen liegt bei Ihnen. Eine erfolgreiche Migration ist deshalb immer eine gemeinsame Aufgabe: Die Agentur liefert die technische Umsetzung, Sie stellen die fachliche Datenhoheit sicher. Wer diese Zusammenarbeit unterschätzt, produziert ein technisch sauber migriertes, aber inhaltlich unbrauchbares System.

Das Vorgehen Schritt für Schritt

1. Analyse und Bestandsaufnahme

Am Anfang steht die Bestandsaufnahme: Welche Daten liegen im Altsystem, in welchem Umfang, in welcher Qualität? Welche davon werden im Neusystem tatsächlich benötigt? Nicht alles muss migriert werden – historische Altlasten lassen sich oft archivieren statt übernehmen. Diese Reduktion senkt Aufwand und Risiko.

2. Mapping

Beim Mapping wird festgelegt, welches Feld im Altsystem welchem Feld im Neusystem entspricht. Hier zeigt sich die eigentliche Komplexität: Datentypen unterscheiden sich, Wertelisten passen nicht zusammen, ein Feld muss auf mehrere aufgeteilt oder aus mehreren zusammengeführt werden. Ein sauber dokumentiertes Mapping ist die Grundlage jeder erfolgreichen Migration.

3. Datenbereinigung

Vor der Übernahme sollten Daten bereinigt werden: Dubletten entfernen, Pflichtfelder ergänzen, offensichtlich falsche Werte korrigieren, veraltete Datensätze aussortieren. Der Grundsatz "Garbage in, garbage out" gilt uneingeschränkt – wer schlechte Daten migriert, hat sie anschließend im neuen System. Eine Migration ist zugleich die beste Gelegenheit, den Datenbestand aufzuräumen.

4. Test-Migrationen

Niemand migriert beim ersten Versuch produktiv. Stattdessen werden Probeläufe in einer Testumgebung durchgeführt, deren Ergebnisse geprüft und die Migrationsroutinen so lange verfeinert, bis sie stabil und wiederholbar sind. Mehrere Testdurchläufe sind die Regel, nicht die Ausnahme.

5. Cutover und Downtime

Der Cutover ist der eigentliche Umstieg auf das Neusystem. Er wird meist in ein Zeitfenster mit geringer Auslastung gelegt (Wochenende, Nachtstunden), weil das System während der finalen Migration oft nicht nutzbar ist. Diese geplante Downtime sollte frühzeitig kommuniziert werden. Ein detaillierter Cutover-Plan mit Zeitangaben und Verantwortlichkeiten verhindert Chaos am Stichtag.

6. Validierung

Nach der Migration wird geprüft, ob alle Daten korrekt und vollständig angekommen sind: Stichproben, Abgleich von Datensatzzahlen, Kontrolle kritischer Felder und Prüfung von Summen (etwa offene Rechnungsbeträge). Erst wenn die Validierung erfolgreich ist, wird das Neusystem produktiv freigegeben.

7. Rollback-Plan

Für den Fall, dass die Migration scheitert, braucht es einen Rückfallplan: Wie kehren Sie kontrolliert zum Altsystem zurück, ohne Daten zu verlieren? Vollständige Backups vor dem Cutover und ein definierter Rollback-Zeitpunkt gehören zu jeder verantwortungsvollen Migration. Legen Sie vorab fest, anhand welcher Kriterien der Rollback ausgelöst wird und bis zu welchem Zeitpunkt die Entscheidung fallen muss – im Ernstfall bleibt keine Zeit für lange Diskussionen.

Migrationsstrategien: Big Bang oder schrittweise

Für den eigentlichen Umstieg gibt es grundsätzlich zwei Wege, die den Aufwand und das Risiko stark beeinflussen:

• Big-Bang-Migration: Sämtliche Daten werden in einem einzigen Cutover übernommen, danach läuft ausschließlich das Neusystem. Der Vorteil ist ein klarer Schnitt ohne parallele Systeme; der Nachteil ist das konzentrierte Risiko – geht etwas schief, betrifft es alles auf einmal. Diese Variante eignet sich für überschaubare Datenmengen und klar abgegrenzte Systeme.
• Schrittweise (phasenweise) Migration: Daten und Funktionsbereiche werden nacheinander überführt, während Alt- und Neusystem eine Zeit lang parallel laufen. Das reduziert das Risiko pro Schritt, erfordert aber eine Synchronisation zwischen beiden Systemen während der Übergangsphase – was zusätzlichen Aufwand bedeutet. Diese Variante bietet sich bei großen, komplexen oder geschäftskritischen Datenbeständen an.

Welcher Weg passt, hängt von Datenmenge, Risikotoleranz und der Frage ab, ob ein Parallelbetrieb technisch und organisatorisch machbar ist. Besprechen Sie die Strategie früh mit Ihrer Agentur, da sie den gesamten Zeitplan prägt.

Typische Risiken

• Unterschätzter Aufwand: Datenqualität und Mapping-Komplexität werden regelmäßig zu niedrig eingeschätzt.
• Schlechte Datenqualität: Dubletten und Lücken werden erst während der Migration sichtbar und blockieren den Zeitplan.
• Fehlende Testläufe: Wer direkt produktiv migriert, riskiert einen Fehlstart ohne Rückweg.
• Zu knappe Downtime: Migrationen dauern oft länger als geplant – Puffer einplanen.
• Kein Rollback: Ohne Rückfalloption wird jeder Fehler existenzbedrohend.
• Unklare Verantwortlichkeiten: Wenn niemand die fachliche Datenhoheit hat, bleiben Zweifelsfälle ungeklärt.

Der Digitalverband Bitkom verweist darauf, wie stark Datenschutz und IT-Sicherheit inzwischen den Alltag von Unternehmen prägen – bei Migrationen kommen technische Sorgfalt und rechtliche Anforderungen unmittelbar zusammen.

DSGVO: Wenn personenbezogene Daten migriert werden

Enthalten die zu migrierenden Daten personenbezogene Informationen – etwa Kunden-, Mitarbeiter- oder Lieferantendaten –, greifen die Vorgaben der Datenschutz-Grundverordnung. Zwei Aspekte sind besonders relevant:

Auftragsverarbeitung nach Art. 28 DSGVO

Führt die Agentur oder ein Dienstleister die Migration in Ihrem Auftrag durch und verarbeitet dabei personenbezogene Daten, liegt regelmäßig eine Auftragsverarbeitung vor. Nach Art. 28 DSGVO muss dafür ein Auftragsverarbeitungsvertrag (AVV) geschlossen werden, der Zweck, Umfang, Weisungsbindung und technische wie organisatorische Maßnahmen regelt. Die Details, welche Inhalte ein solcher Vertrag enthalten muss, erläutert der Ratgeber DSGVO und AVV im Softwareprojekt.

Sicherheit der Verarbeitung nach Art. 32 DSGVO

Migrationen bergen besondere Sicherheitsrisiken, weil Daten kopiert, transportiert und in Testumgebungen verarbeitet werden. Art. 32 DSGVO verlangt geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau sicherzustellen – etwa Verschlüsselung bei Übertragung und Speicherung, Zugriffsbeschränkungen und das Löschen von Test- und Zwischenbeständen nach Abschluss. Personenbezogene Echtdaten gehören nach Möglichkeit nicht ungeschützt in Testumgebungen.

In der Praxis bedeutet das: Für Test-Migrationen sollten Daten möglichst anonymisiert oder pseudonymisiert werden, sodass reale Personen nicht identifizierbar sind. Ist der Einsatz von Echtdaten für aussagekräftige Tests unumgänglich, müssen dieselben Schutzmaßnahmen wie im Produktivbetrieb gelten und die Testbestände nach Abschluss zuverlässig gelöscht werden. Dokumentieren Sie, wer wann auf welche Daten zugreifen konnte – diese Nachweisfähigkeit ist Teil der Rechenschaftspflicht der DSGVO. Prüfen Sie außerdem, ob im Rahmen der Migration Daten in Drittländer außerhalb der EU gelangen (etwa bei Cloud-basierten Werkzeugen), da hierfür zusätzliche Anforderungen gelten können.

Beachten Sie außerdem den Grundsatz der Datenminimierung: Migrieren Sie nur, was Sie tatsächlich benötigen, und nutzen Sie den Umzug, um nicht mehr erforderliche personenbezogene Daten rechtskonform zu löschen. Hinweis: Dieser Beitrag bietet eine allgemeine Orientierung und ersetzt keine Rechtsberatung im Einzelfall.

Wer setzt Datenmigrationen um?

Datenmigration verbindet fachliches Verständnis Ihrer Daten mit technischem Können. Häufig übernehmen Dienstleister aus dem Bereich Data Science & KI die Analyse und Transformation komplexer Datenbestände, während die Bereitstellung von Umgebungen und die technische Ausführung oft bei Anbietern für Cloud & DevOps liegen. In vielen Projekten arbeiten beide Kompetenzen zusammen. Achten Sie bei der Auswahl darauf, dass die Agentur nachweisbare Erfahrung mit vergleichbaren Migrationen mitbringt und ein strukturiertes Vorgehen mit Test- und Validierungsphasen beschreibt – nicht nur die reine Datenübertragung.

Unabhängig davon, wer die Migration technisch umsetzt, bleibt die Kommunikation mit den betroffenen Fachbereichen entscheidend. Die Menschen, die täglich mit den Daten arbeiten, erkennen Fehler und Lücken oft schneller als jede automatische Prüfung. Beziehen Sie sie deshalb früh ein: in die Definition, welche Daten wirklich gebraucht werden, in die Bereinigung und in die Validierung nach dem Cutover. Kündigen Sie die geplante Downtime rechtzeitig an und benennen Sie einen Ansprechpartner für Rückfragen am Stichtag. Eine technisch perfekte Migration nützt wenig, wenn die Anwender dem Ergebnis nicht vertrauen.

Häufige Fragen

Wie lange dauert eine Datenmigration?

Das hängt von Datenmenge, Qualität und der Zahl der Systeme ab. Die reine technische Übertragung ist oft der kürzeste Teil – der Großteil des Aufwands entfällt auf Analyse, Mapping, Bereinigung und Testläufe. Planen Sie die Migration als eigenständigen Projektstrang mit realistischem Puffer ein.

Können wir während der Migration weiterarbeiten?

Meist gibt es ein kurzes Zeitfenster (Downtime), in dem das System nicht oder nur eingeschränkt nutzbar ist – typischerweise während des finalen Cutovers. Frühzeitige Kommunikation und ein Termin mit geringer Auslastung minimieren die Auswirkungen auf den Betrieb.

Was passiert mit dem Altsystem?

Schalten Sie es nicht sofort ab. Bewährt hat sich eine Übergangsphase, in der das Altsystem noch lesend verfügbar bleibt, bis das Neusystem stabil läuft und alle Daten validiert sind. Danach folgt eine geordnete, datenschutzkonforme Archivierung oder Löschung.

Brauchen wir für die Migration einen AVV?

Wenn ein externer Dienstleister personenbezogene Daten in Ihrem Auftrag verarbeitet, ist nach Art. 28 DSGVO in der Regel ein Auftragsverarbeitungsvertrag erforderlich. Klären Sie das vor Projektbeginn. Enthalten die Daten keinen Personenbezug, entfällt diese Pflicht, die übrigen Sorgfaltsanforderungen bleiben aber bestehen.

Wie stellen wir sicher, dass keine Daten verloren gehen?

Durch vollständige Backups vor dem Cutover, mehrere Test-Migrationen, eine systematische Validierung nach der Übertragung und einen definierten Rollback-Plan. Kontrollieren Sie kritische Kennzahlen wie Datensatzzahlen und Summen gezielt, statt nur stichprobenhaft zu prüfen.

Passende Agentur finden: Eine erfahrene Agentur plant die Datenmigration von Anfang an mit, statt sie ans Projektende zu schieben. Vergleichen Sie in unserem Verzeichnis Anbieter aus den Bereichen Data Science & KI und Cloud & DevOps und fragen Sie im Erstgespräch gezielt nach Vorgehen, Testläufen und Datenschutz.