Why Moving Your ERP to the Cloud Won't Fix Your Process Problem

There's a promise repeated in every ERP migration meeting. "Once we're in the cloud, all of this gets simpler." It won't. The cloud changes where your software runs, not how your company works.

If a purchase request today goes through three email approvals, a side spreadsheet, and a phone call, it will keep going through the same path after the migration. Except now it runs on servers in Frankfurt instead of a machine in the basement.

The cloud is a place, not a process decision

Moving to the cloud solves real problems. You stop managing hardware. You get managed backups, elastic scale, updates that don't halt the operation. That's worth the investment. But it's an infrastructure problem.

Your problem is almost always something else. It's the salesperson who approves credit on instinct. It's inventory that drifts from the system because nobody logs returns at the right moment. It's the month-end close that takes two weeks because half the entries live in loose spreadsheets.

None of this improves by changing servers. The ERP, on-premise or cloud, mirrors your processes. If the process is messy, the mirror reflects mess back with better uptime.

The lazy "as-is" assessment mistake

The typical migration starts with an assessment of current processes. The stated goal is to "replicate what we already have." This is where the project dies before it begins.

Replicating what you already have means coding decades of exceptions, shortcuts, and "this is how we've always done it" into an expensive new system. The result is a custom Frankenstein nobody can update later.

Lidl is the most cited public example. The retailer spent years on a new SAP-based inventory management system. The project was cancelled in 2018 after hundreds of millions invested. One reported reason: Lidl insisted on adapting the software to its model of valuing inventory at purchase cost, instead of adapting the process to the standard. The software bent until it broke.

Twenty years earlier, Hershey took the opposite path and failed through haste. It pushed ERP, CRM, and supply chain management into production at the same time, right before Halloween, with no time to stabilize the processes. It couldn't ship orders it already had in the warehouse. The migration was technically done; the operation stopped anyway.

What you have to do before touching the cloud

The right order is uncomfortable because it's slower up front. First you understand the processes. Then you decide which ones are worth keeping, which you cut, and which you align to the software's standard. Only then do you migrate.

• Map the real processes, not the ones in the manual. The real process is what people do at 5pm on a Friday with an angry customer on the phone.
• For every custom exception, ask why. Half the time the answer is a rule nobody needs anymore.
• Decide what you align to the standard. Expensive customization today is technical debt that locks you to a vendor tomorrow.
• Clean the data before you migrate. Dirty data in a new system is still dirty data, full stop.
• Name an owner for each process. Without an owner, nobody defends the change when the team pushes back.

Internal resistance is the real project

The technical part of a migration is the most predictable. APIs, integrations, cutover windows: all of that has manuals. What has no manual are the people who ran the old process for fifteen years and know it better than any consultant.

Classic change management studies are consistent on this point. Most transformation programs don't fail because of technology. They fail on execution, alignment, and getting people on board. HBR captures this well in the work by Sirkin, Keenan, and Jackson on the hard factors of change.

Picture the typical scenario: the warehouse lead gets a new system that forces them to log every movement as it happens, instead of at the end of the shift. To them, the new system is more work, not less. If you don't show them why and don't adjust the process to the reality of the floor, they go back to the side spreadsheet. And your cloud ERP becomes an expensive, dead archive.

So is the cloud worth it?

It is. But for the right reasons. Move to the cloud to stop managing infrastructure, to get elasticity, and to integrate more easily with the rest of your digital stack. Don't migrate expecting a change of server to reorganize your operation.

The sequence that works is easy to say and hard to do. Sort out the process. Clean the data. Align the people. Then turn on the cloud. Whoever inverts this order pays twice: once for the migration and once to undo it.

Good software doesn't fix a bad operation. It only makes it break faster. The right question was never "cloud or on-premise." It was "do our processes deserve to be automated as they are?" In most cases, the honest answer is no, and that's where the project really begins.