Moving an entire operation off a legacy SCADA platform is one of the highest-stakes projects an automation team takes on, because the process keeps running the whole time and any misstep can mean a blind site or a lost signal. Migration planning is the discipline of scoping, sequencing, and de-risking that move before a single site is touched. This guide covers how to inventory what you have, assess the drivers and protocols involved, decide on phasing and parallel running, plan for rollback, gather stakeholder sign-off, and capture it all in a migration runbook.
SCADA Migration Planning in one line: SCADA migration planning is the discipline of scoping, sequencing, and de-risking the move from a legacy SCADA platform to a new one before execution begins. It covers site and tag inventory, driver and protocol assessment, a phasing strategy, decisions about parallel running and rollback, stakeholder sign-off, and a detailed migration runbook - all aimed at minimizing operational downtime across the sites involved.
Good migration planning starts with an honest inventory of what actually exists, which on a mature operation is rarely what the documentation claims. The team catalogs every site, every device, and every tag: which PLCs and RTUs are in the field, what firmware they run, how many I/O points each carries, and which displays, reports, alarms, and historized points depend on them. On a brownfield operation this discovery often uncovers undocumented changes, dead tags, and sites that were modified in the field years ago, and finding them now is far cheaper than tripping over them mid-migration.
Alongside the physical inventory sits a driver and protocol assessment. The new platform has to speak to the existing field devices, so the team confirms which protocols are in play - Modbus, DNP3, OPC, a vendor-specific driver, a proprietary radio protocol - and whether the target platform supports each one natively or needs a gateway or translation layer. Communications media matter too: cellular, radio, satellite, and fibre links each behave differently, and a link that was adequate for the old polling scheme may need attention for the new one.
The output of scoping is a clear-eyed picture of the size and shape of the job: how many sites, how many tags, which protocols, which sites are simple copies of a template and which are one-offs, and where the unknowns and risks concentrate. That picture is what everything else in the plan is built on, and skimping on it is the most common reason migrations run over.
With the scope understood, the plan turns to the order of the move. A phasing strategy groups sites into logical batches - by geography, by criticality, by similarity, or by how self-contained they are - and sequences them so that the earliest batches build confidence and prove the migration pattern before the riskier or more critical sites are touched. Many teams deliberately start with a pilot: one representative, low-consequence site taken all the way through, so that the process, the tooling, and the runbook are shaken out on something forgiving before the fleet follows.
A central decision is whether and where to run the old and new systems in parallel. Parallel running feeds the same live field data to both platforms so their outputs can be compared before the old one is retired, which is the strongest way to build trust that the new system matches the old for values, alarms, and timing. The plan decides how long to run in parallel, what discrepancies would block a cutover, and which sites warrant it. Not every site needs a long parallel period, but the critical ones usually do.
No migration plan is complete without a rollback strategy for when a site does not go cleanly. For each phase, the plan defines the conditions that would trigger a revert, how quickly the old system can be restored to service, and how long the legacy platform is kept warm and reversible before it is finally decommissioned. Because the point is to protect a live operation, the ability to fall back has to be real and tested, not a line in a document, and the legacy system is not switched off the day a site is migrated - it is retired only once the new system has proven itself.
A migration that touches live operations cannot proceed on the automation team's say-so alone. The plan gathers stakeholder sign-off from the people who own the consequences: operations, who run the sites; safety, where the process is hazardous; management, who own the schedule and budget; and often the customers or downstream systems that depend on the data. Each phase typically has an entry and exit gate, so nobody is surprised and there is a clear, recorded decision to proceed at each step.
The execution detail lives in a migration runbook - a step-by-step script for each site or batch that says exactly what to do, in what order, who does it, how to verify each step succeeded, and what to do if it does not. A good runbook is precise enough that a cutover can be executed under pressure without improvisation, and it is refined after the pilot and each phase so it keeps getting better as the fleet moves across. The runbook is where the abstract plan becomes an actionable procedure.
The whole exercise exists to minimize operational downtime across a fleet of remote sites, and this is where a cloud SCADA platform such as Merobix changes the arithmetic. Because the target platform is a hosted service that can read the same field data as the incumbent without new servers at each site, parallel running becomes cheap and low-friction: telemetry can point at both systems, giving a natural comparison window and a ready fallback, so a site is not cut over until its data is proven to match. The per-site work shrinks to configuring and verifying the site in the cloud rather than provisioning hardware, which lets a small team migrate many remote sites in a rolling program with each individual site experiencing only a brief, well-rehearsed switch rather than a long outage.
Start with a thorough inventory and assessment: catalog every site, device, and tag, and confirm which protocols and communication links are in play, because on a brownfield operation the reality often differs from the documentation. Only once you understand the true scope - how many sites and tags, which protocols, and where the unknowns concentrate - can you make sound decisions about phasing, parallel running, and rollback. Skimping on this step is the most common cause of migrations running over.
Most fleet migrations are phased, moving sites in logical batches so that early batches prove the pattern and any problem stays contained to a small part of the operation. Teams often begin with a low-consequence pilot site to shake out the process and runbook before the rest of the fleet follows. Migrating everything at once concentrates all the risk in a single window and is usually reserved for small, self-contained facilities.
A migration runbook is a step-by-step script for migrating each site or batch that specifies exactly what to do, in what order, who does it, how to verify each step succeeded, and what to do if it fails. It is precise enough to execute a cutover under pressure without improvising, and it is refined after the pilot and each phase so it keeps improving as the fleet moves across. The runbook turns the migration plan into an actionable procedure.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.