Almost nobody who computes their cloud exit cost goes on to exit. That is not an argument against computing it. The number tells you how much optionality you have, and optionality is what you are actually negotiating with at renewal.
The four components
Data egress. The obvious one. Total data to move, at the published egress rate, less whatever free allowance applies. For large datasets this is a material number on its own, and it is the component providers have adjusted in response to regulatory pressure — check the current terms rather than what you remember.
Rebuild of managed services. The expensive one. Every managed service you use has to become something you run. A managed database becomes a database plus a team. A managed queue, a managed identity service, a managed key store: each is a project, and collectively they are the migration.
This is where the real lock-in lives, and it does not appear on any invoice.
Parallel running. You cannot switch instantaneously. There is a period where both environments exist and both are paid for, and it is usually longer than planned.
Destination capacity. Somewhere has to receive it. Hardware, colocation, or another provider. Capital or commitment, plus lead time.
Why the exercise is worth doing
It prices lock-in accurately. Everyone knows lock-in exists; almost nobody has a number. Once you have one you can decide whether it is acceptable, and you can see which specific services are driving it.
Frequently two or three managed services account for most of the cost, and those are the ones worth building an abstraction around or replacing with something portable. That is an actionable finding.
It changes renewal conversations. A customer who has quantified the alternative negotiates differently from one who has not, and the other side can tell which they are dealing with.
It informs architecture now. If exit cost is dominated by one service, that is a design input for the next workload.
How to run it quickly
List the managed services in use, by workload. For each, estimate the effort to replace it with something self-operated, in person-months. Be rough; the ranking matters more than the precision.
Add egress at current data volumes. Add six months of parallel running. Add the destination capacity.
You now have a number with an error bar. Publish it internally with the assumptions visible, which is the same discipline as everywhere else.
The related number
The other direction is worth computing too. If you are on premises and considering cloud, what is the cost to go and the cost to come back? An organisation that knows both is making a reversible decision. One that knows only the cost to go is making a one-way one and calling it a strategy.
What I would not do
I would not use this as an argument against cloud. Lock-in is a cost, not a disqualification, and every platform has some. On-premises infrastructure has lock-in too; it is just denominated in hardware and skills rather than APIs, and nobody calls it that.
The point is to know the number. An organisation that has computed it and decided the lock-in is acceptable has made a decision. One that has never computed it has made an assumption.