Discover when to start SAP data preparation, which activities to prioritize, and how to choose data preparation tools for an SAP S/4HANA migration.

SAP Data Preparation: When to Start and What Tools to Use

An SAP S/4HANA migration project can appear to be progressing well, while its data is still far from ready. Source systems have been identified, migration objects have been selected, and the first files are taking shape. Then, testing reveals that: customer records lack organizational data, material units are inconsistent, and nobody has agreed which conflicting supplier details should be retained.

Resolving these issues takes more than correcting spreadsheet cells. Teams need business decisions, reference information, transformation rules, and time to verify the results. When preparation begins late, that work competes with testing, training, and cutover planning.

SAP data preparation helps teams identify and address these requirements earlier. The goal is to build a controlled process that turns source data into datasets suitable for the intended SAP environment — and can be applied again as source records and project requirements change.

This article explains when preparation should begin, which activities can start before the target design is complete, and how to evaluate data preparation tools for SAP projects.

What Is SAP Data Preparation?

SAP data preparation is the process of selecting, assessing, cleansing, harmonizing, enriching, transforming, and validating data, so that it meets the requirements of an SAP system and its business processes.

For an SAP S/4HANA migration, preparation connects existing data with the structures, rules, and operational needs of the target environment. It may involve information from SAP ECC, other ERP systems, specialist applications, databases, and spreadsheets.

The work extends beyond correcting inaccurate values. A source record may be accurate in its current application, but incomplete for its intended use in SAP. For example, a customer’s name and address may be correct, while the organizational information needed to process sales orders is missing.

The related activities serve different purposes as revealed in the table below.

Data preparation brings these activities together around a defined outcome. Although migration is a major use case, similar preparation workflows also support SAP integration, recurring data updates, and maintenance activities.

Why SAP Data Preparation Often Starts Too Late

Preparation can be underestimated when a project plan treats it as a short activity between extraction and loading. In practice, the technical work depends on decisions that may involve several business functions.

Several assumptions can delay progress:

• Preparation is treated as completing migration templates: Templates help define the information required for a particular loading method, but they do not explain where missing values will come from or who should resolve conflicting records. A seemingly simple mandatory field can expose an unresolved business rule that affects thousands of records.
• Teams wait for the entire target design to be finalized: Final mappings require sufficient target clarity, but source profiling and ownership discussions can begin earlier. Waiting postpones the discovery of issues that remain relevant, regardless of the eventual target configuration, such as conflicting identifiers or incomplete reference data.
• Business decisions are mistaken for technical corrections: A developer can implement a rule for choosing a supplier’s payment terms, but the business must first agree which terms are valid. Without an accountable decision-maker, exceptions accumulate while the technical team waits for instructions.
• Small samples create an incomplete picture: A sample drawn from one business unit may contain well-maintained records, but overlook less common countries, organizational combinations, or legacy exceptions. The preparation effort becomes clearer only when profiling covers the relevant population and testing includes representative scenarios.
• The first cleanup is assumed to remain valid until go-live: Source systems continue to change. New records may introduce the same defects, while earlier corrections may exist only in a working file. Without reusable rules and a defined refresh process, teams must repeat manual work before each test load.

Late discovery also appears in practitioner discussions about S/4HANA projects, where contributors describe defects surfacing during later testing and recommend earlier use of representative production data. These examples illustrate a practical concern: successful transfer alone does not establish that data will support the intended business processes.

When Should SAP Data Preparation Begin?

SAP data preparation should begin when the organization starts defining the scope and approach of its transformation. The depth of the work will increase as requirements become clearer, but useful preparation does not require every target decision to be settled.

The key is to distinguish between activities that establish the condition of existing data and activities that depend on the future design.

Work that can begin early

The following activities help teams understand their source data and uncover decisions that could otherwise delay preparation later:

• Inventory source systems and datasets: Identify where required information resides, how it can be accessed, and which sources contain overlapping or complementary data. For example, material records may be held in SAP ECC, technical specifications in a PLM application, and packaging dimensions in spreadsheets. Early discovery of this fragmentation gives the project time to arrange access and understand how the datasets relate.
• Identify data owners and decision-makers: Establish who understands each dataset and who has authority to approve corrections, resolve conflicts, or clarify business meaning. Different attributes may require different owners. For instance, procurement may confirm supplier purchasing terms, while finance approves payment-related information. These responsibilities can be clarified before final target mappings exist.
• Profile completeness, formats, and value distributions: Examine the relevant source population to identify missing attributes, inconsistent conventions, and unusual values. Results should be segmented by business context, so that overall averages do not conceal important gaps. For example, material weights may appear largely complete across the organization, while records from one manufacturing site consistently lack the associated weight unit.
• Investigate potential duplicates and conflicting identifiers: Identify records that may represent the same business entity and document the evidence needed to distinguish genuine duplicates from legitimate differences. For example, the same supplier may have different identifiers in three ERP systems, while similarly named records represent separate legal entities. Investigation can begin early, even if consolidation and target numbering rules remain undecided.
• Identify obsolete-data candidates and dependencies: Assess which records may no longer be required, while checking their relationships with active business data. A customer with no recent orders may still have an outstanding receivable, and a discontinued material may remain associated with stock or an open purchasing document. Early analysis creates a defensible candidate list for business review, without prematurely excluding records.
• Establish a baseline and exception register: Record the initial condition of the data and track material issues with their affected population, business impact, owner, and next action. For example, “supplier data is incomplete” becomes actionable when the register identifies which suppliers lack required information, which business units are affected, and who must provide it. This baseline also allows subsequent checks to show whether issues are being resolved or recurring.

Work that needs sufficient target clarity

These activities can be explored provisionally, but their final implementation requires the relevant target structures, configuration, and business rules to be agreed:

• Finalize source-to-target field mappings: Confirm how source attributes will populate the target, including cases where fields must be combined, split, or derived. For example, a legacy application may store a product characteristic within a description, while the target design requires it in a separate structured attribute. The final mapping depends on agreement about where that information belongs and how it will be used.
• Assign target organizational values: Map records to the organizational structures approved for the future environment, accounting for any consolidation or redesign. For example, two legacy plants may become one target plant, but their storage locations may need to remain distinguishable. Applying organizational mappings before these decisions are settled can create extensive rework across related datasets.
• Apply configuration-dependent validation rules: Implement checks that reflect the actual target requirements for each relevant record category and business context. For example, a material may require additional purchasing information for procurement in a particular plant. General completeness checks can begin earlier, but final validation needs to reflect the agreed configuration and intended processes.
• Implement approved consolidation and numbering rules: Apply decisions about which records will be combined, which identifiers will be retained or assigned, and how dependent records will reference them. For example, consolidating several source customer records into one target identity requires a maintained cross-reference, so that associated records use the correct identifier. The investigation can start early, but execution needs an approved policy.
• Confirm final migration selection criteria: Translate business scope into precise, executable rules, including treatment of dependent records and exceptions. For example, an initial proposal to migrate customers active within the past two years may need to include older customers with open items. Final selection requires agreement on both the main criteria and the relationships that override them.
• Produce and test target-ready datasets: Generate data in the structures required by the chosen loading method and verify it in the target environment. For example, a customer dataset may pass preparation checks, but reveal during sales-order testing that a required sales-area extension is missing. Therefore, meaningful testing depends on sufficient alignment between the prepared data, the target configuration, and the business scenarios being tested.

Early preparation should progressively produce evidence and decisions. Teams can investigate source issues while target requirements develop, provided that assumptions and provisional rules remain clearly documented.

How the transition approach changes preparation

The preparation plan also needs to reflect how the organization is moving to SAP S/4HANA.

A new implementation places substantial emphasis on selecting and shaping data for a new environment. A system conversion retains more of the existing system context, but still requires relevant consistency checks and prerequisite work. For example, SAP identifies customer/vendor integration and synchronization with Business Partners as prerequisites for an SAP ERP to SAP S/4HANA conversion.

Selective data transition introduces its own scope and dependency questions, particularly when organizational units, business entities, or historical records are being selected.

There is no universal number of months that makes preparation “early enough.” A more useful planning question is whether the project has allowed enough time to discover problems, obtain decisions, implement corrections, and verify the results, before those datasets are needed.

How to Prepare Data for SAP S/4HANA

An effective preparation process produces increasingly reliable datasets, while keeping decisions and corrections traceable. The following steps provide a practical structure, although teams will revisit them as testing reveals new requirements.

Step #1: Define the data scope and decision ownership

The starting point is an inventory of the data required to support future business processes. This includes the relevant objects, source systems, organizational coverage, and dependencies.

Scope should be specific enough to guide selection. “Migrate customer data” leaves important questions unanswered, such as:

• Which customers are required?
• Which organizational extensions must be retained?
• How should customers associated with open transactions be handled?

Each dataset also needs people who can explain its meaning and approve decisions about it. Technical ownership of extraction does not automatically include authority to choose a surviving record or approve a business default.

Practical output: A scoped data inventory with named owners, selection assumptions, dependencies, and outstanding decisions.

Step #2: Profile the source data and prioritize findings

Profiling establishes the starting condition of the data. Useful checks include missing values, invalid formats, unusual value distributions, potential duplicates, and broken relationships.

Results should be segmented where business rules differ. A field that is optional for one record category may be essential for another. A single overall completeness percentage can conceal a serious issue in a smaller, but operationally important, population.

Prioritization should consider business consequences as well as record counts. An issue impacting a small set of critical suppliers may deserve attention before a formatting inconsistency across thousands of inactive records.

Practical output: A baseline showing the affected population, business impact, likely cause, and proposed owner for each material issue.

Step #3: Agree on correction, harmonization, and mapping rules

Once data quality issues are understood, teams need explicit rules for addressing them. These may define how to standardize values, resolve conflicts, consolidate records, enrich missing attributes, or convert legacy codes.

A usable rule should explain its scope, required inputs, expected result, and handling of exceptions. “Use the latest record” is insufficient if the latest change affected only a telephone number, while another source remains authoritative for financial information.

The team should also decide where corrections belong. Fixing an issue in the source may improve ongoing operations and future extracts. Applying a transformation in the preparation workflow may be more appropriate when the change is specific to the target structure.

Practical output: An approved rule set with examples, reference mappings, exception conditions, and clear responsibility for unresolved cases.

Step #4: Build repeatable preparation workflows

Approved rules can then be implemented in workflows that extract, transform, enrich, and assemble the required datasets.

Repeatability matters because preparation will usually be executed against multiple source snapshots. A workflow should apply the agreed logic consistently, separate records that require attention, and preserve enough information to trace results back to their source.

Manual input may still be necessary, particularly for business decisions. Approved corrections should be captured in a controlled form that subsequent runs can use, rather than remaining scattered across individual working files.

Practical output: An executable preparation workflow with identifiable inputs, maintained rules, exception outputs, and traceable results.

Step #5: Validate records, relationships, and totals

Validation should establish whether the prepared data meets agreed requirements, before it proceeds to loading.

Checks need to cover more than individual field values. Related datasets must remain consistent: dependent records need valid parent references, mapped identifiers must be used consistently, and selection rules must preserve required relationships.

Reconciliation should also reflect the transformations performed. If approved duplicate consolidation reduces the number of customer records, matching source and target record counts would not qualify as an adequate acceptance criterion. The project instead needs evidence that required identities, relationships, and associated business values have been preserved.

Practical output: Validation and reconciliation results that explain accepted records, rejected records, intentional changes, and unresolved differences.

Step #6: Test prepared data in business processes

Prepared data must eventually be tested in the target environment using representative business scenarios.

A material record may pass structural checks, but still lack information needed for procurement in a particular plant. A customer may load successfully but be unavailable for the intended sales process.

Findings should be classified, so that teams address the right cause. A failed scenario may result from source data, transformation logic, target configuration, authorization, or an incorrect test expectation. Documenting that distinction prevents data teams from making unnecessary corrections.

Practical output: Business-tested datasets, documented findings, and updated preparation rules ready for the next execution.

SAP Data Preparation Examples

The value of preparation becomes clearer when a data issue is connected to its operational consequence. The examples below illustrate the decisions and checks that turn source records into usable SAP data.

These examples also show why preparation cannot be reduced to a universal set of cleanup rules. The correct result depends on the intended process, the relevant relationships, and approved business decisions.

What to Look for in Data Preparation Tools

Data preparation tools should be evaluated against the work required by the SAP project. A tool that produces clean analytical datasets may still need additional capabilities or implementation work to support SAP-specific structures, dependencies, and delivery requirements.

A practical assessment should cover the following capabilities:

• SAP and non-SAP connectivity: The tool needs access to the actual source landscape, including relevant SAP interfaces, databases, applications, and files. Connector availability should be checked alongside extraction coverage, access requirements, and the ability to retrieve related data consistently.
• Profiling and rule-based validation: Teams should be able to inspect source conditions and implement checks that reflect business context. For example, completeness rules may need to vary by material type, country, or organizational scope.
• Reusable transformation and enrichment logic: Mappings, lookups, conversions, and derived values should be maintainable as rules. The assessment should include how the tool handles changed mappings and whether the same logic can be applied consistently to refreshed extracts.
• Support for related datasets: Preparation must preserve relationships across objects and tables. A useful demonstration should show how an identifier change propagates to dependent records and how missing references are detected.
• Clear exception handling: Failed records should be accompanied by reasons that help users act. An exception report is more useful when it includes the source identifier, failed rule, relevant value, and enough context for the responsible person to investigate.
• Traceability and execution monitoring: Teams need to understand which inputs and rules produced a dataset, what changed during processing, and where execution failed. This evidence supports troubleshooting and makes results easier to review.
• Automation with appropriate flexibility: Visual workflows can make common preparation tasks easier to maintain, while SQL or Python extensions can address specialized requirements. Scheduling and execution controls become useful when the same process must run against refreshed data.

A proof of concept should use representative records, including difficult cases. It should demonstrate the path from extraction through preparation and exception correction to validation and delivery. A demonstration that ends with a clean-looking preview table leaves important operational questions unanswered.

How data preparation tools work with SAP loading tools

When using SAP S/4HANA Migration Cockpit, teams need to decide which rules belong in upstream preparation and which will be handled through the cockpit’s mapping tasks. This division should be explicit, particularly when both tools can change the same values.

For example, if a preparation workflow converts legacy payment-term codes into approved SAP target codes, the cockpit’s value mappings must be consistent with that decision. Maintaining separate translations in both places creates a risk that a correctly prepared value will be changed again during loading.

For the staging-table approach, preparation workflows assemble data in the structures required by the selected migration objects. The work includes populating required attributes, preserving relationships between records, and applying agreed transformations before delivery through the supported staging mechanism. Filling those structures is the final packaging step; source conflicts and missing business information should already have been addressed.

Checks should also be divided according to what each environment can establish:

• Preparation checks assess the dataset before transfer: These can identify missing attributes, unmapped legacy codes, duplicate keys, or dependent records that reference an identifier absent from the prepared master data. For example, a workflow can detect that a material’s plant assignment still uses an obsolete source plant code.
• Migration cockpit simulation checks the proposed transfer against the target SAP environment: Simulation can expose issues that upstream checks may miss when they lack current target configuration or application context. Its results should be reviewed before the actual migration.
• Business-process testing verifies operational usability after loading: A customer record may transfer successfully with a valid payment-term code, yet use terms that conflict with the customer’s agreed commercial conditions. Testing a representative order-to-cash scenario helps confirm that the loaded values produce the expected billing and payment outcomes.

Findings from simulation, loading, and business testing should feed back into the preparation workflow. If missing purchasing attributes are corrected only in an upload file, the next extract may reproduce the problem. Updating the source, enrichment rule, or validation check makes the correction repeatable and reduces manual repair before subsequent loads.

How Migravion Supports SAP Data Preparation

SAP data preparation develops over time. Initial source analysis exposes issues, business owners agree how to resolve them, and target requirements introduce additional mappings and checks. Migravion allows teams to implement this work in reusable data workflows that become more complete as the project progresses.

Establishing checks before final mappings are available

Teams can use Migravion to extract source data and configure checks for issues that can already be assessed, such as inconsistent formats, missing reference values, or conflicting identifiers. SAP connectivity and access to databases and files allow these checks to cover information distributed across the source landscape.

For example, an early supplier assessment could identify records with missing country codes or inconsistent tax-identifier formats. The resulting exception dataset gives business owners specific records to investigate while the target business partner design is still being developed.

Incorporating approved business decisions into processing

As decisions are approved, teams can translate them into mappings, lookups, transformations, and validation rules within Migravion. Visual workflow design supports common preparation operations, while SQL and Python extensions accommodate more specialized logic.

Suppose several legacy systems describe product packaging differently: one uses separate attributes, another stores a combined text value, and a third relies on local abbreviations. A preparation workflow can extract the relevant information, apply an approved reference mapping, and separate values that cannot be interpreted reliably. Business decisions then become executable rules that can be applied to the next extract.

Carrying corrections forward to refreshed datasets

A correction made in a working file can disappear when that file is replaced. Migravion workflows can incorporate approved reference tables and correction inputs, so that subsequent executions consistently apply the same decisions.

For instance, business owners could maintain an approved Excel reference containing corrected product classifications, keyed by source system and record identifier. A workflow can join that reference to each refreshed extract and flag records without an applicable mapping. The team can then focus its review on unresolved or newly encountered cases.

Introducing target-specific requirements as they become clear

Once the relevant SAP target decisions are agreed, teams can extend existing workflows with organizational mappings, target attributes, and additional checks. Earlier source analysis remains useful, while preparation becomes progressively aligned with the intended loading method.

Execution logs and reports help teams investigate processing failures; configured validation outputs show which records fail the agreed data rules. Keeping these results distinct helps the project determine whether it needs to repair a workflow, resolve a data exception, or obtain a missing business decision.

This approach gives early preparation work a practical continuation. The checks and corrections developed during discovery become part of the process used to produce later migration datasets.

How to Know Whether Your Data Is Ready

Readiness needs to be assessed against the intended use of each dataset. “The file is complete” and “the load succeeded” are useful milestones, but neither provides sufficient evidence on its own.

Practical readiness criteria include:

• Scope and selection are agreed: Included and excluded populations have been reviewed, and required dependencies are accounted for. The team can explain why particular records are being retained or omitted.
• Critical rules and mappings are approved: Preparation does not depend on undocumented assumptions about identifiers, organizational assignments, defaults, or conflict resolution.
• Exceptions are understood and controlled: Blocking defects have been resolved, while accepted exceptions have a named owner, documented impact, and agreed treatment. A high overall pass rate does not conceal unresolved issues in critical records.
• Relationships and reconciliation checks pass: Required references remain valid, and differences in counts or values are explained by approved selection and transformation rules.
• Business scenarios have been tested: Representative users have verified that the data supports the processes it is intended to enable, including relevant organizational and exception scenarios.
• The preparation process can be rerun reliably: The team can process a refreshed extract, using maintained rules and corrections with clear reporting of new or recurring issues.

Readiness should be tracked by object and business scope, since one overall percentage can hide important differences. Customer data may be ready for one sales area, while another still has unresolved requirements.

For a broader assessment of preparation, ownership, testing, and project controls, the Data Migration Readiness Workbook provides a structured starting point.

Conclusion

SAP data preparation is most effective when it begins early enough to influence decisions and continues as requirements and source data evolve. Source profiling, ownership, and issue investigation can start before the target design is complete. Final mappings and target-specific checks can then be introduced as the relevant decisions are approved.

The lasting value comes from a process that teams can execute, inspect, and improve. Migravion helps implement that process through connected data workflows, reusable transformations, configurable validation, and execution monitoring.

Request a demo to see how Migravion can support SAP data preparation for your migration or ongoing data workflows.