Data Migration: The Part Everyone Underestimates

Code remediation gets the project’s attention because it’s visible — it shows up as a line item in a scan report, with a severity and a count. Data quality problems don’t show up until cutover weekend, which is precisely the most expensive possible moment to discover them, with a go-live date bearing down and no room left to absorb a surprise.

Two different projects wearing one name

Data quality rules are just readiness checks for data

You already understand this pattern from Lesson 3 — a readiness assessment scans code against rules and classifies findings by severity. Data quality rules do the exact same thing for the records themselves: missing mandatory fields, orphaned references, duplicate master data, values that were valid in ECC but violate an S/4HANA constraint. Run those rules early, in planning, and every finding is a calm conversation with a business data owner. Skip them until cutover, and every finding is an emergency.

The Migration Cockpit is the delivery mechanism, not the safety net

SAP’s Migration Cockpit moves the data once it’s clean — but it is not what makes the data clean. Treating it as a safety net that will “catch problems on the way in” is exactly backwards. The DQ rules run before the Cockpit does its job, not instead of running them at all.

Try it yourself

Pick one master data object relevant to a real migration — customers, materials, vendors. Write three plausible data-quality rules for it: one checking a mandatory field, one checking a cross-reference, one checking an S/4HANA-specific constraint that didn’t exist in ECC. For each, decide: would this realistically be caught in planning, or only discovered at cutover, given how most projects are actually run?

Go deeper

For the concrete DQ rule patterns and Migration Cockpit object design, read SAP Data Migration Best Practices.

Key takeaways

• Data quality problems are invisible until cutover unless you go looking for them earlier, deliberately.
• DQ rules are readiness checks for data — same severity-based logic as Lesson 3’s code scan, applied to records instead of programs.
• The Migration Cockpit moves clean data. It doesn’t clean it. Run DQ rules before the Cockpit, not instead of them.

Final lesson: pull scope, remediation, and data together into one thing you can actually hand a client — a real roadmap.