Move the entitlements from 1AD app to another parent

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Hi Team,

we want to delete one AD application and moved its entitlement to another AD application, so I am looking for any recommendation to safely move it with respect to open pending Access request, roles detected and assigned and entitlements, policies

Thanks,
Pranali

2

Hi @Pranali

As per my experience, there is no easy way to map existing access requests and policy violations to the new application.

The rest of the data can be aggregated, but we will lose the history.

Entitlements can be aggregated in the new application. Other open/pending access requests and existing policy violations are not feasible to map.

May I know the actual business scenario for wanting to move to a new application?

3

Hi Pattabhi,

Thanks for the reply, we are not worried about history and data we just want to deprecate 1 AD application and data of it will be coming from other AD application by adjusting the filter.
Here we need suggestions for following,
1)If there are any open pending request for that deprecated AD application
2)How to update the IT roles and will that be detected if we just changed the Application name there from Associated entitlements
3)Entitlement SOD policies

Best Regards,
Pranali

4

Hi @Pranali

point number 2 and 3 will work if we adjust the filter referring to the new application object/entitlements after successful aggregation.

Regarding point number 1, we need to pull the report, try to complete pending items before deprecation. check the statistics how many open, complete vs in-progress.

5

Hi Pattabhi,

Thanks for the reply ,

Could you please elaborate about 2 and 3 suggestions, in our case the old application name and id is different than the new so do you mean we can update in roles and policies directly and it will not cause any inconsistency.

6

You can go ahead and update policies definition by replace old ents/roles with new application ents/roles. Same with roles.

It will not cause any issues, better validate 1st in pre prod and then do same in prod.

7

Hi @Pranali here you are my responses (from my POV only) to your scenario of deprecating one AD application and moving its entitlements to another (and would be great if you validated against your situation):

  1. Pending Access Requests
    Access requests in IIQ are tied to the original application’s entitlement IDs (UUIDs). When you deprecate the old app:
    A- Open or in-progress requests referencing the old app will fail or become invalid if those entitlements no longer exist.
    B- Recommended actions:
  • Extract pending requests using AccessRequest objects via the debug pages or a direct query (e.g., spt_access_request joined with entitlement/app).
  • Manually cancel, approve, or migrate them before decommissioning the old application.
  1. Updating IT Roles (Bundles)
    This is a crucial area requiring careful treatment because Roles (Bundle objects) reference entitlements by internal ID and associated application name.
    A- Simply editing the app name in existing roles will not work, because even identical group names in the new app will have different identityLink/UUIDs.
    B- Proper approach:
  • Export the existing roles (e.g., via iiq console or IIQDebug).
  • In the XML or object structure, replace old entitlement references with entitlement objects from the new app (use matching display names carefully but map the correct ApplicationRef).
  • Re-import the adjusted roles.
  • Then run Identity Refresh to realign identities to the updated roles.

  1. SoD Policies
    SoD policies use Application Name + Entitlement Display Name in the conflictingAccessCriteria.
    • You can update the policy XML to reference the new app’s entitlement names.
    • Run the Policy Simulation Task to confirm that conflicts are still detected.

  2. Deprecating the Old Application
    Instead of deleting it outright:
    • Disable aggregation/provisioning.
    • Rename it clearly, e.g., AD-Legacy [DEPRECATED].
    • Keep the metadata for audit, historical certifications, and troubleshooting.

If needed, you can also maintain a custom object to document the mapping between old and new entitlements — especially helpful if names are not 1:1

Regards,
Mustafa

1 Like