Notifications
Clear all
Topic starter
25/06/2026 5:22 pm
TL;DR: Organisations moving from IdentityIQ to Identity Security Cloud can carry forward configured connectors, objects, and rules, according to SailPoint. The real issue is not lift-and-shift convenience but whether teams are prepared to adapt identity architecture and operating assumptions to a cloud model.
NHIMG editorial — based on content published by SailPoint: Identity Security Cloud migration FAQ and common questions
Questions worth separating out
Q: How should IAM teams approach migration from IdentityIQ to Identity Security Cloud?
A: They should treat it as an architecture and governance transition, not a simple lift-and-shift.
A: What usually breaks is not authentication alone, but the surrounding control logic.
Q: How do organisations know whether their identity migration plan is realistic?
A: A realistic plan identifies the parts of the environment that can transfer cleanly and the parts that need redesign.
Practitioner guidance
- Inventory every custom connector and rule Identify which connectors, objects, and rules must move as-is and which need reimplementation in the cloud extensibility layer.
- Re-map on-premises controls to cloud equivalents For each identity process, document the cloud-native control that will replace the on-premises mechanism, including any difference in release cadence, update handling, or testing workflow.
- Test account-role-entitlement relationships before cutover Validate whether the same relationship model behaves correctly after migration, especially where role mining, entitlement aggregation, or downstream governance reports depend on exact object behaviour.
What's in the full article
SailPoint's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on what the assessment programme actually does across each meeting and review stage.
- The vendor’s own explanation of where IdentityIQ and Identity Security Cloud differ in practice.
- More detail on what can be migrated through configured connectors, objects, and rules.
- The cloud extensibility layer considerations that determine when a process needs redesign rather than reuse.
👉 Read SailPoint’s FAQ on migrating from IdentityIQ to Identity Security Cloud →
IdentityIQ migration to Identity Security Cloud: what changes for teams?
Explore further
25/06/2026 6:01 pm
Identity migration fails when teams treat cloud identity as a deployment swap. SailPoint’s own FAQ points to the central mistake: assuming a cloud rollout can be managed like an on-premises deployment. That is a governance error as much as a technical one, because the control model, update cadence, and extensibility assumptions all change. The implication is that migration planning has to start from operating model differences, not product feature parity.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which shows how thin governance confidence still is.
A question worth separating out:
Q: What should security teams do when cloud identity features differ from on-premises behaviour?
A: They should decide whether the requirement can be met natively, through the extensibility layer, or only by changing the business process. That decision should be made control by control, because assuming equivalence can leave gaps in approvals, provisioning, or reporting.
👉 Read our full editorial: IdentityIQ to Identity Security Cloud migration changes what teams must plan
