News

Datenmigration: Strategien, Checkliste, Beispiel

14. Oktober 2026 · DigifyNow

Eine Datenmigration läuft in drei Schritten: Daten aus dem Altsystem exportieren, sie per Mapping-Tabelle in die Struktur des neuen Systems umbauen und dort einspielen. Davor kommt mindestens ein Probelauf mit einer Kopie der echten Daten. Danach gleichen Sie die Datensatzzahlen und Summen ab. Erst wenn das stimmt, frieren Sie das Altsystem zum Stichtag ein. Löschen Sie es nicht, denn Altdaten unterliegen oft acht oder zehn Jahre der Aufbewahrungspflicht.

Was ist eine Datenmigration? Definition und Abgrenzung

Eine Datenmigration ist das einmalige Übertragen von Datenbeständen aus einem Quellsystem in ein Zielsystem. Fast immer müssen die Daten dabei umgebaut werden, weil die beiden Systeme sie unterschiedlich speichern. Technisch läuft das in drei Schritten, die unter dem Kürzel ETL bekannt sind. Extract heißt, die Daten aus dem Altsystem zu holen, etwa als CSV-Datei nach RFC 4180 oder direkt per Datenbankabfrage. Transform heißt, Felder zuzuordnen, Formate umzurechnen und Dubletten zusammenzuführen. Load heißt, die Daten über die Importfunktion oder eine API ins neue System zu spielen. Zwei Dinge werden oft damit verwechselt. Eine Datensicherung kopiert Daten unverändert, damit man sie zurückholen kann. An der Struktur ändert sie nichts. Eine API-Schnittstelle gleicht dauerhaft zwischen zwei Systemen ab, die beide weiterlaufen. Die Migration dagegen hat ein Ende: Danach ist das neue System die führende Quelle. Das alte wird abgeschaltet oder nur noch zum Lesen behalten. Bei DigifyNow gehört die Migration fast immer zu einem größeren Projekt. Wer eine eigene Software oder ein neues Backoffice bekommt, will Kunden, Aufträge und Dokumente aus dem alten Werkzeug mitnehmen.

Welche Strategien für die Datenmigration gibt es?

In der Praxis gibt es drei Strategien. Sie unterscheiden sich darin, wie lange das alte und das neue System gleichzeitig in Betrieb sind. Welche passt, hängt weniger von der Datenmenge ab als davon, wie eng die Datenbereiche miteinander verknüpft sind und wie teuer ein Tag Stillstand wäre.

Für die meisten kleinen und mittleren Unternehmen empfehlen wir einen Big Bang mit gründlichem Probelauf. Ein Parallelbetrieb klingt sicher. Er scheitert aber häufig daran, dass im Alltag niemand die Zeit für die doppelte Erfassung hat.

Datenmigration Checkliste: Was muss vor dem Umzug geklärt sein?

Die folgenden sechs Punkte arbeiten wir in jedem Migrationsprojekt in dieser Reihenfolge ab. Jeder Punkt liefert ein Ergebnis, das man prüfen kann, und nicht nur ein Gefühl, dass alles passt.

1. Bestand aufnehmen: Welche Tabellen oder Dateien gibt es, wie viele Datensätze enthält jede, welcher Zeichensatz wird genutzt (UTF-8 oder Windows-1252) und welches Exportformat bietet das Altsystem an?
2. Mapping-Tabelle anlegen: Für jedes Quellfeld werden das Zielfeld, die Umwandlungsregel und die Frage festgehalten, ob es ein Pflichtfeld ist. Felder ohne Ziel werden ausdrücklich als 'entfällt' markiert.
3. Vor dem Umzug aufräumen: Dubletten zusammenführen und verwaiste Datensätze ohne Bezug entfernen. Außerdem gemeinsam mit der Fachabteilung entscheiden, welche Altdaten gar nicht mitkommen.
4. Probemigration durchführen: Mindestens ein vollständiger Durchlauf mit einer Kopie der echten Daten in einer Testumgebung. Erfundene Testdaten decken die echten Sonderfälle nicht auf.
5. Abgleich machen: Datensatzzahlen pro Tabelle vergleichen, Summen bilden (etwa alle offenen Rechnungsbeträge) und Stichproben von den Leuten prüfen lassen, die täglich mit den Daten arbeiten.
6. Stichtag und Rückweg festlegen: Das Altsystem wird zum Stichtag schreibgeschützt. Es gibt einen dokumentierten Rückfallplan, und das Altsystem wird nicht gelöscht.

Punkt 3 ist der, der am häufigsten übersprungen wird. Aufräumen kostet vor dem Umzug Stunden. Danach kostet es Wochen, weil sich die Fehler bis dahin im neuen System verteilt haben.

Woran scheitern Datenmigrationen in der Praxis?

Selten scheitert eine Migration an der Menge. Meistens sind es Kleinigkeiten in den Formaten, die beim ersten Blick auf die Exportdatei niemand bemerkt. Diese sechs Fehler begegnen uns immer wieder:

• Kaputte Umlaute: Das Altsystem exportiert in Windows-1252, der Import erwartet aber UTF-8. Dann wird aus 'Müller' plötzlich 'Müller'. Die Ursache ist ein Zeichensatz, der beim Export nicht angegeben wurde.
• Vertauschte Datumsangaben: Aus 03.04. wird der 4. März, weil ein Werkzeug das amerikanische Format annimmt. Als Zwischenformat taugt ISO 8601 (JJJJ-MM-TT), weil es in keiner Richtung missverständlich ist.
• Excel verändert Werte: Führende Nullen fallen weg, aus der Postleitzahl 01067 wird 1067. Zahlen mit mehr als 15 Stellen rundet Excel, was lange Kunden- oder Artikelnummern zerstört.
• Abgerissene Verknüpfungen: Das Zielsystem vergibt neue IDs, und die Aufträge verlieren ihren Kunden. Das lässt sich vermeiden, indem die alte ID in einem eigenen Feld mitwandert.
• Abgeschnittene Texte: Das Zielfeld ist kürzer als das Quellfeld, und der Import kürzt ohne Warnung.
• Freitext mit gemischtem Inhalt: In einem Feld 'Bemerkung' stehen Telefonnummer, Ansprechpartner und Zahlungsziel durcheinander. Kein Skript trennt das zuverlässig. Hier muss ein Mensch entscheiden.

Fast alle diese Fehler zeigen sich im Probelauf, wenn man danach die Zahlen abgleicht. Ohne Probelauf fallen sie erst auf, wenn ein Kunde eine falsche Rechnung bekommt.

Was passiert mit Altdaten, die aufbewahrt werden müssen?

Nach der Migration das alte System einfach abzuschalten ist bei steuerlich relevanten Daten keine Option. § 147 der Abgabenordnung legt Aufbewahrungsfristen fest. Für Bücher, Inventare und Jahresabschlüsse sind es zehn Jahre. Für Buchungsbelege sind es seit dem 1. Januar 2025 acht Jahre, für empfangene und versandte Handels- und Geschäftsbriefe sechs Jahre. Nach § 147 Abs. 6 AO darf die Finanzverwaltung bei einer Prüfung auf elektronisch gespeicherte Daten zugreifen. Die GoBD verlangen, dass die Daten während der gesamten Frist maschinell auswertbar bleiben. Eine PDF-Ausgabe einer Tabelle reicht dafür in der Regel nicht. In der Praxis gibt es zwei Wege. Entweder bleibt das Altsystem im Lesemodus erhalten, oder die Daten werden in ein auswertbares Archivformat exportiert. Welcher Weg in Ihrem Fall genügt, klären Sie mit Ihrem Steuerberater, nicht mit dem Softwareentwickler. Auch die DSGVO spielt mit. Der Grundsatz der Speicherbegrenzung in Art. 5 Abs. 1 lit. e verlangt, personenbezogene Daten nicht länger als nötig zu behalten. Die Migration ist deshalb ein guter Anlass zu prüfen, welche Kontaktdaten ohne Zweck mitwandern würden.

Datenmigration Beispiel: Von Excel und Altprogramm ins neue CRM

Ein typisches Szenario aus dem Mittelstand, bewusst ohne Firmennamen: Ein Handelsbetrieb führt seine Kundenstammdaten in einer Excel-Liste. Die Aufträge liegen in einem älteren Warenwirtschaftsprogramm, und Gesprächsnotizen stehen verstreut in Outlook. Ziel ist ein eigenes Backoffice mit CRM, in dem Kontakt, Firma und Vorgang zusammengehören. Zuerst führen wir die Excel-Liste und den Kundenstamm der Warenwirtschaft zusammen. Dabei zeigt sich, dass dieselbe Firma in beiden Quellen unterschiedlich geschrieben ist. Der Abgleich läuft über Kundennummer und Postleitzahl, und unklare Treffer gehen als Liste an den Vertrieb. Danach folgen die Aufträge. Jeder Auftrag behält seine alte Kundennummer als Verweis, damit die Zuordnung auch nach der neuen ID-Vergabe stimmt. Die Outlook-Notizen werden nicht automatisch übernommen. Sie haben keine Struktur, und ein Skript würde sie den falschen Kontakten zuordnen. Stattdessen werden die wichtigen Notizen von Hand übertragen, der Rest bleibt im Postfach. Nach dem Probelauf werden die Kundenzahl, die Auftragszahl und die Summe der offenen Posten verglichen. Erst wenn alle drei stimmen, steht der Stichtag fest.

Reicht die Importfunktion, oder braucht es ein Migrationsskript?

Die eingebaute CSV-Importfunktion eines Standardprogramms reicht, wenn drei Bedingungen erfüllt sind. Es gibt nur eine Quelle, die Daten haben keine Verknüpfungen untereinander (eine reine Kontaktliste etwa), und das Zielsystem gibt beim Import ein Fehlerprotokoll aus. Dann ist ein eigenes Skript Aufwand ohne Gegenwert. Bei ein paar hundert Datensätzen kann sogar die Eingabe von Hand schneller sein als jede Automatisierung. Ein Skript lohnt sich, wenn mehrere Quellen zusammengeführt werden, wenn Aufträge, Positionen und Kunden aufeinander verweisen oder wenn der Probelauf mehrmals wiederholt werden muss. DigifyNow schreibt Migrationsskripte so, dass sie beliebig oft laufen können, ohne Dubletten zu erzeugen. Jeder Datensatz, der nicht übernommen werden kann, landet mit Grund in einem Protokoll, statt still zu verschwinden. Am Ende steht ein Bericht mit den Zahlen aus Quelle und Ziel. Wo die Migration in den Ablauf eines Softwareprojekts gehört, nämlich vor die Abnahme und nicht danach, sollte schon bei der Planung feststehen. Hilfreich ist außerdem eine vorherige Prozessanalyse. Sie zeigt, welche Daten im neuen Ablauf überhaupt noch gebraucht werden.

Kostenlose Einschätzung für Ihr Projekt anfragen