Plant personnel should approach migration planning by asking: "What existing functionality do we want to maintain, change or improve, and what's the desired outcome of the upgrades?" "What are the steps involved?" "Is the project a clean build or translation?" "Are there third-party software considerations?"
In addition, it's crucial to understand how migration activities will affect the process. Non-redundant controllers likely will be down during software upgrades. Control nodes also may be unavailable during upgrade and cutover (so any associated control will be lost).
Plants should prepare for upgrading software and licenses for each system during the migration — including DCS, server and data historian applications — and determine what's needed from third-party suppliers.
Sites that haven't gone through a migration in many years — and that thus lack their own "proven approach" — should consider adopting a sister plant's approach, to leverage established and successful upgrade methodologies. They also should rely on recommendations from key vendors. Ultimately, there's no substitute for doing homework to come up with the best working strategy.
Properly planned and implemented, a migration should permit a plant to move from legacy control platforms at its own pace, allowing new controllers to be added at any time and integrated with existing equipment. It also should permit the upgrade of subsystems and function blocks to new controllers whenever the user decides.
Success typically depends upon an optimal migration strategy — this demands a structured, organized approach. Regardless of vendor support, plant personnel should play an integral part in the migration effort, reviewing its progress every step of the way.
As part of good engineering and project management practices, plants should take the following steps when developing a migration strategy:
1. Determine the best time to migrate.
2. Identify the best migration path associated with clearly defined goals.
3. Define the project through front-end engineering.
4. Use a proven approach with comprehensive checklists.
5. Develop detailed cutover plans.
6. Establish intermediate operability and training plans.
While timing a migration for a scheduled turnaround may make sense, keep in mind that a host of other factors could affect the timing. These include:
• production rates;
• holiday schedules;
• availability of support;
• release dates of software and associated functionality; and
• general business outlook.
Perform a front-end-loading (FEL) study to identify potential difficulties with a migration project and provide plans to mitigate risks. The study should analyze all aspects of the project, including mechanical, civil/structural, instrument, electrical and controls. The result is an overall design specification, outlining the strategy and schedule for migration activities.
It's also important to allow plenty of time for system upgrades and dealing with software issues. It even might be a good idea to create a complete system build in advance.
Don't forget to prepare notes and detailed instructions on repetitive processes. Engineers may find it useful to write notes as they go on the first build, completing one station and server, testing and debugging, and then revising the notes for the second build. All stations then can be built using the refined method. This will provide a consistent deployment procedure to minimize potential errors.
Also, maintain close contact with plant operations staff during the on-process migration — the more they know, the better (Figure 2). Keep an eye open for improvements without detouring the migration process, which can be long, slow and tedious. Don't get excited or impatient with laborious upgrade tasks. Keep safety top-of-mind while executing your plan and ensure you have adequate help for each migration function.
Most plants lack sufficient in-house staff and expertise to manage large capital projects internally, particularly for specialized tasks performed infrequently such as a DCS migration. That's why many sites hire outside service providers to manage upgrades.
Plants normally want to update their automation technology without having to "rip and replace" their entire legacy hardware and software system, which would be time consuming and often is impractical. They typically should turn to the control system supplier for knowledgeable assistance, including:
• strategies for migrating and supporting existing control system nodes;
• proposals for consolidating legacy control systems to drive down costs and enhance safety; and
• recommendations for ensuring the reliability, robustness, security and future expandability of process control networks.
Plants will benefit from working with their supplier's migration specialists upfront to plan the migration steps and timeframe. (The supplier's migration team may be booked months in advance, so get on its schedule as soon as possible!) Gathering data often requires different permission sets (e.g., local admin, domain admin and software admin). Pre-work and data collection can be a long process; review the collection procedures and make sure to gather all necessary data.