Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 3 of 5

Migration estimation

9 min

Data migration effort is driven by three things: how many data objects you move, how complex and dirty each one is, and how many times you rehearse the whole thing. The trap is to estimate the first and forget the other two. This lesson shows how to estimate per object, per mock, and per person who has to validate the result.

The data object inventory

Start with an inventory: one row per data object, such as business partners for customers and suppliers, products, bills of material, open sales orders, open purchase orders, open receivables and payables, G/L balances, fixed assets and stock. If your program loads data with the SAP S/4HANA Migration Cockpit, its predefined migration objects are a good starting list, and each object's documentation tells you how to check the result after loading. Record for each object the source, the record volume, the transformation rules, the expected cleansing, the validation method and the owner.

Contoso is doing a system conversion, so much of its data moves with the converted database rather than through object loads. The estimating discipline is the same: Contoso's inventory lists 34 data areas, whether they are converted, loaded or reworked, because each one still needs preparation, validation and sign-off in every rehearsal.

Performance riskHigh volume, simple rules: stock by storage location, open items. Load time and reconciliation dominate.
Critical path objectsHigh volume, complex rules: business partners, open sales orders. Highest effort; plan them first.
Template objectsLow volume, simple rules: bank data, small configuration-like lists. Estimate once, reuse rates.
Rules riskLow volume, complex rules: pricing conditions, special supplier terms. Mapping and validation effort dominate.
Classify every data object by volume and complexity; the top-right quadrant drives both effort and the cutover clock.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-303

Effort across the object lifecycle

Each object passes through the same lifecycle, and each step has an owner. IT owns build; the business owns cleansing and validation. A credible estimate shows both.

  1. Analyze and mapSource fields to target fields; rules agreed with the business owner
  2. CleanseFix duplicates, gaps and obsolete records in the source; business effort
  3. BuildExtraction, transformation and load or conversion steps
  4. Test loadsUnit-level loads with sample data; rule tests
  5. Mock loadsFull rehearsals with full volumes; timings captured
  6. Validate and reconcileCounts, totals and samples per object, every mock
  7. Final load and sign-offProduction load, reconciliation, owner signature
The lifecycle of one data object. Validation repeats in every mock, which is why it is so often underestimated.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-303

Mocks multiply validation

Contoso plans two mock cutovers and a dress rehearsal before the production cutover. Every one of those four runs needs business validation for every object. That is why validation, not build, is usually the largest business cost of migration.

ComplexityObjectsValidation hours per object per runHours per run
Simple12224
Medium15690
Complex716112
Total34226

Contoso business validation estimate per run. Across two mocks, the dress rehearsal and the production cutover that is about 900 hours of business and test validation.

Nine hundred hours is roughly half a person-year, spread across Maria, Dan and their colleagues, most of it in compressed windows on weekends. When Grace first showed this figure, the steering committee had expected "a few days of checking". Seeing the arithmetic made the resource conversation straightforward.

Data quality is a variable, not a constant

Cleansing effort depends on error rates you can measure early. Profile the legacy data before you estimate: count duplicates, missing mandatory values, records without activity in years, and inconsistent units or tax codes. Then estimate cleansing as records to fix × minutes per fix, owned by named business people. If you cannot profile yet, estimate a range and state when profiling will narrow it.

  1. ExploreInventory and profilingObjects listed; error rates measured; first range estimate
  2. Early RealizeMapping and buildRules agreed; cleansing under way; estimate narrowed
  3. Late RealizeMock 1First full run; real durations and error rates replace assumptions
  4. Early DeployMock 2Full volumes; re-forecast validation hours and cutover timing
  5. DeployDress rehearsalFinal timings confirmed; estimate becomes the cutover plan
The migration estimate narrows as each step replaces an assumption with a measurement.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-303

What would you do?

Mock 1 shows that 18% of Contoso's customer records fail business partner checks, against the 5% assumed in the estimate. Mock 2 is in five weeks. What should Grace do with the estimate?

Key points
  • Migration effort is driven by object count, complexity and data quality, and the number of rehearsals.
  • Keep a data object inventory with volume, rules, cleansing, validation method and owner for each object.
  • Validation repeats in every mock, so it is often the largest business cost of migration.
  • Profile data early and re-estimate cleansing from measured error rates after each mock.

Check your understanding · not graded

Lesson check

  1. 1. Why does the number of mock loads matter so much to the migration estimate?

  2. 2. Which data objects deserve the most estimation attention first?

  3. 3. How should cleansing effort be estimated?

  4. 4. Who usually owns data cleansing and validation effort?