In an SAP S/4HANA program, no integration test, user acceptance test, or dress rehearsal can start until someone has extracted, cleansed, and loaded the data it runs on. That makes data migration a prerequisite for every test cycle in the plan. When a load slips, the cycle slips with it, and the go-live date follows.
You cannot fix that by moving the migration bars on the Gantt chart. You fix it by changing what the data work depends on: collect and profile data at the start of the program, load and validate it in every cycle, and leave only a short, rehearsed cutover at the end.
This applies to new implementations and selective data transitions, where you load data into a new S/4HANA system. A brownfield conversion carries different risks. And moving work earlier takes migration off the critical path only if the revised plan actually gives it float, meaning room to slip without moving the go-live date.
Why data work lands on the critical path
The sequential plan runs like this. The build team configures the system, the functional leads finalize field mappings for each migration object, the data team cleanses source records to fit the mappings, and the first mock load runs late in the Realize phase. Testing waits for the load.
That sequence puts the least-known work at the end. Nobody has profiled the legacy data yet, so the first mock load is where the team learns how many customer and vendor records will not convert cleanly to Business Partners, how many materials carry units of measure the new system does not recognize, and which open purchase orders reference vendors that were blocked years ago. Each finding needs a business decision, and business owners make those decisions on their own calendars.
The result is a chain where a late mapping decision, a failed load, or an unreconciled balance becomes the reason a test cycle cannot start. Repeat that across several test cycles and data migration is setting the go-live date, whatever the plan says.
The second cause is scope. A plan that treats “all data migrated” as one milestone makes every historical record a prerequisite for going live.
Change the dependency chain, not the deadline
The fix is to reorder the dependencies so data work runs alongside the build, and only the cutover is left at the end.
The line to draw is between work that needs a finished system and work that needs only an agreed field list or business rule. Data profiling, ownership, and mapping rules can start before configuration is complete. Loads cannot: S/4HANA needs the organizational structure, number ranges, Business Partner groupings, and GL accounts in place first. Make each cycle’s load depend only on the configuration that cycle uses.
1. Collect and profile data in the first weeks
Treat data collection as an early delivery activity. Pull extracts from the legacy systems while the Explore phase fit-to-standard workshops are still running, and profile them before anyone writes a load program.
Profiling early shows where source data fails target requirements while there is still time to decide what to do about it. Finding a blank mandatory field in month two is a cleansing task. Found in the week before a test cycle, it is a delay.
The practical deliverable is a versioned mapping agreement: source field, target field, transformation, validation rule, and accountable owner for each object. Keep unresolved decisions on that document where the program can see them. A decision buried in transformation code surfaces only when a load fails.
Ownership needs a turnaround commitment to mean anything. A load can be technically ready and still wait weeks for a business owner to decide which of two duplicate customer records survives, or what a legacy status code means in the new system. Agree up front how quickly a data owner must answer a mapping question, and track open decisions against that commitment the way you track defects. Early profiling generates those questions while you still have time to answer them.
2. Separate go-live data from historical data
“All data migrated” and “business ready to operate” do not have to be the same milestone. For each data object, ask one question: what must exist in S/4HANA for the first production transaction to post correctly?
The answer sorts objects into three planning categories.
| Category | Proposed treatment |
| Needed for day-one operations (for example, active Business Partners, open orders, open items, opening balances) | Load, reconcile and sign off before cutover |
| Needed soon after go-live | Migrate in controlled later waves, where dependencies allow |
| Historical or reference only | Decide separately: later migration, archiving, or governed read access to the legacy system |
These categories do not remove obligations. Business owners must confirm whether each historical record is needed for active transactions, reporting, audit or legal retention before it moves out of the go-live scope.
3. Load and validate in every test cycle
A load that completes is not yet an accepted migration. Put validation next to each load, so every test cycle ends with a known data position and a short list of open exceptions.
This is where collecting data early pays off. If the program has real extracts in the first weeks, it can stand up a working system on its own data long before integration testing, and every later cycle reruns a load the team has already performed. LeapGreat’s Automation Hub is built for this step: it puts your configured process and your own data in front of the business early, so mapping gaps and data defects surface before the first formal test cycle.
Tooling sets how repeatable those loads are. With the staging table approach in the SAP S/4HANA Migration Cockpit, the team fills staging tables from the source extracts, so each mock load reruns the same migration objects against corrected data.
Decide before the first cycle which data discrepancies block go-live, which can be accepted, and who has the authority to accept them. That turns “we still need to check the data” into an owned list of decisions.
4. Rehearse the cutover, then check the float
Run the final transition as a timed runbook in every mock cutover, with named owners, explicit go/no-go criteria, and a rollback decision made in advance. Once users post real transactions in S/4HANA, going back to the legacy system is a project of its own, so the go/no-go is effectively the last clean exit.
Then rerun the schedule. If final data sign-off is still a go-live prerequisite with zero float, that activity is still critical. What has changed is its size: the critical piece is now a short transition the team has already timed.
Where does your program stand?
If your first mock load is scheduled after configuration is finished, data migration is already on your critical path, and every test cycle inherits its delays. The fix starts in the first weeks of the program: real extracts, named data owners, a mapping agreement with open decisions in plain view, and a working system on your own data before the first formal test cycle. A program director should be able to say today which data objects could hold up the next cycle, and who owns each one. If that answer takes a week of meetings to assemble, the schedule risk is already there.
How much backloaded risk is in your plan? The S/4 Transformation Risk Scorecard answers that in seven questions.
