Start With Telemetry: OT Engineers' SCADA Cloud Migration Blueprint

Cloud-hosted SCADA use cases: which one fits your operation?

Cloud SCADA isn't a single thing. There are four categories per NCSC guidance, and selecting the appropriate category is your first engineering decision, not your last decision.

Full cloud control places supervisory control logic in the cloud, where only local execution takes place at sites based on cloud instructions. Telemetry-only analytics uploads read-only data to the cloud for dashboards, historians and machine learning use cases, retaining local control. Hybrid control is a compromise solution between local and full cloud control: time-critical control loops continue to run on local PLCs, while higher-level supervisory control and optimisation is pushed into the cloud. Cloud cold-standby places a redundant copy of the control system in the cloud that only springs into action when needed for disaster recovery purposes.

Before deciding on any of them, go through this quick checklist:

• Latency tolerance: Can the process deal with the round-trip latency inherent to a wide-area link, or does it require sub-second response locally?
• Connectivity loss: What happens operationally if connectivity drops for minutes, or hours?
• Safety functions: Are there safety-instrumented functions involved? If so, do they need to remain hard-wired and local irrespective of the chosen architecture?
• Protocol constraints: Are field devices communicating in legacy serial or proprietary protocols that must be translated to reach the cloud?
• Regulatory boundaries: Is your regulator or industry requiring data residency or on-premise sovereignty for some activities?

If you don't know the answer to safety or latency questions, begin with telemetry-only. That is the safest place to demonstrate value without touching control.

Architecture patterns for SCADA to cloud migration

With use case established, architecture decisions balance the attack surface you create with actual network performance.

1. Push-based telemetry gateways. Instead of listening for inbound connections, edge devices publish data out to a cloud ingestion point. This eliminates the need to allow inbound firewall rules into the OT network, which is the largest mitigation to attack surface most sites can make.
2. DMZ and jump host patterns. Vendor access, patching and remote diagnostics go through a hardened DMZ with jump hosts, not directly into the control network. This provides you with one auditable chokepoint instead of dozens of point products and ad hoc remote-access tools.
3. Edge processing and containerisation. Protocol conversion, buffering and pre-processing occurs on edge compute, right beside field devices, before data ever leaves the site. This can absorb jitter and keep time-critical decisions local, while still allowing cloud scale-out of analytics.

Secrets / key management gets its own vote. Centralised key management supported by a cloud KMS can be feasible for most telemetry and hybrid architectures but only if the key hierarchy and rotation strategy is risk assessed against OT recovery scenarios explicitly, not by default. A comprehensive implementation guide for secure building automation connections discusses analogous authentication/key-handling tradeoffs for compatible OT protocols.

Tip from a Manager: When you cannot install a modern authentication agent on a vendor device, install a broker in front of it instead of hacking the firmware, and work out that change through procurement so you don't void the warranty.

Security and compliance: adapting zero trust for OT

Zero trust was designed with modern endpoints and always-connected IT networks in mind. OT has neither modern endpoints nor constant connectivity, and NIST SP 800-82 Revision 4 clearly states that OT security needs to meet performance, reliability, and safety demands that weren't considered when zero-trust models were created.

For example, "adopting zero trust principles" in the OT environment, per CISA's joint guidance on zero trust for OT, begins with securing supervisory workstations and HMIs first because they are considered the highest-value pivot point into the control network. Layering defenses can then help account for older devices that will never be able to run modern endpoint agents. For example, CISA advises lightweight EDR solutions rather than installing agents across all field devices.

Controls worth prioritising:

• Segmentation between IT, OT supervisory, and OT field layers at the switch level, not just on paper.
• Privileged access management applied to all accounts with access to supervisory systems, with session recording enabled.
• Phishing-resistant MFA on supervisory and cloud-management interfaces.
• Defined key management, including rotation and break-glass recovery.
• Continuous vulnerability and bill-of-materials management of every device/software link in the chain.

Your contract should include support windows for older equipment and incident response timelines as well as, most importantly, clear shared-responsibility language: Who patches the gateway? Who patches the cloud service? Who's liable when that boundary is ambiguous?

Migration approach: a phased plan from assessment to operations

Timing is everything with a cloud SCADA migration. Cutting out the assessment to jump to a pilot phase early is the #1 reason migrations fail half way through.

1. Phase 0, governance and readiness. Take stock of all assets, policies and data flows, then benchmark objectives versus your true risk appetite. Framed slightly differently by NCSC themselves, this should be an assessment of organisational readiness and technology suitability, rather than something you can blindly box-tick. There's a related post about getting stakeholders involved early when mobilising infrastructure, which ties into building that governance mindset before any real tech work begins.
2. Phase 1, pilot and feasibility. Perform latency tests against live network paths, beta test a protocol conversion gateway against a non-mission critical device, and publish a constrained telemetry set to the cloud to validate the pattern in end-to-end fashion.
3. Phase 2, migration and rollback planning. Determine asset by asset if you'll rehost as-is, refactor to cloud-native scaling or rearchitect altogether. Each migrated element must have a rollback path to local control documented before going live.
4. Phase 3, hardening and handover. Implement your entire set of security controls, baselining monitoring, and hand over the running system to operations complete with runbooks, rather than simply documents.

Every phase has a gate at the end. Go, redesign, or kill. Think of the gate as an actual off-ramp, not a hurdle to leap over on your way to an inevitable decision.

Testing, validation and runbooks: proving it works before it matters

If you haven't tested a migration by inducing failure, you haven't properly tested a migration. Construct your test suite around what truly determines safety.

• RTT latency and worst-case jitter on the actual network path, not a shortcut in the lab.
• Protocol conversion load tests under peak data volume, not average conditions.
• Cold-start disaster recovery drills that test actual time to takeover, not failover time.
• Segmentation-break tests that confirm a compromised device cannot reach supervisory systems.

Verify security against the agreed upon control set defined during procurement. This should occur on a regular basis, not just at go-live.

Academic case studies of SCADA migrations to infrastructure-as-a-service clouds showed that event-driven architectures and local protocol conversion mitigates the latency and processing bottlenecks that naive polling over a wide-area link creates. This can serve as useful guidance when developing your own acceptance criteria.

Use a testbed that duplicates production protocols and device firmware versions, don't just test against basic simulators. Maintain it past go-live for regression tests.

Tip: Write your break-glass procedure in advance, not in response to the first incident. Decide who can trigger a fallback to local control, and how quickly they can do it.

Costs, procurement and contractual considerations

Many budget discussions begin at cloud subscription prices and overlook products that are driving total cost.

• Edge gateway hardware and lifecycle maintenance. Easy to forget when the spreadsheet is built solely around cloud line items.
• Data egress and long-term storage costs, particularly for high-frequency telemetry retained for compliance.
• High-availability SLAs if you need anything closer to control-grade uptime instead of dashboard-grade uptime.
• Developer effort. Refactoring an application to scale cloud-natively incurs materially more effort than just a lift-and-shift, but can improve resilience.

Contracts should define shared-responsibility boundaries, SLA commitments around patching/incident response, and require vendors to maintain an up-to-date bill of materials and functioning vulnerability disclosure process.

A quick TCO sanity check before you promise budget: include every gateway and licence, cost data egress at realistic telemetry volumes, price HA at the tier you require not the tier easiest to sell, and decouple one-time migration expense from ongoing operating expense lest the business case silently underestimate year 2.

PODTECH perspective: how we approach SCADA to cloud migrations

We work on the layer that migrations actually rely on. Master systems integration. Legacy modernisation. Developing SaaS products for teams moving off legacy on-premises monitoring into cloud connected platforms. Engagements can be delivered as dedicated teams or staff augmentation. Teams are built to work around your existing operation, not replace them.

Our DCIM Solutions case study is an example of the type of infrastructure monitoring discussed in this article. It also demonstrates our commitment to high uptime and our proven track record of delivering many projects on which high reliability is a requirement for mission-critical work.

Deliverables for a standard migration engagement are a phased architecture plan which incorporates governance check points at each phase gate and hands on involvement with the client' ops team throughout the engagement so that the system implemented is a system ops has already tested and accepted.

Data integrity and synchronisation during migration

Running legacy and replacement systems in parallel, even for a short time, invites data drift or duplication. The mode of failure is seldom catastrophic: a historian that silently mis-agrees with the field device, or a timestamp mismatch that doesn't get caught until an audit years later.

Define a single source of truth for migration window. This will typically be the legacy system up until cutover has been formally declared. Timestamps should be carried with every value pushed to cloud, along with a data quality flag so downstream analytics can differentiate between an actual reading vs. a reconnection artefact.

Add some buffer on the edge. If connectivity is lost, the edge gateway should buffer readings locally instead of dropping them, and replay them in-order when the link comes back up. This is especially important for cloud SCADA vs. most IT integrations, because control-adjacent decisions may depend on the order of data, and not just their presence.

Reconciliation reports should be automated to run during parallel-run, comparing cloud-side and legacy-side values for the same tag and highlighting differences outside of a predetermined tolerance. Treat this as a continuous process throughout parallel-run, not a checkbox validation at go-live: run it until you have sufficient history that you're comfortable with the pipeline running unattended, and then maintain a lightweight version running going forward as sanity check against silent failure.

Practitioner perspective: when cloud is a strategic enabler for OT

Cloud deserves a place in OT when we treat it as an augmentation to resilience, rather than a replacement for local control. Those organisations that extract value quickest are ones who build a testbed early, engage operations before architecture decisions become hardened, and avoid panic migrations when the pressure is on to move everything because "we proved it could work in pilot". Cloud SCADA has more rewards for patience than it does for ambition.

How PODTECH can help with your SCADA migration

Remote access and moving SCADA to the cloud hits integration, legacy protocols and monitoring all at once. That intersection is where PODTECH creates software solutions. We work alongside your engineering and infrastructure teams to develop Master Systems Integration, modernize legacy applications and create SaaS. We build your migration around your existing control systems, we don't ask you to rip and replace everything.

When peer reviewing a migration and want additional feedback on the architecture:

Check out our Master Systems Integration and datacenter services portfolio for examples of work we've completed.

• Review the DCIM Solutions case study to see a real life example of delivered infrastructure monitoring.

Contact us via PODTECH to schedule a discovery call to discuss your unique systems and timeline.

Sources

• SP 800-82 Rev. 4, Guide to Operational Technology (OT) Security | CSRC
• SCADA ‘in the cloud’: new guidance for OT organisations
• Adapting Zero Trust Principles to Operational Technology | CISA

FAQ

What are the main types of SCADA cloud migration?

Full cloud control, telemetry-only analytics, hybrid control which leaves time-critical loops local and cloud-hosted cold-standby failover are described as the primary options in NCSC's guidance document Getting your cloud-hosted SCADA right. Many organisations consider telemetry-only or hybrid options first before looking to move full control to the cloud.

How do I adapt zero trust principles for OT systems?

Begin with securing supervisory stations/HMIs first because they're the crown jewels, then layer defenses to work around older field devices that can't run cutting-edge agent technology. For example, CISA's joint zero trust guidance for OT advises using lightweight endpoint strategies instead of widespread agent deployment.

What are the biggest challenges in SCADA cloud migration?

Some of these issues that keep cropping up are latency-sensitive control loops that can't handle wide area round trips, legacy protocols which must be translated before they can get to the cloud, and security models designed for today's IT endpoints instead of 40-year-old field devices. Data integrity while doing parallel running with new and old systems operating concurrently is another often overlooked vulnerability.

Should safety-critical control functions ever move to the cloud?

Safety-instrumented functions tend to remain local and hard-wired even if everything else moves because they require deterministic response times that cannot be guaranteed across a wide-area link. Typical cloud architectures put supervisory logic, analytics and disaster recovery standby in the cloud with safety interlocks local.

What should a SCADA cloud migration contract include?

Contracts should explicitly say there are shared-responsibility boundaries between vendor and operator, include SLA commitments to patching and incident response, and require vendors to have an up-to-date bill of materials as well as an operational vulnerability disclosure process, all points mentioned in CISA's guidance on OT procurement. Explicitly define support windows for legacy equipment too, instead of leaving it implicit.

Recommended

• Top telemetry tools for UK enterprise infrastructure in 2026
• Custom Software Development in Datacenters: The Single Pane of Glass Imperative
• Industrial automation setup process: a step-by-step guide
• Infrastructure Observability: From Hours to Minutes with PODTECH Pilot