Water utility SCADA migration: legacy to modern IoT paths

It also expands the attack surface, adds latency dependencies, and raises the error rate when the underlying asset model is incomplete.

The migration path is therefore not “legacy PLC out, cloud SCADA in.” It is a sequence of engineering controls: establish what exists, isolate what must remain deterministic, introduce controlled telemetry, then prove that the utility can operate when the digital layer is unavailable.

A station with a reliable local PLC, a poorly documented panel, and intermittent cellular telemetry does not need a dramatic replacement program. It needs an accurate baseline and a constrained modernization boundary.

Start with the operational inventory, not the replacement list

“Legacy” is not a technical classification. A 15-year-old PLC with stable logic, local HMI access, documented I/O, and recoverable backups may be a lower migration risk than a newer controller exposed through an unmanaged cellular router.

The initial inventory must capture the control system as an operating system, not as a procurement register. Listing PLC model numbers is insufficient. The migration team needs to know how commands, measurements, alarms, and operator decisions move through the station.

At minimum, document:

• PLCs, remote I/O racks, local HMIs, managed switches, radio equipment, cellular modems, VPN appliances, and engineering workstations.
• Controller firmware, communication drivers, network addresses, serial links, switch configurations, and any active remote-support paths.
• PLC logic files, HMI graphics, alarm databases, historical trends, and engineering drawings.
• Instrument dependencies: pressure transmitters, level sensors, flowmeters, valve-position feedback, motor protection relays, and VFD status points.
• Every manual fallback procedure. This includes local pump start/stop, valve isolation, chemical feed control, tank-level monitoring, and alarm escalation.
• The owner of each asset and the source of configuration truth. If the only copy of a PLC program sits on a former integrator’s laptop, the asset is not managed.

The most useful output is not a spreadsheet with 400 rows. It is a station-level dependency map. It should identify which functions are safety-critical, which are process-critical, and which are only useful for reporting.

A lift station can often tolerate delayed trend data. It cannot tolerate a remote command path that creates an unintended pump start. A treatment process may tolerate the loss of a dashboard. It may not tolerate loss of chemical dosing control or high-high level alarming.

A migration boundary is credible only when the utility can state which functions must remain local, deterministic, and operable without SCADA.

This distinction reduces scope noise. It also prevents a common design error: routing all station functions through the same gateway because the architecture diagram looks simpler.

Classify the existing control layers

The following model is practical for pump stations, reservoirs, wells, and treatment sites.

This is where legacy PLC replacement steps should become conditional rather than automatic. Replace a controller when there is no supportable programming environment, no recoverable logic, no secure integration path, insufficient capacity, unacceptable hardware failure risk, or a process change that the existing platform cannot execute safely.

Do not replace a controller merely because it is old. Replacement changes logic, wiring assumptions, commissioning load, operator habits, and maintenance inventory. It can reduce risk. It can also create it.

Segment the network before extending remote access

Most water network automation projects begin with a remote-access request: operators need alarms on callout devices, engineers need remote diagnostics, or a contractor needs a path to support a station after hours.

That requirement is valid. Direct Internet exposure is not the appropriate response.

EPA guidance is explicit on the core principle: eliminate direct public-Internet connections to OT assets unless they are operationally necessary. If an Internet connection is necessary, it requires compensating controls including multifactor authentication, firewalls, and centralized logging. Cellular modems at remote wells, tanks, and lift stations require the same scrutiny. They are frequently treated as transport equipment. In practice, they are Internet paths into OT.

The architecture should separate operational zones and define the conduits between them. This is consistent with the ISA/IEC 62443-3-2 approach: define the system under consideration, partition it into zones and conduits, assess risk for each, establish target security levels, and document the resulting requirements.

For a distributed utility, the basic zones often include:

1. Field and local-control zone. PLCs, VFDs, remote I/O, instrumentation, and local HMIs. This zone should continue essential process control without an upstream connection.

2. Site operations zone. Managed switching, protocol gateways, station data concentrators, and approved local engineering access.

3. SCADA supervisory zone. Central SCADA servers, historians, alarm services, and operator workstations.

4. Industrial DMZ or controlled access zone. Remote access brokers, jump hosts, log collection, patch transfer services, and carefully defined integration services.

5. Enterprise and external zone. Corporate IT, reporting users, cloud systems, vendors, and remote personnel.

The point is not to produce a five-box drawing. The point is to reduce unrestricted traversal. A pump station telemetry upgrade should allow the necessary data path and reject everything else.

A field PLC should not accept engineering traffic from a general corporate subnet. A vendor should not receive a flat VPN route into every station. A remote operator should not need direct controller access to acknowledge a high-level alarm.

NIST’s final SP 1800-45, published June 24, 2026, provides three representative secure remote-access architectures for water and wastewater OT. The useful implication is not that one reference design fits every utility. It is that remote access can be implemented in patterns proportionate to utility capacity and resources, while retaining core controls around identity, segmentation, and monitoring.

Remote access is a workflow, not a tunnel

A VPN is a transport mechanism. It is not an OT security architecture.

The remote workflow should answer specific operational questions:

• Which role can initiate the session?
• Which systems can that role reach?
• Is multifactor authentication required?
• Is the session logged?
• Can access be approved for a defined maintenance window?
• Is the vendor limited to one station, one application, or one support function?
• Can the utility disable the path without affecting local control?
• Is there a record of configuration changes made during the session?

A low-cognitive-load design gives each user only the controls required for the task. Operators see SCADA functions. Control engineers use controlled engineering paths. Vendors receive time-limited access to named systems. Nobody receives an unbounded route to “the OT network.”

The distinction matters because Internet-connected legacy devices remain a demonstrated operational risk. In a campaign between November 2023 and January 2024, IRGC-affiliated actors compromised at least 75 Unitronics devices, including at least 34 in the US water and wastewater sector. The exposed devices used default or absent passwords. The failure was not caused by PLC age alone. It was caused by reachable control assets with weak identity controls.

Add interoperability at the edge, not complexity in the controller

The technical objective of remote I/O module integration is usually straightforward: collect pump status, motor run feedback, level, pressure, flow, valve position, power quality, and alarm state from distributed sites. The design becomes unstable when every data consumer is allowed to interrogate the PLC independently.

A legacy station should have a controlled data boundary. That boundary may be a modern SCADA driver, a protocol gateway, an edge device, or a purpose-built telemetry concentrator. The exact product choice depends on the installed controller family, site communications, required update interval, engineering support capability, and cybersecurity model.

The boundary should normalize access without taking over essential local control.

OPC UA is suited to interoperability where structured industrial data must move between sensors, controllers, supervisory systems, enterprise applications, or cloud-facing services. It is platform-independent and includes information, message, communication, and conformance models. Its security model addresses client/server and user authentication, confidentiality, and integrity.

MQTT serves a different function. It is a lightweight publish/subscribe transport protocol designed for constrained machine-to-machine and IoT contexts. It can be useful where many remote stations publish telemetry into a brokered architecture. It is not a substitute for control engineering, segmentation, authentication, or authorization design.

The protocol decision should follow the operational data path.

For example, a remote booster station may retain local PLC control of pump alternation, minimum runtime, suction pressure permissives, VFD fault handling, and emergency stop behavior. The edge layer publishes selected state: lead pump, run command, actual speed, discharge pressure, wet well level, communication status, and alarm priority. The SCADA system supervises. It does not become a mandatory loop in the pump sequence.

That separation protects throughput. It also limits the consequences of WAN latency, broker failure, certificate problems, or historian outages.

Telemetry may be centralized. Process authority should remain as close to the physical process as the operating model requires.

Design tags around decisions, not around available registers

A pump station telemetry upgrade often creates thousands of tags because the controller exposes thousands of registers. This is data accumulation, not observability.

Each tag should support one of four functions:

• A control decision.
• An alarm decision.
• A maintenance decision.
• A performance calculation with a named owner.

If a point supports none of these, it may still be useful during commissioning. It should not automatically enter the permanent SCADA namespace.

Tag design must also specify quality state, timestamp source, scaling, engineering units, stale-data behavior, and alarm treatment during communication loss. A pressure value without a quality indicator has a misleadingly low apparent error rate. The screen may show “42 psi” while the actual instrument path has been dead for 20 minutes.

The same applies to command feedback. A remote start command is not a successful pump start. The interface should distinguish:

• Command requested.
• Command accepted by the controller.
• Output energized.
• Motor running feedback received.
• Flow or pressure response observed.
• Command blocked by a permissive, interlock, or fault.

Compressing these states into a single green icon reduces screen space. It increases diagnostic latency.

Treat alarm migration as an operator-interface redesign

A modern SCADA platform can ingest more data than a legacy system. That does not mean the operator can process more alarms.

Alarm volume is an interface throughput problem. When every analog deviation, intermittent communication event, and VFD status bit becomes a visible alarm, the operator loses the signal hierarchy. Response latency rises. The high-priority event arrives inside a stream of low-value notifications.

Migration teams should review every existing alarm against the action it requires. A useful alarm has a defined response, consequence, priority, and owner. A trend deviation without a required action is usually a display condition, a maintenance indicator, or a report input. It is not necessarily an alarm.

For water operations, separate at least these categories:

• Process protection alarms: high-high level, low suction pressure, loss of disinfection control, critical tank level, loss of required duty pump capacity.
• Equipment fault alarms: VFD trip, motor overload, actuator failure, controller fault, UPS failure.
• Communications alarms: station offline, stale telemetry, gateway fault, cellular service loss.
• Maintenance conditions: pump starts exceeding baseline, abnormal runtime balance, instrument calibration due, repeated low-severity faults.
• Security-relevant events: unauthorized remote-access attempt, configuration change, failed authentication, unexpected asset connection.

The error rate falls when alarm state is contextual. A “pump fail to start” condition has different operational meaning if the station has two available duty pumps, a backup generator, and stable wet-well level than if it is the only pump at a critical location.

The SCADA graphic should expose that context without becoming a process drawing of every wire and relay. Operators need state, consequence, and available action. Engineers need deeper diagnostic views. These are different interfaces.

Build recovery before the first production cutover

Water utility SCADA system migration is often planned as a commissioning event. It should be planned as a recoverability exercise.

The utility must assume that a new gateway fails, a software update causes incompatibility, a remote-access service becomes unavailable, an operator workstation is compromised, or a configuration is overwritten during a rushed change window. The relevant question is not whether these events are likely in isolation. The relevant question is whether the process remains controllable when one occurs.

EPA guidance calls for backups that include more than server data. The backup set should cover PLC logic, HMI graphics, network configurations, engineering drawings, and related configuration records. Backups should be stored separately from their source systems, tested regularly, and backed up and tested at least annually.

The 3-2-1 model remains a workable baseline: three copies of data, on at least two media types, with at least one copy remote, off-site, or in the cloud. This is resilience architecture. It does not compensate for poor access control.

A recovery plan for a pump station must also include physical operation. EPA advises utilities to train essential personnel and conduct exercises for manual operation of collection, storage, treatment, and conveyance when business, process-control, or communications systems are disabled by a cyber incident.

That requirement exposes weak migration assumptions quickly. If a station cannot be operated safely without a central dashboard, the architecture has concentrated too much authority upstream.

Run the cutover as a controlled test sequence

A credible cutover sequence is staged. It limits blast radius and makes rollback explicit.

1. Establish a known-good baseline. Capture controller logic, HMI applications, switch configurations, SCADA databases, and field-device settings. Verify that restoration media can actually rebuild the asset.

2. Deploy passive visibility first where feasible. Observe network behavior, protocol traffic, station availability, and tag quality before changing production command paths.

3. Introduce read-only telemetry. Validate scaling, timestamps, quality flags, alarm behavior, and communications-loss handling. Compare central values with local instruments and HMI displays.

4. Test the remote access path with constrained roles. Confirm multifactor authentication, session logging, authorization boundaries, and emergency disablement. Test with a noncritical asset or isolated environment before broad rollout.

5. Migrate commands one function at a time. Start with low-consequence supervisory commands. Validate feedback chains and local interlocks. Do not bundle pump control, valve control, alarm redesign, and historian replacement into one night shift.

6. Exercise failure states. Remove communications. Stop the edge gateway. Disable remote access. Restore a PLC configuration in a controlled setting. Confirm manual operations and escalation procedures.

7. Measure post-cutover performance. Track communication availability, stale-tag frequency, alarm count per operator shift, remote-session audit completeness, and time to identify a failed station path.

This sequence is slower than a wholesale replacement. It produces lower diagnostic latency. It also gives the utility a usable rollback point at each stage.

The migration route is an operating model decision

Modernization is not defined by cloud connectivity, MQTT adoption, a new dashboard, or a replacement PLC family. Those are components. The operating model is the system.

A durable water network automation path keeps local process control local when continuity requires it. It exposes telemetry through bounded interfaces. It gives remote personnel controlled access rather than unrestricted reach. It treats configuration backups as recoverable assets. It trains operators for the condition in which the SCADA screen is unavailable.

The utility should finish the project with fewer unknown paths, fewer ambiguous commands, lower alarm noise, and a tested ability to operate manually. Anything else is a technology refresh with uncertain operational value.

Use these design heuristics to keep the migration constrained:

• Define every station’s local-control boundary before selecting an IoT or SCADA platform.
• Inventory logic, graphics, network configuration, and drawings alongside hardware assets.
• Replace PLCs based on supportability and operational constraints, not age alone.
• Segment field control, supervisory systems, remote access, and enterprise services into defined zones and conduits.
• Remove direct public-Internet exposure from OT assets unless there is a documented operational need and layered compensating controls.
• Use OPC UA or MQTT for the data path they suit. Do not assign either protocol security properties it does not provide.
• Design telemetry tags around operating decisions, alarm response, maintenance action, and accountable performance metrics.
• Keep alarm volume within operator throughput. A visible event without a defined response is not automatically an alarm.
• Test backup restoration and manual operation before production cutover, then repeat the test at least annually.
• Measure migration quality through availability, command-confirmation integrity, stale-data rate, alarm load, and recovery time. Not through the number of connected devices.