Legacy Manufacturing Software Assessment: What to Check Before Modernization

Manufacturing companies often run ERP, MES, production, quality and reporting systems that are stable in operation but poorly understood as a whole. The systems still work and production continues. But there is a risk elsewhere: in how dependent the business has become on undocumented logic, fragile integrations and scattered data sources.

This is why legacy software modernization should start with assessment. You should postpone architecture decisions or technology selection and start with an application modernization assessment.

Why Assessment Should Come Before Modernization

In manufacturing environments, legacy systems are deeply embedded into daily operations. ERP, MES, quality systems, reporting tools, custom utilities – they continue to run production, planning and reporting without visible issues. The problem starts when companies treat modernization as a technology decision.

Often, teams begin with questions like: “What should we replace the ERP with?” or “Should we move to a new MES?” But at this point, the real structure of the system is still unknown. And it is rarely simple. What looks like a single ERP system is often a combination of:

• ERP as a transactional core
• MES as a partial execution layer
• Excel files used for corrections and planning
• scheduled scripts moving data between systems
• reporting databases that redefine “truth”

If .NET or Delphi modernization starts without mapping this reality, the risk is not only higher cost. The risk is breaking something that is not visible in the documentation but critical for production.

Where the Real Complexity Usually Hides

When we start assessment work, the first discovery is rarely technical complexity in the ERP itself. But we usually find it in the surrounding ecosystem.

Production planning, for example, is often not fully defined in one system. Parts of it live in ERP, parts in MES, and parts in external files maintained by production teams. Over time, these “small adjustments” become part of the actual business logic.

The same happens with reporting. Official reports might come from BI tools, but the actual numbers are often prepared through intermediate transformations – SQL jobs, exports, or manual corrections before data reaches dashboards.

Everything might look structured, but the system behaves more like a network of dependencies than a clean architecture.

When you understand the real architecture, the next step is to break the system into areas that define risk and dependency. In manufacturing environments, we usually group findings into a few stable dimensions: workflows, systems, data, integrations and supportability.

This structure helps answer a simple question: where does change create operational risk, and where does it not?

Area 1 – Business-critical workflows

In the assessment stage, the first step is to understand which workflows would stop production if disrupted. In most manufacturing companies, these workflows include planning, order handling, inventory control, quality processes, reporting, and logistics coordination.

But what is important is how these workflows are actually implemented. Rarely does one system fully own a workflow. More often, responsibility is distributed across several systems and manual steps.

That is why small changes in one area can have unexpected effects elsewhere.

Area 2 – Systems and applications

Most manufacturing IT landscapes include ERP, MES, MRP, PLM, QMS, WMS, SCADA systems, and a set of custom applications built over time. Companies might feel like they have structured processes but usage patterns are different.

Some systems are fully integrated into daily operations. Others are partially replaced by spreadsheets or side applications that became faster or more flexible than official tools.

During assessment, this difference between “installed systems” and “actual operational systems” is one of the most important findings.

A similar challenge appears when organizations evaluate whether older systems can support new traceability and reporting expectations.

This is discussed in How to Check If Older Manufacturing Systems Are Ready for Product Traceability Requirements.

Area 3 – Data and reporting

One of the most important parts of assessment is understanding how data is actually used in the organization.

Manufacturing companies often assume there is a single source of truth: ERP for business and financial data, and MES for production execution. But more often, data is distributed across many systems.

Product, production, quality and traceability data may exist in different applications, databases and files. On top of that, reporting often introduces its own transformation layer, where KPIs are calculated through intermediate steps that have evolved over time.

This is why data inconsistencies appear. Not because systems are “wrong”, but because the same data is interpreted and transformed differently across the landscape.

We explored this problem in more detail in the context of industrial platforms in our case study.

Area 4 – Integrations

Integrations in legacy manufacturing environments are rarely centralized. Instead, they evolve over time. Some are file-based exchanges, and others rely on direct database access. Some run as scheduled scripts, and others depend on manual uploads or ad-hoc tools created for specific operational needs.

What makes integrations risky is their ownership. Often, no single team is fully responsible for them. They “just work” until something changes.

And when modernization starts, these are usually the first points of failure. Because they are undocumented.

Area 5 – Supportability

The next important part of assessment is understanding the system’s knowledge distribution.

In many manufacturing companies, only a small number of people understand how critical parts of the system behave in practice. This happens because real operational knowledge has accumulated outside documentation. For example, through fixes or workarounds.

This becomes a risk factor during modernization, especially when external vendors or legacy contractors are involved.

Area 6 – Modernization options

Assessment also defines what can be done with each type of finding.

The table below is not a fixed roadmap. It is a decision framework used to map technical findings to possible modernization actions.

Finding	Possible next step
Stable but hard to access data	Wrap and extend
Valuable logic but hard to maintain	Refactor
Fragile integration	Redesign integration
Unsupported technology	Migrate
Manual reporting burden	Reporting/data layer cleanup

In practice, most systems do not fall into a single category. A typical ERP or MES environment might contain several layers that require different modernization approaches at the same time.

This is why phased modernization is usually safer than a full replacement.

What an Assessment Should Deliver

A proper assessment is a structured understanding of how the system behaves in reality. Usually, it results in:

Area	Output
Systems	System landscape map
Data	Data flow and ownership model
Integrations	Integration inventory
Risks	Risk map of critical dependencies
Logic	List of hidden business rules
Strategy	Phased modernization roadmap
Value	Quick-win opportunities

The most important output is clarity on sequencing. What can you change safely? What should not be touched yet?

#Fieldnote

In one assessment project, a manufacturer planned to replace reporting functionality inside their ERP system. They considered ERP the source of all production data. During system mapping, it turned out that key production KPIs were not coming from ERP at all.

They were calculated through a combination of:

• a scheduled SQL job
• a shared Excel file maintained by production planners
• a small internal tool developed years earlier

Nobody documented this in official system descriptions. Without this discovery, replacing the ERP reporting module would have disrupted daily production reporting immediately.

What Not to Do Before Assessment

Don’t:

• Start modernization from vendor selection
• Focus only on ERP replacement
• Ignore Excel-based processes
• Underestimate integration complexity
• Assume documentation reflects reality
• Skip data flow mapping

Conclusion

Manufacturing systems don’t need immediate replacement. They wanted to be understood.

Assessment is the step that turns modernization from a high-risk transformation into a controlled process.