To migrate from SailPoint IdentityIQ to Identity Security Cloud: inventory every application, rule, workflow, role, policy and campaign; decide what moves, what is redesigned and what is retired; design ISC identity profiles, transforms and workflows; move authoritative sources first, then applications in waves; reconcile identities, accounts and entitlements before each cut-over; archive IIQ audit history; then retire IdentityIQ.
1. Before you start
- Name an owner for the programme and one for sign-off in the business, usually the IAM lead and someone from audit or risk.
- Confirm the target: Identity Security Cloud, which SailPoint now describes as evolving into SailPoint Human Fabric (August 2026). Check current product names and licensing with SailPoint.
- Agree how long IdentityIQ audit history must be kept and where, because it does not move into ISC.
- List the certification campaigns and SoD reports that must run without a gap, with their dates.
- Freeze non-essential IdentityIQ changes, so the estate you inventory is the estate you migrate.
2. Inventory the IdentityIQ estate
Every later estimate depends on this step. For each item, record whether it is still used and who depends on it.
| Item | What to record |
|---|---|
| Applications and connectors | Connector type, authoritative or target, custom connector code, on-premise or cloud |
| BeanShell and Java rules | What each does, where it runs, whether anything still calls it |
| Workflows and tasks | Trigger, steps, approvals, custom code, run frequency |
| Identity attributes | Source, any calculation logic, which rules and roles use them |
| Roles | Business and IT roles, owners, assignment rules, how many identities hold each |
| SoD policies | Rules, violations open today, who reviews them |
| Certifications | Campaign types, schedules, reviewers, evidence auditors expect |
| Reports and plugins | Who uses them, and what would replace them |
3. Decide: move, redesign or retire
Mark every inventory item with one of three outcomes. The customisation model is different in ISC, so expect much of the custom logic to be redesigned or retired, not copied.
- Move as configured: standard connectors, identity and role models, SoD policies, access requests, certifications and email templates, which map more closely and can often be moved in bulk with SailPoint's tooling. Their logic still needs review.
- Redesign for ISC: IdentityIQ rules, workflows and tasks, which are not portable. Re-express each as configuration, a transform, an ISC workflow or, as a last resort, a rule.
- Retire: rules nobody calls, roles nobody holds, reports nobody reads and plugins whose purpose has gone. Every item retired here is one less to build and test.
4. Design the ISC target
- Identity profiles and lifecycle states for each population, mapped from your authoritative HR sources.
- Transforms for calculated identity attributes, replacing attribute rules where possible.
- ISC workflows for joiner-mover-leaver and approvals, replacing IIQ workflows where possible.
- The few rules that are really needed: cloud-executed rules go through SailPoint's review before deployment; connector-executed rules run on the virtual appliance.
- Virtual appliances for reaching on-premise systems, sized and placed with your network team.
- A wave plan: which sources and applications move together, in what order, with dependencies.
- The reconciliation checks every wave must pass before cut-over.
5. Migrate in waves
- Build each wave in a non-production ISC tenant first and test it against real HR scenarios: a joiner, a mover, a leaver, a rehire.
- Move authoritative sources first, so identities exist in ISC before any application depends on them.
- Move applications in groups, starting with standard connectors and leaving custom-code applications until the patterns are proven.
- Run IdentityIQ and ISC side by side for each wave. Provisioning stays with IdentityIQ until the wave reconciles.
6. Reconcile before every cut-over
Do not switch provisioning to ISC for a wave until both platforms agree. Compare, for each application in the wave:
- Identities: the same people, with the same key attributes and lifecycle states.
- Accounts: the same accounts correlated to the same identities, with orphans explained.
- Entitlements: the same access, with every difference investigated and either fixed or accepted in writing.
- Lifecycle results: a test joiner, mover and leaver produce the same access changes on both platforms.
7. Cut over and retire IdentityIQ
- Switch provisioning and certifications to ISC one reconciled wave at a time.
- Re-create certification campaigns in ISC so audit evidence continues across the change of platform.
- After the final wave, archive IdentityIQ audit data for your retention period, then switch IdentityIQ off.
- Keep production support on ISC through the first certification cycle and the first big round of joiners and leavers.
Where SailPoint's tooling fits
In June 2026 SailPoint announced Agentic Acceleration, AI-assisted tooling delivered through its forward deployed engineers to convert IdentityIQ configurations for ISC. Tooling speeds up conversion. The steps in this checklist still have to be done: deciding what should move, testing lifecycle behaviour against real HR data, onboarding custom applications and reconciling access before cut-over.
Frequently asked questions
What is the first step in an IdentityIQ to ISC migration?
An inventory of the IdentityIQ estate: applications and connectors, rules, workflows, tasks, roles, SoD policies, certifications and reports, with a note of what is still used. Estimates made before the inventory are guesses, because the effort depends on how much custom logic the estate contains.
Can IdentityIQ rules be copied into Identity Security Cloud?
No. SailPoint's developer-community guidance is that IdentityIQ rules, workflows and tasks are not portable. Each is re-expressed as ISC configuration, a transform, an ISC workflow or, as a last resort, a rule. Cloud-executed rules are reviewed by SailPoint before deployment.
Does IdentityIQ audit history move to ISC?
No. Accounts and entitlements are re-aggregated from the sources in ISC, and IdentityIQ audit history stays behind. Decide early how it will be archived and for how long, so it is ready before IdentityIQ is switched off.
Should we migrate everything in one go?
No. Move authoritative sources first, then applications in waves, with IdentityIQ and ISC running side by side. Each wave is reconciled before provisioning switches, so a wave that does not reconcile can stay on IdentityIQ while it is fixed.
Can MappOptimist run the migration or add engineers to our team?
Yes. We can run an IdentityIQ to ISC migration as a managed project, add SailPoint engineers to your IAM team, or deliver white-label for consultancies. Our published SailPoint work is three Identity Security Cloud and two IdentityIQ implementations; we have no published migration case study.
Sources
- SailPoint developer documentation (developer.sailpoint.com): cloud-executed and connector-executed rules.
- SailPoint developer community: IdentityIQ to Identity Security Cloud migration guidance.
- SailPoint announcements: Agentic Acceleration (June 2026) and SailPoint Human Fabric (4 August 2026).
- MappOptimist IdentityIQ to ISC migration method.