Datenübernahme planen
Ein neues System ohne Daten ist eine leere Hülle. Wenn der Kunde sein neu konzipiertes ERP, CRM oder Warenwirtschaftssystem produktiv einsetzen will, muss die Geschichte aus dem alten System mit – Kunden, Bestellungen, Rechnungen, Mitarbeiter, Vertragsdaten. Diese Datenübernahme (auch Datenmigration genannt) ist eine der riskantesten Phasen eines IT-Projekts. Fehler hier sind sichtbar bis in den letzten Winkel: falsche Rechnungen, verlorene Kundenhistorien, Stammdaten mit Müllzeichen. Diese Lektion zeigt dir, wie eine Datenübernahme systematisch geplant wird – vom ETL-Prozess über Datenqualitätsprüfung, Mapping zwischen Quell- und Zielstruktur bis zur Wahl der Migrationsstrategie.
1) Der ETL-Prozess – Extract, Transform, Load
Praktisch jede Datenübernahme folgt dem dreistufigen ETL-Prozess. Klick durch und sieh, was in jeder Stufe passiert:
2) Datenqualität – die wichtigste Vorabprüfung
Eines der ehernen Gesetze der Datenmigration lautet: Garbage in, garbage out. Wenn deine Quelldaten Müll sind, ist auch das Ergebnis im Zielsystem Müll – oft sogar schlimmer, weil das neue System strengere Validierungen hat und die Daten gar nicht erst importiert. Daher gehört eine Datenqualitätsanalyse ganz an den Anfang. Vier Hauptdimensionen werden bewertet:
3) Daten bereinigen – die Vorarbeit
Wenn die Qualität nicht ausreicht, kommt eine Datenbereinigung. Diese kann größer werden als die eigentliche Migration. Typische Aktionen:
- Dedupliziere Duplikate: Derselbe Kunde mehrfach erfasst (Schreibweise unterschiedlich). Tools: Fuzzy Matching nach Name+Adresse, manuelle Sichtung der Treffer.
- Vereinheitliche Schreibweisen: „München", „muenchen", „Muenchen", „MUC" → alle zu „München". Lookup-Tabellen, regelbasiert oder per Standard-Verzeichnis (z. B. Geo-Daten).
- Fülle Pflichtfelder: Wo PLZ fehlt, aus Stadt ableiten. Wo Branche fehlt, aus Kundenname / Marketingdaten ergänzen.
- Archiviere Karteileichen: Kunden, die seit 10 Jahren nichts mehr gekauft haben – nicht migrieren, sondern in Archiv. Sofern DSGVO es nicht ohnehin verlangt zu löschen.
- Behebe Formatfehler: Telefonnummern in einheitlichem Format (+49 30 1234567), E-Mails klein, Datumsformate ISO.
- Validiere mit externen Quellen: Adressen gegen Post-DB, IBAN gegen BIC-Verzeichnis, USt-IdNr gegen VIES.
Wichtige Disziplin: Datenbereinigung ist nicht Sache der IT allein. Die Fachabteilung kennt die Daten am besten und muss bei Entscheidungen einbezogen werden („Ist Kunde A123 noch aktiv? Sollen wir ihn übernehmen?"). Sonst läuft die IT in fachliche Fehlentscheidungen.
4) Mapping zwischen Quell- und Zielsystem
Das Mapping ist die schriftliche Übersetzung zwischen Quellstruktur und Zielstruktur. Ohne Mapping ist eine Migration blindes Raten. Beispiel-Mapping für einen Kundenstamm:
| Quelle (Altes ERP) | Ziel (Neues CRM) | Transformation |
|---|---|---|
| KDN_ID (NUMBER) | customerId (UUID) | UUID neu generieren, Mapping-Tabelle anlegen |
| NAME (VARCHAR 50) | firstName + lastName | Split bei erstem Leerzeichen |
| FIRMA (VARCHAR 80) | companyName | leer wenn nur Privatkunde |
| PLZ (CHAR 5) | address.postalCode | 1:1 Übernahme |
| ORT (VARCHAR 30) | address.city | Lookup gegen Geo-DB für Vereinheitlichung |
| LAND_KZ (CHAR 3) | address.countryCode | ISO-3166 (BRD→DE, ESP→ES) |
| EMAIL (VARCHAR 60) | contactEmail | Lowercase, Trim, Format-Validierung |
| ANGELEGT_AM (DATE) | createdAt (TIMESTAMP) | + 00:00:00 als Zeit, UTC |
| — (nicht vorhanden) | consentMarketing | Default: false (DSGVO-konform) |
| BEMERKUNGEN (BLOB) | notes (TEXT) | Encoding-Cleanup, max 4000 Zeichen |
5) Migrationsstrategien wählen
Wie kommen die Daten ins neue System? Es gibt mehrere Strategien – jede mit Vor- und Nachteilen:
Big Bang
Alle Daten an einem Stichtag ins neue System. Altsystem wird abgeschaltet.
+ klare Grenze, schnell durch – hohes Risiko, kein Rollback einfachParallel-Lauf
Alt- und Neusystem laufen gleichzeitig. Daten synchronisiert. Übergang sanft.
+ sehr sicher, Vergleich möglich – doppelter Aufwand, lange PhaseInkrementell
In Wellen migrieren: Stammdaten, dann Bewegungsdaten, dann Historien.
+ kontrollierbar, früh Wert – komplexes Sync zwischen WellenPilot
Erst Teilmenge migrieren (z. B. eine Filiale), dann andere folgen.
+ Lerneffekt vor Roll-out – temporärer Doppelbetrieb6) Testmigrationen – mehrfach proben
Die echte Migration kommt nie als Erste. Eine professionelle Vorgehensweise sieht mehrere Probe-Durchläufe vor:
- Mock-Migration (Sandbox): Mit einer Stichprobe (z. B. 100 Kunden) als „Trockenübung". Erkennt offensichtliche Mapping- und Format-Probleme.
- Vollmigration in Test-Umgebung: Mit der kompletten Datenmenge, aber ins Test-Zielsystem. Hier zeigen sich Performance-Probleme und seltene Datenfehler.
- Generalprobe in Stage: 1:1 wie die echte Migration, aber in Stage-Umgebung. Zeitmessung: Wie lange dauert es wirklich? Reicht das Wartungsfenster?
- Echtmigration in Produktion: Die finale, einzige produktive Migration.
Jeder Durchlauf verbessert das Migrations-Skript. Bei kritischen Projekten sind 3-5 Generalproben üblich – die letzten zwei davon „Trocken-Cutovers" inklusive aller Begleit-Aktivitäten (Anwender-Information, Backup, Rollback-Plan). Aufwand: enorm. Aber: Die letzte, echte Migration läuft dann routiniert.
7) Datenschutz und Rechtliches
Eine Datenmigration verarbeitet meist personenbezogene Daten – und ist damit datenschutzrelevant. Wichtige Pflichten:
- VVT-Eintrag aktualisieren: Wenn ein neues System personenbezogene Daten verarbeitet, muss es ins Verzeichnis der Verarbeitungstätigkeiten. Mehr in DSB & VVT.
- Auftragsverarbeitungsvertrag (AVV): Wenn ein externer Dienstleister die Migration macht, ist ein AVV nach Art. 28 DSGVO Pflicht.
- Zweckbindung: Daten dürfen nur für vereinbarte Zwecke migriert werden. Keine „nice to have"-Felder einfach mitnehmen.
- Löschpflichten beachten: Daten, die laut Aufbewahrungsfristen gelöscht sein sollten, NICHT migrieren. Sonst werden alte Datenschutz-Sünden ins neue System getragen.
- Pseudonymisierung in Testumgebungen: Test-Migrationen dürfen keine identifizierbaren Echtdaten enthalten. Namen, E-Mails ersetzen oder hashen.
- Datenträger sicher entsorgen: Wenn das Altsystem abgeschaltet wird, müssen Festplatten / Backups professionell gelöscht werden – Stichwort „Recht auf Vergessenwerden".
Bei sensiblen Daten (Gesundheit, Religion, biometrische) oder hohem Risiko: DSFA (Datenschutz-Folgenabschätzung) durchführen – Pflicht nach Art. 35 DSGVO. Migration ist ein typischer DSFA-Auslöser. Mehr in DSFA.
Zusammenfassung
Eine Datenübernahme folgt dem ETL-Prozess: Extract (Daten aus Quelle holen, ohne sie zu belasten), Transform (im Staging-Bereich aufbereiten – Datentyp, Encoding, Format, Dedup, Cleansing, Lookup), Load (ins Ziel einspielen, Stammdaten vor Bewegungsdaten). Alternative: ELT in modernen Cloud-Warehouses. Datenqualität entlang vier Dimensionen messen: Vollständigkeit, Konsistenz, Aktualität, Genauigkeit – < 70 % erfordert eigenständige Bereinigung. Datenbereinigung: Dedup, einheitliche Schreibweisen, Pflichtfelder ergänzen, Karteileichen archivieren, Formate vereinheitlichen, externe Validierung. Mapping als schriftliche Übersetzung Quell- → Zielfeld mit Transformationsregeln, fachlich abgestimmt. Migrationsstrategien: Big Bang (alles auf einen Stichtag, hohes Risiko), Parallel-Lauf (Alt+Neu gleichzeitig, sehr sicher), Inkrementell (in Wellen), Pilot (Teilmenge zuerst). Mehrfache Testmigrationen: Mock → Vollmigration in Test → Generalprobe in Stage → Echtmigration. Datenschutz: VVT-Eintrag, ggf. AVV mit Dienstleister, Zweckbindung, Löschpflichten, Pseudonymisierung in Test, DSFA bei sensiblen Daten.
Verwandte Lektionen: Datenübernahme durchführen und validieren · Rollout-Szenarien · Was ist eine Datenbank? · und mehrWeitere relevante LektionenSQL-GrundlagenDSB, VVT, DSFADSGVO-Grundprinzipien3-2-1-Backup vor MigrationKompatibilität prüfenSystemübergabe planenCI/CD PipelineWelche Doku für welchen Zweck?