---
title: "Cloud Strategy prices lock-in instead of fearing it"
description: "Gregor Hohpe treats cloud lock-in as a decision with a price on both sides, and a migration becomes a set of choices about which lock-in to accept on purpose."
url: "https://michael.zazon.us/notes/cloud-strategy-prices-lock-in-instead-of-fearing-it"
published: "2026-01-08T12:00:00-05:00"
kind: "book-notes"
subject: "architecture"
tags: ["strategy","decisions","cloud"]
---
We usually talk about lock-in as something to be avoided, full stop. But one idea I think is worth keeping from [Cloud Strategy](https://leanpub.com/cloudstrategy) by Gregor Hohpe is that it shouldn't always be treated that way.

That book (Leanpub, 2020, still being updated) describes itself as a decision-based approach to cloud migration. The chapter "Don't Get Locked Up Into Avoiding Lock-In" was first published as an [essay on martinfowler.com](https://martinfowler.com/articles/oss-lockin.html). It argues that lock-in comes in degrees and has a price. There are many kinds of lock-in: vendor, product, version, architecture, platform, skills, legal, and mental. Open source mostly addresses the vendor kind, but leaves the others untouched.

This model prices both sides of the decision: the likelihood and cost of switching, and the unique utility of the locked-in choice that you forfeit by staying generic. When the utility is high and the switching cost is high, lock-in is something you may want to accept deliberately. When the utility is low and the switching cost is high, you need to look hard. Avoiding lock-in has its own costs: the effort to build the abstraction and the new dependency on the layer you own. Hohpe says complexity may be the biggest cost. "Minimizing switching costs may not be the most economical choice."

I think the most common overpayment is the speculative abstraction layer for a migration that never comes. You pay for it every day, and it only pays off on the day (if ever) you migrate. My other view is that the lock-in that nobody puts a price on is skills and organization. Choosing a platform for its portability is still lock-in, to the platform and its experts. That reframing prompted me to ask: how many portability decisions have I priced, and how many have I assumed come for free?

This turns a cloud migration back into a decision problem, with technology choice following decisions. For each component, ask what lock-in you accept and why. Record it while it's still a choice and the switching cost is easy to estimate. One last question: Does lock-in that you drifted into ever get priced before you need to exit?