For organizations that have migrated from IdentityIQ (IIQ) to Identity Security Cloud (ISC), which IIQ capabilities were the hardest to replace in ISC?

Identity Security Cloud (ISC) ISC Discussion and Questions
1

I’m interested in understanding the practical trade-offs between the two platforms.

  • What functionality was easier to implement, customize, or manage in IIQ?
  • Which IIQ features or use cases became more difficult in ISC?
  • Were there any capabilities available in IIQ that were dropped, limited, or required a completely different approach in ISC?
  • How did you redesign those solutions in ISC?
  • Despite these challenges, what benefits ultimately justified the move to ISC?

I’m looking for real-world experiences and lessons learned rather than feature-list comparisons.

Thanks,
Pravin

2

Hi Ranjan Kumar,

The way I understand is the ISC and IIQ have very different architecture styles. Hence when moving from IIQ to ISC it’s not a simple migration but more of a relook at the implementation, identify the use cases which can be moved over easily and rethink of the remaining use cases from their business criticality perspective; if they qualify to spend effort into evaluating the implementation route from IIQ into ISC.

The more the customization via rules, plugins, etc. in IIQ the more difficult the movement to ISC. Also the complex the customization the harder the move.

Based on the implementation the specific features would have to be evaluated. Now some features do have a mechanism may be similar or a bit different. However some features like the Plugins are not available in ISC and would require a complete re-think of the approach. Hence unless the details are spelled out it would be difficult to make call-outs. However based on my discussions I am sharing my observations and learnings.

The following rules are not supported by ISC and if there are any functionalities or features implemented within your current IIQ instance which rely on these you would have to think of an alternative route.

Certain IIQ Rules are not supported in ISC

Certification exclusion: There is a configurable way however if the rule was implementing a complex logic to exclude certification items the functionality may be limited to what is offered out of box in ISC

Identity Selector: These can be done via Role Assignment criteria, however if there is a cross identity relationship in ISC. For example you want to assign a role based on some identity attributes associated with the identity and their direct manager, etc. the same would not be feasible in ISC

Policy Rules / Violation Rules: ISC supports native configuration support only. No rule code blocks are allowed hence if you have a complex cross identity relationship based policy it may need a different approach in ISC

Plugins are not supported in ISC.

Another aspect of the IIQ to ISC move which you have not factored is that ISC is a SaaS platform and has a dependency on SailPoint support team for deployment of certain artifacts like Cloud Rules. The debugging and fixing of these would also require support help is my understanding as they have access to these rules.

These are my findings based on the discussions and discovery. Would love to hear from others as well.

Regards,

Nilesh

3

The Hardest IIQ capabilities to replace in ISC are not Rules /workflows, but the architectural flexibility IIQ provides.

Features like custom objects, custom task definitions, and direct access to identity data are commonly used between processes and integration.

In ISC these require redesign using workflows, API, external services.

Other challenge is operational visibility- IIQ administrators can directly inspect tasks, workflows/data, whereas ISC follows a more controlled SaaS model

I migrations rearchitecting years of customization is the biggest effort.