The Bit Shift

The Universal Remote

The Universal Remote

Stop architecting for a cloud migration you will never actually do.


The Board wants “optionality” because they are terrified of pricing power. They want to hear that we can switch clouds over the weekend. It sounds like prudent risk management. It is actually the most expensive insurance policy in the history of IT. We are attempting to build an “Esperanto” layer for our infrastructure. We want a universal language that abstracts away the differences between the clouds. The problem with Esperanto is that nobody actually speaks it. When you force your engineering team to write generic code that runs everywhere, you ensure it runs poorly everywhere.

You are paying for a “Universal Remote” that only supports the Power button. By refusing to use the proprietary features of your cloud provider you are paying the premium price for the platform but utilizing only the commodity features. You are effectively shorting your own execution speed to hedge against a vendor pricing change that is statistically unlikely to kill you. This isn’t architecture. It is financial anxiety masquerading as strategy.

Please Stop Architecting for a Cloud Migration You Will Never Do

The irony is that you are crippling your velocity today to solve a problem that is rapidly disappearing. If the day comes when you actually need to leave AWS then AI agents will likely be able to refactor your proprietary calls into Azure SDKs in an afternoon. The cost of code translation is trending toward zero. You are optimizing for a future where migration is hard but we are moving toward a future where it is trivial.

We often point to 37signals leaving the cloud as proof that we need this agility. But they didn’t move because they had a perfect abstraction layer. They moved because they did the math on renting versus owning. That was a capital allocation decision for a stable business. It was not a feature of their code. Most of us are not moving to a datacenter. We are just moving sideways to another landlord.

The real “Vendor Lock-in” isn’t code. It is data. Data Gravity dictates that where your petabytes live is where your applications live. Moving that mass is a multi-year logistical nightmare. It is not a configuration change. The abstraction layer you are building is solving the easy problem while ignoring the hard problem. Stop hedging. Pick a cloud. Commit to it. “Lock-in” is just another word for “Leverage.”

CloudArchitecture VendorLockIn SoftwareArchitecture