The short answer. The data migration lead owns the workstream that most often decides whether an S/4HANA programme lands on time. The role covers scope (what moves, what is archived, what is dropped), readiness standards and gates, the load sequence, the mock migration cycle, reconciliation and sign-off, and escalation when business decisions stall. It is a coordination and decision-forcing role more than a technical one, and leaving it unfilled is a common and expensive omission.

Most migration programmes name a technical lead and a functional lead early. The data lead is often appointed later, or absorbed into someone else's remit, which is odd given how reliably data is the workstream that overruns. Here is what the role actually involves.

What the role owns

Scope. Driving the decision on what data migrates, what is archived and what is left behind, and holding that line when it is challenged.
Readiness standards. Working with domain owners to define what good looks like per object, expressed clearly enough to test.
Sequence. Owning the dependency chain and load order so objects arrive in a sequence that works.
The mock cycle. Planning rehearsals, measuring timings against the cutover window, and driving the first-pass rate up between runs.
Reconciliation and sign-off. Ensuring each load is proven against the source and that the right business owners sign.
Escalation. Spotting stalled decisions early and pushing them up before they become schedule risk.

The job is mostly decision-forcing

The data lead rarely fixes the data personally. They make sure the people who can decide, decide.

A common misreading is that this is a hands-on data engineering role. In practice the technical work is usually done by specialists, and the lead's contribution is different: identifying the judgements that need making, getting them in front of the people authorised to make them, and preventing the queue of unresolved questions that quietly consumes a schedule. Research into migration overruns repeatedly points at slow scope resolution and weak governance, which is exactly the territory this role patrols.

What the role needs

Capability	Why it matters
Business fluency	Scope and quality calls are business judgements; the lead must speak that language
Enough technical depth	To challenge estimates, understand dependencies and read profiling output
Comfort with evidence	Readiness and sign-off rest on numbers, not impressions
Escalation instinct	Knowing when a stalled decision has become a schedule risk
Stamina for repetition	The mock cycle repeats; the lead keeps standards constant across runs

Appoint early, not at cutover

The highest-value period for this role is before the plan is fixed, because that is when scope and readiness standards are set and when profiling can still change the plan. A data lead appointed during build inherits decisions already made badly: a scope nobody questioned, a timeline that assumed clean data, standards that were never agreed. Appointing early is also what allows the data workstream to be itemised in the budget rather than absorbed into contingency, which is where a large share of overrun originates.

The role runs on evidence

What makes this role workable is having numbers rather than opinions. Profiling output tells the lead which objects are worst and how big the cleansing job really is. Validation results show whether readiness standards are being met. First-pass rates across mock cycles show whether preparation is improving. Reconciliation results provide the basis for sign-off. Without those, the lead is negotiating from impressions, and impressions lose to confident assertions. With them, readiness becomes a gate that either passes or does not.

Where the role ends

Clarity about what the data lead does not own is as useful as the list of what they do. They do not own the business definition of correct data; domain owners do. They do not own the technical conversion; Basis and the technical team do. They do not own process redesign. What they own is the readiness of data to move and the evidence that it moved correctly. Blurring that boundary is a common failure: a data lead asked to also make business judgements about their employer's customer records is being set up to make decisions they lack the standing to make, and those decisions tend to get revisited later at cost.

Early signals the role is struggling

Decisions aging. A list of open data questions that is growing rather than shrinking week on week.
Flat first-pass rates. Mock cycles that are not improving suggest remediation is not reaching the root cause.
Scope creeping quietly. Objects being added without a corresponding change to timeline or effort.
Readiness by assertion. Gates being passed on confidence rather than measured evidence.

Each of these is visible early and cheap to correct at that point. Left alone, all four converge on the same outcome at cutover.

Working with the system integrator

On most programmes a partner does a large share of the delivery, which changes the role rather than removing it. A data lead employed by the organisation holds something the partner cannot: accountability that outlasts the engagement, and standing to make scope and quality decisions on the business's behalf. The partner brings method and capacity. The risk when the role is left entirely to the partner is that scope and readiness standards get set by whoever is also being measured on delivering against them. Keeping the data lead client-side, even alongside a capable partner, preserves the independence the decisions require.

Plan the handover from day one

The data migration lead role ends, but the work it established should not. Domain ownership, data standards, monitoring and the habit of evidencing readiness are all worth keeping once the programme closes. Planning that handover early, naming who inherits each piece and when, prevents the common outcome where everything the migration forced the business to agree quietly lapses within a quarter of go-live. The organisations that come out of a migration with better data governance than they went in with are generally the ones that treated the handover as a deliverable rather than an afterthought.

How deKorvai helps

deKorvai gives the data migration lead the evidence the role depends on. It profiles source data so scope and effort decisions rest on measured condition, applies configurable rules so readiness standards become objective tests, and reports results on real-time scorecards that make progress visible across mock cycles. It reconciles loaded data against the source, producing the artefact business owners sign off against, and keeps full audit trails so decisions and changes are recorded. Because the flow is repeatable, the same standards apply consistently from the first rehearsal through to cutover.

Key takeaways

The role owns scope, standards, sequence, rehearsals, reconciliation and escalation.
It is decision-forcing, not primarily hands-on engineering.
Appoint before the plan is fixed, or inherit decisions made without evidence.
The role runs on numbers: profiling, validation, first-pass rates, reconciliation.

Frequently asked questions

What does a data migration lead do?

They own the data workstream: scope decisions on what migrates, archives or is dropped; readiness standards per object; the load sequence; the mock migration cycle; reconciliation and sign-off; and escalation when business decisions stall.

Is the data migration lead a technical role?

Partly, but it is mostly decision-forcing. Specialists usually do the hands-on work. The lead identifies the business judgements that need making, gets them in front of people authorised to decide, and prevents the queue of unresolved questions that consumes schedule.

When should a data migration lead be appointed?

Before the plan is fixed. That is when scope and readiness standards are set and when profiling can still change the plan. A lead appointed during build inherits a scope nobody questioned and a timeline that assumed clean data.

What does the role need to be effective?

Evidence. Profiling output to size the work, validation results to test readiness standards, first-pass rates across mock cycles to show whether preparation is improving, and reconciliation results as the basis for business sign-off.

The Data Migration Lead: The Role That Decides Your Timeline