SaaSSMEsGDPRContractsCustom software
SaaS vs on-premise: definitions, real differences and how to choose, as a buyer or as a software vendor
10 min read
SaaS (software as a service) is software you use online on a subscription: the vendor hosts, maintains and updates it for all its customers. On-premise software is installed on servers your organisation owns or rents, and your organisation runs it. SaaS is quick to adopt, billed monthly and needs no in-house technical team. On-premise gives more control, at the price of an operating workload many firms underestimate. For most small and mid-sized businesses, SaaS is now the default; on-premise remains the right answer for specific constraints, and several hybrid options sit in between.
Most comparisons stop at the buyer's view. This one serves two readers: the business leader choosing software, and the founder or software vendor deciding how to deliver theirs. The criteria are the same, seen from both sides of the contract.
SaaS: the definition
The reference definition comes from the US National Institute of Standards and Technology, in NIST SP 800-145: the customer uses the provider's applications running on a cloud infrastructure, accessible from a browser or a program interface, and does not manage the servers, operating system, storage or even the application's capabilities, apart from limited user settings.
In practice, SaaS has four traits:
- access over the internet, from a browser or an app, with nothing to install on your servers;
- hosting and operations by the vendor: servers, backups, security, updates;
- one version for every customer, updated continuously;
- a subscription, per user, per volume or per tier.
SaaS is not a type of software but a delivery model. A CRM, a payroll tool or a custom business application built for a single company can all be delivered as SaaS.
The model is now mainstream. According to Eurostat (published 8 December 2023), 45.2% of EU enterprises bought cloud computing services in 2023. Among those buyers, 51.6% bought finance or accounting software, 25.9% ERP software and 25.0% CRM software as a cloud service.
On-premise: the definition
On-premise (often shortened to on-prem) software is installed on servers the organisation owns or leases, in its own building or in a data centre. It usually buys a licence, sometimes perpetual, pays the vendor annual maintenance for updates, and runs everything itself: installation, patches, backups, monitoring and security.
It is the historical model for enterprise software, and it has not disappeared. It remains common for industrial software, for sites without reliable connectivity, and for organisations with strict sovereignty or regulatory requirements.
The differences, criterion by criterion
| Criterion | SaaS | On-premise |
|---|---|---|
| Time to start | Fast: create an account, configure | Longer: servers, installation, configuration |
| Payment model | Recurring subscription (opex) | Licence, then annual maintenance and hardware |
| Operations | Handled by the vendor | Yours, or a managed service provider's |
| Updates | Automatic, for everyone at once | Scheduled by you, sometimes postponed for years |
| Customisation | Configuration within the vendor's limits | Wider, sometimes down to the code |
| Data location | With the vendor and its sub-processors | With you |
| Remote access | Built in | To be arranged (VPN, secure publishing) |
| Main dependency | The vendor and its continuity | Your own ability to run it |
| Exit | Depends on the contract's exit clause | Data stays with you, but software is often frozen |
Cost: compare like with like
The most common comparison, and the most misleading, puts a monthly subscription next to a licence price. To compare fairly, model both options over three to five years and list the same items on each side. Analysts call this total cost of ownership; in practice it is a simple spreadsheet.
On the SaaS side: the subscription, how it grows with users or volume, paid add-ons, initial configuration, data migration, and possible price rises during the contract.
On the on-premise side: the licence, the vendor's annual maintenance, servers and their replacement every few years, the licences for the underlying system and database, backups, security tooling, and above all the time of the people who run it. That last item is the one small firms forget most often, because it does not arrive as an invoice.
SaaS moves spending from capital expenditure to operating expenditure. It is not always cheaper over the long run, but it is almost always more predictable, and it does not tie up scarce in-house skills.
Security and GDPR: the question is "who", not "where"
"Our data is safer on our own servers" deserves checking. An on-premise server is only secure if someone applies patches, watches access logs, tests backups and responds at night. A serious SaaS vendor does this for a living; a 30-person company without an IT team rarely does.
The reverse is also true: SaaS hands your data to a third party. Under the GDPR, the vendor acts as your processor for the personal data it handles on your behalf, and Article 28 requires a contract setting out its obligations. The UK GDPR contains the same requirement. Questions to ask:
- where the data is hosted, and with which sub-processors;
- who can access it, and from which countries;
- how backups are made, and how often restores are tested;
- which certifications the hosting holds, if your sector requires them (ISO/IEC 27001, SOC 2, healthcare or public-sector schemes).
Our guide to hosting a business application in Europe details the levels of requirement, from a standard European host to sovereign cloud offerings.
The options in between
The choice is not binary. Between multi-tenant SaaS and a server in your office, several arrangements exist:
- single-tenant or dedicated SaaS: the same software, with a database and sometimes servers reserved for your company;
- SaaS hosted in a region you choose, or with a host your requirements impose;
- managed on-premise: the software runs on your servers or a private cloud, but a provider operates it;
- custom software hosted and maintained by the company that built it, paid by subscription: the fit of custom software with the comfort of SaaS.
What separates these arrangements is how data is isolated and who carries the operating workload. The isolation models are explained in our article on multi-tenant SaaS architecture.
For the business choosing software: a decision grid
| Your situation | Best fit |
|---|---|
| SME without an IT team, standard need | SaaS |
| Mobile teams, several sites, remote work | SaaS |
| Highly sensitive data, certification requirements | SaaS on certified hosting, or managed on-premise |
| No reliable internet (factory floor, remote site) | On-premise, or software with a real offline mode |
| Software specific to how your company works | Custom, hosted and maintained by its builder |
Before signing a SaaS contract, read three clauses before the price: the service level (availability, response times), the exit terms (data export) and the price review conditions. Our article on SaaS agreement clauses walks through them.
European law strengthens your position. The EU Data Act, applicable since 12 September 2025, regulates switching between cloud and data processing services, SaaS included, and Article 29 bans switching charges from 12 January 2027. Have a lawyer check what it means for your specific contract, especially if you are outside the EU and buying from an EU vendor, or the other way round.
For the vendor deciding how to deliver: a decision grid
If you publish software, the question becomes how to deliver it to your customers. SaaS is almost always the right starting point, for very concrete reasons:
- one version to maintain: a fix reaches every customer the same day;
- recurring revenue, which funds maintenance and new features;
- simpler support: you see the error in your logs instead of guessing it over a screen share;
- faster onboarding for customers, so a shorter sales cycle.
On-premise carries a hidden cost for the vendor. Every installation is a separate version, updated at the customer's pace, on an environment you do not control. A few large accounts may insist on it. The better answer is often a dedicated instance or a hosting region chosen by the customer, and true on-premise only when the contract pays its full cost, including the support of old versions.
We made that choice for our own products: Izi-Devis, the quoting and invoicing software that LPR Studio publishes and runs itself, is delivered as SaaS, in a browser, on a subscription, rather than installed at each customer's site.
Architecture, billing and pricing questions for a SaaS product are covered in our articles on the cost to build a SaaS platform and on multi-tenant architecture.
Common mistakes
- Comparing a subscription with a licence without counting what it takes to run on-premise software.
- Assuming "on our servers" means "secure", with nobody assigned to apply patches.
- Signing SaaS without an exit clause, and discovering at the end that the export is partial.
- Offering on-premise too early as a vendor, and spending your weeks maintaining old versions at different customers.
- Forgetting offline users: a workshop or a building site without reliable signal needs an offline mode, whatever the model.
- Ignoring lock-in in both directions. SaaS ties you to a vendor; on-premise ties you to the people who know how to run it. Our vendor lock-in guide covers how to plan an exit either way.
Where to start
- List your real constraints: data sensitivity, required certifications, connectivity, in-house skills.
- Model both options over three to five years, operations included.
- Read the contract before the price: service level, exit terms, data location.
- If what you need is software specific to your business, see it before deciding how to host it. We build a free visual prototype, presented on a video call within 5 working days, as explained in see your software before you pay.