How Manufacturing Companies Can Reduce Key-Person Risk in Legacy Systems

Manufacturing software rarely stays the same for long.

An old ERP system receives customizations to support a new production process. Companies adapt an MES platform to work with additional machines. They evolve reports to answer new business questions. Integrations appear between suppliers, customers, quality systems, and internal applications. Over time, hundreds of small decisions shape how the software supports daily operations.

Years later, production is running smoothly. But this is only thanks to a few people who know how everything fits together.

Perhaps it’s a developer who has maintained the system for years. Or it’s an ERP specialist who understands every customization. Sometimes it is an external contractor who built the integrations long ago. In other cases, the knowledge sits with a production planner who knows why certain exceptions exist.

When those people become unavailable, routine changes suddenly become difficult. An ERP update takes longer than expected because nobody understands the logic behind it.

This is one of the most common forms of legacy system knowledge risk in manufacturing. Companies often discover it while planning legacy software modernization, when undocumented knowledge becomes a larger obstacle than the technology itself.

TL;DR

Many manufacturing companies rely on legacy ERP, MES, reporting, and production systems that have evolved over many years. The biggest risk often is not that they are old. It is that critical knowledge exists only in the heads of one or two people.

Reducing key person risk in legacy software starts with identifying undocumented business logic. You should map integrations, document critical workflows, and share knowledge across the team. Most companies can reduce operational risk without replacing their existing systems.

Why Key-Person Risk Is Common in Manufacturing Software

Unlike modern applications, manufacturing systems often evolve over decades. Rarely, they are just designed all at once.

Companies continuously adapt their software to support new production lines, customer requirements, quality procedures, and operational improvements. Each change solves a business problem. But few organizations have the time to fully document every customization or integration.

Over the years, this creates an environment where people remember decisions better than documents do.

Several factors contribute to key person dependency in manufacturing software.

Systems evolve through continuous change

Manufacturing companies rarely replace their ERP or MES systems every few years. Instead, they extend existing platforms by adding custom modules and scripts whenever business needs change.

As a result, today’s software often reflects decisions made by many teams over many years.

Local contractors build business-critical functionality

Many companies have worked with the same local software consultant or contractor for a decade or longer. During that time, they may have created custom ERP logic or production reports or something else.

The software continues working long after those projects finish. But the knowledge often stays with the original developer.

Business workarounds become permanent

Temporary solutions have a habit of becoming permanent.

An Excel macro created to solve a reporting issue remains in daily use for years. A scheduled SQL procedure originally written as a short-term fix becomes part of the production process. Manual data corrections continue because “that’s how we’ve always done it.”

Eventually, nobody remembers why these workarounds exist.

Production exceptions accumulate over time

Manufacturing rarely follows identical processes for every customer or product.

Employees gradually add special production rules, customer-specific workflows, quality checks, and planning exceptions to the system. They document some of them but leave others to exist only because experienced employees remember them.

Integrations are rarely documented completely

Modern manufacturing depends on data moving between many systems:

• ERP
• MES
• Quality management software
• Warehouse systems
• Reporting platforms
• Customer and supplier portals
• Machine and device interfaces

While each integration may work, the underlying logic is often understood by only one person.

#Fieldnote

During legacy system assessments, we often discover that the biggest dependency is not the ERP or MES platform itself. The highest risk usually sits in scheduled SQL jobs, reporting logic, Excel automation, or integration scripts. They became business-critical over many years but were never fully documented.

The result is a growing bus factor in legacy software. If one key person becomes unavailable, the business doesn’t lose the software, of course. But it loses the ability to safely change, support, or troubleshoot it. It loses the main support figure.

Where Key-Person Dependency Usually Appears

Not every part of a legacy system carries the same level of risk.

Some components are well documented and easy to maintain. Others rely heavily on knowledge that has accumulated over years of day-to-day support.

The following areas most commonly create legacy system knowledge risk in manufacturing companies.

Area	Typical dependency
ERP customizations	One specialist understands years of custom business logic.
MES configuration	A single engineer knows all production rules and machine settings.
Reporting logic	Only one person knows how to calculate SQL procedures, KPIs, or production reports.
Excel automation	Critical operational tasks rely on spreadsheets maintained by one employee.
SQL procedures and scheduled jobs	Database automation has evolved without central documentation.
Machine and device integrations	Communication with production equipment depends on knowledge held by the original developer.
Deployment scripts	Software updates require one specific engineer because deployment steps aren’t documented.
Supplier and customer data exchange	File formats, validation rules, and data mappings exist only in historical knowledge.
Production planning exceptions	Special business rules have accumulated over time without formal documentation.

These areas rarely attract attention while experienced employees remain available. The problem usually becomes visible only when a business needs to make changes quickly or respond to unexpected events. At that point, companies often realize that maintaining business-critical software support depends on a handful of people being available.

Why This Becomes a Business Risk

For technical teams, key-person dependency is often viewed as a maintenance issue. For business leaders, however, its impact is much broader.

When one or two people hold critical knowledge, everyday operations may continue without obvious problems. The real challenges appear when the company needs to make changes or respond to incidents.

Changes take longer than expected

A seemingly simple request, for example, adding a field to a report, can turn into a lengthy investigation if nobody understands how the existing logic works. Instead of implementing the change, the team first has to rediscover how the system was built.

This slows down projects that should take days but end up taking weeks.

Support becomes unpredictable

Routine support also becomes more difficult. If only one person knows how to generate a production report or why a scheduled SQL procedure behaves a certain way, every support request depends on that person’s availability. When they are on vacation or have left the company, even minor issues may remain unresolved longer than expected.

Knowledge transfer becomes expensive

Hiring new developers or transferring responsibilities to another team is rarely straightforward.

Without clear documentation, experienced employees spend significant time explaining historical decisions, undocumented business rules, and production-specific exceptions.

The longer you delay this knowledge transfer, the more difficult it becomes.

Operational disruptions become more likely

Many manufacturing systems support business-critical activities. If an integration stops working or a production report fails, troubleshooting becomes much harder. Nobody fully understands how the solution was implemented.

The issue may not stop production entirely, but it can delay decisions and increase operational pressure.

Vendor dependency increases over time

Some companies discover that only the original contractor can safely change the system. Even if the software is stable, every enhancement or bug fix requires the same specialist.

If that contractor retires or changes business direction, the company may struggle to find someone willing to work with the existing solution.

Modernization projects become harder

One common misconception is that replacing the software automatically removes the problem. But modernization projects need a deep understanding of existing business logic. If nobody can explain why certain things exist, migrating them becomes more difficult.

The less you understand the current system, the greater the risk of losing important functionality during modernization.

Audit and traceability become more difficult

Manufacturing companies often rely on accurate production and operational data.

When information exists only in someone’s memory, it becomes harder to explain why specific business rules exist. Even if the software produces correct results, undocumented processes create unnecessary uncertainty during internal reviews and process improvements. The same lack of visibility can also make it more difficult to prepare older manufacturing systems for new product traceability expectations.

Practical example

A manufacturer needed to change a production quality report. They wanted to support a new customer rule. The report itself was easy to locate. But nobody knew that several scheduled SQL procedures and an Excel-based validation process also contributed to the final output. What appeared to be a one-day change required weeks of investigation before development could even begin.

How to Identify Key-Person Risk

Many organizations underestimate legacy system knowledge risk because the software appears stable. A practical assessment often reveals that critical knowledge is concentrated in a few individuals rather than distributed across the organization.

The following checklist gives a good starting point.

Key-Person Risk Assessment Checklist

Use these questions to check your current environment.

Question	Yes	No
Can more than one person explain how the system works end-to-end?	☐	☐
Is the business logic behind ERP customizations documented?	☐	☐
Can someone other than the report owner change production reports?	☐	☐
Are integrations with machines, suppliers, and customers documented?	☐	☐
Does more than one person understand scheduled SQL jobs and database procedures?	☐	☐
Are deployment and rollback procedures documented?	☐	☐
Are production exceptions documented together with the reasons behind them?	☐	☐
Could another team maintain the system if the current owner became unavailable tomorrow?	☐	☐

The company’s goal should be to identify the areas where the business depends on individual knowledge.

Look beyond source code

One of the most common mistakes is assuming that source code contains everything needed to understand the system. But more often, much of the most valuable knowledge exists outside the application.

Ask questions such as:

• Why was this customization introduced?
• Which departments rely on it?
• Which reports support daily production decisions?
• Which integrations are critical for a business?
• What manual steps do employees perform before or after the software runs?
• Which Excel files are part of everyday operations?
• Which scheduled jobs would affect production if they stopped running?

These questions often reveal dependencies that are invisible during a traditional code review.

Identify the knowledge that isn’t written down

Some knowledge never appears in documentation because experienced employees remember it. Examples include:

• customer-specific production rules
• historical workarounds
• exceptions introduced years ago
• undocumented deployment steps
• manual recovery procedures
• reporting assumptions that everyone “just knows”

These undocumented decisions often become the biggest source of key person risk in legacy software.

#Fieldnote

During system reviews, we rarely find organizations where source code is the biggest problem. More often, the challenge is that business logic lives in conversations, emails and spreadsheets. And of course, the experience of long-term employees. Capturing that knowledge usually delivers more immediate value than making technical changes.

How to Reduce the Risk Without Rewriting the System

Reducing key person risk in legacy software begins with understanding how the existing system supports the business today.

In most manufacturing environments, the goal is not to cut every legacy component immediately. The priority is to make sure that critical knowledge is no longer concentrated in a single person. Also, the organization should be able to support the system even if one expert becomes unavailable.

A practical approach usually comes down to three things: understanding the current environment, making the important knowledge visible, and reducing dependence on individual experts.

1. Understand how the system really works. Start with the people who support the software every day. They usually know everything about the system. Talking to them might help reveal dependencies that are not obvious in the codebase.
2. Document what the business cannot afford to lose. Focus on critical workflows rather than trying to capture every feature. It is also important to record hidden business logic. It may live outside the ERP or MES. Even simple support playbooks can reduce operational risk.
3. Reduce dependency on one person and plan the next step. Once you document the most important knowledge, the highest-risk areas become easier to identify. Some systems only need better support. Others may benefit from targeted refactoring or a gradual modernization roadmap. The key is to make those decisions based on a clear understanding of the current environment rather than assumptions.

What Not to Do

Companies often increase legacy system knowledge risk by reacting too late or focusing on the wrong problem.

• Waiting until a key employee resigns before documenting the system.
• Assuming vendor documentation includes years of customizations.
• Starting a complete system replacement before understanding the existing business logic.

These mistakes usually make knowledge transfer more expensive and increase project risk.

Why Replacing the System Isn’t Always the Answer

When organizations see their dependency on one or two people, replacing the software may seem like the obvious solution. But it is also a rushed decision.

Technology is often only part of the problem. If you move undocumented rules and logic into a new platform, the same dependency often continues. A new ERP or MES system cannot replace knowledge that was never documented.

Often, companies achieve better results by first understanding how the current environment works. Only then can they make informed decisions about which parts of the system to modernize, replace or keep.

One example is our modernization project for a scientific instrumentation platform, where understanding the existing application and business logic was an important prerequisite before larger technical improvements could be implemented.

When External Support Helps

Internal teams often understand the business well. But they have limited time to investigate years of historical decisions.

External legacy support can be valuable when the original contractor is no longer available. Also, when internal IT teams are overloaded with operational work, documentation is incomplete or missing, the technology stack is difficult to support, or production systems cannot tolerate extended downtime. It is also useful when legacy system modernization should be gradual with daily operations continuing.

An external team brings a structured approach to documenting existing systems. They can help identify hidden dependencies and stabilize support without disrupting production.

Conclusion

Key-person dependency is one of the most common risks in legacy manufacturing software. But it often remains invisible until something changes.

The software may continue running for years. But every undocumented customization or production exception increases reliance on individual knowledge. Reducing that dependency does not always mean replacing existing systems.

The first step is to understand what exists today and document critical business logic. You should ensure that operational knowledge is shared across the team.

Once that foundation is in place, supporting existing applications and modernizing them when appropriate becomes less risky.