What ERP cloud computing changes and what it leaves

What ERP cloud computing means in practice

ERP cloud computing changes three things: who operates the servers, how upgrades arrive, and how you plan spend. It does not change what your system does. Your enterprise resource planning system runs on infrastructure a provider operates, and your staff reach it through a browser or API. The provider handles servers, storage and uptime. You still own the business rules inside it.

The formal definition is older than most ERP vendors' marketing. The US National Institute of Standards and Technology describes cloud computing as on-demand access to a shared pool of configurable resources that can be provisioned with minimal management effort. Nothing in that sentence says your invoicing logic gets simpler.

Reading the search results for this topic, you would think "cloud based ERP" is one product category. It is at least three different arrangements, and they carry very different amounts of risk.

What changes with ERP cloud computing

Three things change: who operates the servers, how upgrades arrive, and how you plan spend. The system's behaviour changes only if you choose to change it. The three usual arrangements differ as follows.

On-premise. Your team runs the servers and applies upgrades when you choose. Customisation freedom is full, and capacity changes mean a hardware purchase. The main risk is ageing hardware and key-person dependence.

Cloud servers, same ERP. A cloud provider runs the servers and your team configures them. You still apply upgrades when you choose, and customisation freedom stays full. Capacity changes take minutes to hours. The main risk is the same code with a new bill.

Vendor-run cloud ERP. The vendor runs the servers and applies upgrades on their schedule. Customisation is limited to what the vendor allows, and capacity changes are a contract change. The main risk is forced upgrades and lost customisations.

The second arrangement is the one competitor pages skip. Moving the same ERP onto cloud servers is a legitimate cloud migration, and it carries the least change to how your people work.

Who patches, who pays, who is responsible

Cloud providers split responsibility with you, and the split is narrower than buyers assume. AWS publishes its shared responsibility model: the provider secures the underlying infrastructure, and the customer secures what they put on it, including configuration, access and data.

For a hosted ERP, that means your user permissions, your integrations and your backups-you-have-actually-restored are still yours. For a vendor-run ERP, the vendor takes more of that, but you inherit their upgrade calendar. Ask for it in writing before signing.

Spend changes shape too. You swap a large hardware purchase for a recurring bill that grows with users and usage. That suits some finance teams and horrifies others. Neither is a technical argument.

What stays the same in ERP cloud computing

Your data quality, your approval rules and your undocumented customisations all arrive in the new environment untouched. A cloud platform copies a mess faithfully.

If your sales team keeps pricing in a spreadsheet because the ERP quote screen is too slow, they will keep doing that on the cloud. If three departments define "active customer" differently, the cloud ERP will store three definitions.

This is why we treat ERP and cloud as two separate questions in a project plan. The cloud question is about hosting and operations. The ERP question is about what the system actually does and whether anyone can explain it. Teams that answer the first and skip the second find out during cutover, which is the most expensive time to find out.

Customisations decide how hard the move is

A heavily customised ERP is hard to move because nobody knows what it does. A lightly customised one is easy. The count and documentation of your extensions predict the project better than the vendor's feature list.

Vendor-run cloud ERP products usually restrict custom code to protect their upgrade path. Microsoft's Dynamics 365 documentation describes a continuous-update model, so any extension you build has to keep working as updates arrive.

So before you pick a destination, inventory what the current system does that its standard version does not. Each item goes into one of three buckets that you decide on with the business owner: keep, replace with a standard feature, or retire.

Our five-day diagnostic is built around this step. In the OFBiz engagement below, it gave us a verdict on the customisations and on the database schema underneath, before anyone had chosen a destination.

An OFBiz system we left where it was

We did not recommend the cloud move in this engagement, the Apache OFBiz modernisation reference build. The usual advice (migrate to a cloud ERP) would have been the wrong first move. We work with Apache OFBiz, the open-source ERP framework involved here. The figures below come from our engagement records for this one client, so read them as a single result, not a benchmark.

The client was a wholesale distributor running OFBiz 17.12, live since 2016. They were scoping a move to a tier-one cloud ERP, mainly because nobody could explain what the current system did. We recommended finding out first.

What was wrong

The instance had 340 custom extensions. The two engineers who wrote them had left and there was no documentation. Every new report became a developer ticket with a two-to-three week queue, so the business built 41 Excel exports, maintained by 11 people. Quote turnaround was 2.5 days because pricing lived half in OFBiz and half in a spreadsheet.

A five-day diagnostic found the customisations were sound but undocumented, and the PostgreSQL schema underneath was clean. The problem was access, not data.

What we changed

We did not migrate. Over eight weeks we reverse-engineered and documented all 340 extensions, put a read-only API layer over the existing schema, and built quote assembly that pulls price, stock and delivery estimate in one call. Quote turnaround fell from 2.5 days to 3 hours. Report tickets to developers fell from roughly 14 a month to 2.

OFBiz stayed on 17.12. We scoped the upgrade and deliberately did not bundle it, because if an upgrade and a rollout break together you cannot tell which caused it. We also left 12 of the 41 spreadsheets alone, since Excel is the right tool for ad-hoc analysis.

What we got wrong

We shipped the documentation of the 340 extensions alongside the build. It should have been the first deliverable on its own. It unblocked every later decision, including the one about the cloud ERP migration, which the client deferred.

Three ways to approach an old ERP

Pick the approach by how well your team understands the system today. If the answer is "not well", spend your first weeks on understanding, whatever the destination. A broken workflow assessment is a natural way to do that.

Approach 1: Move it as it is

Lift the same ERP onto cloud servers. This suits systems that are documented and stable but sit on ageing hardware. Our cloud migration work covers this case.

Approach 2: Modernise in place

Document the system, add an API over the data, and fix the specific workflows that hurt. This is what the OFBiz case did, and it sits under system modernisation.

Approach 3: Replace with vendor-run cloud ERP

Right when the current system is genuinely at end of life or your processes are close to standard. Wrong when you are doing it mainly because you cannot explain what you have.

A cheap first step for any of them

Read-only access to the existing database is often the cheapest first step. PostgreSQL itself documents replication and standby servers that let you query a copy without touching the live system.

Questions to ask before you commit

Before signing a cloud ERP contract or starting a migration, get written answers to these. A vendor or partner who cannot answer them yet is telling you something useful.

• How many custom extensions or modifications exist, and where is each one documented?
• Which of them does the vendor-run product support natively, and which would be rebuilt?
• Who on your side can explain each major workflow, and are they staying?
• When does the vendor force upgrades, and what happens to your extensions when they do?
• What is the exit path: can you export your data in a usable form?
• Which reports and spreadsheets do people use because the ERP is slow to answer?

The last question finds the shadow system. In the OFBiz case it was 41 spreadsheets, and counting them took less time than anyone expected. Our data engineering team usually starts exactly there.

Finding out what you have before you move it

If you are weighing cloud based ERP against fixing what exists, start with the workflows that currently break: the quote that takes days, the report that needs a ticket, the spreadsheet only one person understands.

A broken workflow assessment looks at those specific workflows and tells you whether the cloud move would fix them or just relocate them. It is the same kind of diagnostic that preceded the OFBiz build.

You can book it without committing to any later work. If you would rather talk it through first, get in touch and we will scope it after a discovery call.