Why moving your ERP to the cloud won't fix your process problem

There's a promise that gets repeated in every ERP migration meeting. "Once we're on the cloud, all of this will get 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 parallel spreadsheet and a phone call, it will keep going through the same dance after the migration. Only 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 scaling, updates without halting the operation. That's worth the investment. But it's an infrastructure problem.

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

None of this gets better by switching servers. Your ERP, on-premise or cloud, mirrors your processes. If the process is a mess, the mirror hands back a mess with better uptime.

The lazy "as-is" survey trap

A typical migration starts with a survey 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 hard-coding decades of exceptions, shortcuts and "this is how we've always done it" into an expensive new system. The result is a customised Frankenstein nobody can update afterwards.

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

Twenty years earlier, Hershey went the opposite way and failed through haste. It pushed ERP, CRM and supply chain management live all at once, right before Halloween, with no time to stabilise the processes. It couldn't ship orders it had sitting in the warehouse. The migration was technically done; the operation stalled anyway.

What you need to do before you touch the cloud

The right order is uncomfortable because it's slower at the start. First you understand the processes. Then you decide which ones are worth keeping, which you cut and which you align to the software 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 customised exception, ask why. Half the time the answer is a rule nobody needs any more.
• Decide what you align to the standard. Expensive customisation today is technical debt that locks you to a vendor tomorrow.
• Clean the data before you migrate. Dirty data in a new system is dirty data, full stop.
• Define who owns each process. With no owner, nobody defends the change when the team pushes back.

Internal resistance is the real project

The technical side of a migration is the most predictable part. APIs, integrations, cutover windows; all of it comes with manuals. What doesn't come with a 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 programmes don't fail because of technology. They fail on execution, alignment and people buying in. HBR captures this well in Sirkin, Keenan and Jackson's work on the hard factors of change.

Picture the typical scenario: the warehouse manager gets a new system that forces him to log every movement as it happens, instead of at the end of the shift. To him, the new system is more work, not less. If you don't show him why, and you don't fit the process to the reality of the shop floor, he goes back to the parallel spreadsheet. And your cloud ERP becomes a dead, expensive archive.

So is the cloud worth it?

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

The sequence that works is simple to say and hard to do. Sort out the process. Clean the data. Align the people. Then switch on the cloud. Anyone who inverts this order pays twice: once for the migration, and again to undo it.

Good software doesn't fix a bad operation. It just makes it break faster. The real 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 truly begins.