Replacing the SCADA system that watches over a live facility is not like upgrading an app on a phone, because the process never stops and the operators can never go blind. At some point the responsibility for monitoring and control has to move from the old system to the new one, and that moment of transfer is the cutover. This guide explains what a cutover is, the difference between switching everything at once and doing it in stages, how the cutover window and freeze period are managed, and how a live-process facility keeps eyes on its sites throughout.
SCADA Cutover in one line: A SCADA cutover is the controlled switch of monitoring and control responsibility from an old SCADA system to its replacement. It can be done all at once (big-bang) or in stages with both systems running side by side (phased or parallel), and it is managed with a cutover plan, a defined cutover window, a change freeze, and pre-agreed rollback triggers so a live facility is never left without supervision.
The most consequential decision in a cutover is whether to switch everything at once or move across in stages. A big-bang cutover retires the old system and brings the new one into service in a single planned event: at the end of the window the old system is off and the new one carries the whole facility. Its appeal is simplicity and a short transition - there is one date, one event, and no lengthy period of running two systems. Its risk is concentration, because everything depends on that one window going well, and if it does not, the pressure to fix or fall back is intense.
A phased cutover spreads the transition out, moving one site, one area, or one subsystem at a time onto the new system while the rest stays on the old one. For an operator with many remote sites this is often the natural approach: wellpads or stations are migrated in batches, each batch proven before the next begins, so a problem is contained to a small part of the fleet rather than the whole operation. The cost is a longer transition and a period during which two systems must be kept working, sometimes reading the same data in parallel so results can be compared before the old view is retired.
The choice depends on how much risk the operation can absorb in a single window versus how long it can tolerate running two systems. A small, self-contained facility might reasonably go big-bang in a quiet maintenance window, while a large distributed operation almost always phases the move to keep any single failure small. Many real projects are a hybrid: a phased rollout across sites, with each individual site experiencing something closer to a big-bang switch of its own telemetry.
A cutover is executed within a planned cutover window - a defined block of time, usually chosen for low process activity or scheduled maintenance, during which the switch is made. The window has a start, a sequence of steps, checkpoints where the team confirms progress, and a hard deadline by which the system must be either accepted as live or rolled back. Building the window around a period of reduced operational demand limits how much is at stake if something goes wrong.
Around the window sits a change freeze: a period before and often just after the cutover during which no unrelated changes are allowed to either system. The freeze exists so that if something breaks, the team knows the cutover is the only thing that changed, rather than chasing an unrelated modification made the same day. Configuration is locked, the old system is left in a known, stable state, and only the cutover activities proceed.
The hardest constraint on a live-process cutover is that the facility can never lose supervision. Operators must be able to see and, where required, control their process throughout, so the plan spells out exactly which system is authoritative at each moment and how coverage is maintained during the handover. In practice this often means the old system keeps monitoring right up to the point the new one is confirmed good, with operators watching both, so there is never an instant when nobody is looking at the process. A cutover that leaves a live facility blind, even briefly, is not an acceptable plan.
Because a cutover touches a running operation, risk management is not an add-on but the core of the plan. Every cutover plan defines rollback triggers - the specific conditions under which the team will abandon the switch and revert to the old system - and a point of no return after which rolling back is no longer practical, so the decision to proceed past it is made deliberately and by a named authority. A dry run or rehearsal of the cutover steps, where feasible, exposes gaps in the sequence before the real window rather than during it.
For a producing field or a pipeline, the stakes are physical: pressure, flow, and safety systems are all in play, so the plan coordinates with operations and, where relevant, safety personnel, and it schedules the cutover to minimize exposure. Communication during the window is scripted - who is on the bridge, who declares each checkpoint passed, and who has the authority to call a rollback - so decisions are not improvised under stress.
A cloud SCADA platform such as Merobix makes the safest cutover pattern - running the old and new systems in parallel - considerably cheaper and easier, which changes what is practical. Because the new system is a hosted service that can read the same field data as the incumbent without new servers on site, an operator can point telemetry at both, watch the new displays fill with live data alongside the old ones, and compare them for as long as they like before retiring the legacy view. That turns a nerve-wracking big-bang moment into a gradual, evidence-backed handover: each site is confirmed reporting correctly in the cloud, operators build trust in the new view while the old one still runs, and the actual switch becomes a formality once the parallel period has proven the new system matches the old. The old system stays available as a fallback throughout, which is exactly what a live-process cutover needs.
A big-bang cutover switches the entire facility onto the new SCADA in a single planned event, which is simple and quick but concentrates all the risk in one window. A phased cutover moves one site, area, or subsystem at a time while the rest stays on the old system, containing any problem to a small part of the operation at the cost of a longer transition and a period of running two systems. Distributed operations usually phase the move.
A cutover window is the defined block of time during which the switch from the old system to the new one is made, usually scheduled for a period of low process activity or planned maintenance. It has a start, a sequence of steps with checkpoints, and a hard deadline by which the new system is either accepted as live or the team rolls back. Building it around quiet operations limits what is at stake if something goes wrong.
The cutover plan spells out which system is authoritative at each moment and ensures the facility never loses supervision. In practice the old system usually keeps monitoring right up to the point the new one is confirmed good, with operators watching both, so there is never an instant when no one is seeing the process. A cloud SCADA that reads the same field data as the incumbent makes this parallel watching cheap and straightforward.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.