SCADA Migration: A Plant Manager's Guide to Upgrading Without Stopping Production

The SCADA system that's been running your plant for the last 15 years is showing its age. The server it runs on is no longer supported. The vendor discontinued the software version you're on. Finding engineers who know the platform is getting harder every year. And the data visibility your management team is asking for — OEE dashboards, production reports, remote access — is something the current system simply can't deliver.

You know a migration is coming. The question is how to do it without disrupting the production that everyone depends on.

This guide walks through what a SCADA migration actually involves, how to evaluate your options, and how to plan a cutover that keeps your plant running throughout the process.

Why SCADA Migrations Get Delayed — and Why That's Risky

The most common reason manufacturers delay SCADA migrations is risk aversion — and it's understandable. A SCADA system is deeply integrated into your operation. It's connected to PLCs, historian databases, HMI panels, and sometimes ERP systems. Any migration touches all of those connections.

But delay has its own risks:

• Vendor end-of-life means no security patches, leaving your OT network increasingly vulnerable
• Software bugs and compatibility issues with modern operating systems become harder to resolve
• Engineer availability for legacy platforms continues to shrink as specialists retire or move to modern toolsets
• The longer you wait, the larger the gap between your current system and modern capabilities — and the more complex the migration becomes

Choosing the Right Platform

Platform selection is the most consequential decision in a SCADA migration. The wrong choice means another migration in ten years — or sooner. The right choice gives you a platform that grows with your operation.

Key evaluation criteria:

Vendor longevity and ecosystem health

Choose platforms with strong vendor backing, active development roadmaps, and large user communities. Ignition by Inductive Automation has become the dominant platform for new SCADA implementations due to its licensing model (unlimited tags and clients), active development, and strong integrator ecosystem. FactoryTalk View SE remains widely deployed in Allen-Bradley-centric environments. Evaluate the platform's trajectory, not just its current capabilities.

Connectivity and integration capabilities

Modern SCADA platforms should connect natively to your PLCs via EtherNet/IP, Modbus TCP, OPC-UA, and other industrial protocols. They should also provide pathways to enterprise systems — databases, ERP platforms, and cloud data pipelines — without requiring extensive custom development.

Historian and reporting capabilities

If your current system has a historian (and if it doesn't, it should), understand how historical data will migrate. Losing years of production data in a migration is a real risk that needs to be planned for explicitly. Evaluate the new platform's historian capabilities — tag capacity, compression algorithms, query performance, and reporting tools.

Licensing model

SCADA licensing has historically been complex and expensive — per-tag, per-client, per-server licenses that constrain how you deploy and scale the system. Ignition's unlimited-tag, unlimited-client licensing model has disrupted this space significantly. Understand exactly what you're buying and what growth will cost.

The Migration Process: Phase by Phase

Phase 1: Discovery and documentation

Before designing the new system, fully document the existing one. This means:

• Complete tag database export — every tag, its source, its data type, and its use in the system
• Screen inventory — every operator display, its function, and the tags it references
• Alarm inventory — every configured alarm, its setpoints, and its priority
• Report inventory — every report, its schedule, and the data it draws from the historian
• Interface documentation — every external system connected to the SCADA (PLCs, databases, ERP, etc.)

This documentation phase is often underestimated. Legacy SCADA systems frequently have undocumented tags, screens that no one uses, and alarms that fire constantly and are universally ignored. The migration is an opportunity to clean all of that up — but only if you know what you're starting with.

Phase 2: Architecture design

With the existing system documented, design the new architecture:

• Server topology: single server, redundant servers, or distributed architecture
• Client access: fixed HMI panels, thin clients, web-based access, mobile access
• Historian strategy: on-premises, cloud, or hybrid
• Security architecture: how the SCADA server connects to PLCs, to historians, and to the enterprise network
• Tag naming convention: this is the time to establish a clean, consistent naming standard

Get the architecture approved by all stakeholders — IT, OT, operations, and management — before development begins. Changes to architecture during development are expensive.

Phase 3: Parallel development

The new SCADA system is built in parallel with the existing system continuing to operate. Development includes:

• Tag database creation in the new platform
• Operator screen development — rebuilt for the new platform, improved for usability
• Alarm configuration — rationalized and prioritized, not just copied
• Historian configuration — tag logging, compression settings, retention policies
• Report development — existing reports rebuilt, plus new reports the business has been asking for

This phase also includes developing and testing all PLC communications — confirming that the new SCADA reads and writes correctly to every connected PLC before the cutover.

Parallel development is also where an experienced integration partner earns their keep — building and testing tag structures, redesigned screens, and PLC communications while the legacy system keeps running production. This is the core of what our SCADA & HMI development engagements focus on.

Phase 4: Staging and acceptance testing

Before going live, the new system is tested thoroughly in a staging environment — ideally connected to the actual PLCs or to a simulation of them. Key tests include:

• All tags reading correctly from all PLCs
• All alarms firing at correct setpoints and reaching correct destinations
• All operator displays functioning correctly under simulated process conditions
• Historian logging and data retrieval
• Failover and redundancy (if applicable)
• Remote access and security controls

Acceptance testing should be conducted with operations staff — the people who will actually use the system — not just engineers. Issues found in staging are far cheaper to fix than issues found at 2am after cutover.

Phase 5: Cutover

The cutover is the transition from the old system to the new one. There are two basic approaches:

Hard cutover: The old system is shut down and the new system goes live at a defined point in time. Simpler to manage but higher risk — if something goes wrong, production may be impacted while issues are resolved.

Parallel operation: Both systems run simultaneously for a defined period, with operators gradually transitioning to the new system. Higher complexity but lower risk — if the new system has issues, the old one is still available as a fallback.

For most SCADA migrations, a parallel operation period of one to four weeks is recommended, followed by a planned decommission of the old system once the new one is confirmed stable.

What a Successful Migration Looks Like

The best SCADA migrations are the ones no one notices — operations continue, the new system goes live, and the improvements (better visibility, faster reporting, cleaner alarm management) become apparent gradually.

Success requires:

• Thorough documentation of the existing system before any work begins
• Architecture decisions made and locked before development starts
• Adequate time for parallel development and testing — migrations that are rushed into cutover are the ones that go badly
• Operator involvement in screen design and acceptance testing
• A clear cutover plan with a defined rollback procedure if something goes wrong
• Post-cutover support from the integration team for at least two to four weeks

Common Mistakes to Avoid

• Copying the old system exactly: Migrations are an opportunity to improve. An exact copy of a poorly organized, alarm-flooded, hard-to-use system is a missed opportunity.
• Underestimating the tag documentation effort: “We’ll figure out the tags as we go” is how migrations run months over schedule.
• Skipping operator training: A technically perfect system that operators don’t trust or know how to use isn’t a success.
• No rollback plan: Know exactly what you’ll do if the cutover goes badly. Have the old system ready to restart for at least the first two weeks after cutover.

The Bottom Line

A SCADA migration is a significant project — but it's a manageable one when it's planned properly. The manufacturers who struggle with migrations are the ones who underestimate the documentation phase, rush the testing, or try to do the cutover without a rollback plan.

The ones who do it well treat the migration as an engineering project with clear phases, defined deliverables, and stakeholder alignment at every step. The result is a system that's more capable, more reliable, and more secure than the one it replaced — and a cutover that the plant floor barely noticed.