Cloud is amazing for highly variable loads. I also see it as a bit of a luxury service for ops types (like me) - I don't have to go to a DC and manage hardware or deal with a DCops crew, so that's nice, but you probably wouldn't buy luxury cars if you were starting a courier business.
Everyone's locked into a vendor at some level or another. Want to move off of Oracle? It's work. Want to move off of servers and into VMs? It's work. Do you want to move off of some Java library like Spring? It's work. Even moving from apache to nginx is work (assuming you're not just serving static files).
Your technology choices always lock you in. You can minimize the cost of moving with architecture, but there's only so much you can do.
The key isn't avoiding vendor lock-in, it's understanding what the tradeoffs are for that lock-in and making sure it's a decision instead of a by-product.
It's like writing your stuff in NEW_TECH_LANGUAGE. Sure it might give you better performance, but now you have a bunch of deployment and maintenance headaches, and your people will cost more and be harder to find. And does it even work/scale in production/HA? How do you monitor it? What kind of weird runtime things are you going to get abused by?
I do spend a fair amount of time and effort trying to keep my company nimble; we try to use open source software and generic cloud primitives so we can move with some ease if need to. As you say, it is all work.
I wouldn't be surprised if Oracle or any outsourcer did that...but that implies a breach of contract, not a transition after a contract is done.
IBM sells mainframes because they're impossible to replace due to the way they're used. Those big printers that print financials statements apparently don't talk to anything else (funny, I was just talking about those the other day). It's about I/O and throughput with those things. You'd think someone would have come up with a replacement, but presumably the market is so small that nobody cares.
Some can do it, some require you to basically image the entire machine onto a new one, some can't handle it at all.
First, changing out the CPU type to something that isn’t almost identical out from under a running VM is a mess and may require degrading the system by removing features from the starting CPU. Switching manufacturers at runtime (AMD vs Intel), while sort of possible in theory, is effectively a lost cause.
To add CPUs, you have to deal with the architecture’s nasty hot-add CPU mechanism, and the guest OS needs to be expecting those CPUs starting from when it boots, and that expectation isn’t free. (The latter is Linux’s num_possible_cpus vs num_present_cpus.)
Adding memory involves getting that memory into the kernel’s memory map in the right places. This is more complex than one would like. Removing memory is worse.
And all this happens, in the cloud data center, on essentially normal hardware. If you want to add RAM, the CPUs need to be on a system with more RAM, preferably on the same NUMA node. And vice versa for adding CPUs. If the tenant is paying for local storage, that needs to move, too.
The thing that really pissed me off is when a cloud provider is UNABLE to add more CPU and RAM on reboot. I even understand having to migrate the instance disks to another host that has CPU/RAM available.