Ein Datenmigrationskonzept kann freigegeben sein und die Umsetzung trotzdem nicht tragen. Die Belastungsprobe ist einfach: Nehmen Sie ein priorisiertes Datenobjekt wie offene Kundenaufträge. Kann das Projektteam gemeinsam erklären, welche Aufträge aus welcher Quelle übernommen werden, wie Status und Werte im neuen ERP-System zu verstehen sind, welche Kunden- und Materialdaten vorher vorhanden sein müssen und woran der Fachbereich einen korrekt migrierten Auftrag erkennt?
Bleiben diese Antworten allgemein, fehlt nicht unbedingt ein längeres Dokument. Es fehlen Entscheidungen, auf denen Mapping, technische Umsetzung und Tests verlässlich aufbauen können.
Vor der Umsetzung muss deshalb eine geschlossene Entscheidungskette stehen: vom Zweck der Daten im Zielsystem über den konkreten Datenumfang und die fachlichen Regeln bis zu Verantwortlichkeit, Prüfnachweis und produktiver Übernahme. Nicht jedes einzelne Feld muss bereits abschließend geklärt sein. Das Konzept muss aber zeigen, was entschieden ist, was noch offenbleibt, wer den offenen Punkt klärt und welchen nächsten Schritt er blockiert.
Ein Datenmigrationskonzept ist kein Sammelordner für Projektdateien
In ERP-Projekten werden sehr unterschiedliche Unterlagen als „Migrationskonzept“ bezeichnet. Dadurch kann ein umfangreicher Ordner entstehen, ohne dass klar ist, welches Dokument welche Entscheidung trägt.
Ein schlanker Aufbau trennt die Aufgaben:
- Das Datenmigrationskonzept hält die projektweiten Grundentscheidungen fest: Ziel, Grenzen, Rollen, technischer Weg, Testlogik und Bedingungen für die produktive Übernahme.
- Das Datenobjektregister führt fachlich zusammengehörige Bestände wie Kunden, Materialien oder offene Aufträge mit Quelle, Umfang, Verantwortlichen, Abhängigkeiten und aktuellem Status.
- Das Mapping beschreibt, wie Bedeutung, Felder, Werte und Beziehungen aus den Quellen in das Zielsystem übersetzt werden.
- Test- und Freigabenachweise zeigen, mit welchem Daten- und Regelstand geprüft wurde, welche Abweichungen bestehen und wer das Ergebnis fachlich bestätigt hat.
- Der Cut-over-Plan steuert später den produktiven Umstellungsablauf rund um den Go-live – mit Reihenfolge, Zeiten, Kontrollen und Stopppunkten.
Diese Inhalte müssen nicht in einer einzigen Datei stehen. Entscheidend ist, dass sie miteinander verbunden sind und nicht widersprüchliche Stände enthalten. Der Fahrplan für die Datenmigration ordnet die Arbeit zeitlich. Das Datenmigrationskonzept legt dagegen fest, nach welchen Regeln und Nachweisen diese Arbeit im konkreten ERP-Projekt erfolgt.
Die Belastungsprobe: ein Datenobjekt von der Quelle bis zur Freigabe durchdenken
Ob ein Konzept arbeitsfähig ist, lässt sich am besten an einem wichtigen Datenobjekt prüfen. Offene Kundenaufträge eignen sich als anschauliches Beispiel, weil dabei nicht nur Auftragsfelder betroffen sind. Kunden, Materialien, Einheiten, Preise, Statuswerte und organisatorische Zuordnungen müssen im Zielsystem zusammenpassen.
Für dieses eine Datenobjekt sollte das Team sieben Sätze konkret vervollständigen können:
- Wir übernehmen … aus dieser maßgeblichen Quelle und schließen … anhand dieser Regel bewusst aus.
- Im Zielsystem wird der Bestand für … benötigt und besitzt dort diese fachliche Bedeutung.
- Quellwerte, Schlüssel und Beziehungen werden nach … übersetzt; diese Zielkonfiguration muss vorher vorhanden sein.
- Über die noch offenen fachlichen Regeln entscheidet …; technisch umgesetzt werden sie durch …
- Der Datenstand lässt sich erneut erzeugen, weil Quelle, Extraktion, Regeln, Programme und Importdateien eindeutig versioniert sind.
- Technisch prüfen wir … und fachlich prüfen wir …; die Freigabe erteilt … für genau diesen Daten- und Regelstand.
- Produktiv übernehmen wir die Daten nur, wenn …; bei diesen Befunden stoppen wir oder wechseln auf die vorbereitete Rückfalloption.
Wo eine Antwort fehlt, wird die tatsächliche Konzeptlücke sichtbar. Das kann ein unklarer Datenumfang sein, ein noch nicht vorbereiteter Zielwert, eine offene Fachentscheidung oder ein nicht wiederholbarer technischer Ablauf. Diese Diagnose ist für die Projektleitung nützlicher als die pauschale Aussage, das Konzept sei „zu 80 Prozent fertig“.
Zuerst entscheiden, wofür die Daten im Zielsystem gebraucht werden
Ein Datenbestand gehört nicht allein deshalb in das neue ERP-System, weil er im alten vorhanden ist. Ausgangspunkt ist seine künftige Verwendung: Welche Geschäftsprozesse müssen unmittelbar nach dem Go-live funktionieren? Welche Informationen werden für offene Vorgänge, gesetzliche Nachweise, Auswertungen oder den Kundenservice benötigt? Und welche Historie kann verlässlich im Altsystem oder in einem Archiv verfügbar bleiben?
Erst daraus entsteht der Datenumfang, häufig auch Scope genannt. Er sollte je Datenobjekt erkennen lassen, welche Gesellschaften, Standorte, Zeiträume, Status und Datensatzgruppen einbezogen werden. Ebenso wichtig sind bewusste Ausschlüsse. „Alle relevanten Daten“ ist keine ausführbare Festlegung, weil weder Relevanz noch Vollständigkeit messbar sind.
Für offene Kundenaufträge könnte die Entscheidung beispielsweise von Auftragsstatus, Lieferstatus, Stichtag und der weiteren Bearbeitbarkeit im Zielsystem abhängen. Damit ist zugleich klarer, welche abhängigen Kunden- und Materialstämme vorher geladen werden müssen. Wie Unternehmen diese Auswahl systematisch treffen können, vertieft der Beitrag Welche Daten gehören beim ERP-Wechsel ins neue System?.
Quelle und Zielbedeutung müssen im Mapping zusammenfinden
Die Angabe „Daten kommen aus dem alten ERP“ reicht selten aus. Dieselbe fachliche Information kann in einem ERP-System, einer Branchenlösung, einer Zusatzdatenbank oder einer gepflegten Tabelle vorkommen. Das Konzept muss deshalb festlegen, welche Quelle für welchen Wert maßgeblich ist und wie der Zugriff technisch erfolgen kann.
Auf der Zielseite reicht eine Importvorlage ebenfalls nicht. Pflichtfelder, Schlüssel, Wertelisten und Objektbeziehungen hängen von der Zielkonfiguration ab. Ist beispielsweise eine Auftragsart noch nicht eingerichtet oder ein alter Status im Ziel nicht vorgesehen, kann das Mapping nicht allein durch eine Feldzuordnung gelöst werden.
Ein belastbares Mapping verbindet daher fünf Dinge:
- die fachliche Bedeutung des Quellwerts,
- die erwartete Bedeutung im Zielsystem,
- die Transformations- oder Zuordnungsregel,
- den Prüfschritt für diese Regel und
- den Verantwortlichen für eine noch offene Entscheidung.
Dadurch wird erkennbar, ob ein Problem in den Quelldaten, in der Regel, in der technischen Umsetzung oder in einer fehlenden Zielkonfiguration liegt. Ohne diese Trennung werden Fehler häufig direkt in einer Importdatei korrigiert. Der nächste Lauf beginnt dann wieder mit demselben Problem, weil die Ursache nicht an einer reproduzierbaren Stelle behoben wurde.
Verantwortung muss bis zur einzelnen Entscheidung reichen
Datenmigration ist Teamarbeit, doch „das Team entscheidet“ ist keine belastbare Regel. Die ERP-Projektleitung steuert Termine und Abhängigkeiten. Fachbereiche beurteilen die geschäftliche Bedeutung und Einsatzfähigkeit der Daten. Die IT stellt Zugänge und Umgebungen bereit. Der ERP-Partner erläutert Anforderungen des Zielsystems und verantwortet seinen vereinbarten Leistungsanteil.
Für kritische Datenobjekte muss zusätzlich feststehen, wer Datenumfang, Mapping-Regeln, akzeptierte Abweichungen und fachliche Freigabe verbindlich bestätigen darf. Mehrere Personen können vorbereiten und prüfen. Eine konkrete Entscheidung braucht trotzdem einen benannten Verantwortlichen und einen Termin.
Wir können als externer Datenmigrationsdienstleister Quellen analysieren, Regeln vorbereiten, Transformationen technisch umsetzen, Testläufe strukturieren und Befunde entscheidungsfähig aufbereiten. Die fachliche Freigabe des Kunden ersetzen wir damit nicht. Diese Grenze schützt beide Seiten: Das Projekt gewinnt Umsetzungskraft, während geschäftliche Entscheidungen dort bleiben, wo ihre Folgen verantwortet werden können.
Prüfkriterien gehören vor die Umsetzung, nicht hinter den ersten Import
Ein importierter Datensatz ist noch kein fachlich brauchbarer Datensatz. Deshalb muss das Konzept vor einem relevanten Test festlegen, was der Lauf beweisen soll und anhand welcher Ergebnisse er bewertet wird.
Technische Kontrollen prüfen beispielsweise Datensatzmengen, Pflichtfelder, Schlüssel, Beziehungen, Protokollfehler und die Anwendung der Transformationsregeln. Fachliche Prüfungen gehen weiter: Ist der offene Auftrag dem richtigen Kunden zugeordnet? Stimmen Mengen, Werte und Einheiten? Kann der Fachbereich den Auftrag im vorgesehenen Prozess weiterbearbeiten? Sind die übernommenen Status fachlich nachvollziehbar?
Die Freigabe muss sich auf einen bekannten Daten- und Regelstand beziehen. Eine grüne Ampel oder eine Erfolgsquote kann den Befund zusammenfassen, aber nicht ersetzen. Benötigt werden die zugrunde liegenden Kontrollen, dokumentierte Abweichungen und eine klare Aussage dazu, welche Restpunkte für den nächsten Schritt akzeptiert wurden.
Für den ersten Durchlauf hilft die ERP-Migration-Checkliste vor dem ersten Testlauf. Ist ein Lauf bereits gescheitert oder fachlich nicht aussagekräftig, zeigt der Beitrag So wird der nächste Testlauf wieder belastbar, wie sich die Ursache vor einer Wiederholung eingrenzen lässt.
Wiederholbarkeit verbindet Konzept und technische Umsetzung
Ein Konzept wird erst dann technisch wirksam, wenn ein Migrationslauf mit einem bekannten Stand erneut erzeugt werden kann. Dazu müssen nicht nur die Importdateien, sondern auch Quellabzug, Auswahlregeln, Mapping, Transformationsskripte, Zielvoraussetzungen und Fehlerkorrekturen nachvollziehbar zusammengehören.
Diese Wiederholbarkeit verändert den Umgang mit Fehlern. Eine Korrektur wird nicht nur in der letzten CSV-Datei vorgenommen. Sie landet dort, wo ihre Ursache behoben werden muss: in der Quelle, in einer freigegebenen Fachregel, in der Transformation oder in der Konfiguration des Zielsystems. Beim nächsten Lauf lässt sich dann prüfen, ob genau diese Änderung gewirkt hat.
Ein Migrationstool kann wichtige Schritte ausführen, aber diese Entscheidungen nicht abnehmen. Das SAP S/4HANA Migration Cockpit unterstützt beispielsweise Migrationsobjekte, Mapping-Aufgaben, Simulation und Migration. SAP weist zugleich darauf hin, dass offene Mapping-Aufgaben bearbeitet und Simulationen nach neuen Befunden wiederholt werden müssen. Auch der Implementierungsleitfaden von Microsoft verbindet Datenmigration mit Quellenanalyse, Scope, Mapping, Transformation, Test, Validierung und Cut-over. Das Werkzeug ist damit Teil der Ausführung; das Datenmigrationskonzept verbindet die fachlichen und organisatorischen Entscheidungen darum herum.
Der Cut-over beginnt als Konzeptentscheidung
Der Cut-over – also der kontrollierte produktive Wechsel rund um den Go-live – wird erst später minutengenau geplant. Seine Grundbedingungen gehören jedoch früh in das Datenmigrationskonzept.
Dazu zählen der Datenstopp, die Behandlung von Änderungen seit dem letzten vollständigen Abzug, die Reihenfolge abhängiger Datenobjekte, notwendige Prüfzeiten, Go-/No-go-Kriterien und real verfügbare Rückfalloptionen. Diese Punkte beeinflussen bereits die technische Architektur. Wer spätere Änderungen nur über einen zusätzlichen Abzug übernehmen kann, braucht dafür andere Regeln und Prüfungen als ein Projekt mit einem vollständigen Datenstopp.
Die konkreten Zeiten dürfen aus Testmigrationen und einer Generalprobe entstehen; reine Schätzungen sind für den Produktivlauf zu unsicher. Wie aus diesen Ergebnissen ein ausführbarer Ablauf wird, beschreibt der ERP-Cutover-Plan für die Datenmigration.
Was muss wirklich entschieden sein, bevor die Umsetzung beginnt?
„Vor der Umsetzung entschieden“ bedeutet nicht, dass jedes Mapping für jedes Datenobjekt endgültig abgeschlossen sein muss. Bei einem iterativen Vorgehen werden Regeln in Testläufen präzisiert. Die Umsetzung darf aber nicht auf unbemerkten Annahmen beruhen.
Für ein priorisiertes Datenobjekt sollten vor dem ersten substanziellen Umsetzungsschritt mindestens feststehen:
- der geschäftliche Zweck im Zielsystem und der einbezogene Datenbestand,
- die maßgeblichen Quellen und der verfügbare technische Zugriff,
- die benötigten Zielobjekte, Pflichtfelder und Konfigurationsvoraussetzungen,
- das Verfahren für Mapping, Transformation, Versionierung und Fehlerkorrektur,
- die Personen, die Regeln entscheiden, Ergebnisse prüfen und freigeben, sowie
- die Kriterien, mit denen ein Testlauf bewertet und der nächste Schritt erlaubt wird.
Ein Detail darf offenbleiben, wenn seine Auswirkung bekannt ist, ein Verantwortlicher und ein Klärungstermin feststehen und klar ist, welchen Schritt es bis dahin blockiert. Kritisch sind dagegen offene Punkte, die sich als scheinbare technische Vorgabe in Skripte oder Dateien einschleichen. Sie werden später schwer sichtbar und erzeugen Wiederholungen, deren Ursache das Projekt kaum noch zuordnen kann.
Wann externe Unterstützung beim Datenmigrationskonzept sinnvoll wird
Externe Unterstützung ist besonders hilfreich, wenn die Informationen im Projekt grundsätzlich vorhanden sind, aber niemand sie zu einer durchgängigen Entscheidungs- und Umsetzungskette verbindet. Dann kennt der Fachbereich die Daten, der ERP-Partner das Zielsystem und die IT die technischen Zugänge – trotzdem bleiben Umfang, Regeln, Tests oder Verantwortlichkeiten zwischen den Beteiligten offen.
Wir können an einem priorisierten Datenobjekt beginnen und daraus den erforderlichen Arbeitsrahmen ableiten: Quellen und Zielanforderungen zusammenführen, offene Entscheidungen sichtbar machen, Mapping und Transformation vorbereiten sowie den nächsten Test mit nachvollziehbaren Prüfschritten aufsetzen. Dadurch entsteht nicht nur ein Konzepttext, sondern ein abgegrenztes Arbeitspaket, dessen Ergebnis geprüft werden kann.
Vor einer Beauftragung sollte deshalb geklärt werden, ob lediglich ein Konzeptdokument erwartet wird oder ob die Unterstützung bis zur technischen Umsetzung, zu Testmigrationen und zur Cut-over-Vorbereitung reichen soll. Der Beitrag Was ein belastbares Angebot für die ERP-Datenmigration regeln muss hilft, diese Leistungsgrenze und die erwarteten Ergebnisse konkret zu prüfen.
Der nächste sinnvolle Schritt ist ein vollständiges Datenobjekt
Beginnen Sie nicht mit der Frage, wie viele Seiten Ihr Datenmigrationskonzept noch braucht. Wählen Sie ein wichtiges Datenobjekt und legen Sie den aktuellen Quellabzug, die Zielanforderungen, das Mapping sowie vorhandene Testbefunde nebeneinander. Vervollständigen Sie anschließend die sieben Sätze aus der Belastungsprobe.
Damit wird schnell sichtbar, ob dem Projekt eine fachliche Entscheidung, ein technischer Zugang, eine Zielvoraussetzung, ein Prüfnachweis oder schlicht Umsetzungskapazität fehlt. Genau diese Lücke bestimmt den nächsten Arbeitsschritt – und schafft eine belastbare Grundlage dafür, interne Aufgaben und externe Unterstützung sinnvoll voneinander abzugrenzen.