By Trevor Cusworth, Collaborative Systems Integration · November 12, 2026
Plan the advanced applications before you plan the migration
A DCS migration is the moment a plant is most likely to lose the value of its advanced applications, and the cheapest moment to protect it.
Most migration plans are built around I/O, HMI and cutover. Advanced process control, inferentials, optimisation and machine learning models are wired into the old platform's interfaces, historian tags and configuration tools. They do not move across by themselves.
When they sit outside the main scope, they get pushed to a later phase. Controllers come back in manual after cutover, the people who understand the models are busy elsewhere, and the margin the applications were installed to capture leaks away without anyone deciding it should.
This guide is for plant and engineering leaders facing a DCS end-of-life decision, and for the control engineers they will pass it to.
Three decisions to make before you sign
- Advanced applications are in the main migration scope, with a named owner, a budget and a date.
- You know what each application delivers today, measured from the historian, not remembered from the original business case.
- The new architecture lets those applications move again in 15 years without being rebuilt from scratch.
The first step costs nothing but time: list every advanced application on the site, who owns it, and what it earns.
Why migrations break advanced applications
Advanced applications are often the most valuable software on a control system, and the least portable.
They are wired into the old platform
A multivariable controller reads and writes through the DCS's own interfaces, tag structure and execution environment. Inferentials depend on historian tags and on data cleaning built around the old system. Optimisation layers call into both. Change the platform and every one of those connections has to be re-made, tested and proven again with operators watching.
The know-how lives with a few people
Models, tuning choices and the workarounds that keep a controller stable are built up over years and often understood by one or two engineers. A migration project consumes those same people: factory acceptance testing, cutover, the punch list. The advanced applications get whatever time is left, which is usually very little.
Schedule pressure pushes APC to phase 2
When the migration schedule tightens, the work that is not needed to start the plant moves to the end of the list. Advanced control is the obvious candidate. It is not needed for start-up, and it is hard to estimate, so it becomes a later phase with no firm date.
Field note. On one migration schedule I reviewed, "Re-commission APC" sat at the bottom as phase 2, below the I/O cutover, the HMI rebuild and the operator training. It had no date and no budget owner. Everyone in the room knew what that meant. Trevor Cusworth, CSI
Nobody decides to lose the value
Controllers are switched to manual for start-up. Operator trust has to be rebuilt on the new screens. Without an owner and a date, the controllers stay off, and after a few months nobody remembers why. The original business case still shows the benefit. The plant's results stop showing it.
The pattern repeats
The same thing happens at the next migration if the new platform is as closed as the old one. Applications rebuilt for one supplier's environment are tied to that environment again. In 15 to 20 years, the plant faces the same rebuild, the same schedule pressure and the same risk of losing the value.
That is why the migration decision and the advanced applications decision are really one decision. The architecture you choose now sets how much it will cost to keep your advanced applications working through every hardware refresh and supplier change that follows.
What this looks like from the control room
- Controllers that were on before cutover are still in manual three months later.
- Inferentials report values nobody trusts because a tag or filter changed during the migration.
- The engineer who built the models is now the only person who can rebuild them, and is also running the punch list.
- The steering committee hears that the migration finished on time. Nobody reports that the unit's margin quietly fell.
What it looks like when it goes right
The Tuesday morning shift change looks the same as it did before the migration. The controllers are on. The operators trust them, because the screens they use to see what the APC is doing were designed in from the start. The engineer who built the models is improving them, not rebuilding them, and the monthly report shows service factor next to throughput.
Getting there is not about heroics during cutover. It comes from three things decided early: scope, measurement and architecture.
What is actually at stake
Before you can protect your advanced applications, you need to know what they are worth today.
Advanced applications on a typical process site include multivariable predictive controllers, real-time or economic optimisation, inferentials and soft sensors, and machine learning models used in operations. Each one was justified by a business case. Few sites check whether that case still holds.
The measure that matters most is service factor: the share of time each controller is actually on and in closed loop, doing the job it was built for. Server uptime does not count. A controller can be running and doing nothing.
Worksheet: your advanced applications
Fill in one row per application. Use the historian for service factor and the original project documents for value. Where nobody can put a number on an application, write that down too. The PDF includes a printable version.
| Application | Unit | Owner | Value per year (your estimate) | Service factor, last 90 days | Depends on (interfaces, tags, tools) | Plan in migration |
|---|---|---|---|---|---|---|
This guide quotes no industry averages, on purpose. The numbers that decide your migration plan are your own, and the worksheet is where they start.
Five questions to ask before you sign
Asked in writing, these will tell you more about your migration risk than any supplier presentation.
1. Who owns the APC models, configurations and IP after the migration?
Why it matters: If the answer is unclear, you may be paying again for knowledge your plant already built.
A good answer: The plant owns them, in documented and exportable form.
2. Can the applications run unchanged on the new platform, or must they be rebuilt?
Why it matters: Rebuilding means new engineering, new testing and a new period of operator distrust.
A good answer: A list, application by application, of what moves as is, what is reconfigured and what is rebuilt.
3. What is the re-commissioning plan for advanced applications, who does it, and who pays?
Why it matters: Work that has no owner and no budget is the work that slips to phase 2.
A good answer: Named people, dates inside the main schedule and a line in the contract.
4. How will service factor be measured before and after cutover?
Why it matters: Without a before and after, nobody can see value being lost.
A good answer: A baseline taken now, a target agreed for 30 and 90 days after start-up, and a named person reporting it.
5. If you change suppliers again in 15 years, what does it cost to move the applications?
Why it matters: This is the question that tells you whether you are buying an architecture or another lock-in.
A good answer: A clear description of how the applications are separated from the hardware and supplier underneath.
The vendor-neutral path
Open, standards-based architectures are designed to separate applications from the hardware and supplier they run on.
The Open Process Automation Standard (O-PAS™), developed by the Open Process Automation Forum of The Open Group, defines a standards-based, interoperable and secure architecture for process control. It is a standard of standards: it builds on established standards, such as OPC UA for communication, rather than inventing new ones.
Two ideas that matter for advanced applications
Interoperability means products from different suppliers can work together. Your controllers, HMI and historian exchange data even when they come from different companies.
Portability means an application can move to new hardware, or to a different supplier's environment, without being rebuilt. The control strategy survives when the platform underneath changes.
Most systems can show interoperability today. Portability is the harder and more valuable property, and it is the one that protects advanced applications through the next migration.
What portability means for an MPC application
The controller's logic, models and configuration are held in standard, documented forms, and it connects to the rest of the system through a standard communication framework. A hardware refresh or a change of supplier then becomes a re-deployment and a test, not a rewrite and a re-tune. For more on this, see Advanced Process Control in OPA Environments.
An honest note on maturity
Open architectures are in field use, but the market is younger than the traditional DCS market. Portability is a design goal of the standard; how much of it you get in practice depends on the components chosen and how the system is engineered. Ask for evidence from working systems, not slides.
Where CSI fits
CSI is a vendor-neutral consultancy and a co-founding member of the Coalition for Open Process Automation (COPA). We help plants plan advanced applications into the migration, and design them to stay portable on open architectures.
Use the migration to recover value, and to put AI into production
A migration is disruptive anyway. Use it to bring back the value you have already paid for.
Bring switched-off APC back on
Most sites have controllers that have been off for months. The hardware, the licences and most of the engineering are already paid for, which makes them the cheapest margin on the site. A migration is the natural moment to recommission them properly: with an owner, retrained operators, displays that show what the controller is doing, and a service-factor target that someone reports every month.
Put machine learning into the control room
Many plants have machine learning or soft-sensor pilots that worked well in a presentation and never reached operations. The gap is rarely the model. It is the path from a promising model to something operators trust during an upset. Three questions decide whether a model gets there:
- Who owns it when the feed changes, the catalyst ages or an instrument is replaced?
- Where does it run, and does it survive the next platform change without being rebuilt?
- How does an operator see, at a glance, when the model is wrong and it is time to ignore it?
Those are control engineering questions as much as data science ones. The plants that get value from AI treat models the way they treat APC: each one has an owner, a monitor, a measured result in the monthly report, and a home on an architecture that does not lock it to one supplier.
What good looks like. The night shift sees a predicted quality number they actually use to make a move, and the engineer spends Monday improving the model instead of defending it in a meeting.
A 90-day starting plan
You do not need a migration contract to start. You need 90 days, a historian and a short list.
| Days | Focus | Actions |
|---|---|---|
| 1 to 30 | Inventory | List every advanced application on the site, with its unit and owner. Pull 90 days of on and off status for every controller and calculate its service factor. Find the original business case for each application and note the value it was meant to deliver. |
| 31 to 60 | Baseline and dependencies | Map what each application depends on: interfaces, tags, calculations and tools. Mark which applications are at risk in a platform change, and why. Agree service-factor targets for the applications that matter most. |
| 61 to 90 | Portability check and roadmap | Put the five questions above to your current and prospective suppliers, in writing. Decide, application by application, what moves, what is rebuilt and what is retired. Build a prioritised 12-month roadmap, with the business case for the top three moves. |
The output is one page for the steering committee that shows what your advanced applications earn today, what is at risk in the migration, and the decisions needed to protect it. It is far easier to get APC into the main scope with that page than without it.
Appendix: migration checklist, per advanced application
Work through this list for each application on your worksheet. It is the detail behind "planned into the main scope".
Interfaces
- Every read and write point, tag and execution dependency on the current platform is listed.
- The communication method on the new platform is defined and tested.
Data
- Historian tags, calculations, filters and data validation are documented and mapped.
- Units, scaling and time stamps are checked against the new system.
Models
- Models and tuning are exported, versioned and stored where the plant controls them.
- Known limits, workarounds and the reasons behind them are written down.
Testing
- Offline testing against recorded plant data is complete before cutover.
- A closed-loop test plan exists, with acceptance criteria tied to service factor and performance.
Operator acceptance
- Operators are trained on the new displays and know what the controller is doing and why.
- Operators know how to tell when an application is wrong, and who to call.
After cutover
- Service factor is tracked against the baseline from day one.
- A named owner reviews performance at 30 and 90 days and reports it to the steering committee.
For a deeper review of individual controllers, use the MPC Health Checklist.
Talk it through
If a DCS migration is on your horizon, or your advanced applications are not delivering what they should, book a 20-minute conversation with Trevor Cusworth.
- Want a quick read on how open your current architecture is? Try the OPA Advisor.
- New to open process automation? Take the free Introduction to Open Process Automation course.
About CSI. Collaborative Systems Integration (CSI) is a vendor-neutral industrial automation consultancy. We help process plants plan, migrate and modernise control systems, with a particular focus on advanced process control, analytics and machine learning, and open process automation.
O-PAS™ is a trademark of The Open Group. References to O-PAS describe the standard and do not indicate certification.