- Why It's Not Just a Compliance Issue
- Where Legacy Manufacturing Systems Most Often Create Data Gaps
- Why ERP or MES Alone May Not Solve the Problem
- The Common Modernization Mistake
- What to Check Before Starting a Large Modernization Project
- How to Modernize Without Disrupting Production
- When Does It Make Sense to Outsource Legacy System Modernization?
- When to Modernize and When Existing Systems Can Stay
- Conclusion
German manufacturing companies are actively moving toward more connected and data-driven operations. Initiatives such as Industrie 4.0 speed up investments in automation and real-time process insights. Also, the implementation of the Digital Product Passport (DPP) is creating new requirements. For product traceability, material data transparency, product lifecycle information, and sustainability performance.
It is natural for many manufacturing companies to ask a practical question: Are existing systems capable of reliably and consistently providing the necessary information?
The problem is that most manufacturers already use mature ERP, MES, quality management systems, and other manufacturing solutions. These systems have supported their business processes for many years. Production is running smoothly. It processes orders and generates reports. From an operational perspective, such systems often appear reliable and efficient.
But successful product management doesn’t mean a company can generate structured data throughout the product lifecycle.
When organizations begin assessing their readiness for Digital Product Passport, they often discover that the main challenge is different. It is not understanding the regulations themselves. The real issue is determining whether existing systems can provide the necessary data without extensive manual processing.
Why It’s Not Just a Compliance Issue
Discussions about the Digital Product Passport often revolve around regulatory compliance. Compliance teams determine what information should be accessible and documented. Sustainability specialists define reporting requirements. Product teams determine what characteristics to track. But translating these requirements into reliable data is the IT and operations teams’ job.
The necessary information is rarely stored in a single system. More often, it’s distributed across several applications developed and implemented over many years:
- ERP systems contain data on products, suppliers, and procurement
- MES platforms record production operations and events
- Quality management systems store inspection results and compliance data
- Supplier information may be stored in separate databases or external portals
- Engineering data is often stored in PLM systems
- Historical records often remain in spreadsheets, reports, or local tools of individual departments
As you see, it is a fragmented data landscape. Information exists but is difficult to integrate into a coherent picture.
For many manufacturing companies, the primary challenge is to understand where exactly the data resides. Also, who handles its quality, how reliable it is, and whether it can be consistently extracted and combined?
This is why you should view DPP readiness as a data readiness effort, not just as a compliance project. Companies should understand well their data flows and interdependencies between systems. Then, they are typically in a much better position than organizations that rely on manual processes and disparate applications.
Where Legacy Manufacturing Systems Most Often Create Data Gaps
Organizations often assume that if information already exists internally, it will be easy to use for Digital Product Passport initiatives. Experience shows that this is not always the case. When analyzing legacy manufacturing IT landscapes, we identify the same problem areas regularly.
Product Master Data
Product information is often distributed across many systems. But data might differ between ERP systems, engineering databases, and reporting tools. Over time, duplicate records and inconsistent naming make it difficult to create a reliable source of product data.
These inconsistencies are a common source of legacy ERP data gaps. Especially in environments where product information has evolved across many systems over many years.
Material and component data
Manufacturers typically maintain detailed records of materials. But the level of detail can vary significantly. Some information is in procurement systems, while engineering departments maintain more characteristics manually. As a result, obtaining a complete picture of the materials can be a lengthy and labor-intensive process.
Suppliers information
In some environments, supplier certifications are maintained outside the ERP because procurement teams needed a faster way to update records. Years later, those spreadsheets become the most current source of information, even though everyone assumes the ERP contains the latest data.
Responsibility for this data is often divided among several departments. This makes it difficult to identify the most reliable source of information.
Production batch/lot data
Product traceability in legacy systems often depends on batch and lot records captured across multiple applications. But tracking the stages between raw materials and finished products is often more difficult. In legacy environments, some of these may exist only in the form of ad hoc reports or manual procedures.
Quality records
Inspection and test results and certificates are often stored in separate systems. Even when information is available, linking it to specific products can require manual effort. As a result, quality data traceability can become significantly more difficult than expected.
Repair/service history
For products with long lifecycles, separate applications or external service databases usually store service and repair data. This is a challenge when a company needs a complete picture of a product’s lifecycle after it leaves production.
Sustainability/lifecycle data
Many manufacturers are just beginning to collect sustainability-related information. Data on recycled content, environmental impact, energy consumption, and life-cycle indicators are often incomplete. It is scattered across various sources or even located outside of operational systems.
Reporting logic hidden in old systems or spreadsheets
Manufacturing reporting systems are often one of the least understood parts of a legacy application landscape. We often encounter production environments where important calculations live inside SQL procedures or spreadsheet macros created years ago. The original developers may no longer be available. But those rules still affect inventory or production reporting every day.
An organization may know how to generate a specific report. But few employees understand how to perform the underlying calculations. When such reports become part of regulatory compliance, hidden dependencies quickly become a serious risk.
Often, such data gaps do not interfere with the day-to-day operations of the enterprise. Problems become clear when the company needs to provide structured product information or integrate data from many systems. At this point, the limitations that have remained unnoticed for years come to the stage.
Why ERP or MES Alone May Not Solve the Problem
When companies discuss DPP readiness, they often assume that the necessary data already is in an ERP or MES system. But the situation is usually much more complex.
Discussions around legacy MES modernization often focus on replacing production systems. In practice, the larger challenge is understanding how MES, ERP, reporting, and quality systems work together. Effective ERP MES integration in manufacturing environments is often more important than replacing individual systems.
An ERP system may indeed contain a significant part of the information. An MES platform records manufacturing operations, order statuses, and production events. But neither system captures the entire picture.
For example, a team can store quality data in a separate quality management system. Supplier certification information may reside in external portals or local databases. And people often manage exceptions and adjustments in spreadsheets outside the company’s IT landscape.
Established manufacturing companies often create custom applications to solve specific business problems. Such systems may contain critical business logic or reporting rules that no one wants to change due to the risk of disrupting workflows.
As a result, the data needed for product traceability and DPP preparation ends up distributed across many system layers.
The problem is not the lack of an ERP or MES. The challenge lies in securely integrating these data layers and preserving the business logic accumulated over years of use.
This is why projects related to DPP and Industrie 4.0 most often involve integration, data management, and modernization of the existing landscape.
Field Note
In one manufacturing software modernization project, what initially appeared to be a simple requirement quickly revealed years of embedded business logic. During the assessment, the team identified more than 100 specialized unit types, reporting dependencies, and custom rules distributed across multiple modules.
Replacing the platform would have introduced significant operational risk. A phased modernization approach allowed the company to preserve proven functionality while addressing the most important limitations first.
The project became an example of business-critical software modernization where operational continuity was as important as technical improvement.
The Common Modernization Mistake
When organizations discover limitations in their systems, they often lean toward one of two approaches. This pattern appears frequently in organizations running old manufacturing software that has supported operations for many years.
The first option is to completely replace existing solutions. The logic seems simple: if old systems are creating problems, you must implement a new platform and make a new start. But this approach entails high costs and a high risk of losing business logic.
In one modernization project for a manufacturing technology company, the business depended on 14 applications built on Delphi 7 and a larger ecosystem of interconnected systems. The initial temptation could have been a full platform replacement.
Instead, the modernization started with understanding application dependencies, platform constraints, security requirements, and embedded business logic. The result was a phased migration to a modern technology stack without disrupting existing operations or requiring a complete rewrite.
This approach allowed the company to preserve proven functionality while reducing operational and compliance-related risks.
The second option is to postpone the changes and continue to resolve the problem manually. In this case, employees continue to combine data from different sources. They keep maintaining additional tables and creating temporary reports. This approach may work for a while, but as reporting requirements increase, the workload on teams inevitably grows too.
Both scenarios carry risks.
Usually, the most effective first step is a detailed assessment of the existing IT landscape and data flows.
Before making decisions about major investments or a complete system upgrade, answer a few questions:
- Where exactly is critical product and production data located?
- Which systems continue to perform effectively and don’t require replacement?
- Where are employees using manual workarounds?
- Where is business logic hidden, the loss of which could lead to operational problems?
- Which processes need integration between systems?
- Which components can be gradually modernized without disrupting business?
Often, such an analysis shows that you can continue using some part of existing solutions. The primary focus is on integration, improving data quality, and gradually modernizing the most problematic areas.
What to Check Before Starting a Large Modernization Project
Before undertaking a major modernization program, assess the current state of your systems and dependencies. The following checklist helps identify key risks and prioritize change.
Data and Systems Readiness Assessment Checklist
A focused legacy software assessment can help identify risks before major investments are made. These are the questions that might be helpful:
- Which systems contain product and production data? Is there an understanding of where data on products, materials, manufacturing operations, and suppliers resides?
- What data do you consider reliable, and what is usually manually corrected? If employees are constantly manually correcting information, this may indicate data quality issues or integration gaps.
- Which reports rely on legacy business logic? Understand what rules are hidden within old scripts or custom applications.
- Which integrations are the most vulnerable? Are there interfaces between systems that are difficult to maintain or document?
- Which processes rely on the knowledge of one or two employees? Such dependencies often become risky when upgrading and handing over systems to new teams.
- Which systems are difficult to change without risking regression? If even a small change requires extensive testing or raises concerns for the business, you should consider such a system when planning the upgrade.
- What data will be required for DPP, traceability, and reporting? Determine what data is already available and what you should collect from other sources.
- What improvements can be implemented without a complete system overhaul? Often, modernization of individual components or an architecture update can resolve significant issues without a costly and risky complete rewrite.
Answering these questions helps plan a custom ERP modernization strategy and understand what changes are truly necessary. The goal is to improve Digital Product Passport readiness in manufacturing and further develop Industry 4.0 initiatives.
How to Modernize Without Disrupting Production
After identifying data gaps, many companies wonder how to move forward. This is especially true if existing systems support critical business processes and any major change could impact production.
In practice, manufacturing systems modernization is rarely a quick or simple project. Most mature manufacturing IT landscapes have evolved over many years and contain many dependencies between ERP, MES, quality systems, reporting, and custom applications.
Therefore, the safest approach usually involves a phased modernization for manufacturing software.
#1 Taking an inventory of systems and data flows
This stage is essentially a data flow mapping manufacturing exercise that helps organizations understand how information moves across systems.
The first step is understanding the current picture. It’s important to determine:
- which systems are involved in product and manufacturing management
- what data is stored in each system
- how data is transferred between applications
- and which processes rely on manual input or extra tables
Many organizations at this stage discover dependencies that were not fully documented before.
#2 Data Readiness Assessment
The next step is to analyze the quality and availability of data. The goal is to improve production data management before larger modernization decisions are made. It is important to understand:
- what data is available in a structured format
- what data requires manual processing
- where duplicate records exist
- what information is needed for product traceability, reporting, and the Digital Product Passport
The purpose of this analysis is not only to identify missing data but also to assess the reliability of existing information.
#3 Creating a Risk Map
After analyzing the data, it’s useful to create a risk map of the existing IT landscape. This typically includes:
- legacy systems with high business dependencies
- critical integrations
- complex reports and calculations
- manual workarounds
- components that are difficult to change without risking regression
This approach allows you to identify the most sensitive areas before making changes.
#4 Small Modernization Steps
Often, initial improvements don’t need to replace core systems. The greatest impact can be achieved by:
- creating modern data access interfaces
- implementing integration and data extraction layers
- cleaning and standardizing reporting
- eliminating unstable integrations
- and reducing manual operations
Such changes improve data availability and quality without disrupting production processes.
#5 Long-Term Modernization Plan
Once you have a more complete picture, you can make decisions about larger-scale changes. For some companies, this may mean a phased software migration of individual components. For others, it may mean a gradual refactoring of existing applications. In some cases, replacing individual systems may be appropriate.
Make such decisions based on an understanding of real dependencies and risks, not assumptions.
Modernizing production systems is rarely a simple transformation. But a phased approach can reduce risks and maintain business continuity.
When Does It Make Sense to Outsource Legacy System Modernization?
Not every organization requires external support. Many internal teams are well-versed in their processes and successfully manage the evolution of existing systems.
But there are situations when engaging legacy system modernization specialists can help mitigate risks and speed up the preparation phase. In practice, this most often occurs when:
- the internal team has a strong understanding of business processes but lacks sufficient resources to analyze and modernize legacy systems
- the company no longer collaborates with the original contractor or system developers
- documentation is incomplete or missing
- the current IT team is fully focused on supporting operations
- modernization should be performed without interrupting production and critical processes
- the system contains a large volume of old code, custom modifications, reports, and integrations that are difficult to evaluate without additional analysis
In such cases, external specialists can help conduct a technical assessment. They can identify dependencies between systems and determine modernization options without the need to immediately replace the existing solution.
When to Modernize and When Existing Systems Can Stay
| To modernize | To keep |
| You can’t extract critical data reliably | Data quality is reliable |
| Manual reporting is growing | Integrations are documented |
| Integrations are difficult to maintain | You can reproduce the reporting |
| Business logic is poorly understood | Business logic is understood |
| Traceability requirements expose data gaps | Modernization risk exceeds expected business value |
Conclusion
Preparing for Digital Product Passport and further developing Industry 4.0 initiatives doesn’t begin with a major system rewrite.
The first step is understanding whether existing systems can provide reliable and traceable data. Where the key data gaps lie and what risks are associated with the current IT landscape. For many manufacturing companies, the key challenge is understanding which systems continue to perform effectively and which require modernization.
Before deciding on a major modernization project, conduct a targeted assessment of existing systems, data flows, and integration risks. This analysis helps determine what you can preserve and which areas require attention, and where a phased modernization approach would be more secure and cost-effective.
In our experience, the most successful legacy software modernization initiatives rarely start with replacing systems. They start with understanding data flows, business dependencies, and operational risks. Only then does it become clear what can remain unchanged, what requires modernization and where gradual improvements will deliver the greatest value.