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’re terrified of pricing power. They want to hear that we can switch clouds over the weekend. It sounds like prudent risk management. It’s actually the most expensive insurance policy in the history of IT. We’re 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’re paying for a “Universal Remote” that only supports the Power button. By refusing to use the proprietary features of your cloud provider you’re paying the premium price for the platform but utilizing only the commodity features. You’re effectively shorting your own execution speed to hedge against a vendor pricing change that’s statistically unlikely to kill you. This isn’t architecture. It’s financial anxiety masquerading as strategy.

Please Stop Architecting for a Cloud Migration You Will Never Do

The irony is that you’re crippling your velocity today to solve a problem that’s 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’re optimizing for a future where migration is hard but we’re moving toward a future where it’s 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 wasn’t a feature of their code. Most of us aren’t moving to a datacenter. We’re just moving sideways to another landlord.

The real “Vendor Lock-in” isn’t code. It’s data. Data Gravity dictates that where your petabytes live is where your applications live. Moving that mass is a multi-year logistical nightmare. It’s not a configuration change. The abstraction layer you’re 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