Ein neuer Shop, ein ERP-Wechsel oder die Ablösung eines alten CRM scheitert selten an einem einzelnen Import. Die Top Fehler bei Datenmigrationen entstehen meist früher: Daten werden für vollständiger gehalten, Prozesse für einfacher und Schnittstellen für stabiler, als sie tatsächlich sind. Das fällt spätestens auf, wenn Aufträge doppelt angelegt werden, Lagerbestände nicht stimmen oder der Kundenservice nach dem Go-Live mit Excel-Listen improvisieren muss.
Eine Datenmigration ist keine technische Nebenaufgabe. Sie ist der Moment, in dem gewachsene Geschäftsabläufe sichtbar werden: Sonderpreise, historische Bestellungen, individuelle Kundengruppen, Artikelvarianten, abweichende Rechnungsadressen oder manuelle Korrekturen aus dem Tagesgeschäft. Wer diese Realität sauber aufnimmt, schafft die Grundlage für ein System, das im Betrieb funktioniert - nicht nur für eine erfolgreiche Projektpräsentation.
Warum Datenmigrationen so oft unterschätzt werden
Viele Projekte starten mit einer scheinbar einfachen Frage: Welche Daten sollen vom Altsystem ins neue System? Die bessere Frage lautet: Welche Daten und Regeln braucht das Unternehmen nach dem Umstieg tatsächlich, damit Verkauf, Einkauf, Lager, Buchhaltung und Service ohne Unterbrechung weiterarbeiten können?
Das ist ein Unterschied mit Folgen. Ein Shopware-6-Shop benötigt beispielsweise nicht nur Produkte und Bilder. Entscheidend sind auch Variantenlogiken, Preise, Kundengruppen, Steuerregeln, Lieferzeiten, Cross-Selling-Beziehungen und die Zuordnung zu ERP- oder PIM-Daten. In Odoo betrifft das zusätzlich Stammdaten, offene Vorgänge, Kontenlogik, Lagerorte und Berechtigungen. Werden diese Zusammenhänge erst kurz vor dem Go-Live geklärt, wird aus einer Migration schnell ein teures Aufräumprojekt unter Zeitdruck.
Die technische Übertragung ist dabei nur ein Teil der Arbeit. Mindestens genauso relevant sind Datenqualität, fachliche Entscheidungen, Testfälle und ein klar geregelter Übergang. Gerade mittelständische Unternehmen mit mehreren gewachsenen Systemen profitieren davon, Migration als eigenes Arbeitspaket mit Verantwortlichkeiten, Zeitplan und Abnahmekriterien zu behandeln.
Die Top Fehler bei Datenmigrationen
1. Altdaten ungeprüft übernehmen
Der häufigste Fehler ist die Annahme, dass alles, was im Altsystem vorhanden ist, auch ins Zielsystem gehört. In der Praxis finden sich oft doppelte Kundenkonten, nicht mehr verwendete Artikel, inkonsistente Kategorien, fehlende Pflichtfelder und Felder, deren Bedeutung niemand mehr sicher erklären kann. Werden diese Daten unverändert kopiert, zieht das Unternehmen sein Excel-Chaos lediglich in eine neue Oberfläche um.
Vor der Migration braucht es deshalb eine fachliche Bereinigung. Dabei geht es nicht darum, historische Daten pauschal zu löschen. Manche Altbestellungen sind für Gewährleistung, Buchhaltung oder Kundenservice relevant. Es geht um eine nachvollziehbare Entscheidung: Welche Daten werden aktiv übernommen, welche archiviert und welche bewusst nicht mehr verwendet? Besonders bei personenbezogenen Daten sollten Aufbewahrungsfristen und Datenschutzanforderungen von Beginn an berücksichtigt werden.
2. Datenfelder ohne klare Zuordnung mappen
Ein Feld mit der Bezeichnung „Status“ bedeutet nicht automatisch in jedem System dasselbe. Im alten Shop kann es den Bestellfortschritt meinen, im ERP den Zahlungsstatus und in einem CRM den Bearbeitungsstand eines Kontakts. Werden solche Felder nur nach Namen verbunden, entstehen falsche Informationen und fehlerhafte Folgeprozesse.
Ein belastbares Mapping beschreibt daher Quelle, Zielfeld, Datenformat, Transformationsregel und fachliche Bedeutung. Es beantwortet auch Sonderfälle: Was passiert mit fehlenden Werten? Welche Kundengruppe erhält ein Konto ohne gültige Umsatzsteuer-ID? Wie werden Artikel mit mehreren Lieferanten behandelt? Diese Regeln müssen Fachbereich und Technik gemeinsam festlegen. Ein Entwickler kann Daten transformieren, aber nicht entscheiden, welche betriebliche Logik korrekt ist.
3. Abhängigkeiten zwischen Systemen übersehen
Ein Datensatz lebt selten allein. Produkte hängen an Kategorien, Medien, Preisen, Beständen und Steuersätzen. Kunden sind mit Adressen, Rollen, individuellen Konditionen und Bestellhistorien verbunden. Ein Lagerbestand ist nur dann verlässlich, wenn Artikelnummer, Einheit, Lagerort und Reservierungslogik zusammenpassen.
Besonders kritisch wird es bei Systemlandschaften aus Shop, ERP, CRM, Zahlungsdienstleister, Versandlösung und PIM. Wenn die Migration nur das Zielsystem betrachtet, bleiben Schnittstellen oft bis zum Schluss außen vor. Dann ist der neue Shop zwar gefüllt, erhält aber keine aktuellen Bestände. Oder Aufträge werden übertragen, jedoch ohne die nötige Zuordnung für Versand und Rechnung.
Vor dem ersten Import sollte deshalb feststehen, welches System künftig für welche Daten führend ist. Ohne diese Entscheidung entstehen Doppelpflege und widersprüchliche Werte. Ein System statt zehn Insellösungen beginnt nicht mit einem neuen Tool, sondern mit klaren Zuständigkeiten für Daten.
4. Nur technisch testen statt fachlich prüfen
Ein erfolgreicher Import sagt lediglich, dass Daten angekommen sind. Er sagt nicht, dass sie richtig verwendet werden. Ein Produkt kann sichtbar sein, aber den falschen Preis ausspielen. Ein Kunde kann angelegt sein, aber seine B2B-Konditionen verlieren. Eine Bestellung kann im ERP erscheinen, ohne dass die Rechnung korrekt erzeugt wird.
Sinnvoll sind Tests entlang echter Geschäftsvorfälle. Ein Vertriebsmitarbeiter legt einen Kunden mit Sonderkonditionen an. Ein Kunde bestellt eine Variante mit abweichender Lieferzeit. Das Lager bucht eine Teillieferung. Die Buchhaltung verarbeitet eine Stornierung. Solche Fälle zeigen, ob Daten, Rollen, Schnittstellen und Prozessregeln zusammenspielen.
Dabei sollten nicht nur IT und Projektleitung testen. Die Menschen aus Vertrieb, Lager, Kundenservice und Buchhaltung kennen die Ausnahmen, die in keinem Standardprozess stehen. Ihre Rückmeldung ist kein zusätzlicher Abstimmungstermin, sondern Teil der Qualitätssicherung.
5. Den Go-Live als einmaligen Stichtag behandeln
Die meisten Systeme bleiben bis kurz vor der Umstellung in Betrieb. Während ein erster Datenexport geprüft wird, gehen neue Bestellungen ein, Bestände ändern sich und Kundendaten werden ergänzt. Wer diesen Zeitraum nicht plant, startet mit einem Datenstand, der bereits überholt ist.
Bewährt hat sich eine Kombination aus Testmigration, finaler Übernahme und klar definiertem Delta-Import. Zuerst wird mit einem realistischen Datenbestand getestet. Danach werden erkannte Fehler im Mapping und in den Quelldaten korrigiert. Kurz vor dem Go-Live folgt die finale Übernahme der Änderungen seit dem Testlauf. Wie lange dafür Schreibsperren gelten müssen, hängt vom System und vom Geschäftsmodell ab. Ein B2B-Portal mit wenigen Aufträgen verträgt andere Wartungsfenster als ein stark frequentierter Onlineshop.
Ebenso wichtig ist ein Rückfallplan. Nicht jede Unstimmigkeit verlangt sofort den Abbruch. Aber es muss vorab klar sein, welche Kriterien einen Stopp auslösen, wer entscheidet und wie das Altsystem weiterbetrieben wird. Das reduziert Stress, wenn am Launch-Tag unerwartete Probleme auftreten.
So wird die Migration planbar
Planbarkeit entsteht nicht durch besonders viele Statusmeetings, sondern durch frühe Klarheit. Zu Projektbeginn sollten Datenquellen, Datenverantwortliche, Zielprozesse und technische Schnittstellen erfasst werden. Daraus entsteht ein Migrationskonzept, das nicht nur Tabellen und APIs beschreibt, sondern auch fachliche Regeln, Testfälle, Zeitfenster und Abnahmen.
Ein sinnvoller Ablauf beginnt mit einer Datenanalyse. Dabei werden Mengen, Dubletten, Pflichtfelder, Formate und auffällige Ausnahmen sichtbar. Anschließend folgen Bereinigung und Mapping, dann mindestens ein Testimport mit repräsentativen Daten. Erst wenn die Fachbereiche die Ergebnisse anhand konkreter Vorgänge geprüft haben, wird der finale Umstieg vorbereitet.
Transparenz ist dabei wichtiger als eine scheinbar perfekte Planung. Wenn alte Artikelnummern nicht eindeutig sind oder historische Aufträge nur teilweise übernommen werden können, sollte das früh auf den Tisch. Solche Entscheidungen sind normal. Problematisch werden sie erst, wenn sie kurz vor dem Go-Live überraschend auftauchen und niemand Zuständigkeit oder Budget geklärt hat.
Nach dem Launch beginnt die Absicherung
Auch eine gut vorbereitete Migration braucht Beobachtung im Betrieb. In den ersten Tagen sollten Aufträge, Bestände, Zahlungen, Schnittstellenprotokolle und Fehlermeldungen gezielt kontrolliert werden. Nicht jeder Fehler hat dieselbe Priorität: Ein falsch zugeordnetes Produktbild ist ärgerlich, eine fehlerhafte Rechnung oder ein nicht übertragener Lagerbestand muss sofort behandelt werden.
Hilfreich ist eine feste Anlaufstelle für Rückmeldungen aus den Fachbereichen. So verschwinden Auffälligkeiten nicht in einzelnen E-Mails, sondern werden bewertet, priorisiert und nachvollziehbar gelöst. Gerade bei langfristig betriebenen Plattformen zahlt sich diese Phase aus: Sie zeigt, wo Regeln präzisiert, Automatisierungen angepasst oder Schulungen ergänzt werden müssen.
Eine gute Datenmigration wirkt nach außen oft unspektakulär. Genau das ist ihr Ziel. Wenn Kunden bestellen können, das Lager richtige Bestände sieht, die Buchhaltung verlässliche Belege erhält und niemand nach versteckten Excel-Listen suchen muss, ist der Wechsel gelungen. Der entscheidende Schritt dafür liegt nicht im letzten Import, sondern in den vielen sauberen Entscheidungen davor.