You inherit a seven-year-old analytics estate on one cloud platform and are asked how locked in the company actually is — how do you answer with an inventory instead of a feeling?

## The question behind the question When a new owner asks "how locked in are we", they are not asking for a philosophy of portability. They are asking for a number they can act on: is leaving something we could do in a quarter with a budget, or is it effectively off the table for the next several years? An answer of "very" or "not too badly" is unusable. The deliverable is an **inventory**: four rows, each with a unit and a rough magnitude, and an explicit statement of which row dominates. ## The four rows and what to count in each | Dimension | What you count | Unit | Where the number comes from | |---|---|---|---| | Technical | call sites in application code that reach a proprietary interface, split into those with an equivalent elsewhere and those without | call sites, then engineer-months to rewrite and retest | a search of the code, not a list of capabilities in use | | Data | stored volume that survives expiry, times the per-gigabyte charge, the sustained throughput out, and the effort to extract it | gigabytes, then money and weeks | storage inventory plus a measured export rate, not an assumed one | | Operational | how many engineers could run a different platform unaided, and how long the rest would need | engineer-months of relearning, expected incident-duration penalty | an honest conversation with the on-call rota | | Commercial | months and money still to run on any term commitment | months, and the remaining obligation | the contract, not the invoice | ## How to run it 1. **Count call sites, not capabilities.** "We use eleven managed capabilities" says nothing. One proprietary interface called from three places is a week; another called from four hundred is a year. Split the count by whether a broadly implemented equivalent exists, because those two halves have completely different costs. 2. **Net the data down before you price it.** Ask what fraction of the stored volume is past its retention or read by nothing. In a seven-year-old estate the honest answer is usually most of it. Price only what would actually move. 3. **Measure throughput rather than assuming it.** Run a real export of a slice and extrapolate. This single step is what turns a wrong estimate into a defensible one, because elapsed time is where the largest errors live. 4. **Put a number on the people row.** It feels unquantifiable and it is not: how many engineers have operated anything else, what the rota would look like during the relearning period, and how much longer the same incident takes when nobody recognises the failure mode. 5. **Read the contract for the end date.** The commercial row is the easiest to get exactly right and the one most often left out. A commitment with a long tail can make the whole question moot until a known date. ## What an old analytics estate usually shows An estate that has been accumulating for seven years usually has a **narrow code surface and an enormous data surface**. The reporting jobs tend to call a handful of interfaces, several of which have equivalents elsewhere, so the technical row is smaller than people expect. The data row is the opposite: volume has grown every day as a side effect of the system working, nobody set a retention policy, and the unit move cost is dominated by elapsed time rather than by the charge. The operational row is usually second, because seven years produces a team whose entire operating intuition is one platform's. This is a tendency, not a law — an estate whose analytics were written against one proprietary interface in every job inverts it — which is exactly why you count rather than assume. ## Ranking, and why it is the point The ranking is what makes the inventory actionable. If the data row dominates, the highest-value work has nothing to do with code: it is retention, and keeping one readable copy. If the code row dominates, it is an engineering plan. If the people row dominates, it is hiring and training and probably a slower move. If the contract row dominates, the answer is simply a date. Presenting four unranked numbers invites everyone to fix the row they personally find most interesting. ## Where the inventory stops An inventory says what binds you and how much. It is deliberately **not** three other things: it is not a costed migration with a sequence, a cutover and a dual-running window; it is not a recommendation to leave, since most estates that are inventoried never move; and it is not a vendor comparison, since nothing here scores an alternative platform. Keeping those apart is what lets you present the inventory without it being read as a proposal.