Cloud ERP is now the default choice for new buyers, which means the interesting question is no longer whether to go cloud. It is how to buy it without signing something you will regret in year three.
Subscription software shifts risk in ways that a licence purchase does not. You no longer own a copy that keeps working if the relationship sours. Your version changes when the vendor decides. Your data sits somewhere you cannot inspect. None of that is a reason to avoid cloud ERP — but all of it is a reason to read the contract properly. This guide covers what cloud ERP actually is, its genuine benefits and risks, and the specific checks to complete before signing.
Not All Cloud ERP Is the Same
Vendors use “cloud” loosely. Three quite different arrangements hide behind the word, and they carry different costs and different control.
| Model | How it works | What you give up and gain |
| Multi-tenant SaaS | One shared application version serving many customers, with isolated data | Lowest cost and least maintenance; vendor controls the version you run |
| Single-tenant / private cloud | Your own instance of the software on a provider’s infrastructure | More control over version and configuration; higher cost, more responsibility |
| Hosted legacy | Traditional on-premise software running on someone else’s servers | Familiar product, remote access; you still own upgrades and much of the maintenance |
The distinction that matters most is who controls the version you run. In multi-tenant SaaS the vendor upgrades everyone on a schedule. That is the source of both the cost advantage and most of the frustration buyers report later. Establish which model you are being sold before comparing prices, because the three are not comparable.
The Genuine Benefits
• No infrastructure. No servers to buy, patch, back up or replace every four years. For a company without dedicated IT staff, this removes an entire category of cost and risk.
• Predictable operating expense rather than periodic capital outlay, which is easier to approve and easier to forecast.
• Faster deployment. Nothing to procure and install, so the project starts with configuration rather than with hardware.
• Access from anywhere, natively, without VPN configuration — which matters for multi-site operations, remote finance teams and warehouse mobile devices.
• Security and continuity handled by specialists. Major vendors run dedicated security teams, independent audits and tested disaster recovery that few mid-sized companies can fund internally.
• Elastic scaling. Add users when you hire, remove them when you do not, without stranded licences.
• Continuous improvement. New capability arrives without an upgrade project.
The Risks That Are Actually Real
Some of the common objections to cloud ERP are outdated. These are the ones that hold up.
Loss of upgrade control
Your version changes on the vendor’s schedule. A change can alter a workflow your team depends on, at a moment you did not choose. Ask how much notice you get, whether updates can be tested in a sandbox first, whether any deferral is possible, and what the vendor’s obligation is if an update breaks something for you.
Subscription cost drift
The cost you sign is rarely the cost you pay in year four. User growth, tier upgrades, storage overages, API charges and renewal uplifts all push it upward. This is manageable through contract terms, and unmanaged it is the most common source of cloud ERP regret.
Internet dependency
No connection, no system. For an office this is an inconvenience; for a warehouse or production line it can stop work. Plan for it deliberately — redundant connectivity, mobile failover, or an offline-capable process for genuinely critical operations.
Customisation ceilings
You extend within supported frameworks; you cannot modify shared core code. This constraint is mostly healthy, because it prevents the upgrade-blocking customisation that trapped many on-premise deployments. It becomes a problem only if you have a genuine requirement the platform cannot express — which is why scripted demos on your real scenarios matter so much.
Lock-in and exit friction
Your data, configuration, integrations and trained staff all accumulate inside one platform. Leaving means re-implementation. You cannot eliminate this, but you can reduce it by securing clear export rights before signing rather than when you want to leave.
Jurisdiction
Your data sits under the legal regime of wherever it is hosted, which may not be where you operate. For regulated sectors and for personal data under regional privacy law, this is a compliance question rather than a preference.
Security Due Diligence
The instinct that data is safer on your own server is usually wrong — an unpatched box in a locked cupboard only feels secure. But “the vendor handles security” is not diligence either. Ask for evidence.
1. Which certifications do you hold, and may we see the current audit reports? SOC 2, ISO 27001 or regional equivalents. A summary letter is not the report.
2. Where is our data physically hosted, and can we choose the region?
3. Is data encrypted at rest and in transit, and who holds the keys?
4. What is your backup frequency, and what are the documented recovery time and recovery point objectives? These should be numbers in a contract, not reassurances.
5. Have you tested recovery, and when? Untested backups are a hypothesis.
6. Which subprocessors touch our data, and are we notified when that list changes?
7. What is your breach notification commitment and timeline?
8. How is access controlled internally? Which vendor staff can see customer data, and how is that logged?
9. Do you use customer data to train shared models? Increasingly relevant, and the answer belongs in the contract.
10. What penetration testing do you conduct, and will you share the summary?
Contract Terms Worth Negotiating
Most of these are obtainable if you raise them before signing and nearly impossible afterwards.
| Term | Why it matters | What to aim for |
| Renewal uplift cap | Introductory pricing ends; increases compound | A stated maximum annual increase, in writing |
| User type definitions | A light user reclassified as full changes your cost materially | Written definitions of each user type and what triggers reclassification |
| Service level agreement | An uptime figure with no remedy is marketing | Defined uptime with service credits and an escalation path |
| Data export rights | Determines whether you can ever leave cleanly | Complete data in usable formats, defined timeframe, no exit fee |
| Data retention after termination | How long they keep your data, and how it is destroyed | A stated period and a certificate of deletion |
| Sandbox environments | Needed for testing updates and training | Included, or at a fixed known cost |
| API and integration limits | Overages move you to a higher tier unexpectedly | Stated limits and the cost of exceeding them |
| Notice of material change | Feature removal or repricing mid-term | Advance notice and a right to terminate on material adverse change |
| Assignment on acquisition | Vendors get acquired; terms can change | Your terms survive a change of ownership |
| The clause people wish they had negotiatedData export rights and the renewal uplift cap, in roughly equal measure.Both are easy to secure before signature and effectively unobtainable once the relationship depends on you staying. |
Total Cost: What to Model
Cloud looks cheaper in year one. Whether it stays cheaper depends on how honestly you model years two to five.
• Subscription at projected user numbers, not today’s headcount — model growth in line with your hiring plan.
• Realistic annual increases, not flat pricing.
• Implementation, migration and integration, which are not smaller because the deployment is cloud.
• Sandbox and test environments, if charged separately.
• Storage and transaction overages for document-heavy or high-volume businesses.
• Integration or API tier costs.
• Internal administration — someone must own the system, manage users and build reports.
• Training, including for new starters and after significant updates.
Run the model twice: once at your expected growth and once at fifty percent higher. Some pricing structures are comfortable in the first case and painful in the second, and finding that out during negotiation is far better than at renewal.
What to Verify Before You Commit
11. Confirm the deployment model. Multi-tenant, single-tenant or hosted — this changes cost, control and comparability.
12. Run scripted demos on your own scenarios, including your awkward exceptions, with data resembling yours.
13. Check localisation for every country you operate in. Tax and statutory reporting quality varies by market far more than vendors suggest.
14. Test the mobile experience on a real phone, particularly if warehouse or field staff will use it.
15. Establish the update cadence and notice period, and whether a sandbox is available for testing.
16. Review the integration catalogue — confirm each connector you need is supported today, not merely possible.
17. Complete the security questionnaire above and get the answers in writing.
18. Call three references at your size in your industry and ask what surprised them after go-live.
19. Model three to five years of total cost at projected user numbers.
20. Negotiate renewal caps and exit terms before signature.
Migrating from On-Premise to Cloud
• Audit your existing customisations and integrations, and establish which are genuinely still used. Many are not.
• Classify each one: supported natively, needs rebuilding, or can be dropped. The third category is usually larger than expected.
• Clean your data before migrating rather than carrying years of duplicates into a new platform.
• Plan for retraining. Cloud interfaces and workflows generally differ from the version staff know, and treating this as a minor change is a common cause of poor adoption.
• Decide how long the old system stays available read-only for reference and audit.
• Expect to change some processes. The customisation ceiling means adapting where the platform is opinionated — better to decide this deliberately during design than to discover it during testing.
Frequently Asked Questions
What is cloud ERP software?
ERP hosted and maintained by the vendor and accessed over the internet, usually on a subscription. The most common form is multi-tenant SaaS, where one shared application version serves many customers with isolated data, and the vendor handles infrastructure, security patching and upgrades.
Is cloud ERP secure?
Major vendors typically maintain stronger security practices than most mid-sized companies can fund internally, including independent audits and dedicated security teams. The genuine trade-offs are control, visibility and jurisdiction rather than weaker protection — which is why the due diligence questions above are worth asking directly.
What happens if the internet goes down?
The system becomes inaccessible. For offices this is an inconvenience; for warehouses and production lines it can halt work. Mitigate with redundant connectivity, mobile failover, or an offline-capable procedure for genuinely critical operations. It is a manageable risk, but it must be planned for rather than assumed away.
Can I customise cloud ERP?
You can configure extensively and extend through supported frameworks and APIs, but you cannot modify the shared core code. In practice this constraint prevents the upgrade-blocking customisation that trapped many on-premise deployments — though it does mean testing your genuinely unusual requirements during demos rather than assuming they can be built later.
Who owns my data in cloud ERP?
You do, under any reputable vendor’s contract. What varies is the practical detail — export formats, how quickly you can retrieve everything, retention period after termination and any charges. Read and negotiate the exit clause before signing, not when you want to leave.
How long does cloud ERP take to implement?
Six to twelve weeks for a small business with standard processes and clean data; four to nine months for a typical mid-market deployment; longer for multi-entity structures or significant integration work. Cloud removes infrastructure time, not configuration, data migration or training time.
Will my subscription cost increase?
Almost certainly, through user growth, tier changes and renewal uplifts. This is normal and manageable — negotiate a capped annual increase in writing before signing, and model your costs at projected rather than current user numbers.
Can I move back to on-premise later?
Rarely without a full re-implementation, and some cloud-only products have no on-premise equivalent at all. If deployment flexibility matters to you, choose a vendor that offers both models rather than planning to reverse the decision later.
Conclusion
Cloud ERP is the right default for most businesses, and the reasons are practical rather than fashionable: no infrastructure, faster deployment, specialist security, and costs that scale with the business rather than arriving in lumps.
The risks that remain are contractual rather than technical. Establish which cloud model you are actually buying, complete real security due diligence rather than accepting reassurance, model five years of cost at projected user numbers, and negotiate renewal caps and data export rights before you sign. Those four steps cost you a fortnight and remove most of what buyers regret three years later.