I remember the first factory I ever migrated to the cloud, about eight years ago. Mid-sized manufacturer, family-owned for three generations, with a basement data center full of servers that still had Windows Server 2003 stickers on them. The new CIO came from a SaaS company and decided everything was going to Azure in six months. I was the lead consultant, and I thought it would be straightforward. VM replication, VPN tunnels, a few late nights. I was dead wrong.
We did a classic lift-and-shift on their MES system, the one that tracks work orders in real time across the assembly line. Nobody thought to measure what "real time" actually meant on the plant floor. Turns out, the operators expected barcode scans to register in under 50 milliseconds. Over the VPN, we were hitting 200 milliseconds on a good day. The first week, production stopped twice because workers kept double-scanning, thinking the system hadn't caught the first one. I got a call at three in the morning from a plant manager who used language I won't repeat here.
That failure taught me that cloud migration in manufacturing isn't a single pattern, it's a spectrum. Back-office stuff like ERP and PLM can usually handle the latency. You can lift-and-shift those or re-platform them with minimal drama. But anything touching the shop floor, SCADA systems, quality control, real-time machine monitoring, those need a different approach. I started drawing a line between systems that need to respond in seconds and systems that need to respond in milliseconds. That line has saved my sanity more than once.
After the MES disaster, we pivoted to a hybrid pattern. We left the SCADA servers on-prem but put Azure Stack Edge devices in each production cell to handle local processing and caching. Sensor data from the CNC machines got aggregated at the edge, only summaries and alerts went to the cloud. That cut our latency to under ten milliseconds and our cloud egress costs by a factor of five. The operators never noticed the difference, which was exactly the goal.
Another pattern I've used more times than I can count is the strangler fig, especially with legacy systems that nobody wants to touch. At one plant, they had a custom quality inspection app written in Delphi by a guy who retired in 2012. We couldn't rewrite it, but we couldn't leave it on a dying physical server either. So we containerized it, wrapped it in a thin API layer, and deployed it to a local Kubernetes cluster. Over two years, we gradually replaced its modules with cloud-native microservices, one at a time. No big bang, no downtime, no angry phone calls.
Data gravity is the thing I wish more people talked about. I've seen teams underestimate how much data a single vibration sensor on a CNC machine can generate, ten megabytes per minute, per sensor. A factory floor with a thousand sensors will saturate your pipe to the cloud in no time. You have to think about where the data lives and where the decisions happen. Most of the time, you don't need raw sensor data in the cloud. You need a few aggregated KPIs and maybe the last ten minutes of high-frequency data when an anomaly is detected. That's an edge analytics pattern, and it's often cheaper and more reliable than pure cloud streaming.
Looking back, the biggest lesson isn't about technology at all. It's about spending time with the people who use the systems. I now start every migration project by standing on the factory floor for a full shift, watching how operators and maintenance techs interact with the software. They'll tell you what "slow" really means, and it's never what the IT architecture diagrams assume. The network is always the weakest link, not the cloud. If you don't respect that, you'll be the one getting the three a.m. call.