“Dilbert” cartoonist Scott Adams clearly understands the trepidation with which most of us approach a system migration. “Change is good,” one of his cubicle dwellers says to the other. “You go first.” The co-worker looks as if he’s just been challenged to jump off a cliff.

However, while system migration will probably never make anyone’s “Top 10” list of favorite assignments, thousands of companies have migrated, bulldozed, progressed, evolved, torn out or replaced their systems and survived to tell the tale. The first step is to take a deep breath — migration is not as daunting as it seems — and understand and prepare for the most common pitfalls. Sure, you’ll probably overlook one or two, but the more complete your preparation, the better equipped you’ll be to take those surprises in stride.

To help you get started, we’ll look at 10 basic migration techniques, highlight the hurdles you’re most likely to encounter, and suggest how to deal with them.

1.  HMI replacement

Distributed control systems (DCSs) come with a human/machine interface (HMI) system that is supported for a limited time (Figure 1). At many plants, multiple types of HMIs are installed. At some point, the HMI hardware will wear out or the cost of finding replacement parts will become prohibitive. The good news is that replacing multiple, proprietary HMIs with a single, open system can significantly cut your costs while eliminating the need for operators to learn to use multiple interfaces.

Figure 1. New HMI continuously communicates with legacy controllers, preferably after parallel operation with the old HMI.

Your goal should be to find a solution that allows the new HMI to communicate with existing controllers on a continuous basis. Ideally, the new HMI should run in parallel with the older one for a while, giving operators continuity during the transition.

Hurdle: For data in the controllers to be continuously available, the tag database, if one exists, must be moved from the legacy HMI system to the new one. Beware of OLE for Process Control (OPC) server vendors that claim to be able to communicate with any legacy system. Rarely will they have all the connections needed to get every piece of data from the controller. They will also lack a tool to move the tag database. If the controller vendor offers an OPC server, it may be purposely limited so that only its new HMI can see all of the data required.

Suggestion: Use third-party HMIs with OPC connectivity (assuming your controllers have OPC server software available). The connection will require some manual manipulation and, possibly, double database entries.

Ask your existing system’s vendor what evolutionary paths are available to connect its newest HMI with your existing controllers. Upgrades to the controller or network may be required before a connection to the new HMI can be made. Depending upon the vendor, you may have to wait in line behind other users with legacy systems before it develops an evolution plan for yours. The plan can take years.

If your vendor can’t or won’t help, consider a DCS vendor that does the whole soup-to-nuts for you and will take full responsibility for ensuring the system works.

2. HMI conversion
In this strategy, existing intellectual assets (software configuration like graphics, faceplates, trend configuration and historical data) are moved from the old HMI to the new HMI (Figure 2). The HMI conversion is done once to move data and assist in the HMI migration. Of course, that assumes the old graphics and configuration are worth moving.

Figure 2. A one-time effort moves graphics, faceplates, historical data and other intellectual assets to the new HMI.

Hurdle: Depending upon your system, it may be easy (e.g., Visual Basic-based) or difficult (proprietary UNIX-based) to move the graphical data from one HMI to another.

Suggestion: Be sure of why you are moving the graphics in the first place. The graphic package of the new system may have the features you want. If so, it’s best to start from scratch. The new system may also use an object-oriented approach to the entire HMI. Again, it’s best (or required) to start from scratch to take advantage of this approach.

The HMI vendor is the best place to start. Ask if it has any graphic/trend/report migration tools. Be sure to probe its answers. Most will say they offer tools. However, you may find the vendor has to do everything by hand, which increases the chances for errors and drives up costs.

Most importantly, be sure the tool includes a function for historical data migration. Surprisingly, an incumbent vendor may not have the ability to move historical data from its own legacy systems to its new HMI historian due to the nature of the legacy database structure. If this is the case, check with other DCS vendors; they may have access to better resources for this important service. What’s the point of migrating to a new HMI if you must keep the old HMI around just to look at historical data?

3. Other special applications
Applications loaded on your HMI to do specific tasks, including batch management or maintenance management, need special attention (Figure 3).

Figure 3. Special applications like batch management in legacy systems can pose special challenges in migration.

Hurdle: The key point is to save the intellectual investment of the special application while migrating to a similar but state-of-the-art application for viewing and manipulating older data.