Exit Cost
Exit cost is the money, time, and effort an organization would spend to move off a platform, product, or supplier and onto something else. It is the cost that makes lock-in real: GOV.UK’s guidance describes lock-in as a situation where switching from one technology or provider to another is difficult, time-consuming, and disproportionately expensive, and advises putting estimated exit costs and time into the business case.
What it is made of
Exit cost is easy to reduce to the charge for moving data out. That charge is real, but for a data platform it is only one component. The breakdown below is a working checklist rather than a standard taxonomy:
| Component | What drives it | An example of the kind of fact to check |
|---|---|---|
| Moving data | Volume, regions, clouds, and transfer pricing | Snowflake documents transfer charges for operations such as COPY INTO <location> across regions or clouds, while client or driver retrieval of query results has a stated egress-fee exception. Check the actual operation, source and destination, provider charges, and contract |
| Rewriting logic | SQL dialect, stored procedures, proprietary functions, data type differences | Microsoft’s Synapse-to-Fabric migration guidance notes that some T-SQL may need rewriting and that converting datetimeoffset to datetime2 loses the time zone offset |
| Rebuilding operations | Monitoring, access control, cost controls, scheduling, and runbooks built around the old platform | How many alerts, roles, and budgets reference product-specific objects |
| Running both | How long the old and new systems must operate side by side until results match | The reconciliation criteria and who signs off |
| Contracts | Commitments, notice periods, and discounts that lapse | GOV.UK advises estimating exit costs as they would be after negotiated discounts or benefits have lapsed |
| People | Skills tied to one product and the productivity dip while teams relearn | GOV.UK counts skill gaps among the causes of technical lock-in |
Why it gets left out
Selection discussions tend to emphasize the proposed acquisition and operation. Exit can be planned around contract expiry or a deliberate replacement, or become urgent after a price change, acquisition, or unmet requirement. Urgent exits can face tighter time and resource constraints; estimate both planned and contingency scenarios. A total cost of ownership model should state its horizon and treatment of exit. Omission can hide a material obligation; identify any excluded scenario rather than silently treating it as free.
Estimating it well enough
Use the precision the decision and evidence support. An early order-of-magnitude range with an owner for each assumption may be enough to compare options; a larger commitment may justify migration trials and more detailed estimates. In an invented example: 40 TB to move across clouds, around 600 SQL objects of which a sample shows one in five uses product-specific features, and an expected three months of parallel running. Each number can be challenged and refined, and it would be hard to leave becomes a figure someone is accountable for.
- Sample, don’t guess. Run a small part of the real logic and data through a different engine and count what breaks.
- Know what design choices do and don’t reduce. Open table formats can reduce conversion work or let another compatible engine read retained data. They do not automatically reduce transfer volume, network charges, or destination operating costs. Snowflake documents cross-region and cross-cloud Iceberg operations that incur transfer charges. Test feature and catalog compatibility; procedures, operational tooling, and skills still need separate migration work.
- Accept some of it on purpose. GOV.UK notes that accepting some lock-in can let teams deliver faster and build a less complex service. The point of estimating exit cost is to make that trade knowingly.
Turning the estimate into a tested plan with an owner is the subject of portability and exit plans. How exit cost fits into comparing data platforms is worked through in Choosing a Data Platform: What to Compare When the Feature Lists Match.
References:
- GOV.UK, Managing technical lock-in in the cloud
- Snowflake Documentation, Understanding data transfer cost
- Microsoft Learn, Migration Strategy and Planning for Azure Synapse Dedicated SQL Pools to Fabric
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.