How do you migrate Geo SCADA to the cloud without downtime?

Build the cloud environment and run it in parallel with production, restoring a copy of the database and validating communications, historian recording, and client access before cutover. Schedule a controlled maintenance window, take a verified backup, repoint field communications, and confirm data flow and failover. Keeping the old server as a rollback path until the cloud environment is proven minimizes risk, though a brief cutover window is usually still needed.

Should I upgrade ClearSCADA and move to the cloud at the same time?

Often yes — planning the version upgrade and the hosting move together avoids doing two disruptive projects separately. However, it increases the number of variables changing at once, so thorough parallel testing is essential. Assess your current version, validate the target version in the cloud environment, and confirm all integrations and licensing before cutover.

What is the biggest risk when migrating Geo SCADA to the cloud?

The most common avoidable risks are skipping parallel testing, under-sizing the VM or historian disk, licensing surprises discovered at cutover, fragile connectivity without a redundant path or edge buffering, and untested backups that cannot be restored. A structured plan with verified backups and a rollback path addresses each of these.

Migrating Geo SCADA to the Cloud: A Step-by-Step Plan

Quick Answer

Migrating Geo SCADA to the cloud follows a structured plan: assess the current system and licensing, design the target cloud architecture and connectivity, validate licensing and sizing with Schneider Electric, build and test in parallel with production, then cut over during a controlled maintenance window with verified backups — confirming field communications, historian continuity, and failover before decommissioning the old server. A migration is a project, not a maintenance task, and rushing it is the most common cause of avoidable outages.

Step 1: Assess the Current System

Document the existing deployment thoroughly: Geo SCADA Expert version and patch level, database object and point counts, historian size and retention, all communication drivers and channels, redundancy configuration, every integration (reporting, OPC, Ignition or other platforms), and the current licensing type. If you are also moving off legacy ClearSCADA, review our ClearSCADA to Geo SCADA Expert migration guide first, since a version upgrade and a hosting move are best planned together.

Step 2: Design the Target Architecture

Decide on the cloud platform (Azure or AWS), VM sizing from your object count, disk tiering for the historian, the primary/standby topology across fault domains, and — critically — how field sites will connect (VPN or private circuit, with redundancy). Design edge buffering so events are not lost during the transition. Security must be designed in from the start; see securing hosted Geo SCADA.

Step 3: Validate Licensing and Sizing

Before building, confirm with Schneider Electric how your license transfers to the cloud: instance-based licensing, soft-key MAC/disk-ID pinning, and a license per running instance including standby and Virtual ViewX. Have license files reissued for the new machine identifiers. Validate that your chosen VM and disk tier meet the recommended configuration for your object count so you do not discover a performance shortfall after cutover.

Step 4: Build and Test in Parallel

Stand up the cloud environment and restore a copy of the production database into it. Run the cloud instance in parallel — ideally receiving live or replayed data — to validate communications, historian recording, alarm processing, client access via ViewX and Virtual ViewX, reports, and any scripting. This is where you find latency issues, timeout tuning needs, and integration gaps without risking production.

Step 5: Controlled Cutover

Schedule a maintenance window. Take a final, verified backup of the production system (test the restore, do not just trust the job — see backup and failover testing). Repoint field communications to the cloud server, verify each channel reconnects and data flows, confirm there are no historian gaps, and test alarm processing and client connectivity. Keep the old server available as a rollback path until you are confident.

Step 6: Verify and Stabilize

After cutover, monitor closely for the first days: communication stability, historian continuity, alarm rates (watch for new alarm noise introduced by latency-driven timeouts), backup success in the new environment, and a failover drill of the cloud primary/standby pair. Only decommission the old server once the cloud environment has proven stable and a full recovery has been tested.

Common Migration Pitfalls

Skipping parallel testing and cutting over blind.
Under-sizing the VM or disk, especially for the historian.
Licensing surprises discovered at cutover instead of during planning.
Fragile connectivity with no redundant path or edge buffering.
Untested backups that cannot actually be restored.

Getting Help

NFM Consulting plans and executes Geo SCADA cloud migrations end to end — assessment, architecture, licensing coordination, parallel validation, and cutover — and provides managed support afterward. Contact NFM Consulting to scope a low-risk migration.