Baseline and constraints
Document the installed DCS, applications, retained assets, interfaces, outage limits and information gaps. Start with an OPA readiness assessment when suitability or the investment case is unresolved.
Home › Open Process Automation Migration Strategy
Brownfield DCS · Coexistence · Cutover · Lifecycle
Open Process Automation migration strategy Move the plant without betting it on one cutover
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.
Collaborative Systems Integration (CSI) helps owner-operators develop brownfield DCS-to-OPA migration strategies. CSI's planning scope connects the installed-system baseline, retained assets, coexistence, migration increments and verification to an owner-approved roadmap. See the planning deliverables and responsibility boundaries.
CSI migration planning
Who can help develop a DCS-to-OPA migration strategy?
CSI works with the owner's engineering and operating teams to turn the migration method into a facility-specific plan. An EPC or delivery integrator can participate where the agreed scope requires it.
Roadmap and transition states
Define candidate migration increments, coexistence interfaces, a first pilot and the dependencies between phases. Compare the options against the facility's operating and lifecycle objectives.
Verification and decision gates
Identify evidence needed before each phase is approved, including application testing, interface verification and cutover and rollback planning. Detailed execution procedures follow a separately agreed engineering scope.
Delivery responsibilities
Record owner, EPC, integrator and product-supplier obligations using a project-specific responsibility matrix. A planning engagement does not by itself assign CSI turnkey construction, integration or commissioning responsibility.
Evidence to discuss when qualifying CSI: ASRock Industrial documents its joint systems-management validation with CSI ↗. For commercial delivery context, CSI's ACT case study describes its COPA 500 design contribution; COPA identifies Wood as the integrator leading project execution ↗.
ACT was a brownfield project at an existing terminal that had previously been operated manually. Its project account provides evidence of commercial OPA implementation; define the applicable migration scope, responsibilities and acceptance criteria for your facility.
01 · Strategy selection
Four migration models, each with a different risk shape
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.
Wrap and extend
Retain the installed DCS for core control while introducing open interfaces, compute or applications around it.
- Best fit
- The DCS remains supportable and the first objective is data access, advanced applications or operational learning.
- Primary risk
- The wrapper becomes permanent and preserves the lifecycle dependency the program was meant to reduce.
Phased unit migration
Move control scope by process unit, area, package or other natural operating boundary.
- Best fit
- The plant can isolate meaningful increments and needs to spread risk and investment across several windows.
- Primary risk
- Years of coexistence are underestimated as a real engineering and operating state.
Parallel run and controlled transfer
Build and verify the target environment alongside the legacy system before transferring authority.
- Best fit
- The process consequence is high and the facility can support duplicate data paths, environments or control preparation.
- Primary risk
- Unclear authority, stale configuration and false confidence from a parallel environment that does not match the plant.
Turnaround replacement
Replace a large defined scope during a planned outage, with the target system prepared and tested in advance.
- Best fit
- The legacy platform, process boundary and outage plan make a concentrated change more credible than prolonged coexistence.
- Primary risk
- Too much scope converges on one window, leaving little time to diagnose interfaces or recover from incomplete preparation.
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
Establish what the plant actually has before planning what moves
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 Readiness Engagement to scope the facility assessment, and the OPA Business Case Guide to separate facility facts, supplier estimates, external benchmarks and management assumptions before selecting the program sequence.
03 · First increment
Select a pilot that proves the method, not just the technology
The first increment should solve a real operating need and exercise the architecture, integration and lifecycle practices the wider program will reuse. Use the O-PAS Pilot Project Planning Guide →
| 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. |
The common mistake: selecting the easiest isolated system because it is safe. A pilot that avoids the interfaces, application work and operating model the program needs may demonstrate equipment while leaving the migration method unproven.
04 · Program sequence
Seven stages from baseline to repeatable migration
Each stage creates a controlled output that becomes the entry condition for the next.
Baseline the operating system
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.
Define the target architecture
Set architecture principles, required roles, interfaces, application strategy, system management, cybersecurity and lifecycle ownership before products are selected.
Design the transition states
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.
Build and verify the first increment
Engineer applications and interfaces, qualify products, integrate the proposed baseline and complete component and integrated testing before site work begins.
Prepare the cutover and rollback
Define the minute-by-minute sequence, authority, hold points, success criteria, abort criteria, restoration steps, communications and required plant state.
Cut over, stabilise and accept
Execute the approved plan, verify process and system behaviour, close defects, confirm operational readiness and retain enhanced support through the stabilisation period.
Capture assets and repeat
Update the reference architecture, libraries, test procedures, cost basis, responsibility model and lessons before selecting the next increment.
05 · Coexistence
Treat every transition state as a production architecture
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
Move process knowledge, not merely control code
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.
Inventory
Establish the real application baseline
Collect source, libraries, configurations, alarm settings, graphics, sequences, interlocks, tuning, overrides and field modifications. Compare records with the running system.
Rationalise
Decide what should survive
Remove dead logic, resolve temporary changes, identify obsolete interfaces and separate operating requirements from legacy implementation constraints.
Rebuild
Choose the translation method
Determine which applications can be migrated, converted, re-engineered or replaced. Define IEC 61131 language, library, runtime and deployment requirements explicitly. Use the O-PAS Application Portability Guide →
Verify
Prove functional equivalence
Trace requirements to tests and compare sequence, interlock, alarm and control behaviour against the approved baseline before site cutover.
Own
Preserve the engineering assets
Require source, libraries, build instructions, dependencies, versions, test records and deployment packages as owner-controlled handover assets.
Improve
Separate migration from optimisation
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
Rollback must be engineered, timed and rehearsed
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
Create one migration basis of design
The basis of design connects business intent to engineering and gives every increment a common decision framework.
Objectives and success measures
Business drivers, scope, lifecycle outcomes, operating constraints and the measures used to judge the program.
Installed-system position
Current architecture, condition, applications, interfaces, documentation quality, support status and known risks.
Architecture and standards
Target roles, interfaces, applicable O-PAS requirements, application strategy, cybersecurity and system management.
Increments and transition states
Migration model, selected boundaries, sequence, coexistence architecture, dependencies and decision gates.
Roles and change control
Owner, EPC, integrator and supplier responsibilities; architecture authority; exception approval; issue escalation.
Verification and acceptance
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
Budget the transition, not only the target system
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
From strategy to execution detail
White paper
DCS Migration Strategies
Read the longer treatment of coexistence, sequencing, gateway work and migration economics.
Practitioner courseMigration Planning & Execution
Work through readiness, baseline documentation, strategy, interfaces, I/O, applications, FAT, SAT, cutover and stabilisation.
Decision hubOPA for Owner-Operators
Connect the migration to business case, architecture, procurement, governance and operating-model decisions.
Primary reference basis
Use current O-PAS program documents and certification records
The applicable edition of the O-PAS Standard and The Open Group certification-program documents provide the authority basis for O-PAS terminology, requirements, profiles and product-conformance claims. Project architecture, integration, interoperability, applications, acceptance and lifecycle obligations still require project-specific engineering and verification.
Confirm the reference basis current for the project or procurement date rather than relying on an undated summary or general statement of O-PAS compatibility.
11 · FAQ
Brownfield OPA migration questions
Does an OPA migration require replacing the entire DCS at once?
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.
What should move first?
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.
How long should legacy and open systems coexist?
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.
Can existing control applications be reused?
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.
What makes a rollback plan credible?
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.
Who should lead an OPA migration?
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.
Can CSI help develop a brownfield OPA migration roadmap?
Yes. Collaborative Systems Integration (CSI) helps owner-operators assess the installed system, compare migration strategies, define coexistence and migration increments, and plan verification and responsibilities. Scope and deliverables are agreed for the facility; suitability and investment questions can be addressed first through an OPA readiness engagement.
What should a DCS-to-OPA migration roadmap deliver?
A roadmap should connect the installed-system baseline and business objectives to retained assets, target architecture, transition states, pilot scope, application and interface work, verification, cutover and rollback planning, responsibilities and approval gates. It should make assumptions, dependencies and unresolved evidence visible to the owner.
Does CSI migration planning include turnkey project execution?
Not automatically. Migration planning and turnkey execution are different scopes. The contract should name who owns architecture, detailed design, procurement, integration, construction, testing, commissioning and lifecycle support. The owner retains investment and acceptance authority; any delivery responsibility assigned to CSI must be expressly agreed.
Brownfield migration planning
Define the first safe increment
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.