I read elsewhere that because it was such a big and complex account there was some manual elements involved in the original accounts creation. It was that manually set configuration that eventually led to this clusterfuck and why it was a "one off" event - such things aren't done or allowed anymore. So my guess is that some engineer years ago either bypassed or failed to set some flag(s) that the normal tools would configure.

There is one fundamental difference and that's the management of the server configuration and the data it controls. On premises it's your own staff, on cloud it's not google staff, it's a few thousand lines of python and yaml or whatever. Someone makes a change, tests it against their test data, gets all the green OKs and pushes it to production. And it promptly screws over a handful of customers whose systems need special attention and processes not properly documented.

I had this happen to me twice. We have very simple requirements, defaults are usually good enough, but we have the problem that once it's set up we rarely have to talk to the hosting company. It just keeps on trucking. And so nobody is looking at all that old configuration data. And it's all good until their IaaS platform needs updating and we find out that our defaults are not the current defaults and oh shit, your config is hosed.

This is the reason I want to get away from a managed service. Because their management is concerned about different things to our management and move-fast-and-break-things is at odds with our do-it-once-and-use-it-forever approach.