Direct answer
From a systems administrator's chair, the IaaS-to-SaaS ladder isn't a technical abstraction exercise, it's a description of which daily tasks disappear or move to a different team at each step, starting with patching and ending with almost the entire job shifting from "keep the infrastructure running" to "manage user access and vendor relationships."
IaaS: the starting point
Example services: AWS Elastic Compute Cloud (EC2), Azure Virtual Machines.
The sysadmin still owns OS patch management: choosing a patch cadence, testing patches, and applying them across the fleet, exactly as with on-premises servers, just on rented hardware. The monitoring and backup implication is direct: you must build and maintain your own OS-level and application-level monitoring and backup jobs, since the provider guarantees the underlying hardware and network, not that your specific virtual machine's disk gets backed up or that a runaway process gets alerted on. A sysadmin moving from on-premises to IaaS who assumes "the cloud backs things up for me" is making the single most common early mistake in this transition.
PaaS: the first real shift
Example services: Azure App Service, Google App Engine.
OS-level patch management moves entirely to the provider. The sysadmin's job shifts from "patch the box" to "verify the platform's automatic runtime and OS updates haven't broken application compatibility," and to managing deployment configuration and scaling policy instead of server configuration. The monitoring and backup implication: infrastructure-level monitoring, is the OS healthy, is disk full, is now the provider's concern, so monitoring effort moves up the stack to application-level health checks and request and error-rate metrics. For backup, "backing up a server" stops being a meaningful task, since there's no persistent server to back up, and the real backup concern moves entirely to whatever managed database or storage the application actually uses.
SaaS: the full shift
Example services: Salesforce, Google Workspace.
There's no infrastructure left for the sysadmin to touch. Operational responsibility shifts to identity and access management, who has an account, what permissions they hold, how quickly access is revoked when someone leaves, and to vendor management, tracking the vendor's service-level agreement (SLA) commitments and uptime history. The monitoring and backup implication: "monitoring" becomes watching the vendor's status page and your own usage and license metrics rather than any system you operate, and "backup" becomes verifying, often by actually testing it rather than trusting a marketing claim, that the vendor's own data-export or retention policy actually meets your organization's recovery needs, since you generally have no independent backup mechanism of your own unless you build one on top of the vendor's export capabilities.
Worked example: a sysadmin's week, across the shift
Under IaaS, a real chunk of a sysadmin's week might go to reviewing patch reports and confirming backup jobs completed successfully across a virtual machine fleet. After a move to PaaS for the same application, that time gets reallocated to reviewing application-level error-rate dashboards and adjusting an autoscaling policy, since there's no OS layer left to patch. After a further move of an adjacent capability, internal email for example, to a SaaS product, the equivalent time goes to a quarterly access review, confirming former employees' accounts were actually deactivated, and confirming that the vendor's exported backup of mailbox data can actually be restored, since that's now the only backup lever left.
Trade-offs and pitfalls
The pitfall specific to this transition is treating it as "less work" rather than "different work." A SaaS-era sysadmin still carries real, auditable responsibility: identity governance, vendor SLA tracking, and verified export or backup capability. An organization that lets go of headcount assuming "SaaS runs itself" typically discovers the gap first during an access-related security incident or a data-recovery request that the vendor's default retention policy doesn't actually cover.
