SCADA systems have been the backbone of industrial operations for decades. They've controlled power grids, water treatment plants, manufacturing lines and building automation systems reliably, often for 20 or 30 years. But the world SCADA was designed for is not the world industrial operators work in today. Cloud connectivity, AI-driven analytics, modern APIs and distributed workforces demand capabilities that most legacy SCADA architectures cannot provide. Here's a practical guide to migrating without putting your operations at risk.
What SCADA Is and What It Isn't
SCADA (Supervisory Control and Data Acquisition) is a control system architecture that combines PLCs or RTUs at the field level with a supervisory layer that monitors, logs and presents operational data. SCADA systems were engineered for reliability and determinism in air-gapped, proprietary environments. They're very good at what they were designed to do.
The limitations of traditional SCADA become apparent when organisations need to:
- Connect to the cloud: Most SCADA systems were designed for air-gapped networks. Adding cloud connectivity is often a complex, security-fraught retrofit.
- Integrate with modern systems: SCADA platforms use proprietary data models and APIs. Connecting to ERP, CMMS, BI tools or AI pipelines requires custom development.
- Scale across sites: Multi-site SCADA deployments typically require separate instances per site with no unified view.
- Support remote access: Secure remote access to SCADA was an afterthought in most architectures.
- Enable analytics and AI: SCADA historians store data, but extracting it for modern ML pipelines is painful without middleware.
Why Companies Are Migrating Now
Several converging pressures are accelerating SCADA modernisation:
- Vendor end-of-life announcements on legacy SCADA software versions are forcing hardware and software refreshes anyway, so migration becomes the logical choice over like-for-like replacement
- Cybersecurity rules and guidance (NIS2 in the EU; in the UK, the NIS Regulations 2018 and the NCSC's CAF framework, which is guidance rather than law) are driving security upgrades that air-gapped SCADA architectures struggle to satisfy
- The business case for predictive maintenance, energy optimisation and AI-driven operations requires cloud-accessible, analytics-ready data infrastructure
- Engineering talent increasingly expects modern tooling, and legacy SCADA expertise is harder and more expensive to hire
The 4-Phase Migration Approach
Phase 1: Audit and Baseline
Before touching anything, document the existing estate thoroughly. This means:
- Cataloguing every PLC, RTU, sensor and communication path
- Documenting all SCADA screens, alarm configurations and historian tags
- Mapping data flows: what data goes where, at what frequency, and who uses it
- Identifying critical control loops that require zero interruption during migration
- Establishing baseline uptime and data quality metrics to validate against post-migration
This audit typically takes two to six weeks depending on site complexity. Skipping it is the most common and most costly mistake in SCADA modernisation projects.
Phase 2: Parallel Running
Rather than a hard cutover, mature migration projects run the IIoT platform in parallel with the existing SCADA system for a defined period, typically four to twelve weeks. During this phase:
- The IIoT platform receives the same data feeds as SCADA (often via a gateway pulling from the SCADA historian or directly from field devices)
- Teams validate data quality, latency and completeness against the SCADA baseline
- New dashboards, alerts and integrations are built and tested by operations staff in a live-but-non-critical context
- Differences between SCADA readings and IIoT platform readings are investigated and resolved
Parallel running de-risks the migration significantly. It also gives operations teams time to build familiarity and confidence with the new platform before they depend on it.
Phase 3: Cutover
Cutover should be planned down to the minute. A well-executed cutover includes:
- A defined cutover window during planned maintenance or low-activity periods
- A tested rollback plan with clear triggers: if specific conditions occur, SCADA remains primary
- All critical staff on-site or on-call during the cutover window
- A freeze on configuration changes to both systems in the 48 hours preceding cutover
- Post-cutover monitoring for a defined stabilisation period before declaring success
Phase 4: Optimise
Migration is the starting point. Once the IIoT platform is the system of record for operational data, the real value creation begins:
- Building predictive maintenance models using historical data now accessible in the cloud
- Integrating with ERP and CMMS for closed-loop work order management
- Enabling multi-site unified views that SCADA could never provide
- Rolling out advanced analytics and AI-driven anomaly detection
Common Migration Pitfalls
- Underestimating the audit phase: Teams that rush the baseline documentation spend months chasing data quality issues post-migration.
- Cutting over critical control systems first: Start with monitoring-only feeds. Never begin migration on systems involved in process control.
- Neglecting change management: Operations staff who weren't consulted on the platform selection often resist adoption. Involve them early.
- Assuming SCADA tags map cleanly to IIoT data models: Tag naming conventions, engineering units and calibration offsets frequently differ. Data normalisation takes time.
- Picking a platform without SCADA integration experience: Your IIoT platform vendor should have documented experience with SCADA historian connectivity and OPC-UA/Modbus bridge scenarios.
What to Look for in a Replacement Platform
Not all IIoT platforms are equal for SCADA migration scenarios. Prioritise platforms that offer:
- Support for the industrial protocols your estate uses (for example OPC UA, Modbus, BACnet or DNP3), either natively or through a gateway, without custom middleware
- Gateway software that can connect to existing SCADA historians during parallel running
- Data normalisation tooling that handles engineering unit conversion and tag remapping
- Multi-site architecture that can consolidate your entire estate under one management interface
- A migration support programme that includes expertise in industrial transition projects as well as software
Conclusion
Migrating from SCADA to IIoT is a significant undertaking, but it's one that industrial organisations across every sector are completing successfully. The organisations that do it well share a common approach: thorough audit, extended parallel running, disciplined cutover, and a clear plan for the optimisation phase that follows.
SIMBIOSYS has been designed with SCADA migration scenarios in mind: Modbus, MQTT, HTTP and WebSocket ingestion, flexible gateway connectivity, multi-site architecture and data normalisation capabilities are core to the platform.