Die Datenmigration beim ERP-Wechsel beginnt häufig mit einem Satz wie: „Wir übernehmen alle relevanten Daten.“ Für eine Aufwandsschätzung, ein Mapping oder einen Testlauf ist das jedoch noch kein belastbarer Scope. Es bleibt offen, was „relevant“ bedeutet, wer darüber entscheidet und wie mit Daten umgegangen wird, die zwar weiterhin erreichbar sein müssen, aber nicht im operativen Zielsystem benötigt werden.
Die Gegenposition „Wir nehmen einfach alles mit“ ist ebenfalls keine sichere Abkürzung. Sie verlagert Dubletten, veraltete Stammsätze, unklare Historie und unnötige Datenmengen in das neue ERP. Umgekehrt kann ein zu knapp gewählter Umfang offene Vorgänge, Referenzen oder benötigte Auskünfte abschneiden.
Ein guter Migrationsscope entscheidet deshalb nicht pauschal zwischen alles und nichts. Er legt für jeden fachlichen Datenbestand fest, was direkt migriert, vor der Übernahme bereinigt, außerhalb des neuen ERP zugänglich gehalten oder bewusst nicht übernommen wird. Dieser Beitrag zeigt ein Entscheidungsmodell, mit dem ERP-Projektleitung und Fachbereiche diese Grenze nachvollziehbar ziehen können.
Die kurze Antwort: Jeder Datenbestand braucht einen von vier Zielwegen
Die Frage „Welche Daten migrieren wir?“ wird handhabbar, wenn jeder abgegrenzte Bestand einem Zielweg zugeordnet wird:
| Zielweg | Wann er passt | Was vor der Umsetzung feststehen muss |
|---|---|---|
| Direkt migrieren | Die Daten werden für einen Prozess im neuen ERP benötigt, sind fachlich verwendbar und können im Ziel korrekt abgebildet werden. | Auswahlregel, Zielobjekt, Beziehungen, Mapping und Abnahmekriterium |
| Bereinigen und dann migrieren | Der Bestand wird im Ziel benötigt, enthält aber beispielsweise Dubletten, fehlende Pflichtwerte, veraltete Schlüssel oder widersprüchliche Zuordnungen. | Bereinigungsregel, verantwortlicher Fachbereich, Ort der Korrektur und Wiederholbarkeit |
| Außerhalb des Zielsystems zugänglich halten | Die Daten werden nicht für laufende Zielprozesse gebraucht, müssen aber weiterhin gezielt gefunden, ausgewertet oder nachgewiesen werden können. | Zugriffsweg, Suchbarkeit, Berechtigungen, Verantwortlichkeit und Dauer der Verfügbarkeit |
| Nicht übernehmen | Es besteht weder ein operativer Bedarf noch ein bestätigter Zugriffs- oder Aufbewahrungszweck. | Dokumentierter Ausschluss und Freigabe durch die fachlich sowie gegebenenfalls rechtlich Verantwortlichen |
„Nicht übernehmen“ bedeutet zunächst nur: Der Bestand liegt außerhalb des Migrationsumfangs. Ob und wann Daten im Altsystem gelöscht werden dürfen, ist eine eigene Entscheidung. Ebenso ist „Archiv“ kein Synonym für einen ungeordneten Dateiablageplatz. Wenn Informationen später benötigt werden, muss der vorgesehene Zugriff praktisch funktionieren.
Der Go-live-Prozess entscheidet – nicht das Alter eines Datensatzes
Die Auswahl sollte bei den Geschäftsprozessen beginnen, die am ersten Tag im neuen ERP arbeitsfähig sein müssen. Erst danach wird auf Tabellen, Dateien und Zeiträume zurückgegangen. Für jeden Prozess lässt sich fragen:
- Welche Stammdaten müssen vorhanden sein, damit der Vorgang angelegt oder fortgeführt werden kann?
- Welche offenen Vorgänge, Bestände oder Salden müssen im neuen System weiterbearbeitet werden?
- Welche Referenz- und Steuerungsdaten braucht das Ziel, damit diese Datensätze gültig sind?
- Welche abgeschlossenen Informationen müssen Anwender weiterhin nachschlagen können, ohne dass sie operativ migriert werden?
Diese Reihenfolge verhindert zwei typische Fehler. Zum einen werden Tabellen nicht nur deshalb vollständig übernommen, weil sie technisch leicht exportierbar sind. Zum anderen geraten abhängige Daten nicht aus dem Blick. Ein Kundenstamm kann beispielsweise korrekt geladen sein und trotzdem unbrauchbar bleiben, wenn benötigte Zahlungsbedingungen, Vertriebsbereiche oder Ansprechpartner fehlen.
Auch Herstellerleitfäden trennen Sichtbarkeit und operative Speicherung. Microsoft empfiehlt bei nicht migrierten Daten, ihren Wert gegen Qualität, Volumen, Zeit und Migrationskosten abzuwägen und bei Bedarf einen anderen Zugriff bereitzustellen. Die konkrete Lösung hängt vom Zielsystem und den Anforderungen des Unternehmens ab. Der übertragbare Grundsatz lautet: Nicht alles, was erreichbar bleiben muss, muss im operativen ERP-Datenmodell liegen.
Sechs Datenarten brauchen unterschiedliche Auswahlregeln
Eine einzige Regel wie „die letzten drei Jahre“ wird den verschiedenen Datenarten nicht gerecht. Für einen ersten Scope sollten mindestens diese Gruppen getrennt betrachtet werden:
| Datenart | Typische Beispiele | Leitende Scope-Frage |
|---|---|---|
| Stammdaten | Kunden, Lieferanten, Materialien, Konten, Ansprechpartner | Welche Datensätze werden in zukünftigen Prozessen benötigt, und welche abhängigen Sichten oder Rollen gehören dazu? |
| Offene Bewegungsdaten | Aufträge, Bestellungen, Fertigungsaufträge, offene Posten | Welche Vorgänge müssen im neuen ERP weiterbearbeitet werden, und an welchem Prozessstand werden sie übernommen? |
| Bestände und Eröffnungswerte | Lagerbestand, Kontensalden, laufende Mengen und Werte | Welcher Stichtag gilt, wie wird abgegrenzt und wodurch wird der Wert zwischen Quelle und Ziel abgestimmt? |
| Referenz- und Steuerungsdaten | Einheiten, Zahlungsbedingungen, Wertelisten, Organisationseinheiten | Werden sie migriert, im Ziel konfiguriert oder aus einer anderen maßgeblichen Quelle bereitgestellt? |
| Abgeschlossene Historie | Erledigte Aufträge, alte Buchungen, frühere Bewegungen und Auswertungsbestände | Muss die Historie operativ im neuen ERP vorliegen, oder genügt ein verlässlicher Lese- und Auskunftsweg? |
| Dokumente und Anhänge | Belege, Zeichnungen, Zertifikate, Korrespondenz und verknüpfte Dateien | Welche Dokumente werden künftig in welchem Prozess gebraucht, und wie bleiben ihre Beziehungen und Berechtigungen erhalten? |
Diese Gruppen sind keine universelle Importliste. Das Zielsystem kann einzelne Inhalte als Konfiguration behandeln, für bestimmte Bewegungsdaten Standardobjekte anbieten oder historische Übernahmen technisch begrenzen. Der Scope muss daher fachliche Notwendigkeit und tatsächliche Zielmöglichkeit zusammenführen.
Mit sechs Fragen wird ein Datenobjekt entscheidungsfähig
Für jedes priorisierte Datenobjekt sollte das Projekt dieselben sechs Fragen beantworten. Erst ihre Kombination ergibt eine belastbare Auswahlregel:
- Welcher Zielprozess benötigt die Daten? Ohne benannten Verwendungszweck lässt sich weder Relevanz noch Vollständigkeit prüfen.
- Welche Teilmenge ist dafür erforderlich? Möglich sind Status, Organisationseinheit, Gültigkeit, Zeitfenster, offene Menge oder eine Kombination mehrerer Merkmale.
- Welche Beziehungen müssen mitkommen? Schlüssel, übergeordnete Objekte, Wertelisten und abhängige Datensätze bestimmen, ob der Bestand im Ziel nutzbar ist.
- Kann das Ziel die Information fachlich korrekt abbilden? Ein Quellfeld ist nicht automatisch ein Zielfeld. Manchmal braucht es Transformation, Zusammenführung oder einen anderen Zugriffsweg.
- Ist die Datenqualität für den Zielzweck ausreichend? Falls nicht, muss feststehen, welche Fehler vor der Übernahme behoben werden und wer Zweifelsfälle entscheidet.
- Woran wird die richtige Auswahl erkannt? Erwartete Mengen, Summen, Referenzen, Stichproben und Geschäftsvorgänge machen aus einer Absicht eine prüfbare Scope-Regel.
Die Antwort „alle aktiven Datensätze“ genügt dabei selten. Aktivität kann im Quellsystem eine technische Kennzeichnung, eine letzte Bewegung oder eine fachliche Einschätzung bedeuten. Eine ausführbare Regel nennt das konkrete Feld beziehungsweise Kriterium, den Bezugszeitpunkt und den Umgang mit Ausnahmen.
Vier Beispiele zeigen, warum pauschale Regeln scheitern
Kundenstammdaten: „Aktiv“ ist keine vollständige Definition
Ein Kunde ohne Umsatz in den letzten zwölf Monaten kann trotzdem für einen offenen Posten, eine laufende Reklamation oder einen Servicefall benötigt werden. Umgekehrt kann ein formal aktiver Stammsatz eine Dublette sein. Eine tragfähige Auswahl kombiniert deshalb mehrere Kriterien, etwa offene Vorgänge, bestätigte zukünftige Nutzung, gültige Organisationseinheiten und fachlich freigegebene Ausschlüsse.
Zusätzlich ist festzulegen, welche abhängigen Informationen dazugehören: Adressen, Rollen, Ansprechpartner, Zahlungsbedingungen oder steuernde Merkmale. Erst danach lässt sich prüfen, ob der Kunde im Ziel nicht nur vorhanden, sondern verwendbar ist.
Materialstamm: Seltene Nutzung kann trotzdem kritisch sein
Ein Material ohne jüngere Bewegung ist nicht automatisch entbehrlich. Es kann Bestandteil einer Stückliste, Ersatzteil für ein langfristig betreutes Produkt oder Referenz in einem offenen Auftrag sein. Die Entscheidung sollte deshalb sowohl direkte Nutzung als auch Beziehungen zu anderen migrierten Objekten berücksichtigen.
Bei Varianten, Einheiten und Klassifikationen entsteht die eigentliche Komplexität häufig nicht durch die Anzahl der Materialien, sondern durch die Zielregeln. Eine bloße Datumsgrenze erkennt diese Abhängigkeiten nicht.
Offene Vorgänge: Status allein sagt nicht, ob sie übernehmbar sind
Bei offenen Aufträgen oder Bestellungen muss das Projekt entscheiden, ob sie im neuen ERP fortgeführt, im Altsystem abgeschlossen oder kontrolliert neu angelegt werden. Dafür zählen Prozessstand, Restmengen, Bezüge zu Lieferung und Rechnung, abhängige Stammdaten sowie der Stichtag des Cut-overs.
Eine technische Übernahme ist nur sinnvoll, wenn das Ziel den aktuellen Zustand korrekt darstellen und weiterverarbeiten kann. Andernfalls kann ein begrenztes Übergangsverfahren die sicherere Lösung sein. Diese Entscheidung gehört in den Scope, nicht erst in die Nacht des Produktivwechsels.
Abgeschlossene Historie: Zugriff ist nicht gleich Migration
Historische Vorgänge werden häufig für Auskünfte, Analysen oder Nachweise benötigt. Daraus folgt aber nicht automatisch, dass jede alte Transaktion im neuen ERP rekonstruiert werden muss. Zu klären ist, wer welche Information wie schnell benötigt, ob Originalbelege oder verdichtete Auswertungen genügen und wie der Zugriff nach Abschaltung des Altsystems funktioniert.
Je nach Zielsystem können historische Daten über ein Archiv, eine Berichtslösung, einen lesenden Altzugang oder einen gesonderten Datenbestand bereitgestellt werden. Aufbewahrungs-, Lösch- und Zugriffsanforderungen müssen dabei von den zuständigen Fach-, Datenschutz-, Steuer- oder Rechtsverantwortlichen bestätigt werden.
Warum ein Stichtag allein keinen Migrationsscope ergibt
Zeit ist ein nützliches Filtermerkmal, aber selten die alleinige fachliche Regel. Ein pauschaler Schnitt kann drei Arten von Fehlern erzeugen:
- Zu viel: Alle Datensätze eines Zeitraums werden übernommen, obwohl ein großer Teil abgeschlossen und im Ziel ohne operativen Nutzen ist.
- Zu wenig: Ältere Stammdaten oder Vorgänge fehlen, obwohl sie noch Beziehungen zu offenen Prozessen besitzen.
- Inkonsistenz: Ein Hauptobjekt liegt im Scope, benötigte Unterobjekte oder Referenzen fallen aber durch eine andere Datumsregel heraus.
Der Stichtag sollte deshalb erst angewendet werden, nachdem der Verwendungszweck und die Abhängigkeiten feststehen. Bei offenen Vorgängen ist der Status möglicherweise wichtiger als das Anlagedatum. Bei Stammdaten kann die tatsächliche Nutzung zählen. Bei Historie bestimmt der benötigte Auskunftsweg, welche Granularität bereitgestellt werden muss.
Ein Datenobjektblatt macht den Scope kalkulierbar
Die Entscheidungen müssen nicht in einem umfangreichen Konzeptdokument verborgen werden. Ein schlankes Datenobjektblatt oder Register reicht, wenn es je Objekt die entscheidenden Angaben enthält:
| Feld | Beispielhafte Aussage |
|---|---|
| Datenobjekt und Zweck | Kundenstamm für Auftragserfassung, offene Posten und Serviceauskunft |
| Quelle und maßgeblicher Stand | Benanntes Quellsystem, Extraktionszeitpunkt und verantwortlicher Datenbestand |
| Positive Auswahlregel | Konkrete Status-, Nutzungs-, Organisations- und Beziehungsmerkmale |
| Bewusste Ausschlüsse | Abgegrenzte Datensatzgruppen mit Grund und Freigabe |
| Zielweg | Direkte Migration, Migration nach Bereinigung, externer Zugriff oder keine Übernahme |
| Abhängigkeiten | Benötigte Referenzdaten, übergeordnete Objekte und Ladefolge |
| Offene Entscheidung | Konkrete Frage, Auswirkung, Entscheider und Termin |
| Prüfung und Abnahme | Mengen, Summen, Schlüssel, Stichproben, Prozessprüfung und Freigabestelle |
Dieses Register verbindet fachliche Entscheidung, technische Umsetzung und kaufmännische Planung. Der Dienstleister erkennt, welche Teilmengen analysiert und verarbeitet werden müssen. Der Fachbereich sieht, welche Regel er bestätigen soll. Die Projektleitung kann offene Punkte mit Termin und Auswirkung steuern.
Im Datenmigrationskonzept für ERP-Projekte wird dieses Objektregister mit Rollen, Mapping, Teststrategie und Cut-over-Regeln verbunden. Der Scope ist damit kein isoliertes Excel, sondern eine ausführbare Grundlage für die weitere Migration.
Diese vier Abhängigkeiten werden beim Scope häufig übersehen
1. Referenzen zwischen Datenobjekten
Ein Datensatz kann nur dann korrekt genutzt werden, wenn seine fachlichen Beziehungen im Ziel bestehen. Die Auswahl muss daher objektübergreifend geprüft werden: Haben alle offenen Aufträge gültige Kunden und Materialien? Sind Wertelisten und Organisationseinheiten vorhanden? Bleiben Dokumentverknüpfungen erhalten?
2. Abstimmung von Mengen und Werten
Bestände, Salden und offene Mengen brauchen einen gemeinsamen Bezugszeitpunkt. Wenn verschiedene Quellen zu unterschiedlichen Zeiten extrahiert werden, kann jede Datei für sich korrekt und das Gesamtergebnis trotzdem widersprüchlich sein. Scope und Cut-over müssen deshalb dieselbe zeitliche Abgrenzung verwenden.
3. Änderungen zwischen Test und Go-live
Das Altsystem bleibt während der Vorbereitung meist in Benutzung. Der Scope muss festlegen, welche seit dem letzten Lauf geänderten oder neu angelegten Daten im Produktivlauf zusätzlich berücksichtigt werden. Ohne diese Delta-Regel ist ein erfolgreicher Test noch kein Beleg für einen vollständigen Go-live-Bestand.
4. Zugriff nach der Ablösung des Altsystems
Wer Historie außerhalb des neuen ERP belässt, braucht einen realen Betriebsweg. Dazu gehören auffindbare Inhalte, Berechtigungen, technische Verantwortung, Sicherung und ein Verfahren für Auskünfte. Eine ungeprüfte Annahme, das alte System werde „irgendwie lesbar bleiben“, verschiebt das Risiko lediglich hinter den Go-live.
Der Migrationsscope bestimmt Aufwand und Vergleichbarkeit von Angeboten
Für einen Datenmigrationsdienstleister ist „Kunden, Lieferanten, Artikel und Bewegungsdaten übernehmen“ keine ausreichend kalkulierbare Leistungsbeschreibung. Der Aufwand ändert sich wesentlich mit Teilmengen, Quellen, Historie, Beziehungen, Datenqualität, Zielwegen und Abnahmetiefe.
Eine belastbare Anfrage sollte daher mindestens enthalten:
- die priorisierten Datenobjekte und bekannten Quellen,
- den aktuellen Stand der positiven Auswahlregeln und Ausschlüsse,
- die gewünschte Behandlung von Historie und Dokumenten,
- bekannte Qualitätsprobleme und fachliche Entscheider,
- den Reifegrad des Zielsystems und verfügbare Importvorgaben sowie
- den nächsten Test- oder Go-live-Termin.
Noch offene Entscheidungen sind zulässig, wenn sie sichtbar bleiben. Sie können als begrenzte Analyse, Option oder Annahme in das Angebot eingehen. Unsere Einordnung zu den Kosten einer ERP-Datenmigration zeigt, warum gerade Scope, Objektkomplexität und Testzyklen die Schätzung beeinflussen. Für die Beauftragung helfen außerdem die zwölf Fragen zum Vergleich von Datenmigration-Dienstleistern.
Wann der Scope für die Datenmigration beim ERP-Wechsel entschieden werden muss
Der erste belastbare Scope gehört vor die detaillierte technische Umsetzung. Das Fachbuch „Erfolgreiche ERP-Projekte“ ordnet Festlegungen zum Umgang mit Bewegungsdaten bereits in das Einführungskonzept ein und warnt davor, Datenübernahme und andere Implementierungsarbeiten vor dessen Genehmigung zu starten: Spätere Änderungen können sonst dazu führen, dass Arbeit mehrfach ausgeführt werden muss.
Das bedeutet nicht, den Scope einmal festzuschreiben und neue Erkenntnisse zu ignorieren. Testmigrationen werden Ausnahmen, unbekannte Beziehungen und Qualitätsprobleme sichtbar machen. Jede Änderung sollte jedoch nachvollziehbar aus einem Befund entstehen, fachlich entschieden und in Auswahlregel, Umsetzung sowie Prüferwartung übernommen werden.
Ein guter Zeitpunkt für die erste verbindliche Fassung ist erreicht, wenn die Go-live-Prozesse, priorisierten Datenobjekte, Zielwege und Entscheidungsverantwortlichen benannt sind. Danach kann das Mapping in die Tiefe gehen. Vor jedem vollständigen Test wird geprüft, ob der Scope-Stand noch zu Quelle, Ziel und Projekttermin passt.
Mit welchem Datenbestand soll Ihr neues ERP am ersten Tag arbeiten?
Der beste Migrationsscope ist weder der größte noch der kleinste. Er ist derjenige, der die vorgesehenen Geschäftsprozesse mit verlässlichen Daten arbeitsfähig macht und für alle übrigen Informationen einen bewusst entschiedenen Weg vorsieht.
Für eine erste externe Einordnung der Datenmigration beim ERP-Wechsel reichen meist ein Quellenüberblick, die wichtigsten Datenobjekte, repräsentative Exporte und der nächste Projektmeilenstein. Daraus lässt sich erkennen, welche Auswahlregeln bereits tragfähig sind, wo Beziehungen oder Historie den Umfang verändern und welches abgegrenzte Analyse- oder Umsetzungspaket als Nächstes sinnvoll ist.