.svg)
How manufacturers split systems between cloud and on-premise
Manufacturing is the sector where on-premise never went away. Cloud is the default for new deployments now, but the installed base of local systems across plants, regulated production, and defense supply remains large and mostly deliberate. Most manufacturers are therefore not choosing between the two. They already run both and are deciding what moves next.
The division tends to follow one line: how badly a system needs to keep working when the network does not. Production scheduling, machine-level control, quality gates, and warehouse execution stay close to the floor. Group finance, demand planning, analytics, customer portals, and increasingly AI workloads run in the cloud, where compute is elastic and access is not tied to a building.
That division is sound engineering. It is also where the trouble starts, because the two sets of systems were bought separately, speak different formats, and were never given a common owner.
Why do manufacturers keep production systems on-premise?
An hour of stopped production costs more than any licensing saving a cloud migration might fund. That arithmetic, rather than caution, is what keeps critical systems inside the building. The reasoning breaks into three specifics.
Latency is the first. A scheduling or interlock decision sitting next to the equipment cannot wait on a round trip to a region several hundred milliseconds away. Autonomy is the second, since a plant needs to keep producing through a WAN outage, which rules out any dependency on a link leaving the site. Regulation is the third, because production and quality records in regulated sectors carry residency and retention obligations that are simpler to evidence locally.
Sunk investment in systems that work accounts for the rest. Some of that footprint is habit rather than requirement, and the genuine cases are narrower than they were five years ago. Several of them are still real.
What do manufacturers gain by moving planning and analytics to the cloud?
Comparability across sites is the largest gain. When each plant reports from its own local instance, a group-level question about output, scrap, or margin per line turns into a reconciliation exercise rather than a query.
Elastic compute is the second gain. Demand planning, scenario modeling, and quality analytics are bursty workloads that sit idle for most of the month, which is precisely what fixed local hardware handles badly. The third is that upgrades stop being projects scheduled around production windows.
AI belongs in this column too, though not as the headline. Models need pooled historical data across sites and years, structured consistently. That is a data problem before it is a model problem, which is why manufacturers pursuing AI usually end up moving their data layer first.
Why do local and cloud systems drift into separate silos?
Nobody owns the traffic between them. Plant IT owns what runs in the building and group IT owns what runs in the cloud, while the flows crossing from one to the other belong to whoever built the last connection.
What fills that gap is familiar. A point-to-point link per system pair, each written by a different person in a different year. A nightly file drop nobody monitors until the file is missing. A spreadsheet where someone squares plant output against group reporting every Monday. The symptom is two versions of the truth, where the plant manager and the operations director quote different production numbers from systems that both believe they are correct.
Fixing it means treating those flows as a component with an owner rather than a collection of accidents. The cost lands before the benefit does, which is the part worth being honest about. What it buys back is the manual checking, and the confidence that a change on one side will not quietly break something on the other.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
