SCADA Migration Guide:
Replace Legacy SCADA
Without Disrupting Operations
Legacy SCADA systems built on aging Windows servers with no mobile access, no cloud connectivity, and limited or expired vendor support are a liability for industrial operations. The question for most operators is not whether to migrate - it is how to replace a system that runs 24/7 without creating a dangerous gap in monitoring and alarm coverage during the transition. This guide walks through every step of a SCADA migration, from auditing your existing system to decommissioning the old platform, with realistic timelines and cost figures for both traditional and cloud-native replacement approaches.
Why Operators Migrate From Legacy SCADA
Legacy SCADA systems are not replaced because operators want to - they are replaced because the cost and risk of keeping them running eventually exceeds the cost and risk of replacement. The inflection point arrives differently for each operation, but the drivers are consistent across industries.
End-of-Life Hardware and Software
Most legacy SCADA deployments run on Windows Server versions that Microsoft stopped patching years ago - Windows Server 2008, 2012, or in some cases Windows XP systems that have run without rebooting for a decade. When the operating system is end-of-life, every unpatched vulnerability becomes a permanent exposure. The SCADA software itself may be equally outdated: older versions of on-premise SCADA or HMI software that the vendor no longer supports with bug fixes or security patches. Running an end-of-life SCADA platform is not a theoretical risk - it is the documented entry point for the ransomware attacks on industrial control systems that CISA publishes incident advisories about every quarter.
No Vendor Support
When a SCADA vendor discontinues a product line, the support contracts eventually expire and the expertise walks out the door. Operators find themselves with a system no one can fix, running on hardware no one manufactures, with documentation that predates current network architecture. A hard drive failure or a corrupted historian database becomes an emergency that requires locating archived installation media from a decade ago and hoping the product key still works.
High Maintenance Costs
Legacy SCADA maintenance is expensive in ways that are invisible until you add them up: annual server hardware maintenance contracts, extended support agreements for end-of-life software, on-call integrator fees for emergency troubleshooting, and the internal IT labor to keep aging infrastructure patched and backed up. A realistic annual cost for maintaining a 5–10 site legacy SCADA installation - including server hardware, software licenses, IT labor, and integrator retainers - is $30,000–$80,000 per year for a mid-size oil and gas operation. That cost does not include the opportunity cost of IT staff time spent on a dead-end platform instead of higher-value work. A SCADA-as-a-service subscription replaces those line items - server maintenance, extended support, integrator retainers - with a single flat fee.
No Mobile Access, No Remote Visibility
Legacy SCADA was built for fixed workstations in a control room. The operator sits at a dedicated PC with a proprietary client installed, on a specific network segment, with a specific screen resolution configured for the HMI layout. Field operators on a mobile device, managers checking production from the airport, or on-call engineers receiving an alarm notification and needing to see live data have no path into the system without a VPN, a terminal server, or a dedicated laptop with the thick client installed. That architecture is not a minor inconvenience - it is an operational constraint that delays response to abnormal events and forces unnecessary site visits.
Cybersecurity Vulnerabilities
Legacy SCADA systems were designed before industrial cybersecurity was a serious concern. They often lack encryption for data in transit, use default or shared passwords, have no multi-factor authentication, and communicate over protocols with no authentication layer - Modbus TCP being the most common example. Connecting a legacy SCADA system to a corporate network or the internet - even through a firewall - creates exposure that the platform was never designed to defend against. See cloud SCADA vs on-premise SCADA for a detailed security architecture comparison.
Signs Your SCADA System Needs Replacing
- Hardware older than 10 years - server components approaching mean-time-to-failure with no upgrade path
- Can't connect to mobile devices - no web client, no mobile app, no browser-based access
- No remote access without VPN or thick client - access requires specific hardware or complex network configuration
- Vendor stopped supporting the software version - no security patches, no bug fixes, no phone support
- Spare parts unavailable or on allocation - replacement cards, servers, or I/O modules discontinued
- The only person who knows the system is retiring - institutional knowledge concentrated in one person with no succession plan
- Historian data regularly corrupted or lost - database instability causing gaps in production records
- Alarms regularly missed - no SMS notification, alarm routing relies on someone being at the workstation
- System downtime every few months - reboots required to clear memory leaks or recover from software hangs
SCADA Migration Options
Full Replacement
A complete replacement retires the legacy system entirely and deploys a new SCADA platform from scratch. All tags are reconfigured, all HMI screens are rebuilt, and the historian database starts fresh on the new platform. For traditional on-premise replacements, this is a major project - 6–18 months of engineering, installation, and commissioning. For cloud SCADA platforms like Merobix, full replacement can be accomplished in 1–4 weeks because there is no server infrastructure to deploy and HMI configuration is done through a browser-based interface rather than proprietary engineering workstations.
Hybrid Approach
A hybrid migration runs the new SCADA platform in parallel with the legacy system for a defined period. Both systems receive live data from the field simultaneously, allowing operators to validate accuracy before committing to the new platform. This approach is particularly valuable when the legacy system has complex alarm logic or production calculations that need to be verified against the new implementation. The parallel run period is typically 2–4 weeks for straightforward monitoring applications and 4–8 weeks for more complex control and reporting implementations.
Phased Migration
A phased migration migrates one site or one process unit at a time, leaving the remaining sites on the legacy system until each successive phase is complete. This approach minimizes risk at any single point in the migration and allows the operations team to build confidence with the new platform on a lower-priority site before migrating the most critical assets. The tradeoff is that the phased approach extends the total migration timeline and requires maintaining both systems in parallel - including their respective support infrastructure - until all phases are complete.
Which Approach Is Right?
For most oil and gas operators migrating from legacy SCADA to Merobix, the hybrid approach with a 2–4 week parallel run is the right choice. It delivers the fastest path to full cutover while providing a validation safety net. Full replacement without a parallel run is appropriate when the legacy system is already unreliable (frequent downtime, corrupted historian) and the risk of parallel operation outweighs the validation benefit. Phased migration makes sense for large multi-site operations with significant operational differences between sites.
Step-by-Step SCADA Migration Process
- Audit the existing system - Document all data points currently monitored: tag names, engineering units, scan rates, alarm setpoints, and the PLC/RTU communication configuration at each site. This audit becomes the specification for the new system configuration.
- Document all tags and calculation points - Identify derived calculations (totalized flow, runtime accumulators, efficiency metrics) that are computed in the SCADA layer rather than in the PLC. These require special attention during migration to ensure the calculation logic is correctly replicated in the new platform.
- Choose the new platform - Evaluate platforms against your specific requirements: number of sites, protocol support, mobile access, alarm management, historian retention, reporting needs, and budget. For Merobix, the platform feature overview summarizes what is included across cloud and on-premise deployment options. See the Merobix complete solution overview for a full platform description, or the cloud vs on-premise SCADA comparison for a detailed look at the two most common choices.
- Plan the phased cutover - Define which sites migrate first, what the parallel run period duration is, and what criteria must be met before each site transitions from legacy to new. Involve operations supervisors in this planning - they own the go/no-go decision for cutover.
- Configure the new platform - Set up communication drivers to existing PLCs, configure all tags and alarm setpoints, build dashboards, and set up notification routing. For Merobix, this configuration is completed by the Merobix engineering team as part of the engagement - operators are not expected to self-configure the platform.
- Test in parallel - Run both systems simultaneously and compare data for accuracy. Verify that alarms trigger correctly in the new system. Confirm that historian data is recording without gaps. Validate that mobile access and notification delivery work as expected.
- Go live - After the parallel validation period, cut over to the new platform as the primary monitoring system. Communications shift to the new system, legacy alarm notifications are disabled, and operators begin using the new dashboards exclusively.
- Decommission the old system - Once the new system is confirmed stable (typically 2–4 weeks post-cutover), shut down the legacy SCADA server. Archive historian data from the legacy system to a cold storage format before decommissioning. Return or dispose of hardware appropriately.
How Long SCADA Migration Takes
| Migration Type | Timeline | Primary Driver of Duration |
|---|---|---|
| Traditional on-premise replacement | 6–18 months | Server procurement, software licensing, integrator scheduling, on-site engineering |
| Cloud SCADA (Merobix) | 1–4 weeks | Gateway installation at each site, cloud configuration, parallel validation |
| Phased multi-site (traditional) | 12–36 months | Sequential site-by-site deployment, extended dual-system operation |
| Phased multi-site (cloud) | 4–12 weeks | Site-by-site gateway deployment with cloud platform already configured |
Cloud SCADA migration is typically faster than traditional replacement for one structural reason: there is no server to procure, rack, configure, and integrate. The cloud platform already exists and is already running. Adding a new site requires installing a cellular gateway, connecting it to the existing PLC communication port, and mapping the data points in the cloud dashboard - work that typically takes one to two days per site for a Merobix deployment. Traditional SCADA replacement requires procuring hardware, shipping it to site, installing and cabling a server, installing the SCADA software, configuring communication drivers, building HMI screens, and commissioning the historian - work that takes weeks per site and requires on-site engineering presence throughout.
SCADA Migration Costs
| Cost Category | Traditional Replacement | Merobix Cloud Migration |
|---|---|---|
| Server hardware | $10,000–$40,000 | None |
| Software licenses | $15,000–$80,000 | None (included in subscription) |
| Field gateways | $2,000–$5,000/site | $300–$600/site |
| Engineering / integration | $30,000–$150,000 | Included in Merobix engagement |
| Ongoing subscription | $20,000–$50,000/yr (maintenance) | Custom quote - flat, all-inclusive |
| Total Year 1 (5-site operation) | $100,000–$300,000 | Custom quote - scope-based, all-inclusive |
How Merobix Handles SCADA Migration
Merobix is designed to connect to existing field devices - not to replace them. The migration process starts with a discovery call to document your existing PLC models, communication protocols, and site connectivity. The Merobix engineering team then configures the cloud platform with your tag structure, alarm setpoints, and dashboard layout before any field work begins.
Field installation involves mounting a cellular gateway (Teltonika RUT956 for most sites) at each location, connecting it to the existing PLC's communication port, and verifying that data is flowing correctly in the cloud dashboard. For Allen-Bradley ControlLogix and CompactLogix, the connection is EtherNet/IP. For legacy Modbus devices, the connection is Modbus TCP or RTU. For existing RTUs communicating via DNP3 or OPC-UA, Merobix supports those protocols natively.
A parallel run period of two to four weeks follows, during which both the legacy system and Merobix are receiving live data. Operations teams verify data accuracy, alarm triggering, and notification delivery against the legacy system. When the parallel validation is complete, the full cutover takes minutes - switch primary alarm monitoring to Merobix, disable legacy system notifications, and the migration is complete. Visit Merobix services for information on field installation, PLC programming, and panel work available alongside the SCADA migration engagement.
Key principle: A SCADA migration does not require replacing your PLCs. Your existing Allen-Bradley, Siemens, or Modbus-compatible field devices stay in place. Only the supervisory layer changes - and that change can happen in days, not months. See request a demo to see how Merobix connects to your existing infrastructure.
Frequently Asked Questions
How long does SCADA migration take?
SCADA migration timelines vary significantly by approach. Traditional on-premise SCADA replacement projects typically take 6–18 months from project kick-off to full commissioning. Cloud SCADA migration with Merobix takes 1–4 weeks, because no new server infrastructure is required and the cloud platform connects directly to existing PLCs and RTUs already in the field. The primary factor that compresses the cloud timeline is that configuration happens in the cloud dashboard rather than on-site, and field work is limited to installing a cellular gateway at each site rather than deploying a full SCADA server.
Do I need to replace my PLCs to migrate SCADA?
No. In the large majority of SCADA migrations, the PLCs and RTUs remain in place. The SCADA platform connects to the existing field devices via their communication interfaces - Modbus TCP/RTU, EtherNet/IP, DNP3, or OPC-UA. The PLCs continue to execute their control logic; only the supervisory layer changes. Merobix connects a cellular gateway to the existing PLC communications port - the migration completes without touching field wiring or replacing any control hardware.
How much does SCADA migration cost?
Traditional on-premise SCADA migration costs $50,000–$300,000+ depending on the number of sites, complexity of the system, and the integrator engaged. This includes new server hardware, software licenses, engineering, and installation labor. Cloud SCADA migration with Merobix has a different cost structure: a cellular gateway per site ($300–$600 hardware), plus a custom-quoted monthly subscription; your quote lists the full fee schedule, and Merobix does not charge per-tag or per-user fees on current plans. There is no server, no software license, and no months-long integration project.
Can Merobix replace my existing SCADA system?
Yes. Merobix is designed to replace legacy on-premise SCADA for oil and gas operators, water utilities, and industrial facilities. The migration connects Merobix directly to your existing PLCs and RTUs - Allen-Bradley, Siemens, or any Modbus-compatible device - without replacing field hardware. A parallel run period allows operators to verify data accuracy against the legacy system before full cutover, which typically completes within 1–4 weeks of project start.
More in the Merobix Automation Fundamentals.
Sources and verification
This page references the vendor products and their official documentation published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Industrial Control Systems - U.S. Cybersecurity and Infrastructure Security Agency (CISA)
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.