When Control System Modernization Requires a Familiar Operator Experience

By Alan Polk, P.E. | Technical Execution Leader

Replacing an obsolete control system creates an opportunity to improve functionality, streamline code, strengthen troubleshooting, and introduce modern operator interfaces. In some facilities, modernization comes with another priority: upgrading the underlying technology without significantly changing the operator experience.

This is a reasonable objective, especially in plants where operators have worked with the same system for decades and where changes to familiar workflows could introduce unnecessary training, safety, or quality concerns. However, it is challenging to determine how much of the legacy experience should be preserved and what will be required from the new control system.

Start by Defining “Familiar”

During early migration planning, teams often focus on major technical questions such as hardware, I/O, networking, controllers, and system architecture. Operator expectations can appear simpler by comparison, but they present their own challenges.

Preserving the existing operator experience may involve much more than just recreating graphics: batch reports, faceplates, historical data, pop-ups, process sequences, navigation, and other workflow details may all behave differently on a modern platform and require custom development.

A plant migrating from Fisher PROVOX to Emerson DeltaV, for example, may find that functions built into the new platform do not look or behave like their legacy equivalents.

One question is especially important during the planning phase of a migration:

Which features, workflows, displays, reports, or system behaviors must remain unchanged after the migration?

Answering this question early helps separate operational requirements from preferences and gives the project team a better understanding of the engineering effort involved.

Understand the Cost of Recreating Legacy Behavior

Modern control platforms are designed around current architectures and standards. Their native tools for functions such as batch management, historical data, troubleshooting, and reporting are intended to work together. Recreating legacy behavior can change how these capabilities are used.

For example, modern systems based on ISA-88 principles are structured so that information can flow through equipment, phases, operations, and procedures in a way that supports troubleshooting and root cause analysis. Heavy customization (such as to match legacy behavior) can make the information flow less direct, which may increase the effort required to trace process issues or identify opportunities for optimization. This does not mean legacy behavior should never be retained, but each retained feature should be an intentional decision.

Plant teams should evaluate whether a familiar workflow contributes to safe, efficient operation or simply reflects how the system has always worked. In some cases, preserving legacy functions may be worth the additional engineering effort, but in others, adopting the new platform’s native functionality may provide greater long-term value.

Use a Proof of Concept to Expose Hidden Requirements

When a migration strategy depends heavily on preserving legacy behavior, a proof of concept is a valuable first step. Rather than moving directly into full field implementation, the team can select a representative process area, vessel, unit, or sequence and build a working model of the proposed approach.

This gives operations, engineering, and automation teams an opportunity to identify differences between the legacy and modern systems before those differences affect a larger project.

A proof of concept can reveal requirements that are difficult to capture in an RFP or functional specification. A particular report format, screen behavior, pop-up, sequence, or operator shortcut from the legacy system may seem insignificant until the new system behaves differently. Discovering those expectations during a pilot allows the team to determine what should be recreated, modified, or replaced with native functionality.

Capture Undocumented Knowledge

Legacy control systems often carry decades of institutional knowledge. In some facilities, much of that knowledge resides with one or two experienced people who understand how the system works. The original code may still be available, but the reasoning behind individual workflows, sequences, and operator conventions may never have been formally documented. A migration is an opportunity to document that institutional knowledge.

Frequent reviews with experienced plant personnel can help the project team understand not only what the legacy system does, but why operators rely on particular behaviors. Those discussions can be translated into functional specifications, coding standards, and design requirements for future migration work.

This is especially valuable when the legacy platform can no longer be easily virtualized, licensed, or reproduced for development purposes. In those situations, exported data and plant knowledge may become the primary sources for reverse engineering the existing system.

Determine Where Familiarity is Most Valuable

Modernization can be a mix of making changes and preserving previous functionality. A useful approach is to identify the elements of the operator experience that deserve continuity and the areas where the plant can benefit from modern functionality.

For example, preserving a familiar sequence or navigation method may reduce training requirements and help operators remain confident during startup. Retaining a legacy reporting format, however, may require significant custom development when the modern platform already provides a robust reporting tool.

These decisions should consider several factors, including operator training, safety, quality, troubleshooting, maintainability, lifecycle support, and the amount of custom engineering required. The goal is to find the right balance for the facility rather than automatically choosing the newest functionality or reproducing the old system.

Build the Migration Standard Before Scaling

Once legacy functionality preservation decisions are made, they should be documented before the migration expands to additional units. A well-developed pilot can produce coding standards, functional specifications, sample code, interface expectations, and clear guidance on when native functionality should be used and when customization is required. This information gives the plant a repeatable approach for future phases and reduces the likelihood of repeating the same questions during every unit migration. It also gives operations and engineering teams a clearer understanding of what the completed system will look like before field implementation begins.

For facilities facing an aging or unsupported control platform, the most important early conversations may have less to do with hardware than with how people use the system. Understanding which parts of that experience should carry forward can help define a modernization strategy that supports both the operators working with the system today and the plant’s long-term automation goals.

Hargrove Controls & Automation can help facilities evaluate legacy system requirements, identify where proof-of-concept testing may be beneficial, and develop a migration approach that balances operator familiarity with the capabilities of a modern control platform. Contact us today.