Häufig gestellte Fragen
Welche Daten müssen bei einer ERP-Datenmigration übernommen werden?
Zwingend übernommen werden in der Regel die aktiven Stammdaten – etwa Artikel, Kunden, Lieferanten und Konten – sowie die offenen Bewegungsdaten wie offene Posten, laufende Aufträge und aktuelle Lagerbestände, weil das neue System sonst nicht arbeitsfähig ist. Abgeschlossene historische Belege werden dagegen häufig nicht produktiv mitgenommen, sondern im Altsystem oder in einem Archiv aufbewahrt, oft mehrere Jahre rückwirkend. Diese Eingrenzung des Migrationsumfangs senkt Aufwand und Fehlerquellen deutlich, weil nicht jeder veraltete oder inaktive Datensatz transformiert und geprüft werden muss. Welche Daten konkret benötigt werden, sollten die Fachabteilungen pro Datendomäne festlegen, nicht allein die IT.
Wie lange müssen alte ERP-Daten und Belege nach einer Migration aufbewahrt werden?
Steuerlich und handelsrechtlich relevante Unterlagen unterliegen in Deutschland Aufbewahrungspflichten nach Abgabenordnung (AO) und Handelsgesetzbuch (HGB), die je nach Dokumentart sechs, acht oder zehn Jahre betragen. Mit dem Vierten Bürokratieentlastungsgesetz wurde die Frist für Buchungsbelege ab dem 1. Januar 2025 von zehn auf acht Jahre verkürzt, während für Bücher, Jahresabschlüsse und Inventare weiterhin zehn Jahre gelten. Werden Belege bei der Migration digitalisiert oder ins neue System übernommen, müssen sie nach den GoBD revisionssicher, unveränderbar und maschinell auswertbar archiviert sein. In der Praxis bleiben abgeschlossene Altbelege deshalb oft lesend im Altsystem oder in einem GoBD-konformen Archiv verfügbar, statt produktiv ins neue ERP übernommen zu werden.
Was ist der Unterschied zwischen Big-Bang- und phasenweiser Datenmigration?
Beim Big-Bang-Ansatz erfolgt die Übernahme zu einem festen Stichtag, an dem vollständig vom Alt- auf das neue System umgeschaltet wird, häufig an einem Wochenende mit kurzer Ausfallzeit. Der Vorteil ist ein klarer Schnitt ohne längeren Parallelbetrieb; der Nachteil ist das höhere Risiko, weil bei Problemen das ganze Unternehmen betroffen ist und ein Rollback nötig werden kann. Bei der phasenweisen Migration werden Daten und Funktionen in Teilschritten übernommen, sodass Alt- und Neusystem zeitweise parallel laufen – das reduziert das Stichtagsrisiko und erlaubt einen schrittweisen Rückfall, erhöht aber Aufwand und Komplexität durch doppelte Datenpflege. Welche Variante passt, hängt von Branche, Unternehmensgröße, Ausfalltoleranz und der Komplexität des Customizings ab.
Wie wird die Vollständigkeit und Richtigkeit der migrierten Daten geprüft?
Die Prüfung kombiniert in der Regel eine technische und eine fachliche Validierung: Technisch werden Datensatzzahlen zwischen Quell- und Zielsystem abgeglichen, Summen verglichen (etwa Salden oder Bestandswerte) und Pflichtfelder auf Vollständigkeit kontrolliert. Fachlich prüfen Key-User stichprobenartig einzelne Datensätze – beispielsweise eine Auswahl von Kunden, Artikeln oder offenen Aufträgen – inhaltlich gegen das Altsystem. Dieser abschließende Abgleich, oft als Reconciliation bezeichnet, stellt sicher, dass keine Daten verloren gegangen oder falsch zugeordnet worden sind. Bewährt ist, mehrere Testmigrationen in einer Sandbox durchzuspielen und erst nach dokumentierter fachlicher Abnahme produktiv zu übernehmen.
Warum scheitern so viele ERP-Projekte an der Datenmigration?
Die Datenmigration gilt als einer der kritischsten Teilschritte einer ERP-Einführung und ist ein häufiger Grund für verzögerte Go-Live-Termine, weil schlechte Datenqualität oft erst auffällt, wenn die Migration bereits läuft. Verbreitete Branchenanalysen – häufig Gartner oder Bloor Research zugeschrieben – nennen seit Jahren hohe Misserfolgs- und Budgetüberschreitungsquoten bei Datenmigrationsprojekten, wobei Dubletten sowie veraltete oder inkonsistente Sätze regelmäßig als Hauptursache gelten. Ein typischer Fehler ist, die Migration als reine IT-Aufgabe zu behandeln, statt die Fachabteilungen einzubinden, die beurteilen können, welche Daten wirklich gebraucht werden. Frühe Datenbereinigung, ein verbindliches Zielmodell und mehrere Testläufe gelten deshalb als die wirksamsten Gegenmaßnahmen.
Wann sollte die Datenbereinigung im Migrationsprojekt stattfinden?
Bewährt hat sich, die Datenbereinigung möglichst früh anzusetzen und nicht ans Ende des Projekts zu schieben, weil fehlerhafte Daten sich sonst dauerhaft im neuen System fortsetzen. In der Praxis werden vor der eigentlichen Übernahme Dubletten konsolidiert, veraltete Sätze entfernt und inkonsistente Werte vereinheitlicht – etwa uneinheitlich vergebene Artikelnummern oder doppelt geführte Lieferanten. Eine saubere Stammdatenpflege im Vorfeld senkt den späteren Migrationsaufwand spürbar und verringert die Zahl der Fehler, die in Testläufen auftauchen. Klare Verantwortlichkeiten pro Datendomäne und ein dokumentiertes Mapping unterstützen dabei, die Bereinigung nachvollziehbar und wiederholbar zu gestalten.