Skip to content
ERP Migration

Migrating Manufacturing Data: Preserving Bill of Materials and Routing Logic

A practical guide for CIOs and ERP consultants on migrating complex manufacturing data, specifically focusing on preserving Bill of Materials (BOM) hierarchies and routing logic without disrupting production.

9 min readSysGenPro Editorial
Migrating Manufacturing Data: Preserving Bill of Materials and Routing Logic

Direct Answer: How to Preserve BOM and Routing Logic During Migration

Migrating manufacturing data requires a structured approach to preserve the integrity of Bill of Materials (BOM) hierarchies and routing logic, which are the backbone of production planning. The recommended approach involves a phased migration strategy that prioritizes data profiling, rigorous mapping of hierarchical structures, and extensive validation in a staging environment before cutover. This process is critical because BOMs and routings define how products are made; errors in these data sets lead directly to production stoppages, material shortages, or incorrect costing. The main risks to control include data loss during transformation, broken parent-child relationships in multi-level BOMs, and misaligned routing sequences that disrupt work center scheduling. By treating manufacturing data as a distinct, high-risk domain within the broader ERP migration, organizations can maintain operational continuity and ensure that the new system accurately reflects real-world production processes.

Phase 1: Data Profiling and Structural Analysis

Before any data is moved, a comprehensive profiling of the source system is essential. Manufacturing data is rarely flat; it is deeply relational. BOMs are hierarchical, with parent items referencing child components, which may themselves be parents to sub-assemblies. Routings are sequential, linking operations to specific work centers with defined time standards and resource requirements. The first step is to extract a representative sample of this data and analyze its structure. Identify the depth of BOM hierarchies, the number of active versus obsolete versions, and the complexity of routing paths. Look for anomalies such as circular references, missing parent items, or operations without assigned work centers. This phase establishes the baseline for data quality and helps identify gaps that must be resolved before migration. It also reveals the volume of data, which impacts migration timing and resource planning.

Identifying Critical Dependencies

BOMs and routings do not exist in isolation. They depend on item master data, work center definitions, and resource calendars. During profiling, map these dependencies to understand the full scope of the migration. For example, a routing operation might reference a specific machine that has a unique maintenance schedule in the legacy system. If the new ERP handles maintenance differently, this dependency must be addressed. Similarly, BOM components must have valid item records with correct units of measure and inventory status. Failing to account for these dependencies can result in data that loads successfully but fails during production planning or order execution.

Phase 2: Data Mapping and Transformation Rules

Data mapping is the process of defining how fields in the source system correspond to fields in the target system. For manufacturing data, this is particularly complex due to the need to preserve hierarchical and sequential logic. Standard field mapping is insufficient; you must define transformation rules that handle the structure of BOMs and routings. For BOMs, this involves mapping parent-child relationships, ensuring that the hierarchy is preserved in the target system. For routings, it involves mapping operation sequences, work centers, and time standards. Transformation rules should also handle data cleansing, such as standardizing units of measure, removing obsolete BOM versions, and consolidating duplicate items. These rules must be documented and approved by both IT and manufacturing stakeholders to ensure that the business logic is accurately translated.

Handling Multi-Level BOMs

Multi-level BOMs are a common source of migration errors. The transformation process must ensure that the parent-child relationships are correctly established in the target system. This often requires a specific load order: parent items must be loaded before child items, or the system must support recursive loading. Additionally, BOM versions must be managed carefully. If the legacy system has multiple active BOM versions for the same item, a decision must be made on which version to migrate. Typically, only the current active version is migrated, with historical versions archived or discarded. This decision must be documented to avoid confusion during post-migration validation.

Phase 3: Staging Environment Validation

A representative staging environment is critical for validating the migration of manufacturing data. This environment should mirror the production system in terms of data volume and complexity. Load the transformed data into the staging environment and run a series of validation checks. These checks should include structural validation, ensuring that BOM hierarchies are intact and routing sequences are correct. Functional validation involves creating test production orders and running material requirement planning (MRP) to see if the system generates the correct component requirements and operation schedules. Compare the results from the staging environment with the expected outcomes from the legacy system. Any discrepancies must be investigated and resolved before proceeding to the next phase. This phase is where most migration errors are caught, making it a crucial step in the process.

Reconciliation and Audit Trails

Reconciliation involves comparing the data in the source and target systems to ensure that no records are lost or altered during migration. For manufacturing data, this includes counting the number of BOM lines, routing operations, and work centers in both systems. Discrepancies must be explained and resolved. Additionally, an audit trail should be maintained to track the transformation of each record. This audit trail is essential for troubleshooting issues that arise after go-live. It allows you to trace a problematic BOM or routing back to its source record and the transformation rules that were applied. This level of detail is often overlooked but is vital for maintaining data integrity and accountability.

Phase 4: Cutover Planning and Execution

Cutover is the final step in the migration process, where the new system goes live. For manufacturing data, cutover planning must account for the timing of production schedules. Ideally, cutover should occur during a period of low production activity to minimize the impact of any issues. A detailed cutover runbook should be created, outlining the steps for final data loads, validation checks, and go/no-go criteria. The runbook should include rollback procedures in case of critical failures. During cutover, a freeze on changes to BOMs and routings in the legacy system is essential to ensure that the data loaded into the new system is consistent. After the data is loaded, a final validation should be performed to confirm that the manufacturing data is accurate and complete. Only after this validation is passed should the new system be declared live.

Go/No-Go Criteria

Go/no-go criteria are the specific conditions that must be met before the new system is declared live. For manufacturing data, these criteria should include the successful completion of all validation checks, the resolution of all critical defects, and the sign-off from key stakeholders, including production managers and IT directors. The criteria should be objective and measurable, such as '100% of BOM hierarchies validated' or 'No critical routing errors found in test production orders.' If any of these criteria are not met, the go-live should be delayed until the issues are resolved. This disciplined approach helps to prevent the introduction of data errors into the production environment, which can have significant operational and financial consequences.

Phase 5: Post-Migration Stabilization

After go-live, the focus shifts to stabilizing the new system and ensuring that manufacturing data continues to be accurate and reliable. This phase involves monitoring the system for any issues that may not have been caught during testing. Common issues include unexpected behavior in MRP runs, incorrect costing, or production order scheduling errors. A dedicated support team should be available to address these issues quickly. Additionally, user feedback should be collected and analyzed to identify any areas where the new system does not meet user expectations. This feedback can be used to make adjustments to the data or the system configuration. The stabilization phase typically lasts for several weeks, during which the system is closely monitored and any necessary fixes are applied.

Continuous Improvement

Manufacturing data is dynamic, with BOMs and routings changing frequently as products evolve. The new ERP system must support these changes efficiently. This requires a robust change management process that ensures that updates to BOMs and routings are made correctly and consistently. Training for users on how to manage manufacturing data in the new system is also essential. This training should cover best practices for creating and updating BOMs and routings, as well as how to troubleshoot common issues. By investing in continuous improvement, organizations can ensure that the benefits of the ERP migration are sustained over time.

Risk Management and Mitigation Strategies

Migrating manufacturing data carries inherent risks, but these can be mitigated with a well-planned approach. Key risks include data loss, broken hierarchies, and operational disruption. To mitigate data loss, implement robust backup and restore procedures. Before each migration attempt, take a full backup of the source system and test the restore process. To mitigate broken hierarchies, use automated validation tools that check for parent-child relationships and circular references. To mitigate operational disruption, plan cutover during low-activity periods and have a rollback plan in place. Additionally, involve manufacturing stakeholders throughout the migration process to ensure that their needs are met and that they are prepared for the changes. By proactively managing these risks, organizations can increase the likelihood of a successful migration.

Role of Technology and Tools

While manual processes can be used for small-scale migrations, technology and tools are essential for large-scale manufacturing data migrations. Data migration tools can automate the extraction, transformation, and loading of data, reducing the risk of human error. These tools often include features for data validation, error reporting, and audit trails. Additionally, integration platforms can be used to connect the legacy and new systems, enabling real-time data synchronization during the transition period. When selecting tools, consider their ability to handle complex hierarchical data and their compatibility with the source and target systems. It is also important to verify that the tools support the specific features of the ERP system, such as multi-level BOMs and routing sequences. By leveraging the right technology, organizations can streamline the migration process and improve data accuracy.

Conclusion: Ensuring Long-Term Success

Migrating manufacturing data, particularly BOMs and routing logic, is a complex but manageable process. By following a structured approach that includes data profiling, rigorous mapping, extensive validation, and careful cutover planning, organizations can preserve the integrity of their manufacturing data and ensure a smooth transition to the new ERP system. The key to success lies in attention to detail, stakeholder involvement, and a commitment to quality. By treating manufacturing data as a critical asset and investing in the resources needed to migrate it accurately, organizations can unlock the full potential of their new ERP system and drive operational efficiency. Remember that the migration is not just a technical exercise but a business transformation that requires careful planning and execution.

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

Frequently asked questions

Common questions on this topic. Talk to our team for anything specific to your business.

01What is the most critical data to preserve in a manufacturing ERP migration?

Bill of Materials (BOM) hierarchies and routing logic are the most critical data to preserve. These data sets define how products are made and are essential for production planning, scheduling, and costing. Errors in these areas can lead to production stoppages and financial losses.

02How do you handle multi-level BOMs during data migration?

Multi-level BOMs require careful mapping of parent-child relationships. The migration process must ensure that the hierarchy is preserved in the target system, often by loading parent items before child items or using recursive loading techniques. Only the current active BOM version is typically migrated.

03What are the risks of losing routing logic during an ERP upgrade?

Losing routing logic can disrupt work center scheduling, lead to incorrect production order sequencing, and cause delays in manufacturing. It can also result in inaccurate costing and resource allocation, impacting overall operational efficiency.

04How long does it take to validate manufacturing data after migration?

The time required for validation depends on the complexity and volume of the data. For large manufacturing operations, validation can take several weeks. It involves structural checks, functional testing, and reconciliation with the source system.

05Should we clean BOM data before or after migration?

BOM data should be cleaned before migration. Cleaning the data in the source system or during the transformation phase ensures that only accurate and relevant data is loaded into the new system. This reduces the risk of errors and simplifies the validation process.

06How do you test routing logic in a staging environment?

Routing logic is tested by creating test production orders and running material requirement planning (MRP) in the staging environment. The results are compared with expected outcomes from the legacy system to ensure that operation sequences, work centers, and time standards are correctly mapped.

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