Cloud migration for systems with a physical dependency

A migration plan for an industrial system tends to look fine until somebody walks the floor. There is a beige box in a cabinet beside the line, running an operating system nobody wants to discuss, connected by serial cable to a machine that cost more than the building. That box is not moving to a cloud region.

Most of the interesting decisions on these programmes concern what stays.

Four things that do not move

1. 01Anything with a physical interface. Serial links, field buses, cards in a slot. If it terminates in a cable to a machine, it stays near the machine.
2. 02Licences tied to a host. Industrial and engineering software is frequently licensed to a dongle, a MAC address or a named server. Some vendors do not sell a cloud-compatible licence at all, and the negotiation runs longer than the migration it blocks.
3. 03Anything with a hard latency budget. Control loops and safety interlocks have deadlines in milliseconds. A well-connected region is tens of milliseconds away on a good day and unreachable on a bad one, which is the day the interlock exists for.
4. 04Data with a legal address. Some records must remain inside a jurisdiction and occasionally inside a named facility. That is a legal constraint, so no argument about encryption strength resolves it.

Each is a fixed point the design has to be drawn around, and finding the third one in month seven is how these programmes acquire their reputation.

The shape that keeps working

What we end up with is a split. Deterministic and physically bound functions stay on site, on hardware sized to run with no external connection at all, because a severed link is the state the plant will be in during the worst hour of the year. Analytical and organisation-wide functions move. Telemetry flows outward through a buffered gateway. Commands, where they flow back at all, travel a narrower and more heavily audited path than the data came out on.

The IoT grid platform we built for iConcept PowerTech in Indonesia divides along that line. iConcept operates power plants, transmission and distribution, and none of the plant hardware or its local control was ever a candidate for relocation. We instrumented it and streamed telemetry into a central system holding the models, the downtime forecasting and the dashboards. That layer can be unreachable for an hour and nothing on the ground stops generating.

The gateway is the hinge

Site connectivity fails, and at a remote plant nobody drives out to look, because the plant is still running. If the gateway drops readings while the link is down, the analytics are quietly wrong afterwards and the next model trains across a hole it cannot see.

So the gateway stores and forwards, with local disk sized against the longest outage anyone at the site can remember plus a wide margin, and every reading carries the time it was taken as well as the time it arrived. Recovering that distinction a year later is grim work, and we now treat the gateway as the first component designed rather than a detail of the ingest layer.

Cost turns up sideways

Telemetry volumes surprise finance teams. A few thousand tags at one second resolution is unremarkable by web standards. It becomes a large number running continuously across every site for a year and stored twice for resilience. Downsample at the edge, keep full resolution locally for a defined window, and settle retention early. Retention is usually decided by an engineer picking a generous round number. It should be decided by whoever owns the regulatory obligation, with their name written against it.

One site at a time

The first site takes months and costs disproportionately, and that is the point of it. It is where the gateway design, the tag naming, the time handling and the rollback procedure get settled by contact with reality. The sites after it follow a runbook. Running several in parallel before the first has been through a full seasonal cycle means finding the same defect several times over, most of them a long drive from anyone who can fix it.

An honest plan names the components that will still be sitting in a cabinet on site in ten years, and budgets for keeping them supported: spares, an operating system nobody else runs, an engineer who still knows the protocol. That list never reaches zero where there is a physical dependency, and plans written as though it will tend to reach the third site and stop.