Fortune 500 electronics manufacturing services giant operating factories across tech, automotive, healthcare, and aerospace industries was exploring whether its factory-level data centers could be replaced by a centralized cloud model, organised regionally rather than per-plant. Each factory runs its own large data center managing real-time manufacturing operations: robot coordination, PCB printing, quality control systems. They built a first PoC on Azure and AWS. I was part of a three-person independent expert team brought in to evaluate that PoC over three months – assessing whether it could actually support what a global factory network demands.
OT/IT cloud convergence
Independent PoC evaluation
Azure + AWS dual-cloud
Factory floor systems
On-site factory audit
Global EMS Fortune 500
Independent PoC evaluation
Azure + AWS dual-cloud
Factory floor systems
On-site factory audit
Global EMS Fortune 500
ClientJabil
IndustryElectronics manufacturing services
CloudAzure + AWS (PoC under review)
Duration3 months
My roleInfrastructure Architect – 3-person Expert team
OutcomeDetailed evaluation + next-phase roadmap
Fortune 500
global EMS leader – 100+ factories worldwide
Azure + AWS
dual-cloud PoC evaluated
Factory
on-site visit – real production floor
3-person
independent expert team · 3 months
All levels
KT sessions from floor engineers to C-level
Delivered as Infrastructure Architect at Epam · Epam Certified Technical Mentor · Epam Certified Resource Manager
Why This Problem Is Harder Than Standard Cloud Migration
Most cloud migration case studies are about moving enterprise software to the cloud. This engagement was about moving the operational infrastructure that runs physical factories. That is a categorically different problem, and the difficulty is not obvious until you stand on a factory floor and understand what “downtime” actually means there.
Factory systems are not enterprise IT – OT/IT convergence is the real challenge
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. These systems have microsecond-level latency requirements, zero tolerance for unplanned downtime during production shifts, and often depend on proprietary industrial protocols that were never designed with cloud connectivity in mind. OT (Operational Technology) and IT operate by completely different rules, and most cloud migration expertise is built entirely on IT assumptions.
The scale of what Jabil was proposing is enormous
Jabil operates over 100 manufacturing sites across more than 25 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 – eliminating the capital cost of maintaining hardware across hundreds of facilities while enabling centralised software management and shared upgrade cycles. If it works, the operational and financial transformation is enormous. If it fails at scale, the impact on production is catastrophic.
PoCs for industrial systems lie – production behaviour is different
A PoC for a factory control system is fundamentally misleading if it doesn’t replicate the real load profile. Factory systems don’t have gradual ramp-up – they switch between idle and full production load. They have burst patterns tied to shift changes, quality inspection cycles, and batch completions. Network latency that is acceptable in an enterprise application becomes a production line stoppage in a factory control system. The question was not whether the PoC worked – it did, in a test environment. The question was whether it would work at real factory scale.
Independent evaluation – not the team that built it
The PoC had been built by an internal Jabil team. Before committing to large-scale rollout across a global factory network – a multi-year, multi-billion-dollar infrastructure decision – Jabil needed an independent technical opinion that had no stake in the outcome. Our team of three specialists was brought in specifically 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.
What I Did
Full-stack independent evaluation – not a checklist audit, but a genuine investigation into whether the proposed solution could support what a global factory network actually requires.
1
On-site factory visit – understand what the system actually needs to support
Before evaluating the PoC against requirements, the requirements had to be understood from first principles – not from a specification document but from 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 patterns 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 a factory actually does – at the level of what happens when a robot arm receives a latency spike from its control system.
2
Multi-level stakeholder knowledge transfer sessions
The evaluation involved structured knowledge transfer across all levels of the client organisation – from factory floor engineers who understood the operational detail of production systems, to infrastructure architects who designed the PoC, to C-level stakeholders who would make the scale-out decision. Each level provided different and complementary signal: engineers revealed the operational constraints that weren’t in the documentation; architects explained the design decisions and their reasoning; executives articulated the business requirements that the PoC was supposed to serve. Synthesising these perspectives, and identifying where they didn’t align – was as important as the technical analysis itself.
3
Deep infrastructure and DevOps analysis of the Azure + AWS PoC
As the infrastructure lead on the three-person team, I was responsible for the full technical analysis of the PoC’s infrastructure layer. This covered: cloud architecture design on both Azure and AWS – network topology, compute configuration, storage architecture, and connectivity patterns between centralised cloud and factory-edge systems; deployment pipeline review and DevOps maturity assessment; infrastructure code quality and modularity; assumptions embedded in the infrastructure design that would not hold under production conditions; and performance characteristics of the infrastructure under realistic factory load profiles. I worked closely with the other two team members who led the software architecture and application layer analysis – the final evaluation synthesised all three perspectives.
4
Production load analysis – modelling real factory behaviour against the PoC
The PoC had been validated in a controlled test environment. The critical question was how it would behave under the real load patterns of a production factory – not average load, but peak scenarios: simultaneous production line starts at shift change, quality inspection bursts across multiple lines, real-time robot coordination at full production rate, and the network latency implications of routing factory control traffic through a centralised regional cloud node rather than local data center infrastructure. Load analysis in industrial environments requires a different methodology than standard application performance testing – the load profile is deterministic, the consequences of missed deadlines are physical, and the tolerance thresholds are set by industrial protocol specifications, not SLA agreements.
5
Consolidated evaluation report – pain points, solutions, and next-phase roadmap
The output of the three-month evaluation was a comprehensive assessment document structured to serve both technical and executive audiences. It confirmed that the overall approach – centralised cloud regional infrastructure replacing 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 concrete resolution approaches for each, and defined the adjustments required for the next phase of PoC development. The goal was not to produce a verdict but to give the business a credible and actionable basis for the next decision – which is exactly what an independent evaluation at this stage is for.
What This Engagement Demonstrates
🏭
OT/IT convergence – understanding two worlds that don’t speak the same language
Operational Technology and Information Technology have different latency tolerances, different failure consequence profiles, different upgrade models, and different expertise communities. A cloud architect who understands enterprise IT but not OT will evaluate a factory control system against the wrong criteria, and either miss critical risks or flag non-issues as blockers. The factory visit was not optional background context. It was the prerequisite for making the technical analysis meaningful.
🔍
Independent technical evaluation – finding what the builders couldn’t see
The team that built the PoC was technically capable. The risks they missed were not failures of competence but of perspective: PoC builders optimise for demonstrating feasibility; independent evaluators look for what will fail at scale. The architecture assumptions that work at test environment load break down under real factory patterns. The design choices that simplify development create operational bottlenecks in production. Independent evaluation is a distinct discipline — its value is structural, not personal.
📊
Industrial load analysis – not application performance testing
Standard cloud performance testing models HTTP load, database query latency, and throughput under concurrent users. Factory systems don’t work this way. They have deterministic load profiles, physical timing constraints from industrial protocols, and failure consequences that are not service degradation but production line stoppage. Evaluating whether a cloud architecture can support industrial workloads requires understanding both the cloud performance characteristics and the physical production process it is replacing.
🎯
Evaluation that serves a business decision – not just a technical verdict
The client needed to decide: continue investing in this PoC direction, redirect it, or stop. A binary technical verdict – “this works” or “this doesn’t” – serves nobody at that decision point. What a business needs from an independent evaluation is a structured view of what specifically works, what specifically doesn’t, what the resolution path looks like for each issue, and what a credible next phase looks like. Producing that – clearly enough for both engineers and C-level – is the real deliverable.
🌐
Global-scale infrastructure thinking – 100+ factories, multiple industries, dual cloud
The PoC was a single-factory test. The decision being evaluated was a global rollout across 100+ facilities in tech, automotive, healthcare, and aerospace – each with different production profiles, regulatory requirements, and network infrastructure. Evaluating a PoC for global scale requires thinking beyond whether it works in the test environment to whether the architecture pattern is compatible with the full range of deployment contexts it will eventually face. This is a different analytical frame from optimising a solution that is already in scope.
Skills This Engagement Evidences
OT/IT cloud convergence evaluation
Assessed cloud architecture against operational technology requirements – real-time control systems, industrial protocols, latency constraints, and factory floor processes – not just enterprise IT patterns. On-site factory visit as prerequisite for meaningful evaluation.
Independent PoC / technical due diligence
Structured independent evaluation with no prior involvement in the solution being assessed. Identified risks and assumptions the PoC team couldn’t see from inside – the specific value that independent review provides over self-assessment.
Industrial load and performance analysis
Modelled production-realistic load profiles for factory systems – not standard application performance testing. Shift-change bursts, real-time robot coordination, quality inspection cycles, and industrial protocol latency requirements evaluated against the PoC architecture.
Multi-cloud infrastructure review (Azure + AWS)
Deep technical review of dual-cloud architecture – network topology, compute configuration, storage, factory-edge connectivity patterns, deployment pipelines, DevOps maturity, and infrastructure code quality across both Azure and AWS components.
Global-scale architecture evaluation
Assessed a single PoC against the requirements of a global rollout – 100+ factories across multiple industries and regulatory environments. Identified which architectural patterns would scale and which would fracture under the diversity of real deployment contexts.
Cross-level stakeholder engagement
Knowledge transfer and analysis sessions across all organisational levels – factory floor engineers, infrastructure architects, and C-level executives. Synthesising signal from different levels and identifying misalignments between what executives believed and what engineers knew.
Decision-support evaluation deliverables
Produced a structured evaluation readable by both technical and executive audiences – confirming directional validity, identifying specific pain points, proposing resolution approaches, and defining a credible next-phase roadmap. Not just a verdict – an actionable decision input.
Regulated industry infrastructure (healthcare, aerospace, automotive)
Jabil’s factories operate across heavily regulated industries. Cloud architecture for manufacturing infrastructure in healthcare, aerospace, and automotive sectors must account for regulatory requirements that extend well beyond standard cloud security and compliance baselines.
The Core Insight from This Project
A PoC that works in a test environment is not evidence that a solution works – it is evidence
that the question being tested was answerable in a test environment. The real question for
Jabil was whether the solution would work in 100+ production factories across multiple industries.
Those are different questions, and the first one tells you very little about the second.
The second insight: OT systems require a different evaluation framework than IT systems.
The performance characteristics that matter for enterprise software – throughput, concurrent users,
database query times – are largely irrelevant for factory control systems. What matters is
worst-case latency under burst conditions, deterministic scheduling under load, and physical
failure consequences. These are not measured by standard cloud performance benchmarking tools.
The third: independent evaluation is structurally different from self-assessment.
The PoC builders knew their solution better than anyone. The risks they missed were not in
the parts they had built — they were in the gap between what was built and what the production
environment would demand. Seeing that gap requires a perspective that the builders, by definition, cannot have.
Who This Is Relevant For
You operate factories, plants, or industrial facilities with on-premise infrastructure
Manufacturing, utilities, logistics, energy, mining – any organisation where operational infrastructure runs physical processes. The question of whether those systems can move to cloud is not just a cloud question. It requires understanding what those systems actually do at a physical level – which changes everything about the architecture evaluation.
You’ve built a PoC and need an honest evaluation before scale-out
The team that built the PoC cannot objectively evaluate it – not because of dishonesty but because of proximity. An independent evaluation before committing to global rollout is not a sign of distrust in the team. It is the appropriate governance for a decision of this magnitude. The cost of a three-month evaluation is trivial compared to the cost of discovering critical issues after large-scale deployment.
You’re moving from CapEx data centers to OpEx cloud at industrial scale
The business case for replacing per-factory data centers with centralised cloud is compelling on paper – lower hardware investment, centralised management, shared upgrade cycles. The engineering reality is more complex. Understanding the gap between the business case and the engineering constraints – and how to close it – is exactly what this kind of evaluation produces.
Your board or leadership needs a credible technical assessment for a major investment decision
C-level executives making multi-year infrastructure investment decisions need more than the team’s own assessment of their work. An independent evaluation – conducted by specialists with no stake in the outcome – provides the credible technical basis that boards and investment committees can rely on when making decisions of this scale.
You work in a regulated industry where infrastructure failures have compliance implications
Healthcare, aerospace, automotive, and electronics manufacturing all have regulatory frameworks that extend to infrastructure and operational systems. Cloud architecture for these sectors cannot be evaluated against standard enterprise IT compliance baselines – the requirements are different and often stricter, particularly for operational systems.
Your cloud migration involves OT systems that your cloud team has never worked with
Most cloud teams are built on IT expertise. When the migration scope includes operational technology – industrial control systems, SCADA, manufacturing execution systems, real-time robotics — the evaluation requires someone who understands both sides of the OT/IT boundary. Without that dual expertise, critical risks in the OT layer will be invisible to the evaluation.
Validating a cloud migration PoC, planning industrial cloud transformation, or needing independent technical evaluation before a major infrastructure decision?
In 30 minutes I can tell you whether your situation maps to what I do – what the real risks are in your specific architecture context, and whether an independent evaluation would change the decision you’re about to make.
No pitch. A direct conversation about your infrastructure, the decision you’re facing, and what an honest technical assessment would actually require.