Technisch lassen sich einige rekonstruieren, sinnvoll ist es selten. Belege aus einem anderen Customizing verhalten sich nicht wie native S/4HANA-Belege, und ihre Abstimmung kostet Aufwand ohne operativen Nutzen. Die übliche Antwort lautet: Salden und offene Posten in S/4HANA, Historie im Archiv oder in einem lesenden Altsystem. Wenn produktive Historie wirklich gebraucht wird, ist die selektive Transition der bessere Weg.

Für eine mittelgrosse Einzelsystem-Landschaft läuft der Datenstrang typischerweise sechs bis neun Monate parallel zum Gesamtprogramm, mit drei bis vier Testladezyklen darin. Programme über mehrere Länder oder Instanzen verlängern Design- und Testphasen, ändern aber die Struktur nicht.

Drei mindestens, vier sind komfortabel. Der erste zeigt, dass die Strecke läuft, der zweite legt die echte Datenqualität offen, der dritte probt die Sequenz mit realistischen Laufzeiten — und der vierte existiert, damit der dritte schiefgehen darf.

Sie verantworten die Entscheidungen, wir die Mechanik. Wir finden und quantifizieren die Fehler, schlagen Regeln vor und liefern die Arbeitslisten; der Fachbereich entscheidet, was eine Dublette ist und welcher Satz überlebt. Migrationsteams, die das allein entscheiden, werden beim Go-live meist überstimmt.

Sie werden einzeln bewertet. Manche finden ihr Gegenstück in S/4HANA-Standardfeldern, die es in ECC noch nicht gab, manche wandern in Erweiterungsfelder des Zielsystems, und manche stellen sich als ungenutzt heraus und entfallen. Greenfield ist der günstigste Moment, sie loszuwerden.

Ja, das ist ein üblicher Aufbau. Wir übernehmen den Datenmigrationsstrang als abgeschlossenes Paket mit eigenen Abstimmungs-Gates und docken am Cutover-Plan des Programms an.