The most convincing way to trust a new SCADA system is to watch it produce the same answers as the old one, on the same live data, for long enough to be sure. That is exactly what a parallel run does: it operates the new system alongside the legacy one, both fed from the real field, so their outputs can be compared before the old system is retired. This guide explains how a parallel run is set up, what discrepancies to watch for, how long to run in parallel, and why running both systems side by side takes much of the risk out of a cutover.
Parallel Run in one line: A parallel run is the practice of operating a new SCADA system alongside the legacy system on the same live field data, so their values, alarms, and timing can be compared before the old system is retired. It de-risks a migration by proving the new system matches the old under real conditions and by keeping the legacy system available as a fallback throughout the comparison period.
A parallel run - sometimes called dual running, side-by-side operation, or shadow mode - means both the old and the new SCADA are live at the same time, watching the same process. The essential trick is feeding both systems the same real field data so that any difference in their outputs is a difference in the systems themselves, not a difference in what they are looking at. In practice this means the field data is teed to both: the same signals from the same instruments arrive at both the legacy platform and the new one, which then process, historize, alarm on, and display them independently.
During the run, the new system is typically in a watching role rather than a controlling one - it observes and displays and records, while the legacy system remains authoritative for actual operation. This shadow arrangement lets the new system be exercised against reality without yet trusting it to run anything, so a mistake in the new system shows up as a discrepancy to investigate rather than as a process upset. Operators can begin to familiarize themselves with the new displays and alarms during this period, building confidence and surfacing usability issues while the old system still carries the real responsibility.
How the data is teed depends on the architecture. It might be split at the field or the network so both systems poll or receive the same points, or the new system might subscribe to the same data stream the old one uses. The details vary, but the principle is constant: both systems must see identical inputs for the comparison to mean anything. A parallel run where the two systems are fed even slightly different data produces differences that are impossible to interpret, which defeats the purpose.
The value of a parallel run is in the comparison, so the team decides in advance what to compare and what counts as a meaningful discrepancy. Values are the first thing: for the same point at the same moment, do both systems show the same reading in the same engineering units? Small differences may be explained by different scaling, rounding, or update rates, but a persistent or large gap points to a configuration error - a wrong scaling factor, a mismapped tag, a units mistake - that needs fixing before the new system can be trusted.
Alarms are the second and often the most revealing thing to compare. Because alarms are where a SCADA earns its keep, the run checks that the new system raises the same alarms as the old one under the same conditions, at the same priorities, and neither invents spurious alarms nor misses real ones. A new system that stays quiet when the old one alarms, or that floods with alarms the old one never raised, has a configuration problem that would be dangerous to carry into live operation. Getting alarm behavior to match is frequently the hardest and most important part of validating a migration.
Timing is the third dimension. Timestamps on values, on alarms, and on historized samples should line up closely between the systems, because a new system that lags, or that stamps events with a different time, can mislead operators and corrupt the historical record used for later analysis. Discrepancies in any of these areas are logged, investigated, and resolved, and the run continues until the differences that remain are understood and accepted rather than unexplained. The goal is not necessarily zero difference - some differences are legitimate - but zero unexplained difference.
How long to run in parallel is a judgment about coverage rather than a fixed number. The run needs to last long enough to see the range of conditions the process actually experiences - normal operation, but also the upsets, start-ups, shutdowns, and edge cases that only appear occasionally and are exactly where a new system is most likely to diverge. A parallel run that only ever sees calm, steady operation has not really tested the new system, so teams often continue until a representative variety of conditions has been observed and the systems have been shown to agree across them. Critical sites usually warrant a longer parallel period than simple, low-consequence ones.
A completed parallel run takes much of the fear out of the eventual cutover. By the time the old system is retired, the new one has already been proven to match it on live data across a range of conditions, operators have grown comfortable with it, and the configuration errors that would otherwise have surfaced during go-live have already been found and fixed in the safety of shadow operation. This transforms the cutover from a leap of faith into a formality: the switch of authority from old to new happens after the new system has already demonstrated it produces the right answers, and the old system remains available as a fallback right up to the moment it is retired.
The catch with traditional parallel running is cost, because standing up a whole second SCADA to run alongside the old one has historically meant duplicate servers and infrastructure that exist only for the comparison period. A cloud SCADA platform such as Merobix removes most of that cost, which is what makes parallel running cheap enough to do thoroughly. Because the new system is a hosted service that can read the same field data as the incumbent without new servers on site, teeing the data to both systems and running the new one in shadow becomes a matter of configuration rather than a hardware project. For a fleet of remote sites, each location can be run in parallel and validated in the cloud before its cutover, so the whole migration proceeds site by site on the strength of proven, side-by-side comparisons rather than hope - and the legacy system stays warm as the fallback throughout, exactly as a low-risk migration requires.
The point is to prove the new system produces the same answers as the old one on the same live field data before the old system is retired. Running both side by side lets you compare values, alarms, and timing under real conditions, so configuration errors surface as discrepancies to fix rather than as failures during go-live. It also keeps the legacy system available as a fallback and lets operators build confidence in the new displays.
You compare values, alarms, and timing. Values should match in the same engineering units, with persistent gaps pointing to scaling or mapping errors. Alarms should fire on the same conditions at the same priorities, with no missing or spurious alarms - often the hardest and most important thing to get matching. Timestamps on values, alarms, and history should line up closely. The aim is zero unexplained difference, not necessarily zero difference, since some differences are legitimate.
Long enough to see the range of conditions the process actually experiences - not just calm, steady operation but also upsets, start-ups, shutdowns, and the edge cases where a new system is most likely to diverge. A run that only sees steady operation has not really tested the new system. Teams typically continue until a representative variety of conditions has been observed and the systems agree across them, with critical sites usually warranting a longer period than simple ones.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.