TL;DR
Portability is a plan you can execute, not an architecture you pay for every month.
Two different goals
People say "multi-cloud" for two reasons that are easy to confuse. One is running across providers all the time, so that an outage in one doesn't stop you. That's expensive, complex and right for a few organizations. The other is being able to leave a provider if you have to, because of price, policy, a dispute or an outage that won't end.
Most businesses need the second. It costs far less.
What an exit plan contains
What you run, and where. A list of every service, database and storage location, with the provider and the owner.
Where the data lives and how to copy it out. Your data is the hardest thing to move. Know its size, how long a full export takes, what it costs to transfer, and whether you have a recent copy outside the provider.
What you've tied yourself to. Proprietary databases, queue services and serverless features have no direct equivalent elsewhere. List them and note what each would be replaced with.
Infrastructure as code. If your environment is defined in code, rebuilding it elsewhere is a project. If it was set up by clicking, it's an archaeology exercise.
A target and a timeline. If you had to leave, where would you go and how long would it take? Even a rough answer beats none.
What to do this month
- Write the inventory. One page. If it takes more than a day, that's a finding.
- Keep an independent backup. In a different account, ideally a different provider. Test restoring from it.
- Time a full data export. Measure the hours and the egress cost.
- Mark the lock-in points. The three hardest things to replace.
- Put the plan on a calendar. Review it every six months, and after any big architecture change.
Original analysis by Upfinity.
More in Cloud
Want help applying this?
We build AI-native software for teams navigating exactly this kind of shift.
Start a conversation