I’m looking for insights on the migration process from SailPoint IdentityIQ (IIQ) to Identity Security Cloud (ISC).
Any best practices, lessons learned, or documentation references would be greatly appreciated. Thank you!
Hi @narayanag , your questions are spot-on, and it’s great to see someone approaching this migration with a structured mindset rather than trial and error.
Actually the move from IIQ to ISC isn’t a simple lift-and-shift… it’s a real transformation… there are architectural differences, data models, and connector behaviours that require proper planning.
Here’s a practical path to get you started (from my POV only):
Start with this 3-part video series from SailPoint — it explains core concepts, what changes, and how to think about migrating objects like identities, roles, policies, and certifications:
How to migrate from IdentityIQ to SailPoint Identity Security Cloud
https://community.sailpoint.com/t5/Webinars/How-to-migrate-from-IdentityIQ-to-SailPoint-Identity-Security/ec-p/254791
Then read this official readiness article; it outlines what’s reusable, what’s not, and how to assess your IIQ environment before jumping in:
Are you ready to migrate from IdentityIQ to Identity Security Cloud?
For a real-world project view, this DXC + SailPoint webinar breaks down the phases (assessment, design, configuration, testing, and go-live) :
Identity Modernization: A Hitchhiker’s Guide
A few things to keep in mind technically:
Have a nice and great one!
Regards,
Mustafa
Thank yo so much Mustafa!! May God blees you!!!
More than welcome brother and thank you so much 
Hi, I noticed this topic was recently reopened/unlocked after being inactive for a while. Is there any specific reason it was reopened? Just curious and wanted to understand the context. Thanks!
Hi there,
It’s great to see you taking a structured approach to your migration from IdentityIQ (IIQ) to Identity Security Cloud (ISC)! Moving to ISC it’s more like a upgrade today than ever before.
To help accelerate this journey, SailPoint leverages our advanced AI-based upgrade tooling.
Here are some insights into your specific questions:
1. Data and Configurations: What Migrates?
While our migration tooling handles a lot of the heavy lifting, it’s important to understand what transitions and what requires a cloud-native redesign:
| Category | What it Includes | Migration Path |
|---|---|---|
| Migrates Easily | Identity models, Role models, SOD policies, Access Requests, Certifications, and Email templates. | Straightforward - These map cleanly to ISC’s framework and can often be migrated in bulk using our tooling. |
| Tool-Assisted Rework | Applications to Sources mapping, Workflows, Connector rules, and automated LCM processes. | Accelerated via Tooling - Historically, these required manual redesigns. Now, our AI upgrade tools heavily assist in converting and mapping IIQ workflows, rules, and LCM events into ISC’s modern extensibility framework. |
| Does Not Migrate | Deep Java customizations, system Plugins, legacy Audit/Event history, and old risk models. | N/A - ISC solves these use cases natively through out-of-the-box configuration, eliminating the need for legacy on-prem custom code. |
2. Strategies & Approaches
Phase 0 (Fast Time-to-Value): We highly recommend starting with a “Phase 0” deployment. Empowered by our new AI-based upgrade tooling, Phase 0 is no longer just a read-only foundation. It now includes the accelerated migration and setup of Automated Lifecycle Management (LCM), Rules, and Workflows. This means you achieve a highly functional, automated baseline incredibly fast, allowing you to realize ROI much earlier in the project.
Co-existence / Phased Migration: This is the most common and lowest-risk approach. Both IIQ and ISC run simultaneously while apps and services are migrated over in phases (often starting with non-critical apps). If a process breaks, you can easily roll back. Once ISC is fully stable, IIQ is decommissioned.
Redesign, Don’t Replicate: Avoid the trap of trying to directly copy/paste IIQ’s on-prem configurations into the cloud. Treat this as an opportunity to map your business outcomes to ISC’s modern capabilities.
3. Major Challenges & Pitfalls
The “Customization” Mindset: The biggest hurdle is often a shift in culture. IIQ allowed for unrestricted Java customizations. Moving to ISC requires adopting a “configuration-first” mindset, utilizing standardized APIs and Event Triggers rather than writing deep custom code.
Architecture Differences: ISC operates on a multi-tenant microservices architecture with event-based refreshes rather than legacy batch processes. The timing of aggregations and provisioning actions can differ from IIQ, requiring a shift in how you test and design.
Migrating Bad Data: Teams run into trouble when they attempt to bring over unused custom objects or convoluted rules. It is highly recommended to clean up and simplify your IIQ environment (retiring decommissioned apps and irrelevant rules) before you initiate the migration.
Hope this helps point you in the right direction! Let me know if you have any deeper technical questions regarding the AI tooling or the migration process. We have a monthly webinar series that I would highly recommend.
https://community.sailpoint.com/t5/Migrate-to-Identity-Security/ct-p/migrate-to-isc