SailPoint IdentityIQ to Identity Security Cloud
Cohash moves IdentityIQ estates to SailPoint Identity Security Cloud, the SaaS platform formerly called IdentityNow. We inventory every rule, workflow and connector, decide what ISC covers natively and what needs transforms, workflows or a SaaS connector, and run both platforms side by side until certifications and provisioning match. Audit history is exported and kept before IdentityIQ is switched off.
- 01Inventory and fit
- 02Identity model and sources
- 03Access model
- 04Parallel run
- 05Cut-over and decommission
The story
Told without the client's name or anything that could identify them.
A manufacturer's identity team spent more time patching IdentityIQ and its application servers than onboarding applications, and the IdentityIQ 9.0 estimate came back larger than expected because every custom rule and plugin would be touched. That made it the moment to price a move to Identity Security Cloud. We exported every rule, workflow, plugin and connector first and gave each one a decision: native in ISC, a transform or workflow, a SaaS connector, or retire. Both platforms ran side by side until identities, access and a pilot certification matched, provisioning moved application by application, and IdentityIQ was shut down with its audit history archived.
why it was urgentWhatever happens, IdentityIQ 9.0 means touching every custom rule and plugin, because the product moves to Jakarta EE. Plenty of teams take that as the moment to ask whether to spend the effort on a 9.0 upgrade or on moving to SaaS.
- openHundreds of BeanShell rules that only one contractor still understands.
- recurringInfrastructure and app-server patching eat the time that should go to onboarding applications.
- blockedThe 9.0 upgrade estimate came back bigger than expected, and somebody asked about SaaS.
- openCertification campaigns depend on custom workflows that nobody wants to rebuild twice.
The estate, before and after
Before: self-hosted IdentityIQ carried by custom rules
IdentityIQ ran on servers the team patched itself, with BeanShell rules and workflows holding logic only one contractor understood. Some targets still got access through manual tickets.
Read the diagram as text
- HR system → IdentityIQ: joiner · mover · leaver
- Active Directory → IdentityIQ: aggregation
- BeanShell rules and workflows → IdentityIQ: custom logic
- IdentityIQ → App server and database: runs on
- IdentityIQ → Entra ID: provision
- IdentityIQ → Salesforce: provision
- IdentityIQ → ServiceNow: manual tickets
After: governance in SailPoint Identity Security Cloud
Same sources, same targets, now served by Identity Security Cloud as SaaS. The custom logic moved into versioned transforms and workflows, and certifications run in the tenant.
Read the diagram as text
- HR system → Identity Security Cloud: joiner · mover · leaver
- Active Directory → Identity Security Cloud: aggregation
- Transforms and workflows → Identity Security Cloud: deployed config
- Identity Security Cloud → Certifications: campaigns
- Identity Security Cloud → Entra ID: provision
- Identity Security Cloud → Salesforce: provision
- Identity Security Cloud → ServiceNow: provision
How we run it, phase by phase.
5 phases take you from SailPoint IdentityIQ (self-hosted) to SailPoint Identity Security Cloud. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Inventory and fit
Get the rules, workflows, plugins, forms, connectors and task schedules out. Mark each one: native in ISC, rebuild as a transform or workflow, replace with a SaaS connector, or retire.
- phase 02
Identity model and sources
Rebuild authoritative sources, identity profiles and correlation in ISC, then compare identity counts and attributes against IdentityIQ until they match.
- phase 03
Access model
Bring roles, access profiles and entitlement descriptions across. Rebuild the separation-of-duties policies and test them against conflicts you know exist.
- phase 04
Parallel run
Run aggregation and a pilot certification on both platforms. If who gets what differs, explain it or fix it before you switch provisioning.
- phase 05
Cut-over and decommission
Switch provisioning application by application, export IdentityIQ audit and certification history for retention, then shut down servers and the database.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
No IdentityIQ servers left to patch
Once the last application moved, the IdentityIQ servers, application server and database went dark. Nobody on the team patches them any more.
- result 02
Every customization has a recorded decision
The inventory gives each rule, workflow and plugin one outcome: native in ISC, rebuilt as a transform or workflow, replaced by a SaaS connector, or retired.
- result 03
Access matched before provisioning switched
Before an application cut over, we compared identity counts, attributes and a pilot certification in both platforms and chased down every difference.
- result 04
Tenant configuration lives in version control
We export ISC configuration as versioned files. A change to an identity profile, transform or workflow gets reviewed like code.
- result 05
Audit history outlived IdentityIQ
We exported the certification and provisioning history with decisions, reviewers and dates, in a format the audit team can still read.
Risks we plan for
-
Custom logic with no native equivalent
Some rules exist because of one HR quirk or one target system. They need a decision before migration starts, or they become a late surprise.
-
Connector gaps
Check every target, because some IdentityIQ connectors have no ISC equivalent or one with fewer features. Gaps get a SaaS connector, a delimited file or a web-services build.
-
Losing audit history
Auditors may ask about decisions made years ago. So certification and provisioning history is exported in a format someone can still open.
Where AI helps, and where it needs guardrails
ISC adds AI-driven access recommendations and role discovery, and SailPoint's Agentic Fabric covers AI agents as identities. We use the migration to put owners and scopes on the service accounts and agents that IdentityIQ never tracked, and we can expose read-only identity queries to internal assistants through an MCP server with tightly scoped tokens.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Customization inventory with a decision per rule, workflow and plugin
yours to keep - document02
ISC tenant configuration as exported, versioned files
yours to keep - report03
Parallel-run comparison report per source and target application
yours to keep - runbook04
Cut-over runbook with a rollback point per application
yours to keep - evidence05
Archived IdentityIQ audit and certification history
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Entitlement
- A specific permission or access right a person holds in a system, such as the ability to post journal entries in a finance app.in context →
- 02Connector
- The integration between an identity platform and an app. It's how the platform reads and changes accounts and access in that app.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we upgrade to IdentityIQ 9.0 or move to Identity Security Cloud?
It depends how much of your value sits in custom code and whether you must run on-premises. Lots of customization and strict hosting rules favor the 9.0 upgrade. A smaller rule set and a team that's tired of patching servers favor ISC. We count the custom objects and give you both estimates.
02Can both platforms run at the same time?
For a while, yes, on purpose. Both run aggregation and certifications, provisioning moves application by application, and nobody loses access along the way.
03What happens to old certifications?
They come out with every decision, reviewer and date, and land somewhere your audit team can still open them once IdentityIQ is gone.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study067d7ec7 - 01SailPoint: Identity Security Cloudsailpoint.com ↗
- 02SailPoint Community: Adapting to Jakarta EE (IdentityIQ 9.0)community.sailpoint.com ↗
- 03SailPoint blog: IdentityIQ 9.0 (6 Oct 2026)sailpoint.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it