Migration readiness

SAP Data Migration Readiness Checklist

By Dzmitryi Kharlanau · Published · 21 min read

A migration team can complete mappings, build load files and pass several technical checks while the domain is still not ready for migration.

Contents

Reviewed: 14 July 2026

A migration team can complete mappings, build load files and pass several technical checks while the domain is still not ready for migration.

This happens because readiness is often reduced to a few visible indicators:

These indicators matter. None of them proves that the model, source data, transformation rules, target configuration and business ownership are aligned.

We use a broader definition:

A domain is ready for migration when the programme can explain what will be loaded, where every critical value comes from, which rules were applied, which gaps remain, who accepted them and how the result will be governed after the load.

Readiness is therefore not a document produced immediately before cutover.

It is accumulated evidence.

SAP itself recommends curating master data early, before an SAP S/4HANA implementation, because more automated target processes depend heavily on clean and correct master data.

The practical difficulty is deciding what “curated” and “ready” mean for a specific programme.

This checklist is our answer.

It is intended for migration managers, MDG and MDM architects, data leads, domain owners, testing teams and programme managers. It can be used before a mock load, dress rehearsal or cutover, but the work should begin much earlier.

Readiness is not the same as completion

Projects often report completion through percentages.

For example:

These figures can all be accurate while hiding significant risk.

A mapping may be marked complete even when:

Completion describes the status of an activity.

Readiness describes whether the resulting system and data can support the intended business process.

We recommend reporting both, but never treating them as interchangeable.

The six dimensions of migration readiness

We assess readiness across six connected dimensions:

  1. Model readiness
  2. Source-data readiness
  3. Mapping and transformation readiness
  4. Target-system readiness
  5. Testing and evidence readiness
  6. Operational and governance readiness

A weakness in one dimension can invalidate progress in the others.

A technically perfect load is not useful when the target model is wrong.

An approved target model is not useful when the required source data does not exist.

A clean dataset is not enough when no one owns post-go-live corrections.

The checklist should therefore be reviewed as a whole.

1. Model readiness

The first question is not whether the migration file is ready.

The first question is whether the programme knows what the target model is.

Is there one approved model?

The programme should be able to identify the current approved model without asking several teams to reconcile their own versions.

The model may be represented through several views, but the underlying objects should be consistent.

Check:

A common warning sign is that each workstream has an “official” workbook.

That usually means there is no single approved model, only several documents with different owners.

Are the business objects clearly bounded?

Terms such as Customer, Supplier, Business Partner and Material are too broad by themselves.

The team should understand which components are included.

For Business Partner, for example:

Check:

If boundaries remain unclear, mapping completion will be misleading because different teams will be mapping different interpretations of the domain.

Are critical attributes defined?

A target field name is not a sufficient definition.

For each critical attribute, the programme should know:

Check:

Definitions should be written in business language first and connected to physical fields second.

Are contexts explicit?

Many migration defects are not field defects. They are context defects.

A value may be valid centrally but missing for one company code. A field may be mandatory in one country and optional elsewhere. A material attribute may be valid at plant level but incorrectly applied globally.

Check whether the model explicitly represents:

If these conditions are stored only in notes or tab names, they are difficult to validate.

Are value lists approved?

A field can be mapped while its values remain unresolved.

Check:

Value-list readiness should be tracked separately from field readiness.

Are validation rules defined?

For each critical rule, the programme should know:

Check:

SAP MDG supports validated values, business rules, workflow routing, quality monitoring and auditable changes. The programme still has to define the actual rules and ownership appropriate to its domain.

2. Source-data readiness

A migration model describes what the programme expects.

Source-data readiness shows what the organisation actually has.

Have representative datasets been profiled?

Do not rely only on field catalogues or source-system documentation.

Use actual extracts.

Check:

A dataset from one country or one clean business unit should not be treated as evidence for the entire domain.

Do expected columns exist?

Compare the target model and mapping expectations against the current extract.

Check:

A mapping to a theoretical source field is not a usable mapping.

Is completeness measured by context?

An overall completeness percentage may hide the real problem.

For example, a field may be 95% complete globally but almost entirely missing for one country that goes live in the first wave.

Check completeness by:

Readiness should reflect the population being loaded, not the average across the enterprise.

Are data types and formats understood?

Check:

A format issue is sometimes easy to fix technically. The business meaning may still be unclear.

For example, normalising a date is straightforward if the source is genuinely a date. It is harder when the field contains text such as “unknown,” “before 2010” or “not required.”

Are duplicate patterns known?

For Customer, Supplier and Business Partner migration, duplicate handling can determine the entire loading strategy.

Check:

The migration team should not invent duplicate policy during load execution.

Are invalid references known?

Check for:

Reference-data failures should be visible before the load.

Are obsolete records filtered?

A source system may contain data that is technically valid but no longer useful.

Check:

Migrating everything can increase cost and reduce trust in the target system.

Is remediation ownership defined?

Every significant source-data issue should have a treatment and owner.

Possible treatments include:

Check:

3. Mapping and transformation readiness

This is where programmes often report the highest completion and carry the most hidden assumptions.

Does every target attribute have an identified source or treatment?

For each required target attribute, the team should know whether it is:

Check:

Are transformations precise enough to implement?

A note such as “convert to SAP format” is not a transformation rule.

A usable rule should explain:

Check:

Are value mappings complete against actual source values?

Do not review only the intended value list.

Compare mappings with current dataset distributions.

Check:

A value-mapping table is not complete because every row in the design document has a target. It is complete when it covers the values that actually appear in the migration population.

Are key mappings controlled?

Check:

Identifier errors can be more damaging than field-level defects because they affect relationships and reconciliation.

Are mapping dependencies visible?

Some mappings depend on others.

For example:

Check:

Are temporary workarounds clearly separated?

Migration programmes often introduce temporary logic to keep testing moving.

Check:

Temporary rules have a tendency to become permanent when they are embedded only in code or workbook comments.

4. Target-system readiness

The source and mapping can be ready while the target environment is not.

Is the target model stable enough for the load?

Check:

A changing target is normal during early testing. The programme must still know which version each load targets.

Are MDG and migration validations aligned?

A record may pass migration validation and fail in MDG.

Check:

The goal is not necessarily to implement every rule twice.

The programme should know which layer owns each rule and whether the combined behaviour is correct.

Are prerequisites loaded?

Check whether the target requires:

A migration object can be ready in isolation but blocked by missing prerequisites.

Is load sequencing agreed?

Check:

Sequence should be documented as an operational runbook, not only understood by the technical team.

Are technical capacity and windows confirmed?

Check:

A functionally correct load can still fail operationally if volume assumptions are wrong.

5. Testing and evidence readiness

Readiness requires evidence that the intended model works with representative data.

Have tests covered more than technical loading?

A successful load proves that records entered the system.

It does not prove that the resulting data is correct or usable.

Check whether testing covers:

Are tests linked to model objects?

The programme should know which attributes, mappings and rules have been tested.

Check:

A list of executed test cases is less useful than evidence of model coverage.

Was representative data used?

Check:

Testing only clean “happy path” records provides false confidence.

Are reconciliation criteria defined?

The team should know how to prove that the load result is complete and correct.

Check:

Reconciliation should distinguish between expected and unexplained differences.

Are defects classified correctly?

We recommend classifying defects as:

This matters because each category has a different owner and resolution path.

A generic defect backlog hides systemic problems.

Is evidence retained?

Check:

A test result without model and dataset context is difficult to reuse.

6. Operational and governance readiness

Migration does not end when the load completes.

The organisation has to own the resulting data.

Are owners ready to accept the data?

Check:

The project should not hand over unexplained exceptions as operational surprises.

Are post-go-live validations active?

Check:

SAP positions MDG as a central governance layer with workflows, validated values, data-quality monitoring and audit trails. Migration readiness should therefore include evidence that the loaded records can enter that operational governance model.

Is unresolved remediation transferred?

Some issues will remain open at cutover.

That may be acceptable if they are controlled.

Check:

“Fix after go-live” is not a plan unless ownership and evidence survive the project.

Can AMS understand the migrated model?

Check whether the support team can answer:

If the answer depends on contacting the original migration consultant, the handover is incomplete.

The readiness decision

A readiness review should not produce only “green” or “red.”

We recommend four states.

Ready

The required evidence exists. Critical gaps are closed. Remaining issues are minor and owned.

Ready with accepted exceptions

The programme understands the remaining gaps, their impact, owners and treatment. The appropriate authority has accepted the risk.

Conditionally ready

Specific actions must be completed before the next load or milestone. The conditions are explicit and measurable.

Not ready

Critical model, data, mapping, target or ownership gaps make the outcome unreliable.

This classification is more useful than forcing every domain into a binary status before the evidence supports it.

A compact management checklist

Managers do not need to inspect every mapping.

Before approving the next migration milestone, we recommend asking:

  1. Which approved model baseline are we loading against?
  2. Which required target attributes still lack reliable source data?
  3. Which value mappings do not cover the current dataset?
  4. Which transformations still depend on open business decisions?
  5. Which country or organisational contexts remain untested?
  6. Which target validations differ from migration checks?
  7. Which critical model objects have no test evidence?
  8. Which exceptions will enter production?
  9. Who owns unresolved remediation after cutover?
  10. Can AMS explain and safely change the migrated data later?

These questions expose more risk than a single mapping-completion percentage.

A practical readiness scorecard

A scorecard can help management compare domains, but it should not hide critical blockers.

We use categories such as:

AreaExample evidence
ModelApproved attributes, contexts, rules and ownership
Source dataCurrent profiles, completeness and reference checks
MappingComplete source-to-target and value mappings
TargetStable structures, configuration and prerequisites
TestingRepresentative coverage and reconciliation
OperationsStewards, remediation and handover

Each area can be assessed as:

We avoid averaging a severe blocker into a generally positive score.

For example, a domain should not receive a reassuring 88% readiness score when one mandatory tax requirement remains unresolved for the largest country.

The scorecard should direct attention, not produce comfort.

Where Martenweave fits

We built Martenweave to turn readiness from a manual document exercise into a model-driven control process.

The current Martenweave product can represent:

It supports canonical model files, deterministic validation, generated indexes, dataset profiling, gap detection, trace and impact analysis, ownership and health reports, and reviewable change proposals.

For SAP migration scenarios, Martenweave can connect legacy source columns to SAP field endpoints, validate context and references, compare CSV or XLSX datasets against the expected model, detect missing coverage and trace downstream impact before a rule changes.

A readiness workflow can therefore be built from actual relationships:

Approved model
      ↓
Expected source and target endpoints
      ↓
Current migration dataset
      ↓
Detected gaps and unresolved mappings
      ↓
Validation and impact analysis
      ↓
Reviewable readiness report

This does not replace migration tooling, SAP MDG or testing systems.

It provides a controlled view of whether their outputs remain aligned.

A minimal Martenweave readiness pilot

We recommend starting with:

The pilot should demonstrate that the team can:

  1. validate the target model;
  2. profile the dataset;
  3. detect missing or unexpected fields;
  4. identify incomplete value mappings;
  5. trace source to target;
  6. show the impact of one model change;
  7. generate a management-readable readiness report.

The purpose is not to model every field immediately.

It is to prove that readiness can be assessed through evidence rather than spreadsheet status alone.

Common readiness mistakes

Waiting until the mock load to profile the data

By then, many mapping and design decisions already depend on assumptions.

Profile representative data during model design.

Treating blank values as a cleansing issue only

A blank may indicate poor quality, an incorrect target requirement or a missing business process.

The cause matters.

Reporting mapping completion without value coverage

A field mapping can be complete while most source codes remain unmapped.

Track both.

Hiding temporary defaults

Defaults should be visible, approved and assigned for remediation.

Testing only the successful population

Records expected to fail are part of readiness evidence.

Treating every gap as a migration defect

Some gaps belong to the source, target model, governance process or business decision.

Classify them correctly.

Completing the load without preparing ownership

The loaded data becomes an operational responsibility immediately after go-live.

Stewardship cannot begin after the project team disappears.

Our conclusion

SAP data migration readiness is not demonstrated by a finished workbook or a successful technical load.

It is demonstrated when the programme can connect:

We use this checklist because most migration risk sits between those artefacts.

A source field exists, but not for every country.

A mapping exists, but the value list is incomplete.

A rule exists, but migration bypasses it.

A test passed, but against an outdated model.

A defect was accepted, but no one owns it after go-live.

Each artefact can appear complete while the overall migration remains unsafe.

Our position is simple:

A domain is ready when the programme can explain and prove the full path from source data to governed operational use.

That requires more than technical preparation.

It requires a controlled model, explicit decisions and evidence that the organisation can maintain the result after the migration team leaves.

About the authors

Martenweave is maintained by Dzmitryi Kharlanau.

We work on practical model governance for SAP migration, MDG, MDM and AMS programmes. Our focus is helping architects and delivery teams identify gaps earlier, reduce repeated manual analysis and build evidence that a domain is genuinely ready—not merely reported as complete.

Sources and notes

This article was reviewed on 14 July 2026.

SAP describes SAP Master Data Governance as a central governance hub supporting golden records, governed models, profiling, matching and consolidation, workflow routing, validated values, data-quality monitoring, mass changes and auditable data changes. SAP also recommends curating master data early before an SAP S/4HANA implementation.

Martenweave’s public product materials describe canonical model files, deterministic validation, generated indexes, dataset profiling, gap detection, traceability, impact analysis and controlled model-change proposals.

The Martenweave SAP migration scenario documents source-to-target mappings, organisational context, dataset gap detection, lineage and impact analysis.

Martenweave is an independent project and is not affiliated with or endorsed by SAP. SAP, SAP S/4HANA and SAP Master Data Governance are trademarks or registered trademarks of SAP SE or its affiliates.

Primary sources

Related articles