Cloud ERP vs On-Premise in 2026: How to Decide

For most small and mid-sized companies in 2026, my default is a cloud ERP system, and on-premise is the exception you choose only when a specific condition forces it. But "cloud" is not one option. Split the decision into three separate questions — where the software runs, who operates it, and whether you need to change its code — answer them in a fixed order, and apply an exit test to every candidate before anything is signed.

This post is that procedure. It is not a price comparison; prices depend on your user count and go stale within a year. The questions do not. Every vendor document linked below was checked on 13 October 2026.

Why "cloud vs on-premise" is the wrong question

The phrase bundles three independent choices, and the decision goes wrong when one of them is answered while everyone believes all three were.

Where it runs. In the vendor's data centre, in your own account at a cloud provider such as AWS, or in a server room you own.

Who operates it. The vendor, a hosting company you pay, or your own staff. Operating means applying security patches, running and testing backups, handling upgrades, watching disk and memory, and answering the phone when it stops.

Whether you can change the code. Standard software only, your own add-on modules on top of the standard, or modifications to the core product itself.

The vendors' own hosting documents show how differently these combine:

• Odoo's documentation states plainly that Odoo Online is incompatible with custom modules or modules from the Odoo Apps Store. It is vendor-hosted, vendor-operated and standard-only.
• Odoo.sh is also Odoo's own cloud, but it is built for your code: module dependencies, continuous integration and SSH access. Same vendor, a completely different answer to the third question.
• On Frappe Cloud, the hosted home of ERPNext, you can install a custom app through your bench, but Frappe says it does not provide support for modified versions of the framework. Add-ons are the supported path; core changes are your problem.
• Microsoft ships Business Central both ways. Updates applied to Business Central online are also shipped in the next cumulative update for on-premises, so the product is the same while the operating model differs.
• And "Odoo on AWS" is cloud by location but on-premise by responsibility. Under the AWS shared responsibility model, customers who deploy an EC2 instance are responsible for the guest operating system, including updates and security patches, for the application software they install, and for the firewall configuration.

So before anyone says "we want cloud", fill in who owns each job:

Job	Vendor SaaS	Vendor platform (PaaS)	Your VM at a cloud provider	Your own server room
Hardware and data centre	Vendor	Vendor	Cloud provider	You
Operating system patches	Vendor	Vendor	You	You
ERP updates and upgrades	Vendor, on its calendar	Shared: you schedule and test	You	You
Backups	Vendor	Vendor	You	You
Proving a backup restores	You should verify	You should verify	You	You
Keeping custom code compatible	Not allowed or limited	You	You	You
User access, roles, MFA	You	You	You	You

The last two rows never move off your side of the table, whichever model you pick. That is the first thing every buyer should see.

Five questions, in this order

The order matters. The early questions are knock-outs: if one of them forces a model, the later questions only refine it.

1. Is there a written rule about where the data sits or who can touch it?

This means a law, a regulator, a defence or export-control obligation, or a clause in a major customer's contract. It does not mean "we would feel safer with our own server". Get the rule in writing from whoever owns compliance, then check it against the vendor's actual hosting regions. Odoo's cloud SLA, for example, lists customer databases hosted in Europe, the Americas, Asia-Pacific, the Middle East and Northern Asia, or Oceania, by customer choice.

If a vendor region satisfies the rule, the rule is not a reason for on-premise. If none does, you are choosing between a private cloud in a compliant location and your own hardware. Either way, you will need a named operator.

2. Does the business need code the vendor's SaaS will not run?

List every module, app and integration you expect to run in year one and in year three: marketplace connectors, industry add-ons, a custom approval flow, a report the auditors insist on. Then check each against the hosting option's rules. On Odoo, a single must-have module that is not standard rules out Odoo Online and moves you to Odoo.sh or self-hosting. I would rather find that in a spreadsheet during selection than in month four of the project.

Be honest about year three: a company planning to connect new sales channels next year should not pick an option that cannot host the connector.

3. Must any site keep working when its internet link goes down?

A warehouse scanning deliveries, a shop till or a production line may need to keep running through an outage. An office full of people doing accounting usually does not. If a site must keep working, look for the vendor's documented offline behaviour for that specific app, then test it by unplugging the link during the demo. The usual answer is not "on-premise for everything" but a cloud core with a small number of components that are tested to work offline.

4. Who will operate it at two in the morning?

In my view this is the question that should settle most self-hosting plans. Self-hosting, whether on a cloud VM or on your own hardware, needs a named person or a paid provider for patching, backups, restore tests, certificate renewals, monitoring and upgrades. If the honest answer is "our IT generalist, when they have time", then the real choice is between a vendor platform and a managed host, not between cloud and on-premise.

5. Can you live with the vendor's upgrade calendar?

Every model has an upgrade calendar. What differs is who sets it.

• Business Central online has two major updates a year, every April and October. Each one opens a five-month update period, followed by a one-month grace period. After that comes an enforced period in which extensions that make the update fail might be automatically uninstalled. Their data is kept and comes back when a compatible version is installed. If you have custom extensions, someone must test them in every cycle.
• Odoo releases intermediate SaaS versions every two to three months, available only on Odoo Online, and gives each major version three years of standard support. Beyond that, extended support requires an additional fee and is offered only on Odoo.sh (for a limited number of versions) and on-premise.
• On-premise does not escape the calendar. It postpones it. SAP set mainstream maintenance for the core applications of SAP Business Suite 7 until the end of 2027, with optional extended maintenance until the end of 2030. If you run an older on-premise ERP, its support end date is your real project deadline, whether or not anyone has written it into a plan.

If your processes depend on heavy customization and nobody will own compatibility testing twice a year, a fast vendor calendar will hurt. That is an argument for fewer customizations or a platform where you control the timing, not automatically for on-premise.

An exit test for every option

Before you choose any deployment model, get four answers written down.

1. Can you get a complete copy of your data, in a format that restores elsewhere? That means the database and the attachments, not a CSV export of invoices. Odoo Online, for example, lets the database administrator download a ZIP backup from the database manager, and asks you to contact support when a database is too large for that.
2. Has anyone actually restored that copy somewhere else? Do it once, before go-live, and compare the counts of customers, open invoices and stock on hand against the source. A backup that has never been restored is an assumption.
3. Who owns the repository for any custom code? It should be you, not the implementer, and it should be in version control.
4. What happens at the end of the contract, and what happens on deletion? Odoo's database manager warns that deleting an Online database removes all of its data instantly and that it cannot be restored. That is reasonable behaviour, but it is exactly why the exit copy has to exist before anyone clicks.

Moving between models is not symmetric either. To move an on-premise database into Odoo Online, Odoo's hosting guide requires you to uninstall all non-standard apps first. Going the other way has its own catch. Odoo's support table marks the intermediate SaaS versions as never released for Odoo.sh or on-premise, so an Online database on one of them has no matching self-hosted release until the next major version. Know which direction is expensive, and which version you are on, before you start.

Read the recovery numbers, not the word "backup"

"Backups included" tells you nothing until you know two numbers. The recovery point objective (RPO) is how much recent work you can lose. The recovery time objective (RTO) is how long you are down. Odoo publishes both. Its cloud SLA keeps 14 full backups over at least three months and states a 99.9% monthly uptime target, excluding planned maintenance. For the permanent loss of one server it targets an RPO of 24 hours, adding that for its SaaS databases, which are replicated in near real time, the loss should be near zero, and an RTO of 6 hours. For the loss of a whole data centre it targets an RPO of 24 hours and an RTO of 24 hours. It also says these objectives are not legally binding guarantees.

The question is whether those numbers fit your business. Plan for the worst case the vendor plans for: what would it cost to re-enter up to a day's orders and receipts, and to be down for a day? If that is unacceptable, ask the vendor what it offers beyond the default; self-hosting gives you the tools to go further yourself. PostgreSQL's continuous archiving and point-in-time recovery lets you restore the database to its state at any moment since the base backup. The price is that you now run and test that system yourself.

On-premise has the same two numbers. They are simply unwritten until the first incident. Every option on the shortlist should get its RPO, its RTO and the date of the last successful restore test written in the decision document.

Sensible defaults

These are reasonable starting points before the specific facts of a business move them:

Situation	Default	Why
Standard processes, no custom code, no residency rule	Vendor SaaS	Least operating work; you keep only access and data ownership
Custom modules needed, no in-house operations team	Vendor platform or a managed host	Your code, someone else's pager
A residency rule no vendor region meets	Private cloud or own hardware in a compliant location, with a named operator	The rule decides; the operator makes it survivable
Sites that must run through outages	Cloud core plus tested offline components	Solve the outage where it happens, not everywhere
An on-premise ERP approaching end of support	Plan the move now and treat the support end date as the deadline	Postponed upgrades compound
"On-premise because the licence is cheaper"	Re-check with operating time costed in	People time is the cost the licence line hides

What goes wrong, and how to spot it early

• A must-have app turns out to be incompatible with the chosen hosting. Spot it by listing every module in the evaluation and asking the vendor to confirm each one in writing for that hosting option.
• A "cloud" VM that nobody patches. Ask who applied the last operating system security update, and when. If nobody can answer, you have on-premise risk with a cloud invoice.
• Customizations meet the upgrade calendar for the first time in production. Use the vendor's preview or staging environments. Business Central, for instance, offers preview sandboxes about a month before each major update. Put the test into the calendar, not the backlog.
• Backups that were never restored. Ask for the date of the last restore test. "We have backups" is not an answer.
• Latency at the worst-connected site. Run the real workflows, such as receiving, picking and invoicing, from the site with the weakest link before you sign, not from the head office.
• No exit plan. If nobody can explain how you would leave, the contract is deciding for you.

Where this fits in choosing an ERP

The deployment model is a separate decision from the platform, which I cover in choosing the right ERP for your business. The two interact, because some platforms are SaaS-only. Settle the platform shortlist first, then run these five questions on each candidate.

If you already run Odoo and are deciding whether to move it, my architecture review covers the custom modules, integration patterns and infrastructure of an Odoo deployment, with an upgrade compatibility analysis, a written report and a walkthrough call. Bring these five questions and the exit test to it, so the hosting decision is made on evidence rather than on a sales call.

Frequently Asked Questions

What is a cloud ERP system?

A cloud ERP system is enterprise resource planning software delivered over the internet, where the servers are run in a data centre rather than on your premises. It ranges from vendor-operated SaaS, where you cannot add your own code, through vendor platforms that host your custom modules, to ERP software you install on your own virtual machines at a cloud provider. Those are very different operating models under one name, so always ask who operates it and what code it will run.

Is cloud ERP more secure than on-premise?

It depends on who does each job well. A vendor SaaS takes over the platform, patching and backups, the tasks most easily neglected. You still own user access, roles, multi-factor authentication and what you connect to it. On a VM at a cloud provider, the AWS shared responsibility model leaves operating system patching and firewall configuration with you. Security follows the operator, not the location.

Does on-premise ERP let me avoid forced upgrades?

Only for a while. On-premise lets you choose when to upgrade, but support windows still end. Odoo gives each major version three years of standard support before extended support at an additional fee, and SAP ends mainstream maintenance for Business Suite 7 core applications at the end of 2027. Postponed upgrades usually get harder, not easier, because the gap between versions grows.

Can I move from cloud ERP to on-premise later?

Sometimes easily, sometimes only through a full migration. If the cloud and self-hosted editions are the same software, as with Odoo Online and self-hosted Odoo, a downloaded backup can restore on your own server, provided the database is on a major version that is also released for self-hosting rather than an Online-only intermediate version. If the vendor is SaaS-only, leaving means migrating your data into different software. Test the export before you commit, not when you want to leave.