Quick answer
Choose SaaS when an existing application meets your business requirements. Choose PaaS when you need your own application but do not need to manage its underlying operating system. Choose IaaS when the workload requires operating-system control or an environment a managed platform cannot support. These choices follow the different boundaries of control defined by NIST. (nvlpubs.nist.gov)
Decision rule: Prefer the option with the fewest operational responsibilities that still meets your requirements—and assign an owner to every responsibility you retain.
This guide is for teams choosing how to deliver a business application. It assumes a public-cloud service, not an organization operating its own cloud infrastructure. The product examples illustrate service boundaries; they are not a provider ranking.
1. Understand what each service model gives you
NIST distinguishes three service models by what the customer can use, deploy and control:
- Infrastructure as a service (IaaS): You provision computing resources such as processing, storage and networking. You control the operating system and deployed software, but not the provider’s underlying infrastructure.
- Platform as a service (PaaS): You deploy an application using languages, libraries and tools the platform supports. You control that application and available hosting settings, rather than the underlying servers or operating system.
- Software as a service (SaaS): You use the provider’s application. Your control is through the configuration and interfaces the product makes available, not its underlying infrastructure. (nvlpubs.nist.gov)
Concrete examples are Azure Virtual Machines for IaaS, Azure App Service for PaaS, and cloud applications such as Microsoft 365 or Dynamics 365 for SaaS. (learn.microsoft.com)
Do not confuse service models with deployment models. Public, private and hybrid describe how cloud infrastructure is deployed; IaaS, PaaS and SaaS describe the capability delivered to the customer. (nvlpubs.nist.gov)
For your decision, translate each label into a question: What must our team configure, maintain and recover?
2. Map responsibility before comparing features
The following is a simplified operating-responsibility matrix. It reflects Microsoft’s published shared-responsibility guidance, but individual services and contracts determine the exact boundary. “Shared” means different tasks belong to different parties—not that either party can leave them unassigned. (learn.microsoft.com)
| Responsibility | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical facilities and hosts | Provider | Provider | Provider |
| Operating system | Your team | Provider | Provider |
| Application stack | Your team | Shared | Shared |
| Network security controls | Your team | Shared | Provider |
| Customer-controlled settings | Your team | Your team | Your team |
| User identities and access | Your team | Your team | Your team |
| Data governance | Your team | Your team | Your team |
The provider taking over infrastructure does not remove your responsibility for data, identities or settings you control. (learn.microsoft.com)
Turn the matrix into a task list. Replace “application stack,” for example, with named activities: update dependencies, approve configuration changes, monitor failed transactions and escalate incidents.
For each activity, record:
- Who performs it.
- Who approves changes.
- How problems are detected.
- Where evidence of completion is kept.
- Who covers absence or staff turnover.
Do this for every component. A VM-based application using a managed database has different responsibilities at its application and database tiers.
3. Match the model to your team’s operational capacity
Start with constraints, not familiarity with a particular tool.
Consider IaaS when you need specific environment control. Examples of requirements to investigate include an operating-system dependency, privileged software installation or a vendor application that cannot run within the candidate platform’s supported environment. Azure’s VM documentation explicitly identifies greater environment control as a reason to choose VMs—and says customers still configure, patch and maintain their software. (learn.microsoft.com)
Before selecting it, ask who will own patching, deployment, monitoring and incident response. “The developer who set it up” is not a durable operating plan.
Consider PaaS when custom application behavior matters more than OS control. Azure App Service hosts web applications and APIs on supported stacks without requiring customers to manage the underlying infrastructure. (learn.microsoft.com)
However, distinguish a built-in runtime from software you supply yourself. App Service’s patching guidance says a custom runtime remains unchanged unless you upgrade it; new major and minor built-in runtime versions can also require a manual upgrade. (learn.microsoft.com)
Consider SaaS when the business needs an application rather than a software-development project. Test whether the product’s available workflow, permissions and integrations fit the actual work. Do not reject it merely because your team could build an alternative.
A useful starting recommendation is: evaluate SaaS for functional fit, then PaaS for necessary custom development, then IaaS for demonstrated infrastructure constraints. This is a selection method, not a universal ranking.
4. Worked example: a small-business customer-tracking application
Consider this hypothetical requirement—not a measured deployment or customer case study.
A small business needs staff to record customer enquiries, maintain contacts, track sales opportunities and review progress. Assume:
- The workflow is not yet proven to require custom software.
- The business can adapt nonessential processes.
- Staff need controlled access to customer information.
- Development capacity exists, but routine server administration has no dedicated owner.
- Data export, recovery and integration requirements still need validation.
Compare three ways to deliver the same business outcome.
Option A: run a custom application on virtual machines
The team develops or acquires the application and installs it on VMs. Azure Virtual Machines provides environment control, while the customer maintains the VM’s software. (learn.microsoft.com)
Decision: Do not choose this merely because it is familiar. Under these assumptions, the missing server-maintenance owner is a reason to pause. Reconsider IaaS if an essential software dependency requires it and the business assigns operational support.
Option B: deploy a custom application to a managed platform
The team builds the required workflow and evaluates a supported App Service stack. App Service supplies the application-hosting platform; the team still owns its application and data. (learn.microsoft.com)
Decision: Prefer investigating this route if an essential workflow cannot be met by an existing product. Validate the application’s runtime and dependencies, then identify the separate data-storage service and its responsibilities.
PaaS is not an exemption from application maintenance. Budget for development, testing and supported-version upgrades.
Option C: configure an existing SaaS application
Dynamics 365 Sales is one concrete product to evaluate: its documentation describes account and contact management and sales tracking from lead to order. That establishes relevant functionality, not suitability or affordability for this hypothetical business. (learn.microsoft.com)
Decision: Evaluate SaaS first under the stated assumptions. Use fictional records to test the actual workflow, permissions and reporting. Verify the chosen edition’s integrations, export behavior and commercial terms.
The key distinction is that SaaS would replace the proposed custom application, not host its existing code.
The resulting decision is conditional:
- If SaaS passes the essential requirements, configure it.
- If it fails because distinctive application behavior is essential, evaluate PaaS.
- If the custom workload requires unsupported environment control, evaluate IaaS with an explicit operating plan.
No savings or performance advantage can be established from these assumptions alone.
5. Evaluate customization and portability separately
Customization asks: Can we change what the system does?
Portability asks: Can we move the workload or usable business information elsewhere?
Do not treat them as the same benefit. NIST’s portability guidance identifies standardized interfaces and data formats as important, while noting that even IaaS can face compatibility obstacles. A VM is not automatically a provider-independent workload. (nvlpubs.nist.gov)
Use different checks for each candidate:
| Model | Customization check | Exit check |
|---|---|---|
| IaaS | Does the required software run in the selected environment? | Can you reconstruct compute, networking, storage and identity elsewhere? |
| PaaS | Are the required runtime, dependencies and behaviors supported? | Which platform APIs and configuration mechanisms need replacing? |
| SaaS | Can supported configuration and integrations meet the workflow? | Can another system interpret exported records, attachments and relationships? |
For a custom application, document platform dependencies rather than assuming that possession of source code is enough.
For SaaS, request an export demonstration using fictional records. Inspect whether it preserves identifiers, relationships, timestamps and attachments. Ask separately about configuration and audit-history export.
Treat portability as something to demonstrate. A successful download is useful evidence, but your acceptance test should be whether the information can support a realistic migration.
6. Compare complete operating cost and recovery obligations
Compare equivalent outcomes—not a VM price against an application subscription without accounting for the surrounding work.
Azure’s VM documentation notes that supporting resources have their own costs. The machine’s compute charge is therefore not the complete deployment estimate. (learn.microsoft.com)
Build a comparison worksheet covering:
- Service charges and applicable usage allowances.
- Storage, networking and supporting services.
- Implementation and integration work.
- Maintenance, monitoring and support labor.
- Test environments and change validation.
- Recovery arrangements.
- Migration and eventual exit work.
Use current quotations and pricing documentation for the exact region, service tier and product edition. Do not assume one model is always cheapest.
Reliability also requires service-specific review. Microsoft’s guidance distinguishes provider platform reliability from customer decisions about reliability features and application design. It also says customers must understand and meet applicable service-level agreement conditions. (learn.microsoft.com)
Define acceptable downtime and data loss before choosing. Then verify available recovery mechanisms, retention, restoration scope and who performs recovery.
For VMs and custom applications, rehearse recovery in a separate environment. For SaaS, request evidence of supported recovery procedures and test the customer-accessible process where possible. Record anything that remains unverified.
7. Use a selection checklist—and catch common mistakes
Before approval, require answers to these questions:
- Business fit: Which requirements are mandatory, and which are preferences?
- Environment fit: Does the workload genuinely require operating-system control?
- Ownership: Is every retained operational task assigned to a named role?
- Security configuration: Have access, sharing and customer-controlled settings been reviewed?
- Recovery: Is there a documented, verifiable recovery path?
- Integration: Have essential connections been tested with representative fictional data?
- Exit: Have export or reconstruction procedures been demonstrated?
- Cost: Does the estimate include implementation and ongoing labor as well as service charges?
Watch for these decision mistakes:
- Choosing IaaS for hypothetical flexibility. Require a specific constraint that justifies the additional operating work.
- Treating PaaS as maintenance-free. Identify application dependencies and upgrade owners.
- Treating SaaS as administration-free. Document account management, configuration approval and data-handling procedures.
- Assuming backups meet the recovery requirement. Ask what can be restored, to which point, and through whose action.
- Comparing unlike solutions. Apply the same functional, security and recovery requirements to every option.
- Calling an untested exit plan “portable.” Record the demonstrated steps and remaining gaps.
Finish with a short decision record: selected model, essential requirements, rejected alternatives, named owners and unresolved checks.
Choose by the work your team must reliably perform—not by the number of infrastructure settings it can control.