Almost every Open Process Automation project is a brownfield project. The greenfield case — a new plant designed for an open architecture from the start — is the easy one, and it is rare. The real question facing the industry is harder: how does an operating facility, with a working DCS and a production schedule that cannot stop, move to an open architecture without putting the plant at risk?
This paper is about that question. It is written for the engineering leaders and I&C teams who will own the migration — the people who have largely accepted that Open Process Automation is where their facility is heading and now need to understand how the work actually sequences. It assumes the strategic case is settled. It focuses on method: how a brownfield migration is structured, why the phased approach is the only responsible one, and what costs and risks have to be planned for honestly rather than discovered mid-project.
In short
A brownfield DCS migration to Open Process Automation should never be a single wholesale cutover. The responsible approach is phased coexistence: the open architecture is introduced alongside the existing DCS, the two are bridged by gateway components, and control is moved across in deliberate, low-risk increments. This is not a workaround — the O-PAS standard is explicitly designed for it. Phased migration costs more in engineering and takes longer in calendar time than a clean replacement would, and an honest plan accounts for that. What it buys is the thing that matters most in an operating plant: control of risk.
Why "rip and replace" is the wrong model
When a proprietary DCS reaches end-of-life, the migration the incumbent supplier offers is, in effect, a wholesale swap — the old system out, a new system from the same supplier in, on a turnaround schedule. Operators have lived with that model for decades because a closed architecture leaves little alternative: a proprietary system cannot be partially replaced, so replacement is necessarily all-or-nothing.
That model carries a specific and serious risk. A wholesale cutover concentrates the entire migration into one window. Every loop, every interlock, every operator workflow changes at once. The validation burden is enormous, the rollback options are limited, and the plant is exposed during a single high-stakes event. Operators accept this risk because the closed architecture gives them no other option — not because it is good engineering.
The central advantage of an open architecture in a migration context is that it removes that constraint. Because O-PAS defines standardized interfaces between components, the system can be changed component by component. Migration stops being a single event and becomes a sequence — and a sequence can be ordered, paced, validated, and, if necessary, paused.
The coexistence principle
The foundation of a brownfield OPA migration is coexistence: for a period measured in months or years, the legacy DCS and the new open architecture run at the same time, in the same plant, controlling different parts of the same process.
This is possible because of a specific provision in the O-PAS architecture. The standard defines the gateway — a conformant component, a Distributed Control Node configured for the purpose, that sits between the open system and a non-conformant device or system and makes the legacy equipment visible through standardized interfaces. A gateway connected to an existing DCS exposes that DCS's information to the open architecture without modifying the legacy system itself. The old system continues to do its job; the open architecture can see it, exchange data with it, and coordinate with it.
That gateway is the bridge the entire migration crosses. With it in place, the plant is no longer choosing between "old system" and "new system" as of a single date. It is operating one integrated system that happens to be part legacy and part open — and the migration becomes the gradual, controlled movement of scope from the first kind of component to the second.
It is worth being precise about what the standard does and does not do here. O-PAS specifies that the gateway presents legacy information through conformant interfaces. It does not specify how the gateway translates to and from the particular legacy system on the other side — that conversion is specific to the legacy vendor and protocol and sits outside the standard. In practice this means gateway engineering is real, non-trivial work, and it is one of the costs a migration plan has to carry openly.
How a phased migration sequences
A brownfield migration is best understood as four stages. They are not rigid phases with hard walls between them, but they describe the order in which the work has to happen.
Stage one — assessment
Before any migration is planned, the facility's actual position has to be established: the condition and remaining supported life of the existing DCS, the structure of the control system, the dependencies between units, the integration points with safety and electrical systems, and the operational constraints that will govern when and how work can be done. The output of this stage is not a migration yet — it is an honest map of the starting point. A migration plan built on an inaccurate map of the existing system is the most common way these projects go wrong.
Stage two — readiness and architecture
With the starting point understood, the target is designed: the open architecture the facility is migrating to, and the path between the two. This is where the lifecycle-cost case is modeled against the facility's real parameters, where architectural and organizational readiness are assessed, and where the migration is broken into its increments. The key decision of this stage is sequencing — which part of the process moves first, and in what order the rest follow. That decision is driven by risk: the first increment should be chosen so that it proves the approach while exposing the plant to as little as possible.
Stage three — phased cutover
This is the migration proper, executed in the increments defined in stage two. The gateway architecture is established, the legacy DCS and the open system are bridged, and control scope is moved across one increment at a time. Each increment is a smaller, contained version of a traditional cutover: it is designed, validated, executed, and confirmed before the next begins. The plant is never exposed to more change than one increment's worth at any moment, and a problem in one increment does not propagate to the rest of the system.
Stage four — commissioning and handover
As the last increments move across, the migration completes: the open architecture carries the full control scope, the gateway and legacy components are retired on a planned schedule, and the system is commissioned as a whole. Handover to operations is not a single moment at the end — in a phased migration, operators have been working with the open system, increment by increment, throughout. By the time the migration completes, the open architecture is already familiar.
Sequencing decisions: where the judgment lives
The four stages describe the structure. The judgment in a migration lives in the sequencing decisions within them — and a few principles govern those decisions.
Sequence by risk, not by convenience. The order in which control scope moves should be driven by exposure, not by what is easiest to reach. The first increment should be chosen to prove the architecture and the team's execution on a part of the process where the consequences of a problem are most contained. Confidence earned early is what makes the later, more consequential increments manageable.
Respect the natural boundaries of the process. Increments should follow the real divisions of the plant — process units, areas, logical groupings that already operate with a degree of independence. Cutting an increment across a tightly coupled control boundary multiplies the integration burden and the validation risk. The plant's own structure usually suggests the right increments.
Plan the coexistence period as a real operating state, not a transition to rush through. For the duration of the migration, the plant runs a hybrid system. That is a state to be engineered deliberately — operator interfaces that span both architectures, alarm management that accounts for both, maintenance procedures for both — not an awkward interval to minimize. A migration that treats coexistence as a first-class operating condition is far less stressful than one that treats it as a problem to escape.
Keep rollback real at every increment. The reason to migrate in increments is to preserve options. Each increment should be planned so that, if validation fails, the increment can be backed out without affecting the rest of the system. Rollback that exists only on paper is not rollback. Designing each increment so that retreat is genuinely possible is what converts the phased approach from a sequence of small risks into a genuinely controlled one.
The costs to plan for honestly
A phased migration is the right approach, but it is not the cheap approach in the narrow sense, and a credible plan says so plainly.
Engineering cost is higher than a wholesale swap. Designing increments, engineering gateways, and managing the coexistence period is more total engineering than a single cutover would require. The phased approach trades engineering cost for risk reduction. That is a good trade for an operating plant — but it is a trade, and the budget has to reflect it.
Calendar time is longer. A migration executed in increments, each validated before the next, takes more elapsed time than a single turnaround cutover. The plant gets the benefit of never being exposed to wholesale change; the cost is a longer total migration timeline.
The coexistence period has its own operating overhead. Running two architectures in parallel means maintaining two sets of components, two bodies of engineering knowledge, and the integration between them, for the duration. This is temporary, but it is real, and it should be costed as part of the migration rather than treated as free.
Gateway work is specific and cannot be skipped. Because the conversion between the open architecture and a particular legacy system is outside the standard, gateway engineering is bespoke to the facility's existing equipment. It is one of the more technically involved parts of the project and one of the easiest to underestimate.
None of this argues against phased migration. It argues for planning it with open eyes. The wholesale cutover looks cheaper and faster precisely because its largest cost — concentrated risk to an operating plant — does not appear on the budget line. The phased approach makes that cost visible and pays it down deliberately. For a facility that cannot afford to be wrong about a control system migration, that is the trade worth making.
Where this leaves you
A brownfield DCS migration to an open architecture is a serious project, and it should be approached as one. But it is not the high-wire act that a wholesale proprietary replacement is. The open architecture's defining property — standardized interfaces between components — is what makes a migration something that can be sequenced, paced, and controlled rather than bet on a single window.
The work is real: assessment, architecture, gateway engineering, increment-by-increment cutover, and a coexistence period that has to be engineered as a genuine operating state. The costs are real and should be planned honestly. What the phased approach delivers in return is the one thing an operating facility cannot compromise on — control of risk across the migration.
The starting point for any specific facility is an honest assessment of where it actually is: the condition of the existing system, the structure of the plant, and the constraints that will shape the sequence. That assessment is the foundation everything else is built on, and it is the right first step for any operator whose DCS is approaching the point where this decision can no longer be deferred.
This whitepaper is published by Collaborative Systems Integration (CSI). CSI is a vendor-independent systems integrator specializing in Open Process Automation, with particular focus on brownfield DCS migration in refining, chemicals, and utilities. CSI's founding principal, Don Bartusiak, served as Co-Chair of the Open Process Automation Forum; CSI's Trevor Cusworth served as an OPAF Co-Chair for six years and leads marketing and outreach within the Forum's Business Working Group. CSI operates under a commercial license from The Open Group for the O-PAS Standard. O-PAS™ is a trademark of The Open Group. Views expressed here are CSI's and do not represent positions of The Open Group or the Open Process Automation Forum.