Many manufacturing companies have had ERP and MES systems in successful operation for 15, 20, or even 25 years. They continue to perform their core functions: planning production, managing materials, collecting data from equipment, and storing product quality information.
At first glance, the system appears to be functioning normally. Problems start emerging when the business requires something new. For example, connecting another production line or implementing modern dashboards.
Suddenly, even small changes need weeks of analysis. They affect many systems simultaneously and require manual data corrections. The reason is not always the ERP or MES.
Much more often, limitations happen in the integration layer – the mechanisms for exchanging data between ERP, MES, QMS, WMS, BI systems, internal applications, and production equipment. This layer typically develops spontaneously over many years and eventually becomes the most complex element of the company’s entire IT infrastructure. Many of these integration issues also affect Digital Product Passport readiness.
Key Takeaways
- For many manufacturing companies, the problem is the layer of integrations between systems.
- Data exchange is often based on files, scripts, Excel, direct database connections, and legacy APIs.
- Before changing the ERP or implementing a new integration, understand the existing data flows and dependencies.
- A phased modernization allows you to reduce operational risks and improve the architecture without interrupting production.
- The goal of modernization is to make data exchange transparent and manageable.
Why ERP/MES Integrations Become Fragile Over Time
Almost no manufacturing company implements all its information systems simultaneously. Usually, the ERP comes first. A few years later, companies add an MES. Then comes a quality management system, a warehouse system, a BI platform, new equipment, and internal applications for production planning or process control. Each project addresses a specific business need. And almost every project creates a new integration.
At first, everything seems straightforward. The ERP exports production orders daily in CSV format. The MES receives them on schedule. The quality system imports test results via XML files. For reporting, developers write several SQL queries directly to the database.
Each of these solutions is justified. The problem is that such manufacturing system integrations rarely remain static. Over time, new requirements emerge and business processes change. Gradually, a complex web of dependencies develops that no one designed specifically for it.
What does this look like in practice?
Let’s imagine a manufacturing company that uses:
- ERP for production planning
- MES for production operations management
- QMS for quality control
- WMS for warehouse management
- Power BI for management reporting
- Several in-house developed applications
All these systems operate reliably on their own. The main challenges arise where they interact. Production orders are transferred from the ERP to the MES. The MES supplements them with actual production data. The quality control system links test results to production batches. The BI platform integrates information from many sources at the same time. Some directories are updated manually, some data is adjusted in Excel, and some reports use direct SQL queries to production databases.
This system works up to a point. But if you change the structure of a single table or upgrade the ERP, processes that at first glance seem unrelated to the changes suddenly stop working. The reason is simple: many undocumented dependencies.
The Integration Layer Becomes More Complex Gradually
Unlike major disasters, legacy ERP/MES integration problems rarely happen suddenly. More likely, they accumulate over years. A script written as a temporary solution might continue to work even for seven years.
An Excel file created during data migration becomes a necessary part of operators’ daily work. Employees used a direct connection to the database because it made it faster to implement a new report. Each of these solutions seems insignificant.
But together, they create an architecture that makes it increasingly difficult to understand where data comes from and which systems depend on each other. At some point, the IT team starts spending more time searching for the causes of discrepancies between systems. Instead of developing the production processes.
#Fieldnote
In many production system modernization projects, the most critical component turns out to be not the ERP or MES, but a small script that has been running unchanged for years. As long as it’s doing its job, no one thinks about it. But it’s precisely these undocumented dependencies that often become the main source of risk during modernization.
Common Signs the Integration Layer Needs Attention
Companies rarely decide to modernize their integrations just because the technology is outdated. Usually, the reason is very specific operational issues. If you observe several of the following signs, it’s probably worth focusing on the data exchange architecture between them, rather than the ERP or MES itself.
| Sign | Possible consequences |
| The same production data differs in ERP and MES | Management is losing confidence in reporting |
| Excel is used to transfer information between systems | The number of manual errors is increasing |
| Reports require constant manual adjustments | Report preparation takes longer |
| Production events appear with a delay | It is more difficult to make operational decisions |
| Quality control data is not linked to production batches | Product traceability is becoming more complex |
| Even small changes lead to integration failures | The cost of support is constantly increasing |
| Only one employee understands how integrations work | High operational risk arises |
It’s important to understand that none of these signs mean that you should replace the ERP or MES. More often, they mean that the data exchange architecture is no longer aligned with current business needs.
If product traceability is becoming difficult, this readiness checklist can help identify the underlying gaps.
What Not to Do
When integrations between ERP, MES, and other manufacturing systems begin to create problems, the first instinct is to replace one of the core systems. In practice, this rarely resolves the root cause. As we already said, the problems often stem from the layer of integrations accumulated over the years. Before deciding on a major upgrade, try to avoid several common pitfalls.
- Don’t start with ERP replacement. If existing data flows and dependencies are not documented, the new ERP will face the same problems. The problems won’t disappear just because the core system changes.
- Don’t change MES until you understand how data flows. Discrepancies between ERP and MES don’t always mean that one system is malfunctioning. Data conversions, different synchronization schedules, or manual adjustments between exchange stages can cause them.
- Don’t build a new data warehouse before analyzing existing data flows. A modern BI platform or data warehouse won’t fix errors in the source data. If information comes from different sources with different processing rules, a new warehouse will only transfer existing problems to the new architecture.
- Do not connect systems with new temporary scripts. Whenever there is a new integration task, the quickest option is to write a small script. This is how another SQL Job, PowerShell script, or synchronization service is born. Each of these solutions seems temporary, but over time, they become the most critical elements of the architecture.
Start With Integration Mapping
Before choosing technologies, understand how data flows through the enterprise. Many companies don’t have a unified integration framework. The ERP team knows only its own interfaces, MES specialists know theirs, and internal application developers know only their own services.
So, the first step in any ERP/MES integration modernization is creating a data flow map. For each interface, describe the following parameters.
| What needs to be determined | Example |
| Data source | ERP, MES, QMS |
| Data owner | Production planning |
| Frequency | Every 5 minutes |
| Direction | ERP → MES |
| Transformation logic | Conversion of product codes |
| Manual correction points | Adjusting Excel before importing |
| Failure points | FTP error, sync service stopped |
| Business impact | Unable to start production order |
This type of mapping helps answer questions:
- Where does the data actually come from?
- Where does it change?
- What processes depend on a specific integration?
- What happens if this interface stops working?
Only then is it easier to decide on modernization.
Decide What to Keep, Wrap, Refactor, Replace or Integrate
After analyzing the architecture, you will likely see that not every component needs a complete replacement. More often, it is more effective to modernize only the problematic ones and preserve the business logic.
| Situation | Recommended action |
| System works but data access is poor | Wrap |
| Integration is unstable | Refactor |
| Manual transfer creates risk | Integrate |
| Logic is valuable but hidden | Refactor |
| Component blocks operations | Replace |
This legacy modernization approach helps gradually cut technical debt without a large-scale project of replacing the ERP or MES.
Modernization Patterns
Once the existing manufacturing software integration landscape has been mapped, the next step is deciding how to improve it. In most manufacturing environments, modernization does not require rebuilding the entire integration architecture. Instead, teams usually address the most fragile parts first while preserving stable components that continue to deliver business value.
Although every environment is different, most ERP/MES integration modernization projects rely on a small number of proven patterns.
- Creating an API layer. In many legacy systems, apps access the ERP database directly. Adding an API allows for centralized data access and reduces the number of direct dependencies between systems.
- Data extraction layer. Reporting, BI, and analytics services shouldn’t interact directly with production databases. A dedicated data acquisition layer reduces the load on production systems and makes the architecture more predictable.
- Message queue/event-based exchange. If the exchange is based on batch uploads or CSV files, it makes sense to gradually transition to an event-driven model. This provides faster receipt of production data and reduced latency between the ERP and MES.
- Reporting layer cleanup. Often, differences in data flows cause reporting issues, not the BI tool. Unifying data sources and transformation rules is usually more effective than replacing the reporting system.
- Integration monitoring. Integrations should report problems automatically. Monitoring allows you to rapidly detect synchronization errors and service failures before they impact production.
- Gradual replacement of risky scripts. Almost every manufacturing company has small services, SQL Jobs, or PowerShell scripts that somebody wrote as temporary solutions. These are often the most vulnerable elements of the integration architecture. It’s safer to replace them gradually, one component at a time, rather than attempting to rewrite the entire system at once.
Modernizing the integration layer usually delivers faster business value than replacing core manufacturing systems.
See how we modernized a long-running industrial software platform while preserving business-critical functionality.
#Fieldnote
In many projects, it turns out that the most important integration is not between the ERP and MES but between two small internal services that have been providing production data transfer for years. Until companies document these dependencies, any changes are associated with increased risk.
How to Avoid Production Disruption
For manufacturing companies, successful old ERP modernization means improving the architecture AND maintaining production continuity. For this reason, it’s best to implement changes in stages. The following principles work well in practice:
- Staged rollout. Launching new manufacturing software integrations gradually, rather than simultaneously across all processes.
- Parallel validation. New and old integrations run concurrently for a period of time, allowing for comparison of results.
- Fallback path. For each change, defining a quick reversion to the previous version in advance.
- Test datasets. Using real production scenarios, not just synthetic data, before launch.
- Change windows. Implementing critical changes during pre-agreed periods with minimal production load.
- Involvement of production users. Performing integration testing not only by the IT team but also by employees who work with the ERP and MES daily.
- Continuous monitoring. After launch, monitoring data synchronization, interface performance, and potential exchange errors.
This approach is consistent with the principles of legacy system integration modernization: first reduce risks, then gradually improve the architecture.
Conclusion
Modernizing integrations between ERP, MES, and other manufacturing systems should reduce operational risks, not create new ones. For many manufacturing companies, the problem is in the complex network of historical integrations. For this reason, the first stage of the project should be an analysis of the data flows and dependencies.
Once the architecture becomes transparent, it is easier to make informed decisions about what to retain, what to modernize, and what to replace. This phased approach allows to improve manufacturing software integration without disrupting production. It also preserves the proven business logic that has been developed over the years.
