SAP Data Migration Use Cases for Manufacturing Enterprises: 5 Real-World Scenarios

SAP data migration in manufacturing is often described as an ETL problem: extract data from the legacy system, transform it, load it into SAP S/4HANA, and reconcile the result.

That description is technically correct and operationally misleading.

In a manufacturing program, a material is not just a material number. Its behavior depends on plant data, units of measure, procurement and MRP settings, valuation, classification, batch or serial management, and its use in manufacturing structures.

The same applies to a BOM. A BOM cannot be assessed in isolation if production depends on a particular combination of BOM, routing, production version, validity period, and plant.

This is why manufacturing migrations tend to become difficult at the point where the business asks seemingly simple questions:

• Which materials actually need to exist in the target system?
• Which plant-specific differences are intentional?
• Which BOM is the one production actually uses?
• What happens to an open production order at cutover?
• Should historical transactions be migrated, archived, or left in the legacy system?
• Which legacy customizations have a business purpose that must survive the transition?

The five scenarios below illustrate the types of decisions that make SAP data migration a business and architecture problem, not just a data-loading exercise.

1. ECC to S/4HANA: Defining What Should Actually Survive the Migration

The situation

A manufacturer has operated SAP ECC for many years. The system supports multiple plants, procurement organizations, warehouses, and production sites.

The initial migration inventory is large:

• material masters;
• customers and suppliers;
• BOMs;
• routings;
• work centers;
• production versions;
• purchasing data;
• inventory;
• open orders;
• financial data;
• custom tables and extensions.

At the beginning of an S/4HANA program, the migration inventory can therefore look deceptively simple:

“We have this data in ECC. We need to move it to S/4HANA.”

That is usually the wrong starting point.

The more important question is:

What data does the target business actually need in S/4HANA to operate, report, plan, and comply after go-live?

This distinction is critical because an S/4HANA migration is not a database-copy exercise. It is a transition to a new application architecture, data model, and potentially standardized business processes.

The required migration scope depends heavily on the transition approach.

A system conversion generally preserves much of the existing organizational and application context. A selective data transition provides opportunities to harmonize and selectively move business data. A new implementation requires the organization to define the target data model and processes much more explicitly.

The migration strategy should therefore be established before extraction begins.

Where the legacy data becomes a problem

Consider the material master.

A material may have:

• a valid basic record;
• plant-specific data in only some plants;
• several units of measure;
• old purchasing information;
• outdated MRP parameters;
• historical BOM references;
• an active indicator despite no recent business usage.

There is no single field that answers whether the material should be migrated.

Last changed date is not sufficient.

Material status is not sufficient.

Plant extension is not sufficient.

The real question is whether the material is part of the target business process landscape.

For example, a material may have had no movement for several years but still be required because it appears in an active BOM or production version.

Conversely, a material may have recent technical activity but no legitimate business purpose in the target operating model.

This is why migration scope should be determined through business rules, dependencies, and target-state requirements, rather than simple technical filters.

Data objects cannot be scoped in isolation

One of the most common migration mistakes is treating each data object as an independent record set.

Manufacturing data is highly interconnected.

For example:

Material → BOM → Routing → Work Center → Production Version → Production Order

Removing one object can make another object unusable.

The same applies to:

Supplier → Purchasing Data → Purchase Order → Goods Receipt → Invoice

and:

Customer → Sales Data → Sales Order → Delivery → Billing Document

Therefore, migration scope should consider object dependencies and business process continuity.

A material should not be evaluated only as a material.

It should be evaluated in the context of the manufacturing processes that depend on it.

The migration architecture

An experienced migration program separates at least three fundamentally different decisions.

1. Should the object exist in the target system?

This is a scope decision.

2. If it exists, what should it look like in S/4HANA?

This is a transformation and mapping decision.

3. If it does not move, how will the business access it?

This is an archiving, retention, or legacy-access decision.

These decisions should not be mixed together.

A record can be:

Migrated as-is

Migrated after transformation

Consolidated with another record

Excluded from S/4HANA but retained for historical access

Retired completely

This creates a much more controlled migration model than attempting to reproduce the ECC database inside S/4HANA.

The target state must drive the migration

The Target State Must Drive the Migration

The most effective programs work backward from the target operating model.

Before defining extraction rules, the team should understand:

• which plants will exist in S/4HANA;
• which business processes will be standardized;
• which materials remain active;
• which suppliers and customers remain relevant;
• which manufacturing structures will be used;
• which historical data is required for reporting;
• which regulatory and audit requirements apply;
• which legacy processes will be retired.

This changes the fundamental question from:

“How do we migrate this ECC object?”

to:

“What information does the target business process require?”

That shift is one of the biggest differences between a technically successful migration and a successful business transformation.

What changes during S/4HANA preparation

Migration also needs to account for changes introduced by the S/4HANA target architecture.

Business Partner and Customer/Supplier Data

The transition from the traditional ECC customer/vendor model toward the SAP Business Partner approach requires careful assessment of:

• customer and supplier identities;
• duplicate records;
• roles;
• relationships;
• grouping;
• number ranges;
• organizational assignments;
• address data;
• tax information.

For existing SAP ERP systems, Customer-Vendor Integration (CVI) is therefore an important part of the preparation for S/4HANA.

The objective is not merely to convert records technically.

The organization needs to establish which business identities should exist in the target system and how they should be represented.

Custom data requires the same discipline

Custom Data Requires the Same Discipline

The same principle applies to custom fields, Z-tables, and custom developments.

A custom field should never be migrated simply because it existed in ECC.

For every significant custom data element, ask:

• Is the field still required?
• Which business process uses it?
• Who owns the data?
• Is it populated consistently?
• Is the information still valid?
• Does S/4HANA provide a standard alternative?
• Can the requirement be addressed through configuration or extensibility?
• Does the field need transformation?
• What happens if the field is not migrated?

This is where Clean Core considerations become relevant.

The objective should be to avoid transferring unnecessary legacy complexity into the new environment.

Migration rules should be explicit

Migration Rules Should Be Explicit

For important data domains, migration rules should be documented before the final migration cycle.

For example:

Material is migrated if it is active in a target plant, referenced by an active BOM or production version, required by an open transaction, or explicitly approved by the business data owner.

The exact rules will vary by organization, but the principle is consistent:

Migration decisions should be explainable, repeatable, and auditable.

This also makes migration testing significantly more effective.

Instead of asking:

“Did we load everything?”

the team can ask:

“Did we migrate everything that should have been migrated according to the approved rules?”

Data Quality Is More Than Deduplication

Data quality is more than deduplication

Data cleansing is often reduced to finding duplicates.

For manufacturing enterprises, data quality is broader.

The team may need to validate:

• material completeness;
• units of measure;
• plant extensions;
• MRP parameters;
• BOM validity;
• routing consistency;
• production versions;
• supplier assignments;
• batch characteristics;
• organizational assignments;
• mandatory S/4HANA fields.

A material can be unique and still be wrong for the target business process.

Therefore, data quality rules should be linked to business process requirements, not just technical completeness.

Reconciliation must be designed before migration

Reconciliation Must Be Designed Before Migration

Reconciliation should not be an activity performed after the data load.

It should be part of the migration design.

For each major data object, define:

Source → Transformation → Target → Validation

For example:

ECC inventory → transformation rules → S/4HANA inventory → quantity/value reconciliation

For manufacturing structures:

ECC BOM → mapping/transformation → S/4HANA BOM → component and validity validation

For business partners:

Customer/vendor records → CVI transformation → Business Partner → duplicate and role validation

This creates an auditable chain between the legacy source and the target system.

The real deliverable

The output of migration preparation is therefore not a collection of load files.

The real deliverable is a target-state data model supported by documented migration rules.

For every significant data domain, the program should be able to explain:

• What is being migrated?
• What is being transformed?
• What is being consolidated?
• What is being excluded?
• Why was the decision made?
• Who approved it?
• How will it be validated?
• How will excluded historical information remain accessible?

That is what turns SAP data migration into a controlled transformation rather than a technical copy of legacy data.

SAP focus: SAP ECC to S/4HANA transition, migration scope, Business Partner/CVI considerations, material master, custom data, data transformation, reconciliation, and target-state design.

2. Global Manufacturing Template: When One Material Exists 12 Different Ways

2. Global Manufacturing Template: When One Material Exists 12 Different Ways

The situation

A manufacturer has implemented SAP independently across multiple plants, business units, or regions. Each implementation solved local operational requirements, but over time the organization accumulated different approaches to material creation, classification, procurement, planning, and inventory management.

Now the group is moving toward a common SAP S/4HANA template.

During data profiling, the migration team discovers that the same or similar components exist under different material numbers, descriptions, units of measure, and planning parameters.

For example, twelve plants may have what appears to be the same electric motor represented by twelve different material records.

At first, the project may describe this as a material deduplication problem.

That diagnosis is too narrow.

The underlying issue is a global template and master-data design problem expressed through the material master.

The organization is not simply deciding which records to delete. It is deciding which business rules should be global and which differences should remain local.

Why automatic deduplication fails

Consider three material records:

MOTOR-001
MTR_1001
00012345

Their descriptions may look almost identical.

A conventional matching algorithm might therefore flag them as duplicates.

But identical descriptions do not prove that the materials are interchangeable.

The underlying specifications may differ in:

• voltage;
• power rating;
• dimensions;
• material composition;
• manufacturer;
• approved supplier;
• certifications;
• quality requirements;
• storage conditions;
• service application.

There may also be operational differences.

One plant might use the motor as a production component, another as a maintenance spare, and a third as part of a different finished product.

The records may therefore look identical from a text-matching perspective while representing different business objects.

This is why material harmonization cannot be reduced to fuzzy matching, duplicate detection, or automated cleansing.

The decision model

Potential duplicates are usually classified into categories such as:

True duplicate

The records represent the same business object and can be consolidated.

Equivalent but differently governed

The physical component is equivalent, but differences in sourcing, classification, or plant setup need to be resolved before consolidation.

Legitimate variant

The records look similar but represent different engineering or operational requirements.

Obsolete material

The material is no longer required in the target operating model.

This classification should be performed with the relevant business owners, not by the migration team alone.

The important question is not "Are these materials similar?"

The Important Question Is Not "Are These Materials Similar?"

The more useful question is:

Can these materials be represented by the same target business object without losing information required to operate the business?

That requires input from several functions.

For a manufacturing enterprise, the review may involve:

• engineering;
• procurement;
• production planning;
• manufacturing;
• quality;
• maintenance;
• supply chain;
• finance;
• master-data management.

The migration team can identify candidates and provide evidence, but it should not unilaterally decide that two materials are interchangeable.

That is a business ownership decision.

Plant data makes the problem harder

The material number is only one part of the decision.

Plant-specific data may contain differences in:

• MRP settings;
• procurement type;
• lot-sizing;
• planning parameters;
• production or external procurement strategy;
• storage requirements;
• batch management;
• quality-management requirements.

Some differences are accidental and should disappear.

Others are legitimate consequences of how a particular plant operates.

For example, two plants may use the same component but require different planning parameters because they have different:

• production lead times;
• supplier relationships;
• demand patterns;
• lot sizes;
• manufacturing processes.

Standardizing the material does not necessarily mean standardizing every plant-level attribute.

Designing the global material model

Designing the Global Material Model

The migration program should therefore distinguish between two categories.

Global Attributes

Data that should normally be governed consistently across the organization, such as:

• material identity;
• material type;
• base unit of measure;
• core description;
• classification;
• core product attributes;
• global naming conventions.

Plant-Specific Attributes

Data that may legitimately vary according to operational requirements, such as:

• MRP parameters;
• procurement settings;
• planning parameters;
• storage settings;
• plant-specific sourcing.

The exact split depends on the organization's operating model and S/4HANA template.

The objective is not to make every field identical.

It is to define where variation belongs.

A more realistic target

A common mistake is to define harmonization as:

“Every plant must use exactly the same material data.”

That can create new operational problems.

A better target is:

“Remove accidental variation while preserving variation that represents a genuine business requirement.”

This distinction is fundamental to a global S/4HANA template.

The same principle applies beyond material masters.

The migration team may encounter similar issues with:

• Bills of Material;
• routings;
• work centers;
• production versions;
• classification;
• units of measure;
• purchasing data;
• supplier records;
• quality data.

A global template is therefore not just a technical configuration project. Data is one of the mechanisms through which the template becomes operational.

From material harmonization to a global template

Once candidate materials have been classified, the organization can define target-state rules.

For example:

12 legacy materials

↓

4 true duplicates

↓

2 legitimate variants

↓

3 materials requiring business review

↓

3 obsolete materials

This is much more meaningful than simply reporting:

“We found 12 duplicate records.”

The real result is a documented decision about how the target organization will represent the business.

Where SAP MDG fits

Migration can solve the initial data problem, but it does not automatically solve the governance problem.

Suppose a manufacturer consolidates 10 legacy material records into one global material during the S/4HANA migration.

If the organization does not establish:

• who owns the material;
• who can create new materials;
• which attributes are mandatory;
• how duplicates are checked;
• how changes are approved;
• how global and plant-specific attributes are governed;

the organization can recreate the same problem after go-live.

This is where SAP Master Data Governance (SAP MDG) can become part of the target operating model.

The distinction is important:

Migration establishes the initial clean population. Governance controls what happens to that population afterward.

The data ownership model

The Data Ownership Model

A successful global template therefore needs more than a technical mapping document.

It needs clear ownership.

For example:

The exact ownership model will vary, but without clear accountability, harmonization decisions tend to become temporary.

What the migration team should deliver

What the Migration Team Should Deliver

The output should not simply be a list of duplicate materials.

A mature migration workstream should produce:

• material harmonization rules;
• duplicate classification;
• global vs. plant-specific attribute rules;
• target material model;
• mapping between legacy and target records;
• ownership assignments;
• data-quality rules;
• exception management;
• reconciliation criteria;
• post-go-live governance requirements.

That creates a reusable foundation for the S/4HANA template rather than a one-time cleansing exercise.

Expert takeaway

4. Inventory Cutover: When the Factory Cannot Wait for the ERP Project

3. BOMs, Routings and Production Versions: Do Not Migrate Them as Independent Objects

3. BOMs, Routings and Production Versions: Do Not Migrate Them as Independent Objects

The situation

A discrete manufacturer is moving its production processes from an existing SAP environment to SAP S/4HANA.

The legacy landscape contains thousands of:

• Bills of Material (BOMs);
• BOM alternatives;
• routings;
• work centers;
• production versions;
• engineering change records;
• plant-specific manufacturing structures.

The migration team initially treats these as separate data domains:

BOMs to migrate.
Routings to migrate.
Work centers to migrate.

From a technical migration perspective, this is understandable.

From a manufacturing perspective, it is incomplete.

A production process does not consume a BOM or routing in isolation. It depends on a valid combination of manufacturing master data, determined by material, plant, production version, validity, and business rules.

A more useful representation is:

Material + Plant + Production Version + BOM + Routing + Validity

A technically successful load of each individual object therefore does not prove that the production structure is usable in S/4HANA.

The real migration question is:

Can the target system reproduce the intended manufacturing process using the correct combination of master data?

The BOM problem: "Active" Does Not Always Mean "Required"

Manufacturing enterprises often accumulate years of BOM history.

A single material may have:

• multiple BOM alternatives;
• different BOM usages;
• plant-specific BOMs;
• different validity dates;
• engineering change numbers;
• obsolete components;
• replacement components;
• historical versions.

A BOM can therefore appear active in the legacy system while no longer representing the structure used by current production.

The opposite can also happen.

An older BOM may still be operationally relevant because it is required for:

• an active production scenario;
• spare-parts operations;
• service requirements;
• regulated products;
• contractual manufacturing;
• products with long lifecycle requirements.

This makes a simple rule such as:

"Migrate all active BOMs."

too simplistic.

The migration team needs to define active from a business-process perspective.

BOM usage and alternatives need business context

The migration should also distinguish between different BOM purposes.

For example, a manufacturer may maintain BOMs for:

• production;
• engineering;
• costing;
• maintenance;
• sales;
• other organizational requirements.

Not every BOM needs to become part of the operational production model in S/4HANA.

The same applies to BOM alternatives.

Two alternatives may represent:

• genuinely different manufacturing configurations;
• different plants;
• temporary engineering changes;
• obsolete production methods;
• valid options that should remain available in the target system.

The migration decision therefore needs to consider how the BOM is used, not simply whether the record exists.

Engineering changes add another layer of complexity

Engineering Changes Add Another Layer of Complexity

BOM migration becomes particularly sensitive when engineering change management is involved.

A component may be replaced at a specific effective date.

For example:

Component A → Component B

effective from:

1 January 2027

If the migration preserves the BOM but loses or incorrectly transforms the associated validity and change information, the resulting structure may be technically valid but operationally wrong.

This can affect:

• material requirements planning;
• production orders;
• costing;
• procurement;
• shop-floor execution;
• product compliance.

The migration therefore needs to preserve the business-effective structure, not simply the latest technical version of the BOM.

The routing problem

Routings create a similar challenge.

A routing may contain:

• operations;
• operation sequences;
• work centers;
• control information;
• standard values;
• setup and processing times;
• scheduling data;
• validity;
• production-specific parameters.

Loading a routing successfully does not mean that the target manufacturing process is correct.

For example, a routing may reference a work center that:

• no longer exists;
• has been renamed;
• has been consolidated;
• uses a different capacity model;
• has different scheduling parameters in the target template.

The routing may therefore pass a technical load validation while failing an actual production-planning scenario.

Work centers cannot be treated as a simple prerequisite

Work Centers Cannot Be Treated as a Simple Prerequisite

Work centers are another example of why object-by-object migration can be misleading.

A legacy manufacturer may have hundreds of work centers representing years of local operating practices.

As part of a global S/4HANA template, several legacy work centers may need to be:

• consolidated;
• renamed;
• remapped;
• restructured;
• retired.

That can affect routings and production planning.

Therefore the migration sequence should not simply be:

Load work centers → load routings → load BOMs.

The target manufacturing model should first establish how production resources are represented in S/4HANA.

The legacy objects then need to be mapped to that model.

Production version is the connection

This is where a superficial migration approach most often breaks down.

The production version provides an important link between the material, plant, BOM, and routing used for production.

Consider a simplified scenario:

Material A

→ Plant 1000

→ Production Version 0001

→ BOM Alternative 01

→ Routing Group 100

The migration team may successfully load all four records.

But the real question is:

Can S/4HANA determine and use the correct manufacturing combination under the intended production conditions?

If the production version points to the wrong BOM or routing, the individual records can all be technically valid while the manufacturing process is wrong.

This is why relationship validation is as important as object validation.

Manufacturing data Is a dependency Graph

Manufacturing Data Is a Dependency Graph

A better way to think about the migration is as a dependency graph rather than a collection of files.

For example:

Material

↓

Plant

↓

Production Version

↙︎　　　　　　　　　↘︎

BOM　　　　　　Routing

↓　　　　　　　　　　 ↓

Components　　 Operations

　　　　　　　　　　 ↓

　　　　　　　 Work Centers

Each relationship creates a potential migration dependency.

A change to one object can therefore affect several others.

This should influence:

• migration sequencing;
• mapping;
• cleansing;
• testing;
• reconciliation.

Historical structures need a different treatment

A manufacturer may have accumulated thousands of obsolete BOMs and routings over 10–20 years.

Migrating all of them can create unnecessary complexity in the target system.

The program should instead classify manufacturing structures according to their target business relevance.

The exact rules depend on the business and transition approach.

The principle is more important:

Historical existence does not automatically equal operational migration scope.

The Critical Question: What Does "Current" Mean?

The critical question: What does "Current" mean?

Manufacturing organizations should avoid relying on technical indicators alone.

For example, a BOM with a recent change date may not be part of current production.

A BOM that has not been changed for several years may still be the approved structure for a product manufactured every week.

"Current" should therefore be determined using a combination of:

• production activity;
• material status;
• production versions;
• validity dates;
• engineering status;
• plant usage;
• open production requirements;
• business ownership.

This is where manufacturing, engineering, planning, and data teams need to work together.

How it should be tested

A common migration KPI is:

"98% of BOMs loaded successfully."

That number says very little about whether the factory can operate.

A stronger validation approach starts with real manufacturing scenarios.

For example:

Scenario: Produce Material X at Plant 1000

1. Select the material and plant.
2. Determine the applicable production version.
3. Verify the selected BOM.
4. Verify the routing.
5. Confirm the required work centers.
6. Execute the relevant planning or production process.
7. Validate components and quantities.
8. Validate operations and sequencing.
9. Compare the resulting structure with the approved reference process.

Reconciliation should be relationship-based

This validates the business outcome, not simply the technical migration.

Reconciliation Should Be Relationship-Based

Reconciliation should also go beyond record counts.

For a BOM, validate:

• material;
• plant;
• BOM usage;
• alternative;
• components;
• quantities;
• units;
• validity.

For a routing:

• material;
• plant;
• operations;
• sequences;
• work centers;
• standard values;
• validity.

For a production version:

• material;
• plant;
• BOM;
• routing;
• validity;
• production parameters.

The objective is to prove that the target manufacturing structure is coherent.

What the migration team should deliver

What the Migration Team Should Deliver

For this data domain, the migration workstream should produce more than separate load files.

The key deliverables should include:

• BOM migration rules;
• routing migration rules;
• production-version mapping;
• work-center mapping;
• validity and engineering-change rules;
• dependency mapping;
• obsolete-data strategy;
• target manufacturing model;
• end-to-end validation scenarios;
• reconciliation rules.

This gives the business a clear answer to a critical question:

Which manufacturing structures will actually be available and usable after S/4HANA go-live?

4. Inventory and Open Production Orders: The Migration Problem Is the Cutover, Not the File

The situation

A manufacturer has to move from its legacy ERP to S/4HANA without stopping the factories for longer than the agreed cutover window.

At the freeze point, the system contains:

• stock across multiple plants;
• batch-managed inventory;
• serialized materials;
• quality and blocked stock;
• stock in transit;
• open purchase orders;
• open sales orders;
• reservations;
• production orders at different execution stages.

This is where migration architecture meets operational reality.

Inventory is not one number

A reconciliation such as:

Legacy inventory value = S/4HANA inventory value

is necessary but not sufficient.

The warehouse can still be wrong if quantities are assigned to the wrong plant, storage location, batch, or stock type.

A useful reconciliation model therefore works at several levels:

Material → Plant → Storage Location → Batch/Serial → Stock Type

where those dimensions are relevant to the material.

Financial reconciliation introduces another dimension.

Quantity and value need to be reconciled using the appropriate MM/FI logic rather than assuming that a single total proves the migration is correct.

Open production orders are more complicated

An open production order is not simply another master-data record.

Its migration depends on the target process and the status of the order.

An order may have:

• components already issued;
• operations partially confirmed;
• goods movements posted;
• quantities partially produced;
• reservations;
• dependencies on current BOMs and routings.

That raises an important question:

Is it actually appropriate to reproduce the legacy order as an open order in S/4HANA?

In some scenarios, the answer may be yes.

In others, the more reliable approach may involve closing or completing certain legacy transactions and creating new target-system transactions, with the appropriate financial and operational controls.

The correct answer is determined by the migration design—not by a generic rule that says “migrate all open orders.”

Why mock cutovers matter

The migration team should discover these issues before production cutover.

A serious program runs mock cutovers using representative or production-like data.

The team measures:

• extraction duration;
• transformation duration;
• load duration;
• reconciliation time;
• exception volumes;
• business validation time.

The cutover plan then evolves based on what actually happened.

The final control

At go-live, the migration team needs a defined reconciliation framework.

For example:

Stock quantity

Legacy approved closing position
→ migration adjustments
→ S/4HANA opening position

Inventory value

Legacy approved value
→ documented accounting/cutover treatment
→ S/4HANA value

Open operational documents

Approved legacy population
→ migration/transformation rules
→ approved S/4HANA population

The important word is approved.

Reconciliation is not merely a technical comparison. Business owners need to sign off on the opening position.

SAP focus: inventory migration, stock types, batches, serial numbers, open production orders, open documents, MM/FI reconciliation, mock cutover, and operational continuity.

5. Acquisition and ERP Consolidation: Mapping Is Not Harmonization

5. Acquisition and ERP Consolidation: Mapping Is Not Harmonization

The situation

A manufacturing group acquires a business running another ERP system.

The parent company already has an S/4HANA template.

The acquired company has its own:

• material numbers;
• suppliers;
• customers;
• BOMs;
• routings;
• inventory;
• purchasing processes;
• production structures;
• financial structures.

The first temptation is to build a cross-reference table:

Legacy material A123 → SAP material 10004567

That is necessary.

It is not the migration strategy.

The three different questions

For each important object, the program needs to distinguish between:

Mapping

The source record has a clear equivalent in the target.

Transformation

The source record is required, but its structure or attributes need to change.

Harmonization

There are multiple legitimate source records, and the business must decide how they should be represented in the corporate target model.

These are fundamentally different activities.

A material example

Suppose the acquired company and parent company both purchase what appears to be the same bearing.

The records have different numbers.

The descriptions are similar.

The supplier is the same.

That still does not automatically justify consolidation.

The engineering specification, unit of measure, quality requirements, approved manufacturer, or sourcing strategy may differ.

If the business decides that the materials really are the same, the target material becomes the corporate master and the acquired record is mapped to it.

If they are different, both remain.

If the acquired material is no longer required, it should not be migrated merely because it exists in the source ERP.

Supplier and customer identities create another problem

The same organization can appear multiple times across the two ERP landscapes.

The parent may already have a supplier master record for a company that appears under a different identifier in the acquired system.

This is where duplicate detection and business ownership matter.

The migration team needs to establish whether the records represent:

• the same legal entity;
• different legal entities within the same corporate group;
• different purchasing relationships;
• historical or obsolete entities.

Again, a technical mapping table cannot make that decision by itself.

The target operating model comes first

Before migration rules are finalized, the group needs to decide what the acquired business is becoming.

Will it use the corporate material model?

Will procurement be centralized?

Will the plant retain local manufacturing structures?

Will historical transactions remain in the acquired ERP?

Will the legacy system remain accessible after go-live?

These decisions determine migration scope.

The correct sequence is therefore:

Target operating model → data model → mapping rules → transformation → migration

not:

Extract everything → figure it out during loading.

Why this matters

The success of an acquisition migration is not measured by how many records were transferred.

It is measured by whether the acquired business can operate inside the corporate SAP model without recreating the fragmentation that the integration was supposed to eliminate.

SAP focus: S/4HANA integration, M&A migration, cross-reference mapping, master-data harmonization, supplier/customer consolidation, ERP coexistence, and target operating model.

FAQ

What These Five Scenarios Have in Common

What These Five Scenarios Have in Common

Although the scenarios are different, the underlying migration decisions are remarkably consistent.

A manufacturing migration has to distinguish between five treatments:

This classification is more useful than thinking of migration as a single ETL pipeline.

The same source object can even receive different treatment depending on its business context.

A material used in active production may be migrated.

An obsolete material referenced only by historical transactions may be retained outside the operational target.

A duplicate material may be harmonized into another target material.

A legacy custom field may be excluded because the target process no longer requires it.

The SAP Data Migration Work Is Really About Dependencies

The SAP Data Migration Work Is Really About Dependencies

One of the most common mistakes is to organize migration only by object type:

Materials
BOMs
Routings
Inventory
Orders

Manufacturing data is relational.

A more useful way to think about the migration is through business dependencies.

For example:

Material

→ plant extension
→ planning/procurement data
→ valuation
→ batch/serial behavior
→ BOM
→ routing
→ production version
→ production transaction

If the material is wrong, downstream structures may be wrong even if every individual load technically succeeds.

This is why reconciliation should also be designed around business processes.

The question should not only be:

“Did 99.8% of records load?”

It should also be:

“Can the plant plan, procure, produce, receive, issue, and ship using the migrated data?”

The second question is much closer to what the business actually needs from the migration.

SAP Data Migration Best Practices for Manufacturing

SAP Data Migration Best Practices for Manufacturing

A credible migration program typically needs more than a generic cleansing checklist.

The important controls are:

1. Define the target state before finalizing migration scope

Do not use the legacy database as the definition of what the target system should contain.

2. Profile data before designing transformations

Profiling should reveal duplicates, missing values, inconsistent codes, orphaned relationships, unexpected combinations, and obsolete populations.

3. Assign business ownership

The migration team can identify a questionable BOM.

It cannot decide whether the BOM represents the company's intended manufacturing process without the appropriate business owner.

4. Define object dependencies

Migration sequencing should reflect relationships between objects rather than treating each data domain independently.

5. Separate operational and historical requirements

Not every historical record belongs in the transactional S/4HANA system.

6. Reconcile at the level at which the business operates

For inventory, total quantity is rarely enough.

For manufacturing, record counts are rarely enough.

For finance, technical posting counts are not enough.

7. Use mock migrations to test the design

The purpose of repeated migration cycles is not simply to prove that the load program works.

Each cycle should reduce uncertainty in:

• data quality;
• transformation rules;
• dependencies;
• load performance;
• reconciliation;
• cutover timing.

8. Treat cutover as an operational event

The final migration has dependencies on transaction freezes, extraction, late postings, business validation, reconciliation, and release decisions.

9. Document exceptions

The difficult records are often more important than the easy 95%.

A migration program should know which exceptions remain, who approved them, and what happens to them after go-live.

10. Design governance for after go-live

If the organization fixes 100,000 duplicate materials but keeps the same uncontrolled creation process, the migration problem will eventually return.

FAQ

FAQ

What data is typically migrated to SAP S/4HANA in manufacturing?

The scope depends on the transition approach and target operating model. Common domains include material master, Business Partners, BOMs, routings, work centers, production versions, inventory, open purchasing and sales documents, production-related transactions, and financial data.

The important distinction is that each domain has different dependencies and migration rules.

How do you migrate manufacturing master data to SAP S/4HANA?

Start by defining the target model and business scope. Profile the source data, identify duplicates and obsolete records, establish mapping and transformation rules, resolve business exceptions, perform mock migrations, and validate the resulting structures in actual business processes.

How are BOMs and routings migrated to S/4HANA?

They should be analyzed as part of a manufacturing structure rather than as isolated objects.

The migration needs to consider BOM usage and alternatives, validity, engineering changes where relevant, routings, work centers, and production versions. The final test should demonstrate that the target system selects and uses the intended manufacturing structure.

How do you migrate inventory during an SAP implementation?

Inventory migration is normally designed around the cutover opening position. The approved legacy closing stock is extracted, transformed according to the target design, loaded, and reconciled.

Depending on the material and process, reconciliation may need to cover plant, storage location, stock type, batch, serial number, quantity, and value.

Should historical manufacturing data be migrated to S/4HANA?

Not by default.

The decision should consider operational use, reporting, audit, legal retention, regulatory requirements, and the target architecture. Historical information may be retained in the legacy environment or moved to an appropriate archive or reporting solution rather than loaded into the operational S/4HANA system.

How do you handle duplicate material records?

Do not equate similar descriptions with duplicate materials.

Potential duplicates should be identified through profiling and matching, then reviewed against engineering specifications, procurement requirements, plant usage, units of measure, and other relevant attributes.

The result may be consolidation, mapping, retention of both records, or retirement of one record.

What are the biggest SAP data migration risks in manufacturing?

The most serious risks are usually not failed data loads.

They are incorrect business decisions hidden behind technically successful loads: wrong material mappings, invalid manufacturing structures, incomplete plant data, inconsistent inventory positions, inappropriate open-order migration, and historical data being mixed with operational data.

How can manufacturers improve data quality before an S/4HANA migration?

Start with a measurable profiling exercise.

Identify the data that is actually required for the target operating model, define quality rules for that scope, assign owners to exceptions, and resolve the records that can affect production, procurement, inventory, sales, or finance.

Trying to make the entire legacy database “perfect” is usually neither practical nor necessary.

Conclusion

Conclusion

The difficult part of SAP data migration in manufacturing is rarely moving a record from one system to another.

The difficult part is deciding what that record means in the target business.

A material may be duplicated but not equivalent. A BOM may be active in SAP but obsolete in production. An open production order may exist in the legacy system but still require a business decision about whether it should survive the cutover. Inventory may reconcile financially while remaining wrong for a warehouse. An acquired supplier may look like a duplicate until legal-entity and purchasing relationships are considered.

These are not ETL problems.

They are decisions about the target operating model, SAP data structures, business processes, and operational risk.

That is why a manufacturing SAP migration should be designed around business objects and their dependencies, not simply around files and load programs.

The objective is not to move the maximum amount of legacy data into S/4HANA.

The objective is to make sure that, when the plant starts operating on the new system, the data required to plan, procure, manufacture, store, sell, and account for the business is correct—and that everything else has a deliberate disposition.

That is the difference between loading data into S/4HANA and actually migrating a manufacturing business to S/4HANA.

Disclaimer: The examples and migration scenarios described in this article are illustrative and intended for general informational purposes. The appropriate SAP data migration strategy, scope, tools, sequencing, and validation requirements depend on the customer’s existing SAP landscape, transition approach, business processes, data quality, industry requirements, and target S/4HANA architecture. Actual migration activities should be assessed and validated as part of a project-specific SAP migration strategy.