Glossary

Switching Costs

Everything it would actually cost to move from one supplier, platform or partner to another: migration, retraining, parallel running, integration rework, and the risk of the move itself. The number that decides who holds power at renewal.

Your supplier has a better estimate of your switching costs than you do. Their renewal pricing is that estimate, expressed as an invoice.

Last reviewed 3 July 2026 · Free and ungated

Review this before committing

Before a renewal or replacement decision, operators who have run these migrations can tell you which costs are real and which are the incumbent's bluff.

Review this before committing

How a client brief works · What you receive

What counts as a switching cost

Switching costs are the total burden of changing supplier or platform: data migration and cleansing, integration rebuilds, licence overlaps during parallel running, retraining, productivity loss during transition, contractual exit charges, and the management attention the move consumes. They also include risk, the possibility the migration itself fails, which is a cost even when it never materialises.

The asymmetry vendors understand better than buyers

Buyers estimate switching costs occasionally, under duress, when a relationship has already soured. Vendors model them continuously, because the gap between your cost to leave and their price to stay is their pricing corridor. A supplier will happily concede margin at initial sale to build switching costs, deep integration, proprietary data structures, embedded staff, and recover it across years of renewals priced just below your pain threshold. For decision preparation this cuts in both directions: an artificially low switching estimate flatters a stay-put decision, and an inflated one is the incumbent's favourite argument.

Estimates that miss the real barriers

  • Counting migration and licences while omitting the year of internal attention the move consumes.
  • Assuming data will transfer cleanly, when nobody has tested an export against the new schema.
  • Ignoring the integrations other teams built against the old platform without telling anyone.
  • Treating switching cost as fixed, when staging the exit or dual-running can change it materially.

The incumbent knows your cost to leave. Do you?

Review this before committing