Skip to content
ERP Migration

Data Mapping Best Practices for Complex Manufacturing BOM and Routing Structures

Learn how to map complex Bill of Materials and Routing structures during ERP migration. This guide covers hierarchy preservation, phantom items, version control, and validation strategies to ensure production continuity.

5 min readSysGenPro Editorial
Data Mapping Best Practices for Complex Manufacturing BOM and Routing Structures

Data Mapping Best Practices for Complex Manufacturing BOM and Routing Structures

Effective data mapping for complex manufacturing Bill of Materials (BOM) and Routing structures requires a hierarchical, version-aware, and validation-heavy approach. Unlike simple master data, BOMs and routings define the physical and logical flow of production. Errors in these structures lead directly to production stoppages, inventory discrepancies, and financial misreporting. The primary risk is the loss of hierarchical integrity, where parent-child relationships are broken or quantities are miscalculated during transformation. To mitigate this, organizations must treat BOM and routing migration as a distinct, high-priority workstream. This involves detailed profiling of source data, explicit mapping rules for hierarchy levels, phantom items, and alternative routings, and rigorous reconciliation against source systems. Success depends on preserving the exact logic of the legacy system while adapting it to the target ERP's data model. This guide outlines the practical steps to achieve this, focusing on preparation, execution, and validation to ensure operational continuity.

Preparation: Profiling and Structural Analysis

Before writing any mapping rules, you must understand the complexity of the source data. Manufacturing BOMs are rarely flat; they often contain multi-level assemblies, sub-assemblies, and phantom items that do not exist in inventory but are used for planning. Routings are similarly complex, involving multiple work centers, setup times, run times, and alternative paths. The first step is a deep data profiling exercise. Identify the maximum depth of BOM hierarchies, the number of active BOM versions, and the variety of routing types. Look for anomalies such as circular references, missing components, or zero-quantity lines. These issues must be resolved in the source system or handled explicitly in the transformation logic. Engage production planners and engineers to define which BOM versions and routings are critical for the cutover. Not all historical data needs to be migrated; focus on active and recently used structures. This scoping decision reduces migration risk and improves performance. Document the source data structure in detail, including field definitions, data types, and relationships. This documentation serves as the foundation for the mapping specification.

Identifying Critical Data Elements

Not all fields in a BOM or routing are equally important. Identify the critical elements that drive production planning and execution. For BOMs, this includes the parent item, component item, quantity per, scrap factor, and effective dates. For routings, this includes the operation sequence, work center, setup time, run time, and yield. These fields must be mapped with high precision. Secondary fields, such as notes or historical cost data, may be less critical but should still be reviewed. Determine which fields are mandatory in the target ERP and which are optional. This helps in prioritizing data cleansing efforts. For example, if the target ERP requires a specific work center code that does not exist in the source, a mapping table must be created. This preparation phase is crucial for avoiding rework later in the project.

Mapping Hierarchy and Version Control

The core challenge in BOM migration is preserving the hierarchical structure. Most ERP systems store BOMs as a series of parent-child relationships. The mapping logic must ensure that every component is correctly linked to its parent. This requires a recursive or iterative approach to process the data. Start with the top-level assemblies and work down to the lowest-level components. This ensures that parent records exist before child records are created. Version control is another critical aspect. Manufacturing BOMs often have multiple versions, such as engineering change orders (ECOs) or seasonal variations. The mapping must preserve the version history and effective dates. Determine which version is active at the time of cutover and migrate only that version, or migrate all versions if historical tracking is required. The target ERP may handle versions differently than the source. For example, some systems use a single BOM with effective dates, while others use separate BOM records for each version. The mapping rules must account for this difference. Failure to handle versions correctly can lead to production orders using outdated BOMs, resulting in incorrect material requirements.

Handling Phantom Items and Virtual Assemblies

Phantom items, also known as virtual assemblies, are BOM lines that are used for planning but are not stocked in inventory. They are exploded into their components during material requirement planning (MRP). Mapping phantom items requires special attention. The target ERP must support phantom items, and the mapping logic must correctly flag them. If the target system does not support phantom items, they must be converted into regular items or the BOM structure must be flattened. This decision has significant implications for inventory management and production planning. Consult with the target ERP vendor or documentation to understand how phantom items are handled. Ensure that the mapping logic preserves the explosion logic, so that MRP calculations remain accurate. Phantom items are often used to simplify BOM structures, so their correct migration is essential for maintaining planning efficiency.

Routing Data Transformation

Routing data defines the sequence of operations required to produce an item. It includes work centers, setup times, run times, and labor costs. Mapping routings is complex because it involves multiple tables and relationships. The mapping logic must preserve the operation sequence and ensure that each operation is linked to the correct work center. Work centers may have different names or codes in the source and target systems. A mapping table is required to translate source work center codes to target codes. Setup and run times must be converted to the units used in the target ERP. For example, if the source uses minutes and the target uses hours, a conversion factor must be applied. Alternative routings, which are used for different production scenarios, must also be mapped. Ensure that the target ERP supports alternative routings and that the mapping logic correctly links them to the BOM. Routing data is critical for production scheduling and capacity planning. Errors in routing data can lead to inaccurate production schedules and resource conflicts.

Mapping Scrap Factors and Yield Rates

Written by
SysGenPro Editorial

SysGenPro Editorial

Platform & solutions team

Practical guidance on ERP, AI automation, cloud deployment and enterprise transformation from the SysGenPro team.

Share this article
Continue learning
View all articles
Explore the platform

Where to go next

Browse the knowledge hub

See how SysGenPro fits your business

Discuss your workflows, modules and deployment options with our team.

Back to resources