ERP-Datenmigration: Was sie kostet und wie sich der Aufwand seriös schätzen lässt

Isometrische Illustration mit vier Aufwandstreibern, Schätzwaage, Referenzobjekt und Testschleife für Datenmigrationskosten

Wenn eine Datenmigration im ERP-Angebot nur mit einer pauschalen Zahl von Beratertagen auftaucht, ist das noch keine belastbare Kalkulation. Denn der Aufwand entsteht nicht allein durch die Menge der Datensätze. Entscheidend ist, wie viele Quellen, Datenobjekte, Beziehungen, Sonderregeln und Prüfschritte zwischen dem Altsystem und einer fachlich abgenommenen Übernahme liegen.

Deshalb gibt es auf die Frage nach den Kosten einer ERP-Datenmigration keine seriöse allgemeine Preisliste. Es gibt aber ein nachvollziehbares Kalkulationsmodell. Damit lässt sich früh erkennen, welche Annahmen bereits belastbar sind, wo zunächst eine Analyse nötig ist und ob zwei Angebote tatsächlich dieselbe Leistung enthalten.

Die kurze Antwort: Vier Aufwandsebenen bestimmen die Kosten

Eine tragfähige Aufwandsschätzung trennt vier Ebenen:

Projektgrundlage + Umsetzung je Datenobjekt + Test- und Korrekturzyklen + Cut-over und Stabilisierung

  • Zur Projektgrundlage gehören unter anderem Scope, Quelleninventar, Zugänge, Rollen, Zielvorgaben und die technische Laufumgebung.
  • Der Objektaufwand umfasst Analyse, Mapping, Transformation, Laden, Dokumentation und objektbezogene Prüfungen beispielsweise für Kunden, Materialien oder offene Aufträge.
  • Die Iterationskosten entstehen durch Testmigrationen, fachliche Rückmeldungen, Korrekturen und erneute Läufe.
  • Der Cut-over-Aufwand umfasst die finale Datenbereitstellung, den Produktivlauf, Freigaben, mögliche Rückfallwege und die erste Stabilisierung.

Zusätzlich entsteht interner Aufwand. Fachbereiche müssen Regeln entscheiden, Zweifelsfälle beurteilen und Ergebnisse abnehmen. Ein externes Angebot kann diese Arbeit stark reduzieren und strukturieren, aber nicht vollständig ersetzen. Wer nur den Rechnungsbetrag des Dienstleisters betrachtet, unterschätzt deshalb häufig die tatsächliche Projektbelastung.

Warum die Zahl der Datensätze kein ausreichender Preismaßstab ist

Eine große, gleichförmige Tabelle kann technisch einfacher zu migrieren sein als ein kleiner Datenbestand mit vielen Beziehungen und Ausnahmen. Eine Million historischer Statistikzeilen lassen sich unter Umständen über eine klare Regel verarbeiten. Zwanzigtausend aktive Artikel können dagegen aufwendiger sein, wenn Varianten, Einheiten, Klassifikationen, Stücklisten, kundenspezifische Felder und unklare Verantwortlichkeiten zusammenkommen.

Für die Kosten zählt daher nicht nur das Datenvolumen, sondern vor allem die Zahl der fachlichen und technischen Entscheidungen. Auch die Wiederholbarkeit spielt eine Rolle: Ein sauber automatisierter Lauf kostet zunächst Aufbauarbeit, senkt aber den Aufwand für spätere Tests und den Produktivlauf. Eine scheinbar günstige manuelle Lösung kann sich umkehren, sobald Daten mehrfach korrigiert und erneut geladen werden müssen.

Diese Kostentreiber gehören in jede Aufwandsschätzung

Kostentreiber Was geklärt werden muss Warum er den Aufwand verändert
Migrationsscope Welche Datenobjekte, Gesellschaften, Standorte und historischen Zeiträume werden übernommen? Jedes zusätzliche Objekt erzeugt eigene Analyse-, Mapping-, Test- und Abnahmearbeit.
Quellsysteme Wie viele Datenbanken, Dateien und Nebensysteme liefern Daten, und wie gut sind sie zugänglich? Mehrere Quellen erhöhen Extraktions-, Zusammenführungs- und Abstimmungsaufwand.
Strukturen und Beziehungen Welche Schlüssel, Hierarchien, Abhängigkeiten, Sonderfelder und Eigenentwicklungen existieren? Komplexe Beziehungen brauchen Reihenfolgen, Transformationsregeln und zusätzliche Prüfungen.
Datenqualität Wo fehlen Pflichtwerte, sind Dubletten vorhanden oder widersprechen sich Fachbereiche? Unklare Daten müssen nicht nur technisch bereinigt, sondern fachlich entschieden werden.
Reife des Zielsystems Sind Zielstrukturen, Pflichtfelder, Nummernkreise und Importvorgaben stabil? Änderungen am Ziel führen zu neuem Mapping, angepassten Transformationen und Wiederholungstests.
Migrationsweg Stehen Standardimporte, APIs, Stagingtabellen oder andere geeignete Werkzeuge bereit? Der technische Weg bestimmt, wie automatisierbar, prüfbar und wiederholbar die Übernahme ist.
Test- und Abnahmetiefe Wie viele Teststände sind vorgesehen, welche Prüfkriterien gelten und wer gibt frei? Jeder Zyklus bindet technische Umsetzung und fachliche Prüfung, reduziert aber das Go-live-Risiko.
Cut-over-Bedingungen Wie lang ist das Ladefenster, welche Daten ändern sich bis zuletzt und welcher Rückfallweg besteht? Kurze Zeitfenster und Delta-Übernahmen erfordern mehr Vorbereitung, Proben und Automatisierung.
Interne Verfügbarkeit Wann können Datenverantwortliche entscheiden, zuliefern und abnehmen? Fehlende Entscheidungen erzeugen Wartezeit, Wiederholungen und teure Arbeit unter Termindruck.

Diese Punkte gehören bereits in ein ausführbares Datenmigrationskonzept. Für die Kalkulation müssen sie noch nicht bis ins letzte Feld entschieden sein. Unklarheiten sollten aber sichtbar und als Annahme, Option oder Risiko bepreist werden – nicht stillschweigend in einer Pauschale verschwinden.

So entsteht aus Unsicherheit eine belastbare Schätzung

1. Einmaligen Projektaufwand getrennt erfassen

Ein Teil der Arbeit fällt unabhängig von der Zahl der Datenobjekte an. Dazu gehören Projektaufnahme, Quellenzugänge, technische Umgebung, übergreifende Regeln, Entscheidungswege, Statusführung und Cut-over-Planung. Dieser Sockel sollte im Angebot separat erkennbar sein. Sonst wird er entweder mehrfach auf Objekte verteilt oder später als Zusatzaufwand sichtbar.

2. Datenobjekte nach Aufwand statt nach Namen gruppieren

„Kunde“ und „Material“ sind keine verlässlichen Aufwandseinheiten. Hinter einem Objektnamen können wenige flache Felder oder zahlreiche Unterobjekte, Beziehungen und Regeln stehen. Sinnvoller ist eine Einteilung nach nachgewiesener Komplexität, beispielsweise:

  • klare Quelle, weitgehend direkte Zuordnung und einfache Prüfung,
  • mehrere Quellen oder relevante Transformationen,
  • komplexe Beziehungen, viele Sonderfälle oder hohe fachliche Kritikalität.

Die Einstufung sollte nicht aus einem Bauchgefühl entstehen. Ein repräsentativer Datenexport, die Zielvorlage und ein erstes Mapping zeigen meist schnell, welche Kategorie realistisch ist.

3. Ein Referenzobjekt bis zum Testlauf bearbeiten

Bei unklarer Ausgangslage ist ein begrenztes Analyse- oder Pilotpaket belastbarer als ein früher Gesamtfestpreis. Dafür wird ein typisches, ausreichend anspruchsvolles Objekt durch die entscheidenden Schritte geführt: Quelle analysieren, Zielanforderungen klären, Mapping aufbauen, Daten transformieren, testweise laden und das Ergebnis prüfen.

Der Zweck ist nicht, aus einem einzigen Objekt blind auf alle anderen hochzurechnen. Der Pilot macht vielmehr sichtbar, welche Arbeitsschritte tatsächlich anfallen, wo technische Grenzen liegen und wie schnell fachliche Entscheidungen getroffen werden können. Danach lassen sich die übrigen Objekte wesentlich besser klassifizieren.

4. Testzyklen ausdrücklich kalkulieren

Eine Testmigration ist selten nur ein technischer Probelauf. Sie erzeugt Erkenntnisse: ein Zielpflichtfeld wurde anders verstanden, eine Transformation greift bei Sonderfällen nicht oder die Fachabnahme verlangt eine zusätzliche Regel. Diese Rückmeldungen sind normaler Bestandteil der Arbeit.

Das Angebot sollte deshalb benennen, wie viele vollständige oder objektbezogene Zyklen enthalten sind, was als Fehlerkorrektur gilt und wann eine fachliche Änderungsanforderung zusätzlichen Aufwand auslöst. Der Fahrplan für die ERP-Datenmigration zeigt, wie solche Iterationen bis zum Go-live zusammenwirken.

Welche Annahmen ein vergleichbares Angebot enthalten muss

Zwei Gesamtpreise sind nur dann vergleichbar, wenn sie auf demselben Leistungsbild beruhen. Mindestens folgende Annahmen sollten schriftlich erkennbar sein:

  • benannte Quellsysteme und verfügbare Zugriffswege,
  • Liste der enthaltenen Datenobjekte und bewussten Ausschlüsse,
  • Umfang von Historie, Bewegungsdaten und offenen Vorgängen,
  • Verantwortung für Extraktion, Bereinigung, Mapping und technische Beladung,
  • enthaltene Testläufe, Korrekturschleifen und Dokumentation,
  • fachliche Prüfkriterien und Zuständigkeit für die Abnahme,
  • Leistungen während Cut-over und Stabilisierung,
  • erforderliche Mitwirkung und Verfügbarkeit des internen Teams.

Fehlt beispielsweise die Datenbereinigung im günstigeren Angebot, ist es nicht automatisch günstiger. Die Arbeit liegt dann möglicherweise beim Kunden oder erscheint später als Nachtrag. Dasselbe gilt für Mapping, Testdaten, Fehlerkorrekturen und die Begleitung des Produktivlaufs. Für die breitere Anbieterauswahl helfen unsere zwölf Fragen zum Vergleich von Datenmigration-Dienstleistern.

Wann ein Festpreis sinnvoll ist – und wann er nur Unsicherheit verdeckt

Ein Festpreis kann für klar abgegrenzte Ergebnisse gut funktionieren. Beispiele sind eine Quellen- und Scope-Analyse, die Bearbeitung eines definierten Referenzobjekts oder ein Objektpaket mit stabilen Quell- und Zielvorgaben. Der Auftraggeber weiß dann, welches Ergebnis er für welchen Preis erhält.

Ein Gesamtfestpreis vor Sichtung der Daten ist dagegen nur dann belastbar, wenn der Anbieter die Risiken tatsächlich bewerten kann. Andernfalls passiert meist eines von drei Dingen: Der Preis enthält einen hohen Sicherheitsaufschlag, wichtige Leistungen werden ausgeschlossen oder spätere Änderungen führen zu Nachträgen.

Eine faire Alternative ist ein gestuftes Vorgehen: zunächst eine begrenzte Analyse mit konkreten Ergebnissen, anschließend eine Schätzung nach Objekt- und Arbeitspaketen. Unsichere Teile werden als Optionen oder Bandbreiten ausgewiesen. So bleibt das Budget steuerbar, ohne eine Genauigkeit vorzutäuschen, die die Datenlage noch nicht hergibt.

Diese Unterlagen verbessern die erste Kostenschätzung

Für eine erste belastbare Einordnung braucht es noch kein fertiges Pflichtenheft. Hilfreich sind:

  • eine Liste der Alt- und Nebensysteme,
  • eine vorläufige Liste der zu migrierenden Datenobjekte,
  • repräsentative Datenexporte ohne unnötige personenbezogene Inhalte,
  • vorhandene Zielvorlagen oder technische Importbeschreibungen,
  • bekannte Datenqualitätsprobleme und Sonderlogiken,
  • geplante Testtermine und der gewünschte Go-live,
  • benannte Ansprechpartner für fachliche Entscheidungen und Abnahmen.

Fehlt davon noch etwas, ist das kein Grund, die Kalkulation aufzuschieben. Es muss lediglich als offene Annahme behandelt werden. Schon die gemeinsame Sichtung zeigt oft, welche Unsicherheit zuerst geschlossen werden sollte und für welche Teile bereits eine belastbare Beauftragung möglich ist.

Von der groben Budgetzahl zum belastbaren Leistungsrahmen

Eine gute Kostenschätzung beantwortet nicht nur „wie viel?“, sondern auch „wofür, unter welchen Voraussetzungen und mit welchem Ergebnis?“. Genau dadurch wird sie für Projektleitung und Einkauf nutzbar. Sie zeigt, welche Arbeit beim Dienstleister liegt, welche Entscheidungen das Unternehmen treffen muss und an welchen Punkten sich der Aufwand noch verändern kann.

Für eine erste Einordnung reichen meist die vorhandenen Quellsysteme, eine grobe Objektliste, der Stand des Zielsystems und der geplante Projekttermin. Daraus lässt sich ableiten, ob direkt ein Arbeitspaket kalkuliert werden kann oder ob zunächst ein begrenzter Scope- und Datencheck die wirtschaftlichere Entscheidung ist.