I've been part of more cloud migrations than I care to count, but the manufacturing ones always hit different. You're not just moving data. You're moving the nervous system of a factory that stops making money the second something breaks.
Early on, I tried the lift-and-shift approach with an MES. It was a disaster. The application was built for a local network with sub-millisecond latency to the PLCs. In the cloud, every scan cycle had a jitter that made the line operators furious. We rolled it back within a week.
That failure taught me there's no single cloud migration pattern for manufacturing. It depends on what you're moving and how tolerant the process is to latency or disconnection.
The first pattern I see work well is the edge-first hybrid. You keep real-time control and data acquisition on local edge servers, but push aggregated data to the cloud for analytics, dashboards, and long-term storage. One automotive plant I worked with did exactly this. The edge handled every press cycle and welding robot, while the cloud ran their OEE dashboards and predictive models. The key was defining a clear boundary: anything that needed sub-second response stayed on the edge. Everything else went up.
Then there's the phased migration pattern, which sounds boring but saves your sanity. Instead of moving the whole MES at once, you move one module at a time. Start with something low-risk like maintenance tracking or quality log review. Get that stable, build trust with the plant team, then tackle scheduling or production tracking. This approach lets you learn the factory's quirks without putting the entire operation at risk.
The third pattern I've seen gain traction is the cloud-native rebuild. This is for companies with enough runway to start from scratch. You build the new system in the cloud, designed from the ground up for async messaging, eventual consistency, and offline resilience. Then you run it alongside the legacy system for a quarter, comparing outputs, before cutting over. It's expensive and takes discipline, but the result is a system that actually fits the cloud instead of fighting it.
What all these patterns share is respect for the factory floor. You cannot treat manufacturing IT like a typical enterprise app. The network isn't always reliable. The operators don't care about your cloud strategy when a line goes down. And the data flow has peaks you'll never see in a test environment.
I've learned to start any migration with a simple question: what happens if the internet goes down for an hour? If your answer involves production stopping, you need a different pattern. That edge-first hybrid or phased approach buys you resilience that a straight lift-and-shift never will.
At the end of the day, the best pattern is the one the plant manager trusts. You can have the most elegant architecture in the world, but if the team on the floor doesn't believe it will keep their lines running, it won't matter. I've learned to listen more to the people who touch the machines every day than to the cloud vendor's reference architecture.