Modernize Refinery Control Systems Without Downtime

To modernize a legacy process control system in an operating refinery without lost production, replace it in layers. Move reporting and analytics onto their own data path first, then operator consoles, then controllers and I/O loop by loop through hot cutover. Leave the rest for turnaround windows, and run every step through OSHA PSM management of change.

Several vendor migration paths, and the hot cutover account later in this post, move consoles before controllers and I/O. Putting the data layer ahead of both is our own recommendation, so here is where we stand. Of Ash and Fire is a software company that builds the data and integration layer around a DCS or SCADA system: historian feeds, OPC UA gateways, the paths out to the business network, and the reports on top. We do not cut over control loops, configure controllers or touch safety instrumented systems. That work belongs to your controls team, your DCS vendor and a qualified integrator.

What does "without production downtime" actually mean in a refinery?

It means the migration neither causes an unplanned outage nor adds days to a planned one. Most real projects mix a hot cutover, done while the unit runs, with a cold cutover done inside a scheduled shutdown; Yokogawa's cutover guidance says "in most cases, a combination of hot cutover and cold cutover is usually used."

A hot cutover avoids lost production but carries the risk of upsetting or tripping a running unit while loops move. A cold cutover removes that risk but has to fit inside a turnaround, and turnarounds are rare. The American Fuel & Petrochemical Manufacturers says most refinery units run on a three to five year turnaround cycle, and a 2007 EIA report summarized by Oil & Gas Journal put typical planning at one to two years and the outage itself at 20 to 60 days. A migration step that needs a unit down and is not already in the turnaround scope will probably wait years for its window.

So the practical goal is to move hot whatever your controls engineers and hazard review judge safe to move hot, and to arrive at the next turnaround with only the remaining work, tested and staged.

Who should do which part of a DCS migration?

The control layer belongs to the DCS vendor, a qualified control system integrator and your own controls engineers. The systems that consume plant data for reporting and analytics can be rebuilt by a different team on a different schedule, as long as OT security and the controls team own the connection between the two.

The ISA-95 levels, as the OPC Foundation summarizes them, give a useful split: Level 2 is the controllers and DCS, Level 3 is manufacturing operations management, and Level 4 is business planning and ERP. Loop cutover, controller configuration and operator graphics are Level 2 work. Historians, lab data, production accounting and energy dashboards sit at Level 3 and above. If you are choosing someone for the Level 2 work, ask how many hot cutovers they have run on your platform and who on their team will stand next to the board operator. A software firm should not be on that shortlist, us included.

Why move the data layer before the control system?

Every report, spreadsheet and dashboard that reads from the old console or its historian interface is a migration dependency. Moving those consumers onto a separate, governed data path before control changes start removes most of them from the cutover plan, so the control team is not also chasing broken reports during an outage.

In older refineries that list runs from production accounting pulling meter totals to a planner's workbook with a live link. Many connect through OPC Classic, which the OPC Foundation describes as built on Microsoft COM/DCOM. Microsoft's DCOM hardening under KB5004442 cannot be disabled on systems patched from March 14, 2023 onward, and it broke some remote OPC DA connections. If any of yours were found that way, the inventory is not finished.

The first deliverable is a list of every integration: what it reads or writes, through which interface, how often, and who owns it. Split it into export-only consumers and anything that writes back into the control or Level 3 layer, such as lab results or setpoint downloads from a planning tool. Writebacks cannot ride a one-way path and need their own risk assessment. The August 2025 OT asset inventory guide from CISA, NSA, FBI, EPA and international partners, which includes an oil and gas taxonomy, recommends mapping paths between zones with data flow analysis and protocol identification. Do the discovery passively. NIST SP 800-82r3 (section E.2.3) warns that active scans "may cause device instability or interfere with the device process state" and should run during planned outages whenever possible.

With the list in hand, move each export-only consumer onto the new path. Size the reads with the DCS vendor first, because legacy OPC and historian interfaces have connection and tag limits, and aggressive poll rates can slow operator displays. A Level 3 historian that does not belong to the DCS also keeps years of history readable after the old system goes, instead of forcing an archive migration on cutover weekend. We cover the historian side in getting data out of AVEVA Historian and PI, and the same Level 2 to Level 3 boundary in MES integration in legacy plants.

How should the data path out of the control network be secured?

Send data out to a DMZ so that nothing on the business network can open a connection into the control network, and document the design as IEC 62443 zones and conduits. A firewall can enforce who initiates connections; only a unidirectional gateway enforces one-way flow in hardware.

The 2016 CISA and ICS-CERT recommended practice on defense-in-depth for industrial control systems describes the pattern: put the data historian in a DMZ, have the control side "push" data to it, and let enterprise users only pull from the DMZ server. The May 2025 joint CISA, FBI, EPA and DOE fact sheet on OT mitigations repeats it: segment IT and OT and use a DMZ "for passing control data to enterprise logistics."

A firewall rule that only allows connections initiated from the control side still carries TCP traffic in both directions once the session is open, so it limits who can start a conversation, not what flows back. NIST SP 800-82r3 defines a unidirectional gateway as hardware physically unable to send information back to the source network, paired with software that replicates databases and emulates protocol servers. Because that software decides which historians and servers you can replicate, check its list against your inventory before you buy.

ANSI/ISA-62443-3-2-2020 gives the method: define the system under consideration, partition it into zones and conduits, assess risk for each, and set a target security level (SL-T) for each zone and conduit. The read path out and any writeback path are separate conduits with different requirements, and each should be documented.

OPC UA is the usual choice for new reads at Level 3 because it does not depend on DCOM and builds security into the specification. Our comparison of OPC UA and MQTT covers when a publish and subscribe layer on top makes sense.

How do DCS vendors migrate a running unit?

The major vendors all offer ways to replace the oldest layer while the rest keeps running, mostly by keeping field wiring in place and letting old and new systems coexist. What your installed release supports is a question for the vendor.

• Honeywell's Experion LCN is an on-process, incremental upgrade for TPS systems; once a bridge links Experion to the legacy coax network, the coax can be removed one LCN node at a time. It grew out of an ExxonMobil requirement, reported by Control Global, to "allow on-process migration of components without shutting down."
• Emerson's modernization offerings split the problem by layer. Console.Connect runs the plant from DeltaV consoles while legacy controllers and I/O stay in service, IO.Connect lets DeltaV controllers drive legacy I/O, and Flex.Connect leaves legacy termination assemblies in place and extends wiring to DeltaV I/O.
• Yokogawa's CENTUM upgrade path from CENTUM CS 3000 and older systems lets multiple versions exist in the same system for an indefinite period.
• ABB's INFI 90 Function Code Library for AC 800M reproduces the commonly used Harmony function codes on the newer controller, with a conversion utility for existing logic diagrams.

Sometimes the right first move is buying time. Honeywell's ELCN, for example, emulates the TDC hardware in software, so the existing control code keeps running on supported equipment while the larger migration is planned.

The most detailed public hot cutover account we know of is Eric Schnipke's 2008 Chemical Processing article on the Ineos Nitriles plant in Lima, Ohio. It is a chemical plant, not a refinery, but the method carries over. The team replaced consoles first while old controllers kept running, then cut smaller units over cold during scheduled outages. The acrylonitrile unit went last and hot: 1,023 I/O points over about two months, roughly three to five active loops per day, with operators bypassing and hand-jacking valves as each loop moved. A trip would have cost an estimated $100,000 a day plus a 1.5-day restart. The cutover finished without one (a later trip came from a wiring error made after the cutover). Treat that pace as one team's result, not a benchmark.

Which loops are candidates for hot cutover is an engineering and hazard review decision. Loops that are tightly coupled to others, that feed interlocks, or that have no safe manual fallback are usually poor candidates. The Ineos author recommended bypasses on regulating valves only "if safety isn't an issue." Any bypass or loop parked in manual should go through your site's bypass authorization with compensating measures and a time limit. Before a hot cutover day, expect current backups of both systems' configurations, agreed stop criteria, a tested way back to the old controller, and a go or no-go call that belongs to operations. If your hazard analysis credits an operator responding to an alarm as a safeguard, console and alarm changes should go back through that analysis too.

Where do OSHA PSM management of change and PSSR apply?

For a refinery covered by 29 CFR 1910.119, replacing the control platform is a change to process technology and equipment, so expect each phase to go through management of change. Modified facilities need a pre-startup safety review when the change alters process safety information, and the control system falls under mechanical integrity.

The OSHA process safety management standard says:

• Paragraph (l)(1) requires written procedures to manage changes, except replacements in kind, to process chemicals, technology, equipment and procedures. A replacement in kind is one that "satisfies the design specification." A new controller platform will rarely meet that test, and the MOC should record the technical basis either way.
• Paragraph (l)(2) requires each change to address the technical basis, the impact on safety and health, changes to operating procedures, the time period and the authorization requirements.
• Paragraph (l)(3) requires affected operators, maintenance staff and contract employees to be informed and trained before start-up of the affected part of the process. On a hot cutover that part may be a few loops at a time, so plan training ahead of each group rather than once at the end.
• Paragraphs (l)(4) and (l)(5) require updating process safety information and operating procedures when the change affects them. New graphics, alarm limits and interlock logic usually do.
• Paragraph (i) requires a pre-startup safety review for modified facilities when the modification changes process safety information, and paragraph (j)(1)(v) covers "controls (including monitoring devices and sensors, alarms, and interlocks)" under mechanical integrity.

A new historian interface on the control network is a change to equipment that loads the DCS, so we would expect it to go through your MOC process rather than around it. Refineries in EPA's Risk Management Program have a parallel MOC requirement in 40 CFR 68.75 with the same five considerations. The safety instrumented system has its own lifecycle under IEC 61511, and a data layer project should leave it alone.

For testing, IEC 62381:2024 sets out requirements and checklists for the factory acceptance test, factory integration test, site acceptance test and site integration test of process automation systems. Ask which of those your vendor will run, and add the data layer to the site integration test: after each cutover, every downstream consumer should get the same value, units, timestamp and quality status it got before.

A phased plan for modernizing without production downtime

The plan below gets the data and operator layers off the old system before controllers move, so the control changes are the only thing left to cut over. Set durations with your vendor; they depend on I/O count and the turnaround calendar.

Phase 3 is where data continuity breaks if nobody plans for it. During coexistence, the data layer needs a tag map from old to new addresses, a translation between the two systems' quality codes, consistent timestamps, buffering for any gap during the switch, and a reconciliation check after each group moves. Phase 1 does not depend on a capital decision about the DCS; it needs historian or gateway procurement, vendor sizing and an MOC.

What should a refinery inventory first?

Start with the integrations, because they rarely have a single owner. For each, record the interface and protocol (OPC DA, OPC UA, ODBC to the historian, a vendor API or a file drop), whether it reads or writes, the business owner, and what happens if it stops for a day.

Then pull the DCS vendor's lifecycle notice for your controller and console generation and put the next two turnaround dates beside it. What reads from the system, how long the vendor will support it, and when a unit can come down set most of the schedule.

We use the same approach for any legacy integration, described in our guide to legacy system integration and reverse engineering. On one project we put schema validation in front of an undocumented vendor API, and it caught three vendor-side changes before they broke anything (case study). Our oil and gas and industrial IoT development pages describe the data layer work we take on, and our post on custom software for Oklahoma energy companies covers the business side. If you want a second opinion on your integration list, send it to us.