Die Datenmigration ist in jedem ERP-Programm, das ich geleitet habe, der am häufigsten unterschätzte Workstream. Der Anbieter plant drei Monate Datenarbeit ein. In der Realität sind es sechs bis neun. Zum Cutover kämpft das halbe Team mit Dubletten, und der Lenkungsausschuss fragt, warum das niemand früher gemeldet hat.
Ich habe diesen Rechner gebaut, um dieses Gespräch um einige Monate nach vorn zu ziehen. Er bemisst die Arbeit nach Datenobjekt, nach Volumen und nach Ziel-ERP und liefert eine Schätzung in Personentagen, eine Kostenspanne und einen empfohlenen Migrationsansatz. Er ist herstellerneutral und deckt SAP S/4HANA, SAP ECC, Oracle Fusion Cloud, Oracle E-Business Suite sowie Microsoft Dynamics 365 und AX ab.
Das Ergebnis ist eine Spanne und kein Einzelwert, denn die Wahrheit ist eine Spanne. Die Größen, die die Zahl am stärksten verschieben, sind die Datenqualität, die Zahl der Quellsysteme und die Menge an Historie, die Sie übernehmen.
Wählen Sie Ihr Ziel-ERP. Fügen Sie die Datenobjekte im Scope hinzu und die Datenmengen, die Sie für jedes erwarten. Stufen Sie die Datenqualität ehrlich ein. Der Rechner liefert den Aufwand je Objekt, eine Gesamtspanne in Personentagen, eine Kostenspanne und einen empfohlenen Ansatz (Migration Cockpit, LSMW, individuelle ETL oder Hybrid).
Alles läuft in Ihrem Browser. Nichts wird irgendwohin gesendet. Nichts wird gespeichert. Passen Sie die Eingaben so oft an, wie Sie möchten, um das Ergebnis an Ihren eigenen Annahmen auf die Probe zu stellen.
- Kundenstamm: Auftraggeber, Warenempfänger, Regulierer, Rechnungsempfänger, Partnerfunktionen
- Lieferantenstamm: Lieferantensätze, Zahlungsbedingungen, Quellensteuer, Bankverbindungen
- Materialstamm: Grunddaten, Werksansichten, Vertriebssichten, Disposition, Buchhaltung und Kalkulation
- Sachkonten und Kontenplan: primäre und sekundäre Kosten, Hierarchien
- Kostenstellen, Profit-Center, Innenaufträge: Stammdaten des Controllings
- Offene Bestellungen: Kopf, Positionen, Einteilungen, Kontierungen
- Offene Kundenaufträge: Kopf, Positionen, Konditionen, Partnerdaten
- Offene Rechnungen (Kreditoren und Debitoren): offene Posten mit Zuordnungen und Ausgleichsregeln
- Lagerbestände: nach Lagerort, Charge, Sonderbestand
- Historische Finanzbuchungen: Buchungen, Salden, Saldovortrag zum Jahresende
- Anlagenstamm und Abschreibungshistorie: nach Anlagenklasse und Bewertungsbereich
- HR-Stammdaten: Mitarbeitende, Organisationseinheiten, Planstellen, sofern SuccessFactors oder HCM im Scope ist
Angaben zu Ihrer Migration
Mit * markierte Felder sind Pflichtfelder.
Das Muster ist immer dasselbe. Die Analysephase findet in Workshops statt, mit den Systemverantwortlichen am Tisch. Sie sagen Ihnen, die Daten seien „im Großen und Ganzen sauber“. Auf dieser Aussage wird die Schätzung aufgebaut. Niemand führt eine einzige Profiling-Abfrage aus, bevor die Zahl im Business Case landet.
Ein Fertigungskunde sagte mir, seine Teilenummern seien standardisiert. Wir zogen die Daten und fanden 12 verschiedene Formate im aktiven Gebrauch. In einem anderen Programm erwies sich das führende System für Kundennotizen als ein kundeneigenes Feld, das niemand dokumentiert hatte, und drei Jahre Historie gingen verloren, weil das Mapping es übersehen hatte. Bei einer Finanzmigration war die einzige Person, die den alten Kontenplan verstand, fünf Jahre zuvor in den Ruhestand gegangen.
Teuer wird es, wenn man diese Probleme erst bei der Cutover-Probe findet statt in der Planung. Eine Korrektur der Datenqualität, die in der zweiten Woche der Analysephase auffällt, kostet Tage. Dieselbe Korrektur, die erst im dritten Mock-Cutover auffällt, kostet das Programm Wochen, manchmal ein Quartal. Dann sind die Termine öffentlich, das Change-Netzwerk ist mobilisiert, und einen Go-live zu verschieben ist ein Thema für den Vorstand.
Richtig ist, die Daten zu profilieren, bevor die Schätzung unterschrieben wird. Führen Sie echte Abfragen gegen die Quelle aus. Zählen Sie Dubletten. Zählen Sie Nullwerte. Zählen Sie Datensätze, die die Pflichtfeldregeln Ihres Zielsystems heute verletzen. Der Rechner setzt voraus, dass Sie das tun. Die Kostenspanne wird deutlich breiter, wenn Sie die Datenqualität ehrlich einstufen.
Der richtige Ansatz hängt vom Ziel-ERP, von den Datenmengen und davon ab, wie viele Quellsysteme Sie konsolidieren müssen. Unten sehen Sie grob, wonach ich greife, mit dem Aufwand relativ zur einfachsten Option.
| Ansatz | Geeignet für | Aufwandsfaktor | Tools |
|---|---|---|---|
| SAP Migration Cockpit (LTMC / LTMOM) | Greenfield S/4HANA, Standardobjekte, mittlere Datenmengen | 1,0× | LTMC, LTMOM, von SAP ausgelieferte Vorlagen |
| LSMW | ECC, Altmigrationen, Programme auf älteren Releases | 1,2× | LSMW, aufgezeichnete BDC-Sessions |
| Individuelle ETL über SAP BTP / Integration Suite | Große Datenmengen, komplexe Transformationen, Konsolidierung mehrerer Quellen | 2,0× | BTP, CPI, SAP Data Services, Syniti, SNP |
| Hybrid (Cockpit + ETL) | Brownfield-S/4HANA-Konvertierungen und selektive Migrationen | 1,5× | Cockpit für Stammdaten, ETL für Bewegungsdatenhistorie |
| Oracle-nativ | Oracle-Fusion-Cloud- und EBS-Ziele | 1,3× | FBDI, ADFdi, Oracle GoldenGate |
| Dynamics Data Management Framework | Dynamics-365-F&O- und AX-Ziele | 1,3× | DMF-Entitäten, Azure Data Factory |
Eine individuell entwickelte ETL-Strecke ist die flexibelste und die teuerste Variante. Der ehrliche Test, ob Sie sie brauchen: Verletzen Ihre Quelldaten die Standardregeln des Zielsystems auf eine Weise, die keine Vorlage ohne Logik pro Datensatz beheben kann? Lautet die Antwort Nein, bleiben Sie bei den ausgelieferten Tools.
- SAP S/4HANA (Greenfield, Brownfield, selektiv)
- SAP ECC (weiterhin relevant für parallele Landschaften und späte Migrationen)
- Oracle Fusion Cloud ERP
- Oracle E-Business Suite (R12)
- Microsoft Dynamics 365 Finance and Operations
- Microsoft Dynamics AX (2009, 2012)
- Programmleiter, die den Daten-Workstream dimensionieren, bevor der SI eine Zahl zusagt.
- Leiter der Datenmigration, die ihre interne Schätzung an einer unabhängigen Basis auf die Probe stellen.
- CIOs und CFOs, die die Datenposition in einem Implementierungsbudget von mehreren Millionen Dollar plausibilisieren.
- Unabhängige Berater, die belastbare Zahlen für Angebote oder Assurance-Reviews brauchen.
- Interne ERP-Teams, die den Business Case aufbauen, ohne ein separates Scoping-Mandat zu bezahlen.
- Eine belastbare Zahl, schnell. Schätzung in Personentagen je Objekt statt einer einzelnen Vermutung.
- Herstellerneutral. Aufgebaut auf Mustern aus SAP-, Oracle- und Microsoft-Programmen, nicht auf dem Playbook eines einzelnen Herstellers.
- Empfehlung für den Ansatz. Zeigt, ob Migration Cockpit, LSMW, individuelle ETL oder ein Hybrid der richtige Ausgangspunkt ist.
- Berücksichtigt Volumen und Qualität. Die Kostenspanne wird breiter, wenn die Datenqualität sinkt, so wie bei echten Programmen.
- Kostenlos, nur im Browser, ohne Anmeldung. Nichts verlässt Ihr Gerät. Laden Sie neu und beginnen Sie so oft von vorn, wie Sie möchten.
Wie genau sind die Schätzungen zur Datenmigration, die dieses Tool liefert?
Die Zahlen spiegeln die Muster wider, die ich in den letzten 25 Jahren in SAP-, Oracle- und Dynamics-Programmen gesehen habe. Sie sollen ein Planungsgespräch verankern, nicht ein Profiling Ihrer tatsächlichen Daten ersetzen.
Der größte Hebel für die Genauigkeit ist, ob Sie Profiling-Abfragen gegen die Quelle ausgeführt haben. Eine Kostenspanne auf Basis einer ehrlichen Einstufung der Datenqualität hält stand. Eine Kostenspanne auf Basis von Workshop-Optimismus nicht. Nutzen Sie das Ergebnis des Rechners als Basiszahl für das Gespräch mit Ihrem SI. Liegt dessen Schätzung deutlich darunter, fragen Sie, welche Annahme zur Datenqualität er trifft und wie er sie validiert hat.
Sollte ich historische Finanzbuchungen migrieren oder nur offene Posten?
Für die meisten Programme lautet die richtige Antwort: offene Posten plus Eröffnungssalden, wobei die Historie im Altsystem über ein schreibgeschütztes Archiv oder eine Reporting-Ebene lesbar bleibt. Die vollständige Bewegungsdatenhistorie zu migrieren vervielfacht den Aufwand, bremst die Abstimmung und rechtfertigt ihre Kosten selten.
Die Ausnahme sind regulierte Branchen, in denen gesetzliche Aufbewahrungspflichten verlangen, dass die Historie im führenden System liegt, oder Unternehmen, für die fortlaufende Vorjahresvergleiche im neuen System eine echte betriebliche Anforderung sind. In beiden Fällen bildet der Aufwandsfaktor des Rechners für historische Daten den höheren Aufwand ab.
Welchen Migrationsansatz empfiehlt das Tool?
Es wählt den Ausgangspunkt anhand von Ziel-ERP, Objektumfang und Datenmengen. Greenfield-S/4HANA mit Standardobjekten landet meist beim Migration Cockpit. Brownfield-Konvertierungen und selektive Migrationen tendieren zu einem Hybrid. Große Datenmengen, mehrere Quellsysteme oder aufwendige Transformationen verschieben die Empfehlung zu einer individuellen ETL auf BTP oder einer gleichwertigen Plattform auf Oracle- oder Microsoft-Seite.
Die Empfehlung ist ein Ausgangspunkt. Die eigentliche Entscheidung fällt nach einem Proof of Concept mit einer Stichprobe Ihrer Daten, nicht durch einen Rechner. Betrachten Sie das Ergebnis als die Arbeitshypothese, mit der Sie in diese Übung gehen.
Kann ich den Plan exportieren oder mit meinem Team teilen?
Der Rechner läuft vollständig im Browser. Sie können einen Screenshot des Ergebnisses machen oder die Zahlen je Objekt in Ihre eigene Planungstabelle kopieren. Es gibt kein Konto, keinen Export als PDF, und serverseitig wird nichts gespeichert. Das ist Absicht. Wenn Sie die Zahlen ausführlicher durchgehen möchten, buchen Sie ein 30-minütiges Gespräch und bringen Sie den Screenshot mit.
Deckt es auch Nicht-Stammdaten wie Konfiguration und Sicherheit ab?
Nein. Der Rechner umfasst nur Stammdaten und Bewegungsdaten. Konfigurationsdaten, Sicherheitsrollen, Eigenentwicklungen und Integrationsobjekte gehören zu anderen Workstreams mit eigenen Aufwandstreibern und sollten nicht in die Datenposition gepackt werden. Alles in eine Zahl zu legen ist einer der Gründe, warum Schätzungen zur Datenmigration schon in der Planungsphase aus dem Ruder laufen.
Wie geht es mit Rollouts über mehrere Regionen und mehrere Gesellschaften um?
Der Rechner bemisst ein einzelnes Migrationsereignis. Bei einem Rollout über mehrere Regionen lassen Sie ihn je Welle einmal laufen und addieren die Wellen, mit einem Abschlagsfaktor für die Vorlagen, Mappings und Werkzeuge, die Sie ab der ersten Welle wiederverwenden. Nach meiner Erfahrung kostet die zweite Welle etwa 60 bis 70 Prozent der ersten, die dritte sinkt auf rund 50 Prozent und pendelt sich dort ein. Lokale gesetzliche Datenobjekte (Steuer, Payroll, Bank) lassen sich meist nicht sauber wiederverwenden.
Funktioniert das Tool für Brownfield-Konvertierungen von ECC auf S/4HANA?
Ja, und es berücksichtigt den geringeren Aufwand bei Objekten, die an Ort und Stelle konvertiert werden, im Vergleich zu denen, die neu gemappt werden müssen. Eine Brownfield-Konvertierung liegt typischerweise bei 40 bis 60 Prozent des Datenaufwands einer vergleichbaren Greenfield-Migration, weil Kunden-, Lieferanten-, Material- und Kontenplanstrukturen ohne erneute Extraktion übernommen werden. Der größere Brocken ist meist die Business-Partner-Konvertierung und die Auswirkung des neuen Hauptbuchs auf historische Buchungen.
Ist der Rechner kostenlos?
Ja. Ohne Anmeldung, ohne E-Mail-Abfrage, ohne Zahlung. Die Berechnung läuft in Ihrem Browser, und nichts wird gespeichert oder irgendwohin gesendet. Wenn Sie Hilfe beim Aufbau des Business Case zur Datenmigration möchten, sobald Sie eine Zahl haben, buchen Sie ein 30-minütiges Gespräch.