Platform and integration
SaaS
Software as a Service
Software as a Service is a delivery model where the vendor builds, hosts, patches, and operates the application, and the customer accesses it through a browser, a thin client, or an API rather than installing and maintaining it on their own infrastructure.
Why SaaS matters in a Microsoft estate
SaaS matters because integrations, APIs, virtual machines, and delivery pipelines are how Microsoft estate data and automation become usable. These terms help readers understand how systems connect before they decide what to build or automate.
How SaaS shows up in practice
The customer pays on a subscription or usage basis instead of buying a perpetual licence and running the software themselves. This shifts a meaningful set of responsibilities away from the customer: there is no server to patch, no database to back up, and no infrastructure capacity to plan for. Version upgrades also roll out to every customer on the vendor's release schedule, rather than requiring an internal project to plan and test an upgrade. Microsoft 365 itself is the clearest example most IT teams work with daily.
The same model underlies most of the modern tooling layered on top of it, including cost optimisation, licence management, and tenant reporting products that connect to a customer's tenant through Graph and Azure APIs rather than being installed inside it. That distinction between SaaS and installed software matters practically when evaluating a vendor. A SaaS product's total cost of ownership includes the subscription price but not separate infrastructure, patching, or backup effort on the customer's side. A Win32 desktop application, such as an application packaging tool that runs on an engineer's own machine against local and captured application data, keeps deployment and update control with the customer instead, and avoids sending source application data to a third-party service.
This is a deliberate trade-off some vendors make for exactly that reason, rather than an oversight. Because a SaaS provider holds customer data and, for products acting against a Microsoft tenant, often holds standing API access to that tenant, the questions worth asking before adopting any SaaS tool in a Microsoft 365 or Azure estate go beyond price and features.
Those questions include where data is hosted and processed, whether the vendor's terms confirm customer data is not used to train models, what certifications the vendor holds such as ISO 27001 or Cyber Essentials, how multi-tenant access is isolated so one customer's data cannot leak into another's view, and what happens to data on contract termination. For MSPs specifically, SaaS multi-tenancy is also an operational advantage rather than only a risk to manage. A properly built multi-tenant SaaS platform lets a partner apply the same cost, security, and reporting workflow consistently across every managed customer from one login, rather than each customer needing separately hosted and separately maintained instances. This is the scaling problem SaaS was built to solve in the first place.