Can You Move a Factory’s Data Center to the Cloud? An Independent PoC Evaluation

The challenge

Most cloud migration case studies are about moving enterprise software to the cloud. This engagement was about the operational infrastructure that runs physical factories, and the difficulty is not obvious until you stand on a factory floor and understand what downtime means there.

A factory data center doesn’t run CRM and email. It runs robot arm controllers, PCB printing calibration systems, quality inspection software, real-time conveyor coordination and manufacturing execution systems (MES). The fastest of these systems have latency requirements measured in microseconds, they have zero tolerance for unplanned downtime during production shifts, and they often depend on proprietary industrial protocols that were never designed for cloud connectivity. Operational technology (OT) and IT work by completely different rules, and most cloud migration expertise is built on IT assumptions.

The scale was very large. Jabil lists over 120 sites in more than 30 countries, serving clients in tech, automotive, healthcare and aerospace, each with their own production environments and regulatory requirements. The proposal was to replace per-factory data centers with regionally centralised cloud infrastructure: no capital cost of maintaining hardware in every facility, central software management and shared upgrade cycles. If it worked, the operational and financial change would be enormous. If it failed at scale, the impact on production would be catastrophic.

A PoC for a factory control system is misleading if it doesn’t replicate the real load profile. Factory systems don’t ramp up gradually: they switch between idle and full production load, with bursts tied to shift changes, quality inspection cycles and batch completions. Network latency that is acceptable for an enterprise application becomes a production line stoppage in a factory control system. The PoC worked in a test environment, and the open question was whether it would work at real factory scale.

The PoC had been built by an internal Jabil team. Before committing to a large-scale rollout across a global factory network, a multi-year infrastructure decision, Jabil needed an independent technical opinion from people with no stake in the outcome. Our team of three specialists was brought in because we had no prior involvement with the PoC: we were there to find what the builders couldn’t see, and to give the business a credible basis for its next decision.

My task: as the infrastructure lead of the team, evaluate the infrastructure layer of the Azure and AWS PoC and, together with my two colleagues, judge whether the solution could support a global factory network.

What runs in a factory data center, and what can move to the cloud?

Manufacturers often describe their systems in levels, from the ISA-95 standard and the older Purdue model. Levels 0 to 2 are the machines, sensors, controllers and the systems that supervise them, and they work in real time. Level 3 is manufacturing operations, such as the manufacturing execution system (MES) that guides work through the plant. Level 4 is business planning, such as ERP. The fastest loops are very strict: for motion control, the 3GPP TS 22.104 standard describes cycles of 0.5 to 2 milliseconds. AWS’s own guidance for MES keeps the services that need low latency and can’t tolerate a lost cloud connection at the edge, close to the plant, and moves less time-sensitive work, such as updates to ERP and analytics, to the cloud.

What I did

1. Visited a factory to see what the systems really need to support

   Before evaluating the PoC against requirements, I wanted to understand the requirements on the factory floor itself. I visited one of Jabil’s production facilities to observe real manufacturing operations: the physical layout of factory systems, the connectivity between production equipment and control software, the latency sensitivity of real-time robot coordination, the load patterns of quality inspection cycles, and how shift changes and batch completions affect infrastructure demand. You cannot evaluate whether a cloud architecture can support a factory without understanding what happens when a robot arm receives a latency spike from its control system.

2. Ran knowledge transfer sessions from the factory floor to C-level

   The evaluation included structured knowledge transfer across all levels of the client organisation: factory floor engineers who understood the operational detail of production systems, infrastructure architects who designed the PoC, and C-level stakeholders who would make the scale-out decision. Engineers showed the operational constraints that weren’t in the documentation, architects explained their design decisions and the reasoning behind them, and executives described the business requirements the PoC was supposed to serve. Bringing these views together, and finding where they didn’t match, was as important as the technical analysis.

3. Reviewed the Azure and AWS PoC infrastructure and DevOps setup

   As the infrastructure lead on the three-person team, I was responsible for the full technical analysis of the PoC’s infrastructure layer on both Azure and AWS. My two colleagues led the software architecture and the application layer analysis, and the final evaluation brought all three views together.

   Technical details

   • Cloud architecture: network topology, compute configuration, storage architecture, and connectivity between the central cloud and factory-edge systems.
   • Delivery: deployment pipeline review and a DevOps maturity assessment.
   • Infrastructure as code: code quality and modularity.
   • Hidden assumptions: design assumptions that would not hold under production conditions.
   • Connection loss: what happens on the production line when the link between the factory and the regional cloud slows down or drops.

4. Modelled real factory load against the PoC

   The PoC had been validated in a controlled test environment. The critical question was how it would behave under the peak load of a production factory: simultaneous production line starts at shift change, quality inspection bursts across several lines, real-time robot coordination at full production rate, and the extra network latency of routing factory control traffic through a central regional cloud node instead of a local data center. In industrial environments the load profile is deterministic, missed deadlines have physical consequences and the tolerance thresholds come from industrial protocol specifications, so load analysis needs a different method from standard application performance testing.

5. Delivered the evaluation report and the next-phase roadmap

   The output of the six-month evaluation was an assessment written for both technical and executive readers. It confirmed that the overall approach, regional cloud infrastructure in place of per-factory data centers, was directionally valid and technically achievable. It identified the specific pain points that would prevent the current PoC from succeeding at production scale, proposed a concrete resolution for each, and defined the adjustments required for the next phase of PoC development. We presented the findings to engineers and C-level stakeholders, so the business had a credible and actionable basis for its next decision: continue, redirect or stop.

Results

In six months, the evaluation delivered:

• A clear answer on direction: regional cloud infrastructure in place of per-factory data centers is valid and technically achievable.
• The specific pain points that would stop the current PoC at production scale, each with a proposed resolution.
• The adjustments required for the next phase of PoC development.
• A view of how the PoC would behave under real factory load, from shift-change peaks to real-time robot coordination.
• A shared picture across factory engineers, architects and C-level, including the places where their views didn’t match.
• One report that engineers and executives could both use for the decision to continue, redirect or stop.

What I learned

A PoC that works in a test environment is evidence only that the question it tested could be answered in a test environment.

The question for Jabil was whether the solution would work in 100+ production factories across several industries, and the test result tells you very little about that. OT systems also need a different evaluation framework than IT systems. Throughput, concurrent users and database query times matter for enterprise software. For factory control systems, what matters is worst-case latency under burst conditions, deterministic scheduling under load and the physical consequences of failure, and standard cloud benchmarking tools don’t measure these. Independent evaluation is also different from self-assessment: the risks the builders missed were in the gap between what was built and what the production environment would demand, and seeing that gap needs a view from outside.

Evidence and further reading

• Related projectDORA compliance: benchmarking data center resilience for a Tier-1 Spanish bankAnother independent assessment that came before a big infrastructure decision.
• Related projectLeading a 3-data-center AWS migration without information about infrastructureWhat happens after the decision: exiting data centers at scale.
• Service · this siteCloud migration consultingHow I assess and plan migrations to the cloud.

Delivered as Infrastructure Architect at EPAM, where I was an EPAM Certified Technical Mentor and an EPAM Certified Resource Manager.

Skills and technologies

• Independent PoC evaluation
• Technical due diligence
• Cloud migration assessment
• Manufacturing cloud migration
• OT/IT convergence
• Factory data centers
• Manufacturing execution systems (MES)
• Azure
• AWS
• Multi-cloud architecture review
• Network topology review
• DevOps maturity assessment
• Infrastructure as code review
• Industrial load analysis
• Latency analysis
• Knowledge transfer sessions
• C-level decision support
• Regulated manufacturing (healthcare, automotive, aerospace)

← All projects