> Moreover, the costs were predictable: for a given year and # of users, you knew exactly what you’d be spending for that level of support. No surprises. No unexpected weeks of having a developer doing nothing but troubleshooting a failed migration on a team-essential service.

This just doesn't hold for SaaS. That's the promise of SaaS, but again, IME, it is not how it happens.

I spend a fair portion of my time … I'd say ~1h / week, sometimes 0 but sometimes >>0 … dealing with SaaS systems not behaving the way they ought to. But unlike "owned" systems, often I'm stuck playing support ticket monkey — if the SaaS even has a function support system — and trying to get somebody else to care enough to look, often trying to get somebody else to care who you have to influence indirectly through some "customer success manager" who cares only about closing this ticket as soon as a technicality¹ will permit.

To me, SaaS & owned are nigh identical in this respect: it boils down to the quality of the actual thing at hand. Some owned systems I've used are rock solid: they do their thing, they're more or less bug free, they consume essentially none of my time. But some owned systems are just a time drain. SaaS is the same way: some are rock solid (I'd put S3 in this category) and some are simply not; I know a good number of my support tickets correlate to the same system.

¹Particularly version churn: "we have problem X" → "oh, you're not on the latest version of the SaaS ticket closed → we upgrade → we reproduce X on the new version → refile the ticket → "oh you're not on the latest version of the SaaS".