SQL Server on Azure SQL (PaaS) or SQL on VM (IaaS)?

Most mid-market workloads do better on PaaS (Azure SQL Managed Instance) — automated patching, backups, HA, scaling. Keep IaaS if you have cross-database queries, custom CLR, SQL Server Agent jobs, or SQL versions not supported in Azure SQL.

Is SaaS always cheaper than IaaS?

For commodity workloads at standard scale: yes, often 30-60% cheaper TCO over 5 years vs equivalent IaaS deployment. For heavily-customised or unusual scale: not always — vendor "per-user-per-month" pricing can be expensive at high seat counts.

SaaS vs IaaS vs PaaS for UK workloads: choosing the right cloud model

The cloud "as-a-service" stack — SaaS, PaaS, IaaS — gets thrown around in UK IT discussions without much rigour. The right choice for each workload depends on operational responsibility, customisation needs, and where the value lives.

Shared-responsibility — who runs what

The three models in plain terms

SaaS — vendor runs entire stack. You consume as web app + APIs. Microsoft 365, Salesforce, Workday, Xero. Customer responsibility: data, users, access.

PaaS — vendor runs infrastructure + runtime + tooling. You deploy code. Azure App Service, AWS Elastic Beanstalk, Heroku. Customer responsibility: code + data + config.

IaaS — vendor runs hardware + hypervisor + network. You manage OS up. Azure VMs, AWS EC2. Customer responsibility: OS patching, app install + config, everything above.

When to pick SaaS

Workload is a commodity — email, productivity, CRM, ERP, HR, accounting. Microsoft 365 + Salesforce + Workday + Xero are SaaS because the underlying capability is standardised across customers.

You don't need deep customisation or unusual integrations. SaaS configuration > customisation as a rule.

When to pick PaaS

Building custom software but don't want to manage infrastructure. Microservices, customer-facing APIs, internal apps with specific business logic.

Elastic auto-scaling without operational burden of managing compute. Azure Functions, AWS Lambda, Container Apps.

Trade-off: vendor lock-in is real. Refactoring a PaaS app to a different cloud is significant work.

Pick the cloud model

When to pick IaaS

Lift-and-shifting existing applications that aren't cloud-native. IaaS is your bridge.

You need specific OS / kernel / firmware control that PaaS doesn't allow (database appliances, specialist software, GPU compute).

Existing licensed software with strict deployment requirements (SAP, Oracle, ESRI).

The honest mixed reality

Most UK mid-market orgs run all three. Typical pattern: SaaS for office productivity + CRM + HR. IaaS for legacy apps + Windows / Linux servers (still often on on-prem servers Servnet manages). PaaS for net-new custom development.

Operational maturity = knowing which workload sits where + actively shifting workloads to the right model over time. Pair this view with the cloud vs on-prem 5-yr TCO model, AWS vs Azure selection, and cloud-security posture for governance.