How to Check If Older Manufacturing Systems Are Ready for Product Traceability Requirements

Suppose you are a manufacturing company, and you have a stable ERP, MES, quality management systems, or reporting tools. Often, these companies believe that if systems are stable, they are automatically prepared for new requirements for product traceability, production data management, and data management.

In practice, this is far from always the case. Over the years, a manufacturer with 200 to 500 employees typically accumulates numerous ERP modules, production systems, reporting databases, spreadsheets, specialized applications, old manufacturing software and integrations. They support the company’s daily operations and can successfully perform their functions for decades.

Businesses start having problems when they need to quickly answer specific questions. For example, what batch of steel a particular part was made from, what equipment it was produced on, what quality checks it passed, and which suppliers were involved in the supply chain. This capability is commonly referred to as product traceability. Basically, it means the ability to reconstruct a product’s history from raw materials to finished goods.

At this point, many companies discover that critical information is disjointed or hidden within business logic only a few employees understand.

Below is a typical scenario we see as mature manufacturing companies begin to assess how much their systems are ready for those requirements we mentioned above.

Typical starting point

A company’s technical landscape is usually much more complex than it first appears. An ERP system manages procurement, inventory, suppliers, and customer orders. An MES records production operations. The quality department stores inspection results in a separate database. Financial reporting is generated through a BI system, and employees continue to maintain some data in Excel.

At first glance, everything seems to be working fine. However, when management asks an interesting question:

“Can we trace the finished product’s path to all materials used, production operations, and quality checks?”

the answer turns out to be far from obvious.

For example, employees store raw material batch numbers in the ERP system, production line data in the MES, test results – in a separate quality department database, and information about product adjustments you will find in email correspondence between technologists. All the data exists but compiling it into a single product history proves difficult.

The First Mistake: Starting with Choosing a New System

One of the most common mistakes you can make is to start a legacy software modernization by choosing a new technology. Companies begin enthusiastically evaluating a new ERP, MES, or product data management platform. But they often forget to gain an understanding of how the existing IT environment actually functions.

They might assume that the new platform will automatically address current limitations. What they miss is that the main risks usually lie in how the old environment operates. Over the years, dozens of exceptions and workarounds develop. And they are rarely documented.

Problems most often fall in the following areas:

• undocumented business rules and calculations
• historically established data flows between systems
• custom integrations and scripts
• manual adjustments to reports and data
• exceptions and workarounds accumulated over years of operation

The project gets more expensive and risky if you don’t identify these elements before the modernization. Before discussing system replacement, understand the location of data, business logic, and operational dependencies.

What to Check First

Before reviewing systems in detail, verify:

• where product identifiers originate
• where batch data is stored
• whether quality records are linked to production records
• which reports need manual corrections
• which systems exchange data automatically

Step 1 – Map the Data, Not the Software Names

An effective readiness assessment begins with analyzing data, not applications. Most companies know what systems they use. But far fewer understand where specific business data is created, modified and verified.

At one company, we observed a situation where management considered the ERP to be the primary source of product information. During the analysis, it became clear that product specifications were actually maintained in a separate database in the technology department. The ERP was only receiving some of the data through a nightly upload.

For this reason, it is important to trace the path of each category of information as part of data flow mapping across manufacturing systems:

• product and component data
• supplier and material lot information
• production events and operations
• quality control results and quality data traceability records
• service history and repair data
• information required to follow regulatory requirements

For each element, understand where it first appears, who modifies it, who approves it, and how people transfer information between systems. Very often, such analysis reveals that information thought to be stored in one system is actually maintained in a completely different one.

Step 2 – Find Manual Workarounds

Manual workarounds are one of the main indicators of hidden risks. Over time, employees develop their own ways to compensate for the limitations of existing software.

For example, a production foreman uploads data from the ERP system to Excel daily, corrects errors in product codes, and only then submits a report to management. Or a quality specialist manually transfers test results from the lab system to the corporate database because automatic ERP MES manufacturing integration was never implemented.

Such processes are rarely documented. Yet, they often contain critical business logic that impacts product traceability, reporting accuracy, and management decision-making.

Ignoring such processes increases modernization risks. Analyzing them allows us to understand how a business operates in reality, not as described in instructions.

Step 3 – Identify Old Logic That You Should Not Move Blindly

There is no need to keep all legacy logic. But before removing it, you should understand its purpose. Many legacy manufacturing systems contain years of accumulated business knowledge. And it is usually embedded directly into the code.

For example, at one company, the system automatically changed the production route for a certain group of products if an order came from a specific customer. No one in management remembered this rule existed. But it remained in effect for over a decade, impacting equipment use.

At another company, the delivery lead calculation algorithm took into account the specific operating conditions of a specific warehouse through a set of exceptions added in the early 2000s. Sounds quite complicated, right?

The problem is that such rules are often invisible to the business because the system performs them automatically. If a company migrates systems without identifying such dependencies, it can have serious operational issues after the launch of the new platform. For this reason, separate legacy logic from what still brings value to the business.

Step 4 – Separate What Can Stay From What Must Change

Also, not every system requires replacement. Many times, individual components perform reliably and can remain part of the architecture. For example, an older warehouse management system may operate reliably and store batch data correctly. In this case, it doesn’t necessarily need to be replaced. Sometimes, providing modern data access via an API or integration layer is enough, particularly during custom ERP modernization projects.

A practical approach is to divide systems into several categories. You can leave some components unchanged. Some of them you should supplement with modern data access interfaces. Some modules require redesigning, and some should be completely replaced. In some cases, it is better to integrate existing solutions with new analytics and reporting platforms.

This approach helps prioritize investments and cut the impact of changes on production processes.

When to Modernize vs Leave As-Is

Not every legacy system creates the same level of risk. In many manufacturing environments, some components can operate reliably for years, while others become obstacles to data visibility and traceability.

Situation	Recommended Action
Stable process, reliable data, low maintenance effort	Keep
System still works but data is difficult to access	Wrap
Business-critical logic is valuable but difficult to maintain	Refactor
System creates reporting, integration, or traceability problems	Replace
Data exists in multiple systems and needs consistent exchange	Integrate

The goal is to identify which components create the highest operational and manufacturing system data readiness risks.

Step 5 – Create a Phased Modernization Path

Manufacturing companies rarely have the luxury of shutting down operations for a major transformation. For this reason, they should follow a phased modernization approach.

Successful projects begin with an inventory of systems and data. Then, they identify manual processes and hidden dependencies. Afterward, the company creates a unified data access and reporting layer. It simplifies integration between systems and only then modernizes the most risky components.

This approach helps mitigate risks and gradually improve the company’s readiness to meet new requirements.

Quick Readiness Checklist

• Do you know where product data is created?
• Is it possible to trace batches between ERP, MES and quality systems?
• Are there Excel files that impact reporting?
• Do you understand which integrations are critical?
• Have you documented key business rules?
• Are there processes known to individual employees?
• Is there a plan for modernization without interrupting production?

If the answer to several questions is no, it’s worth starting with an assessment of the current state of systems and data.

What a Readiness Review Should Deliver

A useful readiness assessment should lead to practical results.

After the analysis, management should have a clear picture of the current state of the IT environment. This means they have a map of the enterprise’s systems, a diagram of how data flows between them, a list of manual operations, a list of integration risks, identified gaps in data responsibility and, of course, a realistic modernization roadmap.

These materials help make decisions and avoid costly mistakes.

Who is Responsible for Requirements and Who is Responsible for Data?

When discussing product traceability, you should distinguish between two distinct objectives. Business or industry standards define what data a company must be able to provide. But these requirements do not mean that the necessary data is already available in the required format.

In practice, traceability readiness also depends on the state of ERP, MES, quality systems, reporting, and the integrations between them.

We often see situations when the requirements are clear but the data is spread across many systems. It is partially maintained manually or relies on undocumented logic. That is why you should not look at readiness assessment as a compliance team task. It often needs collaboration between production, quality, business units, and the IT team.

What Not to Do

Modernization projects regularly make the same mistakes. The most common ones are:

• starting the project with a complete overhaul of all systems
• treating the ERP as the sole source of product data
• ignoring Excel files and informal processes
• treating reports as “just reports”
• assigning the entire initiative to compliance without involving IT and production
• and modernizing systems without analyzing the existing business logic

Most failed modernization projects are a lack of understanding of the existing environment.

Conclusion

To improve their manufacturing system data readiness for product traceability requirements, manufacturers often don’t need to replace the whole existing system. It is not the safest path.

It is far more important to understand the system. Where the data resides, how the business logic operates, what operational risks exist, and which components to modernize gradually. Once these aspects are clear, the company can build a realistic modernization roadmap. It will improve data management and maintain the stability of daily operations.

At Softacom, we help manufacturing companies perform a legacy software assessment and identify modernization risks. We can document critical business logic and plan phased upgrades and business-critical software initiatives that drive business operations. You will have a roadmap tailored to your business, industry and goals.