SCADA Migration

SCADA Migration and Modernisation Without Losing Control

Replacing or upgrading a SCADA system is one of the riskiest projects an operator runs: thousands of points, years of undocumented logic, and an operations team that can't stop. I help plan and deliver migrations that keep monitoring and control running throughout.

Why Now

Common Reasons to Modernise

  • Operating systems out of support: Windows 10 reached end of support in October 2025, and extended support for Windows Server 2016 ends in January 2027
  • SCADA software, servers or RTUs no longer supported by the vendor
  • Telemetry stranded or at risk after Australia's 3G networks closed in 2023–24
  • Security requirements from the SOCI Act, IEC 62443 or customer contracts that the current design can't meet
  • The people who built and understood the system retiring or moving on
  • New needs the old system can't serve: cloud reporting, analytics, IIoT sensors, mobile access
Options

Upgrade, Re-platform or Rebuild?

There is no single right answer, and staying on your current platform is sometimes the best one.

Upgrade in place

Move to a current version of the same platform. Lowest risk and cost when the platform still fits; the work is in testing drivers, custom code and integrations.

Re-platform

Move to a different SCADA product. Justified when the current platform has no future or can't meet requirements; most of the effort goes into converting the database, displays and logic, and into retraining people.

Rebuild and rationalise

Use the migration to fix accumulated problems: standard templates and naming, alarm rationalisation (ISA-18.2 / IEC 62682), high-performance displays (ISA-101), and a network designed to IEC 62443.

Staged and hybrid

Run old and new systems side by side and move sites across in planned groups, so every step can be reversed.

Method

How a Migration Runs

  1. Discovery and inventory

    Points, templates, logic, displays, alarms, historic data, reports, integrations and communications paths: what exists, what is used, and what can go.

  2. Requirements and platform decision

    Functional and security requirements agreed with operations, then an options assessment against them.

  3. Design

    Architecture, redundancy, security zones, data model and naming standards, and the cutover strategy.

  4. Conversion tooling

    Scripted conversion and database generation wherever possible, so thousands of points are built consistently and can be rebuilt on demand.

  5. Testing

    Factory acceptance testing against simulated or replayed field data, then site acceptance testing with operations.

  6. Cutover

    Parallel running, site-by-site transfer of RTUs and telemetry, and a tested rollback plan for every step.

  7. Historic data

    Migrated, archived, or kept accessible read-only, depending on regulatory and operational need.

  8. Training, handover and decommissioning

    Operators and engineers trained before the new system is theirs, documentation handed over, and the old system retired cleanly.

Field Devices

Telemetry and RTU Renewal

The master station is often the smaller part of a modernisation. RTUs, radios, cellular modems and the protocols between them are usually the larger cost and the bigger operational risk, as Australia's 3G closures showed. Renewal is a chance to move to supported 4G, LTE-M or licensed radio links, to adopt secure protocol options such as DNP3 Secure Authentication, and to add low-cost IIoT sensors where a full RTU was never justified.

Security

Build Security In, Don't Copy Problems Across

A like-for-like migration faithfully reproduces flat networks, shared accounts and always-on vendor access. Setting security requirements at the start, through an OT risk assessment and IEC 62443 design requirements, costs far less than retrofitting them after commissioning.

FAQ

Frequently Asked Questions

How long does a SCADA migration take?

It depends on scale. Upgrading a single system on the same platform can take weeks to a few months; re-platforming a utility with hundreds of sites is usually a multi-year program delivered in stages. Discovery and a realistic cutover plan come first, because they determine everything else.

Can we keep operating during a SCADA migration?

Yes; that is the purpose of the cutover strategy. Old and new systems run in parallel, sites move across in planned groups, and every step has a tested rollback.

What happens to our historic data?

It can be migrated into the new system, exported to a data platform or archive, or left in the old historian kept available read-only. The right choice depends on regulatory retention requirements and how often the data is used.

Should we move SCADA to the cloud at the same time?

Possibly, but treat it as a separate decision with its own risk assessment. A common pattern is to migrate the control system on premises and send data to the cloud for reporting and analytics; see SCADA cloud integration.

Which SCADA platform should we choose?

The one that best fits your requirements, skills and support arrangements, which is why requirements come before the platform decision. I'm independent, and staying on your current platform is a legitimate outcome of an options assessment.

Related

Related Services