Der Vertrag für das neue ERP-System ist unterschrieben. Der Implementierungspartner liefert Zielstrukturen, Importvorlagen und einen Terminplan. Erst im Datenworkshop fällt die entscheidende Frage: Wer analysiert das Altsystem, übersetzt fachliche Bedeutungen in Mapping-Regeln, baut wiederholbare Transformationen und bereitet die fachliche Prüfung vor?
Wenn die Antwort darauf „der Kunde“ lautet, ist das nicht automatisch ein Versäumnis des ERP-Anbieters. Es kann schlicht die vereinbarte Leistungsgrenze sein. Problematisch wird es, wenn diese Grenze erst spät sichtbar wird und intern weder ausreichend Zeit noch eine durchgängige Migrationsverantwortung vorhanden ist.
Bei einer ERP-Umstellung geht es deshalb nicht um die pauschale Entscheidung „ERP-Anbieter oder Datenmigrationsspezialist“. Entscheidend ist, ob jedes notwendige Arbeitspaket einen benannten Verantwortlichen, ein prüfbares Ergebnis und realistische Kapazität besitzt.
Die kurze Antwort: Es hängt vom vereinbarten Arbeitspaket ab
Ein ERP-Anbieter kann die Datenmigration vollständig abdecken. Das ist besonders plausibel, wenn wenige, gut verstandene Datenobjekte betroffen sind, standardisierte Exporte vorliegen und Analyse, Mapping, Aufbereitung, Testläufe und Cut-over ausdrücklich zum beauftragten Leistungsumfang gehören.
Ein separater Datenmigrationsspezialist wird dagegen sinnvoll, wenn der ERP-Partner vor allem das Zielsystem, das Importwerkzeug und die Zielvorlagen verantwortet, während die operative Übersetzung aus dem Altsystem beim Kunden bleibt. Das betrifft typischerweise Aufgaben wie:
- Quellsysteme und relevante Datenbestände technisch analysieren,
- fachliche Bedeutungen aus dem Altsystem in Zielregeln übersetzen,
- Daten extrahieren, bereinigen und reproduzierbar transformieren,
- ladefähige Datenpakete für mehrere Testzyklen erzeugen,
- Fehlerursachen zwischen Quelle, Regel, Datei und Zielsystem trennen,
- Prüfungen, Entscheidungen und Freigaben für die Keyuser vorbereiten.
Die richtige Entscheidung lässt sich daher nicht aus der Berufsbezeichnung des Anbieters ableiten. Sie entsteht aus einem Soll-Ist-Vergleich: Welche Ergebnisse braucht das Projekt, welche davon sind bereits vertraglich abgedeckt und wer kann die übrigen Ergebnisse tatsächlich liefern?
Warum Zielsystemkompetenz und Migrationsführung zwei verschiedene Leistungen sind
Der ERP-Anbieter kennt sein System. Er weiß, welche Zielobjekte existieren, welche Felder erforderlich sind, wie die Importmechanismen funktionieren und welche Konfigurationen im neuen System zusammenpassen müssen. Diese Kompetenz ist für die Migration unverzichtbar.
Die Datenrealität des Unternehmens beginnt jedoch auf der anderen Seite: gewachsene Tabellen, kundenspezifische Schlüssel, historische Sonderfälle, unvollständige Dokumentation und fachliche Regeln, die bislang nur in Prozessen oder im Wissen einzelner Mitarbeitender existieren. Zwischen dieser Realität und dem Zielsystem liegt die eigentliche Übersetzungsarbeit.
Eine Importvorlage beschreibt, welches Format das Zielsystem akzeptiert. Sie beantwortet noch nicht, aus welcher Quelle ein Wert stammt, welche Altdaten zusammengeführt werden, wie ein alter Status fachlich zu deuten ist oder welche Ausnahme künftig gelten soll. Auch ein erfolgreich eingelesener Datensatz ist noch kein Nachweis dafür, dass er vollständig und fachlich richtig ist.
Dass Zielsystemberatung und Datenmigrationsarbeit unterschiedliche Rollen sein können, zeigen auch Herstellerunterlagen. SAP führt in seiner Checkliste für ERP-Migrationen den Datenmigrationsexperten und den ERP-Anbieter beziehungsweise -Berater als getrennte Rollen im Migrationsteam auf. In einem konkreten Oracle-Cloud-Leitfaden stellt Oracle Werkzeuge und Dokumentation bereit, während Strategie, Bereinigung, Testläufe, Fehlerbearbeitung und Cut-over auf Kundenseite liegen. Diese Beispiele definieren keinen allgemeinen Vertragsstandard. Sie zeigen aber, warum der konkrete Leistungsumfang geprüft werden muss.
Welche Arbeit ohne klare Zuordnung beim Kunden bleibt
Der Satz „Die Datenmigration ist enthalten“ ist für eine belastbare Planung zu grob. Besser ist eine Liste der erwarteten Ergebnisse. Die folgende Übersicht macht sichtbar, welche Arbeit zwischen Altsystem und Import häufig übersehen wird:
| Arbeitspaket | Prüfbares Ergebnis | Entscheidende Klärung |
|---|---|---|
| Quellanalyse | Inventar der Systeme, Tabellen, Dateien und Datenverantwortlichen | Welche Quelle ist für welches Datenobjekt maßgeblich? |
| Migrationsscope | Abgegrenzte Objekte, Zeiträume, Gesellschaften und Ausschlüsse | Was wird migriert, archiviert oder bewusst nicht übernommen? |
| Mapping | Abgestimmte Zuordnung mit dokumentierten Fachentscheidungen | Wer entscheidet über Bedeutungen, Schlüssel und Ausnahmen? |
| Extraktion und Transformation | Wiederholbare Skripte oder Abläufe für ladefähige Datenpakete | Wer setzt Regeln technisch um und versioniert Änderungen? |
| Testmigration | Reproduzierbarer Lauf mit Protokoll, Befunden und Korrekturen | Wer trennt Quellfehler, Regelprobleme und Importfehler? |
| Validierung | Mengen-, Summen- und Fachprüfungen mit nachvollziehbarer Freigabe | Welche Nachweise braucht der Fachbereich für die Abnahme? |
| Cut-over | Erprobte Reihenfolge mit Laufzeiten, Zuständigkeiten und Entscheidungen | Wer steuert den finalen Datenstand bis zur Produktivfreigabe? |
Fehlt bei einem dieser Ergebnisse ein eindeutiger Verantwortlicher, verschwindet die Aufgabe nicht. Sie wird meist stillschweigend zur Kundenzuarbeit. Dann sollen Keyuser Vorlagen füllen, die IT kurzfristig Exporte bauen und die Projektleitung offene Datenfragen zwischen mehreren Parteien koordinieren.
Drei Organisationsmodelle können funktionieren
Es gibt nicht nur einen richtigen Zuschnitt. Entscheidend ist, dass das gewählte Modell zur Komplexität der Daten und zu den verfügbaren Ressourcen passt.
1. Der ERP-Anbieter übernimmt die Migration durchgängig
Dieses Modell ist schlank, wenn der Anbieter neben Zielsystem und Import auch Quellanalyse, Mapping-Moderation, Transformation, wiederholte Testläufe, Fehlerklärung und Cut-over verbindlich übernimmt. Im Angebot sollten dafür Ergebnisse, Mitwirkungspflichten und Abnahmekriterien erkennbar sein.
Das interne Team bleibt trotzdem für fachliche Entscheidungen und Freigaben erforderlich. Es muss jedoch nicht zusätzlich die technische Migrationsstrecke aufbauen.
2. Ein internes Migrationsteam arbeitet mit dem ERP-Anbieter
Ein erfahrenes internes Team kann die kundenseitige Migration selbst führen. Das ist sinnvoll, wenn Mitarbeitende das Altsystem und seine Datenstrukturen kennen, genügend Zeit für Mapping und Testzyklen besitzen und technische Transformationen reproduzierbar umsetzen können.
Das Risiko liegt weniger im fehlenden Wissen als in der Verfügbarkeit. Werden dieselben Personen gleichzeitig für Tagesgeschäft, Prozessdesign, Systemtest und Datenaufbereitung eingeplant, konkurrieren mehrere kritische Aufgaben um dieselbe Zeit.
3. Ein Datenmigrationsspezialist ergänzt die Kundenseite
In diesem Modell bleibt der ERP-Anbieter für Zielsystem, Importlogik und vereinbarte Systemleistungen zuständig. Der zusätzliche Spezialist führt die operative Übersetzung aus den Quellen: Er strukturiert den Scope, bereitet Mapping-Entscheidungen vor, setzt Transformationen um, organisiert Testläufe und liefert prüfbare Ergebnisse für Fachbereich und Projektleitung.
Das schafft keine Gegenposition zum ERP-Partner. Im Gegenteil: Eine klare Aufgabenteilung kann Rückfragen präziser machen, Importpakete stabilisieren und verhindern, dass technische sowie fachliche Probleme ungeordnet beim Zielsystemteam landen.
So prüfen Sie das Angebot Ihres ERP-Partners
Beginnen Sie nicht mit einer allgemeinen Frage wie „Machen Sie auch die Datenmigration?“. Legen Sie stattdessen die Arbeitspakete nebeneinander und lassen Sie für jedes Ergebnis festhalten:
- Wer liefert die Ausgangsinformationen?
- Wer führt die Arbeit operativ aus?
- Wer entscheidet offene Fachfragen?
- Wer prüft das Ergebnis technisch und fachlich?
- Wie viele Testläufe sind im Leistungsumfang vorgesehen?
- Wie werden Fehlerkorrekturen in den nächsten Lauf übernommen?
- Welche Skripte, Mappings, Protokolle und Dokumentationen werden übergeben?
- Welche Annahmen führen zu zusätzlichem Aufwand?
Eine einfache Matrix mit den Spalten „enthalten“, „Kundenzuarbeit“, „separates Arbeitspaket“ und „noch offen“ reicht dafür aus. Sie ist wertvoller als eine lange Tätigkeitsliste, weil sie die tatsächlichen Übergaben sichtbar macht.
Wenn Sie bereits mehrere Anbieter oder Angebote beurteilen, hilft zusätzlich unser Beitrag Datenmigration-Dienstleister vergleichen: 12 Fragen vor der Beauftragung. Er vertieft die Qualitätskriterien für Vorgehen, Tests, Dokumentation und Übergabe.
Wann ein separater Datenmigrationsspezialist wirtschaftlich sinnvoll wird
Ein zusätzlicher Spezialist erzeugt zunächst eine eigene Kostenposition. Wirtschaftlich relevant ist aber die Frage, welche Arbeit dadurch ersetzt oder früher erledigt wird. Verdeckter Aufwand entsteht beispielsweise, wenn Keyuser Daten manuell in Vorlagen übertragen, technische Fehler selbst sortieren oder dieselbe Bereinigung nach jedem Export erneut durchführen.
Besonders prüfenswert ist externe Unterstützung, wenn mehrere der folgenden Situationen zusammenkommen:
- Das Altsystem ist technisch wenig dokumentiert oder stark angepasst.
- Mehrere Quellen müssen zu einem Zielobjekt zusammengeführt werden.
- Mapping-Fragen bleiben zwischen Fachbereich, IT und ERP-Partner liegen.
- Die Aufbereitung erfolgt manuell und ist nicht zuverlässig wiederholbar.
- Ein erster vollständiger Testlauf fehlt oder erzeugt immer wieder dieselben Fehler.
- Keyuser sollen technische Aufbereitung zusätzlich zum Tagesgeschäft übernehmen.
- Der Go-live steht fest, aber niemand führt den Datenmigrationsumfang durchgängig.
Kein zusätzlicher Spezialist ist nötig, wenn der Scope überschaubar ist, der ERP-Anbieter die Kette nachweislich durchgängig abdeckt und das interne Team ausreichend Kapazität für seine Entscheidungen und Prüfungen besitzt. Externe Unterstützung sollte eine echte Lücke schließen und nicht bloß eine weitere Abstimmungsebene schaffen.
Für die finanzielle Einordnung sollten Angebote deshalb nicht nur nach Tagessätzen verglichen werden. Unser Beitrag zu den Kosten einer ERP-Datenmigration zeigt, welche Umfangs- und Komplexitätstreiber eine seriöse Schätzung berücksichtigen muss.
Wie wir die Zusammenarbeit mit dem ERP-Anbieter aufsetzen
Berthelsen Datenmigration positioniert sich nicht als Ersatz für die Zielsystemkompetenz des ERP-Partners. Wir übernehmen klar abgegrenzte Arbeitspakete dort, wo die kundenseitige Datenmigration Struktur, technische Umsetzung oder zusätzliche Kapazität benötigt.
Ein möglicher Zuschnitt sieht so aus:
- ERP-Anbieter: Zielobjekte, Systemlogik, Importverfahren, Konfiguration und zielsystemseitige Fehlerklärung.
- Unternehmen: Scope-Entscheidungen, Fachlogik, Prioritäten, Datenverantwortung und fachliche Freigaben.
- Berthelsen Datenmigration: Quellanalyse, Mapping-Vorbereitung, Extraktion, Transformation, Testpakete, Fehleranalyse, Prüfnachweise und operative Migrationssteuerung.
Die genaue Grenze wird projektbezogen vereinbart. Wichtig ist, dass eine offene Frage nicht zwischen den Rollen pendelt, sondern einem Ergebnis und einem nächsten Bearbeitungsschritt zugeordnet wird. Ein belastbares Datenmigrationskonzept hält diese Zuständigkeiten zusammen mit Scope, Regeln, Tests und Freigaben fest.
Die nächste sinnvolle Entscheidung vor der Beauftragung
Nehmen Sie die Leistungsbeschreibung Ihres ERP-Partners und markieren Sie für jedes Datenobjekt, wer Quelle, Mapping, Transformation, Testkorrektur, Prüfung und Cut-over übernimmt. Prüfen Sie anschließend nicht nur, ob ein Name eingetragen ist, sondern ob diese Rolle über die nötige Zeit, Zugänge und technische beziehungsweise fachliche Kompetenz verfügt.
Bleiben dabei Lücken, sollte nicht sofort ein umfangreiches Zusatzprojekt beauftragt werden. Oft lässt sich zunächst ein klar begrenztes Arbeitspaket definieren: etwa die Analyse eines kritischen Datenobjekts, ein belastbarer Mapping-Stand oder ein erster reproduzierbarer Testlauf.
Für eine fundierte Ersteinschätzung genügen in der Regel die vorhandene Leistungsbeschreibung, eine grobe Objektliste, bereitgestellte Importvorlagen und der aktuelle Stand der Testmigration. Daraus lässt sich ableiten, ob lediglich gezielte technische Unterstützung fehlt oder ob die kundenseitige Datenmigration eine eigene Führung benötigt.