Home › Open Process Automation Migration Strategy
Brownfield DCS · Coexistence · Cutover · Lifecycle
A brownfield migration is not a technology swap. It is a controlled sequence of operating states that moves control, applications and responsibility from the installed DCS into an open architecture while production continues.
The short answer
Most brownfield facilities should migrate to Open Process Automation in bounded increments rather than treat the change as one plant-wide replacement event. The installed DCS and the new architecture coexist while a selected unit, application or control boundary is moved, verified and stabilised. Each increment has its own entry criteria, cutover plan, acceptance evidence and executable rollback.
The right strategy depends on the installed system, outage windows, process coupling, application condition, field wiring, operating capability and business case. The method is phased; the sequence is facility-specific.
01 · Strategy selection
The choice is not between migration and no migration. It is where change is concentrated, how long the transition lasts and how much rollback remains available.
Retain the installed DCS for core control while introducing open interfaces, compute or applications around it.
Move control scope by process unit, area, package or other natural operating boundary.
Build and verify the target environment alongside the legacy system before transferring authority.
Replace a large defined scope during a planned outage, with the target system prepared and tested in advance.
The strategy rule
Choose the model from facility evidence, not from a standard corporate diagram. One site may use wrap-and-extend for advanced applications, phased migration for process units and a turnaround replacement for obsolete field infrastructure within the same program.
02 · Starting position
A migration schedule built on drawings, databases and application records that do not match the operating plant will fail at the boundary between plan and reality.
Hardware age, support status, spares, failure history, network condition, cybersecurity position and remaining service life.
I/O, loops, sequences, interlocks, alarms, graphics, historians, interfaces, packaged systems and safety-system boundaries.
Source availability, language, libraries, undocumented logic, vendor dependencies, dead code and test coverage.
Outage windows, production commitments, seasonal limits, process coupling, temporary-operation rules and rollback time.
Architecture ownership, engineering capacity, operator readiness, maintenance skills, change control and supplier support.
Current support, downtime exposure, refresh capital, engineering effort, application value and lifecycle cost.
Use the OPA Business Case Guide to separate facility facts, supplier estimates, external benchmarks and management assumptions before selecting the program sequence.
03 · First increment
The first increment should solve a real operating need and exercise the architecture, integration and lifecycle practices the wider program will reuse.
| Criterion | A strong first increment | A weak first increment |
|---|---|---|
| Business need | Has funded value independent of being an OPA demonstration. | Exists only to show that components can communicate. |
| Boundary | Follows a natural process or control boundary with countable interfaces. | Cuts through tightly coupled control with many hidden dependencies. |
| Consequence | Material enough to require production discipline but bounded enough to recover. | Either trivial and teaches little, or critical enough to threaten the entire plant. |
| Representativeness | Exercises the products, applications, interfaces and support model needed later. | Uses a special architecture that the larger program will not repeat. |
| Data and documentation | Has recoverable source, drawings, I/O records and known operating tests. | Begins with undocumented logic and no credible functional baseline. |
| Operations ownership | Operators and maintenance personnel participate in design, test and cutover. | The project is owned only by engineering until handover. |
| Reuse | Produces templates, libraries, test assets and governance the next increment can adopt. | Ends as a one-off installation with no controlled assets transferred to the program. |
04 · Program sequence
Each stage creates a controlled output that becomes the entry condition for the next.
Reconcile drawings, I/O, control logic, alarms, interfaces, operational procedures and actual plant behaviour. Record what is unknown rather than treating missing information as correct.
Set architecture principles, required roles, interfaces, application strategy, system management, cybersecurity and lifecycle ownership before products are selected.
Describe how the legacy and target systems coexist after every increment: who controls each scope, where data crosses, what operators see and how maintenance supports both.
Engineer applications and interfaces, qualify products, integrate the proposed baseline and complete component and integrated testing before site work begins.
Define the minute-by-minute sequence, authority, hold points, success criteria, abort criteria, restoration steps, communications and required plant state.
Execute the approved plan, verify process and system behaviour, close defects, confirm operational readiness and retain enhanced support through the stabilisation period.
Update the reference architecture, libraries, test procedures, cost basis, responsibility model and lessons before selecting the next increment.
05 · Coexistence
Brownfield programs can spend months or years with legacy and open systems operating together. That condition needs its own architecture, procedures and acceptance criteria.
| Transition question | Required decision | Evidence before operation |
|---|---|---|
| Control authority | Which system owns each output, sequence, permissive and interlock at this stage? | Authority matrix, approved logic boundary and field verification. |
| Data exchange | What information crosses the boundary, in which direction, at what rate and with what quality status? | Interface definition, loading test and loss/recovery behaviour. |
| Operator experience | Where are alarms, graphics, trends and commands presented while two systems coexist? | Operator workflow test, alarm review and abnormal-situation scenarios. |
| Time and sequence | How are events, alarms and historian records aligned across the systems? | Time-source design and sequence-of-events verification. |
| Cybersecurity | How is the temporary boundary segmented, authenticated, monitored and supported? | Approved network design, access test and incident procedure. |
| Configuration control | How are changes kept consistent while the same process knowledge may exist in two environments? | Version baseline, change workflow and reconciliation record. |
| Support ownership | Who responds when the fault could sit in either system or at the boundary? | Joint escalation map, diagnostic access and response commitment. |
The coexistence rule
Temporary does not mean informal. If the hybrid state will control production, it needs the same architecture discipline, cybersecurity review, operating procedures and acceptance evidence as the final state.
06 · Applications
The legacy application contains years of operating decisions, undocumented changes and embedded assumptions. Migration must recover and verify that knowledge before translating it into the target environment.
Collect source, libraries, configurations, alarm settings, graphics, sequences, interlocks, tuning, overrides and field modifications. Compare records with the running system.
Remove dead logic, resolve temporary changes, identify obsolete interfaces and separate operating requirements from legacy implementation constraints.
Determine which applications can be migrated, converted, re-engineered or replaced. Define IEC 61131 language, library, runtime and deployment requirements explicitly.
Trace requirements to tests and compare sequence, interlock, alarm and control behaviour against the approved baseline before site cutover.
Require source, libraries, build instructions, dependencies, versions, test records and deployment packages as owner-controlled handover assets.
Decide which improvements belong in the cutover and which should wait until the migrated baseline is stable. Combining both can make defects difficult to attribute.
07 · Cutover control
A statement that the team can return to the old system is not a rollback plan. The project needs a verified route back within the plant's safe operating window.
Required plant condition, completed tests, approved defects, staffing, backups, spares, permits and readiness sign-offs.
One cutover leader, named decision makers, communications channels, control-room authority and supplier escalation.
Defined moments where the team confirms evidence before the next irreversible action.
Observable process and system conditions required to continue, stabilise and accept the increment.
Pre-agreed thresholds for stopping before schedule pressure turns a recoverable problem into an operating event.
Backups, legacy readiness, field reconnection, configuration integrity and a timed rehearsal of critical recovery steps.
The integrated test programme should cover the boundary behaviours that make rollback credible. Use the O-PAS FAT and Interoperability Testing Guide to define those scenarios.
08 · Control document
The basis of design connects business intent to engineering and gives every increment a common decision framework.
Business drivers, scope, lifecycle outcomes, operating constraints and the measures used to judge the program.
Current architecture, condition, applications, interfaces, documentation quality, support status and known risks.
Target roles, interfaces, applicable O-PAS requirements, application strategy, cybersecurity and system management.
Migration model, selected boundaries, sequence, coexistence architecture, dependencies and decision gates.
Owner, EPC, integrator and supplier responsibilities; architecture authority; exception approval; issue escalation.
Product evidence, application testing, integrated FAT, SAT, cutover readiness, stabilisation and handover records.
Carry these requirements into contracting with the O-PAS Procurement Specification Checklist and allocate the work using the O-PAS Responsibility Matrix.
09 · Economics
A phased approach reduces concentrated cutover risk but creates real engineering and operating costs that disappear from weak estimates.
| Cost area | Work to include | Common omission |
|---|---|---|
| Baseline recovery | Field verification, documentation reconciliation, source recovery and application inventory. | Assuming the document repository represents the running plant. |
| Architecture | Target design, transition states, interface definitions and migration basis of design. | Pricing only the final bill of materials. |
| Coexistence | Gateways or interface arrangements, duplicate environments, hybrid operations and dual support. | Treating the transition period as free temporary work. |
| Applications | Rationalisation, translation, redevelopment, libraries, functional testing and documentation. | Counting loops without assessing application complexity and knowledge quality. |
| Integration and testing | Staging environment, multi-vendor integration, test development, defect cycles and regression testing. | Using a conventional single-supplier FAT allowance. |
| Site execution | Outage preparation, field work, cutover staffing, rollback readiness, commissioning and stabilisation. | Funding the cutover window but not the preparation that makes the window achievable. |
| Capability and support | Operator and maintenance training, procedures, spares, tools and enhanced early-life support. | Moving technology before the operating model can own it. |
The economic comparison
Compare lifecycle pathways, not purchase prices. The migration case should include the cost of preserving the legacy system, the transition programme, future refresh cycles, downtime exposure, application reuse and the value of later supplier choice.
10 · Continue the work
Read the longer treatment of coexistence, sequencing, gateway work and migration economics.
Practitioner courseWork through readiness, baseline documentation, strategy, interfaces, I/O, applications, FAT, SAT, cutover and stabilisation.
Decision hubConnect the migration to business case, architecture, procurement, governance and operating-model decisions.
11 · FAQ
No. A brownfield programme can introduce the target architecture alongside the installed system and move bounded control, application or process scope in planned increments. The facility must engineer each coexistence state and the interfaces between the two environments.
Select a funded operating need with a natural boundary, manageable consequence and enough representative architecture, application and interface work to prove the method. The easiest isolated system may be safe but may not teach the programme what it needs.
Only as long as the approved programme sequence requires, but the duration may be months or years. The important point is to design coexistence as a supported production state with clear control authority, interfaces, cybersecurity, procedures and ownership.
Some can be migrated or translated; others require redevelopment. The decision depends on source availability, language, libraries, dependencies, code quality and target runtime. Functional equivalence should be demonstrated against an approved baseline.
Defined abort criteria, a known decision authority, verified backups, a ready legacy path, complete field restoration steps, sufficient time inside the operating window and rehearsal of the critical sequence.
The owner should retain architecture and acceptance authority. A named system integrator should be accountable for the integrated multi-vendor system, while the EPC and component suppliers carry their assigned engineering, execution and product responsibilities.
Brownfield migration planning
CSI helps owner-operators assess the installed system, select the migration model, design coexistence, define application and interface work, plan verification and build a sequence the operating plant can execute.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. Migration architecture, testing and cutover requirements must be adapted to the facility, applicable standards, process risk and approved operating procedures.