KuppingerCole Analysts estimate the service attachment rate for Identity Governance and Administration (IGA) deployments at six to ten times the license or subscription cost. That figure covers getting the tool in. Nobody budgets a comparable number for getting it out again, because almost nobody asks the question before signing: how do we get rid of this again?
That question deserves more weight in any tool decision, across IT generally and identity and cybersecurity specifically, even though it is one consideration among several rather than the one asked first. Every tool decision creates two kinds of barrier: an entry barrier, the cost and effort of getting a tool in, and an exit barrier, the cost and effort of getting it out again. Organizations routinely price the first. The second stays unexamined, or in some cases is quietly ignored, because looking at it closely would complicate the case for buying in the first place.
The reasons for skipping the question are understandable, even if they are not good reasons. Investments have to be justified, and “this is a tactical choice we may replace in three years” does not help a budget approval move forward. Implementation itself carries cost, switching carries cost again, and every new tool demands training that the second question makes look wasted before it has even started. None of that makes the avoidance defensible. It only makes it explainable.
Two Risks, Not One
Lock-in gets discussed as a single problem. It is at least two, and they respond to different remedies.
The first is contract leverage. It determines how short a contract term you can negotiate, how favorable an exit clause you can secure, and how much audit and negotiation power you retain once the contract is signed. This matters because your practical ability to leave a tool is not fixed by the tool itself. It is partly set by how much negotiating power you had on the day you signed, and that power scales with the buyer’s own size and market position relative to the vendor. A large enterprise negotiating with a mid-size vendor typically has more room here than a smaller buyer facing a dominant vendor.
The second is data portability, and it does not scale the same way. A vendor’s willingness to grant a favorable exit clause is worth little if the underlying data model, export formats, or API access make actual migration difficult by design. Size and negotiating skill do not fix a closed data model. If portability turns out to be difficult once you look closely, that alone is reason for caution, independent of how good the contract terms otherwise look.
Due diligence that treats these as one question tends to solve the easier one, the contract, and miss the harder one, the data.
The Switching-Cost Myth, With a Real Exception
Switching cost is frequently overestimated in a specific way: organizations assume the second implementation of a tool category costs close to what the first one cost, because the first one required steep training and unfamiliar concepts. It usually does not. A lot of what was learned carries over. Roles, policies, and integration inventories built for the first tool are largely reusable for the second, and the mistakes made the first time round become exactly the lessons that make the second implementation better, not a debt that has to be repaid again.
IGA benefits from this effect as much as any other category. A second implementation reuses role models, access policies, certification workflows, and the integration inventory built for the first, and it avoids the governance mistakes that took years to surface the first time round. None of that has to be redone from a blank sheet.
What it does not avoid is the scale of the exit barrier itself. IGA implementations commonly run as multi-year projects, and replacing one is a multi-year project again, which is exactly why the six-to-ten-times attachment rate matters: learning effects shorten the project, they do not make a deeply embedded identity or infrastructure tool cheap to leave. Understanding where a given tool sits on that spectrum has to happen before the purchase, not at renewal, when the vendor holds most of the useful information about how hard leaving will actually be.
Bigger Is Not the Same as Safer
The instinct to manage this risk by choosing the largest, most established vendor available is itself worth questioning. Dominant vendors change roadmaps. They discontinue products, force customers onto new licensing models, or get acquired and adjust terms unilaterally. A buyer with no exit plan is exposed to those decisions regardless of how strong the vendor’s market position looked at signing.
Exit readiness is not only protection against your own future regret. It is protection against choices the vendor makes that you do not control.
Not Every Tool Deserves the Same Scrutiny
The same logic applies regardless of the deployment model: on premises, cloud, or AI service. What looks like the preferred tool today may not hold that position for long, and the market for AI tools makes the point concretely. A year ago, the default assumption in many organizations pointed to one large language model provider; today it may point to another, and this is unlikely to be the last shift. The faster a category evolves, identity and cybersecurity tooling included, the more costly it becomes to stay locked into yesterday’s choice.
That does not mean applying equal scrutiny everywhere. A public sector body that spends its political capital moving off one office suite and onto another is solving the easy problem. Office tools are comparatively straightforward to replace. The switch that actually determines whether an organization can adapt to what comes next sits in its core business applications, its infrastructure, and its identity and cybersecurity stack, where sophisticated data and access models make replacement genuinely difficult. Scrutiny should track that difficulty, not the visibility of the decision.
Deliberate lock-in, chosen with the question already asked and answered, is a reasonable outcome. It stops being reasonable the moment the question was never raised at all.
Before signing anything, this should be standard practice:
- Separate the contract question from the data question. Negotiate exit terms based on your position relative to the vendor, and test data portability on its own merits regardless of how favorable those terms look.
- Ask for the export path before you need it. A documented, testable data export process at onboarding is worth more than a promise buried in a termination clause.
- Do not treat vendor size as an exit strategy. A dominant vendor’s roadmap changes and acquisitions are risks you carry whether or not you ever plan to leave voluntarily.
- Match scrutiny to switching difficulty, not visibility. An office suite decision and a core identity platform decision do not deserve the same amount of exit analysis.
- Price the second implementation honestly, factoring in what carries over and what does not, rather than assuming it costs what the first one did.
- Treat a knowingly accepted lock-in as acceptable. The problem was never lock-in itself. It was never asking.
None of this makes switching free, and none of it argues against tools that come with some degree of attachment; every solution has some. It argues for knowing the size of that attachment before you accept it, not after a renewal notice arrives with a number attached that nobody planned for.
If your organization cannot answer how it would leave a given tool today, that is not a minor gap in the paperwork. That is the actual risk profile of the decision, and it was there from day one.
This is exactly the kind of due diligence question we work through with clients in KuppingerCole’s advisory practice on identity, cybersecurity, and AI tool selection.
