SailPoint is the enterprise standard for identity governance, and it is built for that market. For a team of 50 to 2,000 people, the case for leaving comes down to three things: the rollout runs through a partner, the rules and connectors need engineers to keep running, and the apps that matter most can still end as tickets. This guide is for a team that has decided to look at Iden: when to start, what moves, how SailPoint's concepts map, and how to make the case inside your company. For the wider comparison, see SailPoint alternatives.
Why teams switch from SailPoint
There are three reasons to move, and a renewal is when they get counted.
The programme costs more than the licence. SailPoint sells implementation services that reach into rule development, and on-prem sources need a virtual appliance cluster. Each year brings partner spend and engineering hours on top of the licence.
The custom work is yours to maintain. Rules, transforms and connectors your partner built have to be kept working through every app change and upgrade, by people who know them. Iden has no rule code: policies are set in the product, and Iden builds and maintains custom connectors itself.
Some apps still end as tickets. SailPoint's connector for apps with no API doesn't support apps behind SSO, MFA or federated sign-in. Iden has connectors for 220+ apps without SCIM and automates the admin console of apps with no API, so those apps get provisioned and deprovisioned rather than queued.
Time it to your renewal, and run alongside SailPoint
Start two quarters before your renewal date. That leaves room for a 2-week trial, one parallel review cycle and a cutover between campaigns, all before you would sign again.
Run the trial on the apps that hurt most in SailPoint today: the ones that end as tickets, plus one app with a partner-built connector. Iden connects the first 15 apps in under an hour, on your own data.
SailPoint keeps provisioning the whole time. Iden runs alongside it until you have seen one full review cycle of its decisions, so nothing about your controls changes until you choose the cutover.
What staying on SailPoint costs against switching
Move the sliders to your own numbers. The SailPoint side counts the licence, the partner spend, the engineer hours on rules, connectors and upgrades, and the IT time on access tickets SailPoint can't automate. Iden needs no partner and no rule code, and provisions those apps, so none of those costs carries over.
What moves, and how
Every app in your SailPoint environment takes one of three routes into Iden.
- Apps with SCIM or a public API are reconnected. Iden's connector library covers them, with no plan upgrade needed for SCIM.
- Apps with a partner-built connector are rebuilt by Iden from your API documentation: a Postman collection, an OpenAPI spec or plain docs. Rebuilt connectors are ready within 12 hours, and Iden maintains them afterwards.
- Apps that end as tickets or manual work are automated through the app's admin console. A person gets a task only where an app needs one, and the task records how the access was closed.
Mapping SailPoint to Iden
| SailPoint | Iden | What changes |
|---|---|---|
| Sources and identity profiles | Your HR system as the source of joiner, mover and leaver events | Contractor end dates enforced as leaver dates |
| Roles and access profiles | Role policies and access templates | Roles nobody can explain are dropped, not copied |
| Rules and transforms | Policies set in the product | No rule code to write or maintain |
| Workflows | Lifecycle policies from the HR record | Set by your IT team, not a partner |
| Partner-built connectors | Custom connectors Iden builds and maintains | Rebuilt from your API docs within 12 hours |
| Disconnected apps and manual work items | Admin-console automation | The access is provisioned and removed, not queued |
| Access requests | Access requests in Slack or Teams, with expiring grants | Approvers see what a role can do before they approve |
| Certification campaigns | Access reviews | One decision per row, with the revocation recorded against it |
| Separation-of-duties policies | Separation-of-duties checks at request time | Conflicts flagged before access is granted |
| Machine identities | Non-human identity governance | Each identity gets an owner, a scope and an expiry |
Before you start
Gather these before the first call. None of them needs anyone outside IT.
- Your SailPoint renewal date and notice period.
- Every custom connector and rule your partner built, and where the API documentation for those apps lives.
- The apps that still end as tickets or manual work items, and how many a month.
- Your HR system, and which events start onboarding, transfers and offboarding.
- Any certification campaign in flight, and when your auditors' next period starts.
- The roles and approval policies people complain about. These are the first to rewrite rather than copy.
The migration plan
The connectors take days. The calendar is set by your review cycle and your renewal date.
- Export your evidence from SailPoint. Pull the certification history and the open access requests. Your auditor will ask for the last period whatever you run next.
- Hand over your custom connectors. Send the API documentation for each app your partner built a connector for. Iden rebuilds them within 12 hours.
- Connect your HR system and apps. The HR system becomes the source of joiner, mover and leaver events. The first 15 apps connect in under an hour, and the rest follow over a few days.
- Map your roles and policies. Roles and access profiles become role policies, and request rules become approval routes and expiry rules. Any role nobody can explain is one to drop.
- Run alongside SailPoint for one review cycle. SailPoint still provisions. Compare who each would have granted and removed, and check that the apps SailPoint left as tickets are now closed by Iden.
- Cut over at a review boundary. Switch the HR trigger to Iden between campaigns, so no review is split across two tools and two evidence trails.
- Let SailPoint lapse at renewal. Keep it read-only until the term ends, with the exports filed, then switch it off.
If anything looks wrong during the parallel run, SailPoint is still provisioning, so stopping costs nothing.
Announce the change
App owners and approvers notice a switch more than employees do. Send something like this a week before the parallel run starts, and edit it to fit.
Subject: We're moving access requests and reviews from SailPoint to Iden
From [date], access requests and access reviews move from SailPoint to Iden. You'll request access in [Slack or Teams]; approvals arrive there too.
If you own an app, you'll see one change: requests for [apps] that used to arrive as tickets will be handled automatically.
Our next access review, starting [date], runs in Iden: one decision per person per role.
Questions go to [name or channel].
Making the case internally
Expect three objections. Each has a short answer.
"SailPoint is the standard, and our auditors know it"
Auditors test controls and evidence, not brands. Iden records every decision, grant and revocation in an audit log you can export, and the parallel cycle gives your auditor two tools' evidence for the same period before you switch.
"We've invested years in our SailPoint build"
The investment worth keeping is what your team knows about your apps and roles, and that carries over in the API docs and role definitions you hand over. The rule code and partner-built connectors don't need to. Iden rebuilds the connectors within 12 hours and has no rules to port.
"Switching is too disruptive"
Nothing changes for employees until the cutover, and nothing changes for auditors until a review boundary. SailPoint keeps provisioning through the parallel cycle, and the switch happens at a renewal you were going to face anyway.
Where to start
Book a 25-minute session with your app list and your list of partner-built connectors. You'll see which apps Iden governs end to end, how the parallel run fits your renewal date, and what the move costs against another SailPoint term.