Search “identityiq vs identitynow” today and most of what comes back is already out of date twice over. SailPoint renamed IdentityNow to Identity Security Cloud (ISC) in March 2024, and then renamed ISC itself to SailPoint Human Fabric (SHF) at Black Hat USA in August 2026 — same SaaS platform, third name in a little over two years. IdentityIQ, the on-premises product, kept its name throughout. If you’re deciding whether to migrate an existing IIQ deployment, or scoping a new implementation and choosing between the two, the naming churn is the least of your problems — the real differences are architectural, and they hit hardest in exactly the area this site’s SailPoint series has covered in depth: BeanShell rule customization.
This guide covers what actually changes in an IdentityIQ-to-cloud migration, what doesn’t have a direct migration path, and how to decide which platform a new deployment should start on.
One Platform, Three Names
For clarity going forward: IdentityNow, Identity Security Cloud, and SailPoint Human Fabric are the same underlying multi-tenant SaaS product at three points in its branding history. The core governance capabilities — identity profiles, access certifications, provisioning workflows, lifecycle states — carried forward through both renames without a rebuild. Human Fabric layers real-time governance and deeper identity-graph capabilities on top of the ISC foundation, and ships alongside a separate but related product, Agentic Fabric, for governing AI agent and non-human identities specifically.
Practically, this means:
- Job postings, RFPs, and older documentation referencing “IdentityNow” are describing the same product family you’d deploy today as Human Fabric.
- SailPoint’s developer documentation and API endpoints largely still use
identitynowandiscin URLs and package names — the rebrand is a product/marketing name change, not (yet) a wholesale API rename. - This guide uses “IdentityNow/ISC” interchangeably with “Human Fabric” since that’s still the dominant search term, but treat them as the current product when you see either.
IdentityIQ, by contrast, is the on-premises (or self-managed IaaS) Java application most of this site’s SailPoint content is written against — deployed as a WAR file, configured through iiq console and BeanShell rules, backed by a database schema you control directly (spt_identity, spt_certification_item, and the rest of the spt_ tables covered in our aggregation troubleshooting guide).
Architectural Differences That Actually Matter
| IdentityIQ | IdentityNow / ISC / Human Fabric | |
|---|---|---|
| Deployment | Self-hosted WAR (on-prem or IaaS) | Multi-tenant SaaS |
| Infrastructure ownership | You patch, scale, back up the database | SailPoint operates it |
| Customization | Unrestricted BeanShell (~200 rule types) | Sandboxed Cloud Rules (fewer than 20 types) + Transforms |
| Connector execution | In-process Java connectors, direct DB/LDAP access | Virtual Appliance (VA) or SaaS-native connectors |
| Console/admin access | iiq console, direct database queries | Admin UI + REST API + sp-config for object export/import |
| Upgrade model | You schedule and run version upgrades | Continuous, SailPoint-managed releases |
The deployment-model row gets the most attention in vendor marketing, but for a team migrating an existing IIQ deployment, the customization row is where the actual engineering work lives.
Why BeanShell Rules Are the Hardest Migration Problem
IdentityIQ’s extensibility model is deliberately unrestricted: a BeanShell rule can import any Java class on the classpath, open a JDBC connection to an external system, call context.saveObject() to commit changes directly, and generally do anything a first-class Java method could do. That’s exactly why our BeanShell Rule Cookbook and certification automation guide can show working exclusion rules, pre-delegation rules, and provisioning logic that reach into arbitrary application state.
ISC/Human Fabric does not run BeanShell. Cloud Rules are JavaScript-based, sandboxed, and time-boxed — SailPoint’s own developer documentation describes them as able to read the ISC data model but explicitly unable to commit transactions or save objects, which rules out the “rule quietly writes back to another object” pattern that shows up in several IIQ provisioning rules. There are fewer than 20 Cloud Rule types total, against roughly 200 rule types in IIQ.
The practical consequence for a migration:
- Identity attribute calculation logic (formatted IDs, computed manager chains, string transforms) mostly maps to a Transform — a declarative JSON object, not code. Transforms handle concatenation, date math, conditional branching, and lookup tables without executing arbitrary logic.
- Rules with genuine procedural logic that don’t fit a Transform’s declarative model become a Cloud Rule, rewritten in JavaScript within the sandbox’s constraints.
- Rules that call custom Java classes, open direct database connections, or write to application state outside IdentityIQ’s own objects generally have no direct ISC equivalent. That logic has to move to the connector layer (a custom SaaS connector, or logic inside a JDBC/Web Services source configuration) or be redesigned around ISC’s supported extension points entirely.
If your IIQ deployment leans heavily on category 3 — and after years of BeanShell customization, most mature deployments do somewhere — that’s the work that actually determines your migration timeline, not the data migration itself.
Connector and Source Migration
For connectors SailPoint has published a supported path for, there’s a VA-to-SaaS source migration tool that converts a Virtual-Appliance-based source to a native SaaS source connection without re-onboarding the application from zero: existing accounts, entitlements, access profiles, roles, password policy settings, and correlation configuration on the source carry over. It requires Admin or Source Admin user level in ISC to run.
That path only exists where SailPoint has built and published it for a specific connector. Two categories fall outside it:
- Custom IIQ connectors extending
sailpoint.connector.Connector(the on-prem SPI) have no automated migration — they need to be rebuilt against ISC’s SaaS connector framework, which is a different extension model entirely, not a recompile. - Connectors without a published SaaS equivalent yet — check the specific connector’s documentation page for a “Source Migration” section before planning around it; don’t assume support exists because a similar connector has it.
Object Migration with sp-config
For configuration objects that do have an ISC equivalent — approved Cloud Rules, Transforms, provisioning policies — the sp-config API and CLI support exporting objects from a sandbox tenant and importing them into production once they’ve passed SailPoint’s rule review process for cloud-executed rules. This is the mechanism for promoting tested Cloud Rules and Transforms between tenants; it is not a bulk IIQ-object-to-ISC-object converter. BeanShell <Rule> XML from an IIQ export does not import into ISC as a Cloud Rule — it has to be rewritten first using the mapping above, then the rewritten object goes through sp-config for promotion between ISC environments.
Realistic Migration Timeline
Vendor case studies and migration-framework write-ups consistently describe IIQ implementations running 12-18 months on their own, with an ISC/Human Fabric migration adding a further multi-quarter program on top rather than replacing that timeline. The variables that move the estimate most:
- Rule inventory size and category — how many of your BeanShell rules fall into the “no direct equivalent” bucket above.
- Custom connector count — each one without a published SaaS migration path is effectively a connector rebuild project.
- Data volume and identity attribute complexity — larger, more customized identity cubes take longer to validate post-migration.
- Whether you run IIQ and ISC in parallel during cutover (recommended for anything beyond a small deployment) versus a hard cutover, which adds coordination overhead but substantially reduces risk.
Should a New Deployment Start on IdentityIQ or ISC/Human Fabric?
For the majority of new SailPoint deployments in 2026, start on ISC/Human Fabric. SailPoint has been explicit that ongoing platform investment — AI-driven access recommendations, predictive access modeling, identity graph relationship mapping, and non-human/agentic identity governance through the companion Agentic Fabric product — is concentrated on the cloud platform, while IdentityIQ continues to receive support and security patches without the same pace of net-new capability.
IdentityIQ still makes sense as the starting point when:
- Data residency or air-gap requirements mandate on-premises deployment with no SaaS option.
- Deep custom Java connector or BeanShell logic is a hard requirement from day one, and there’s no appetite to design around ISC’s sandboxed extension model from the start.
- Regulatory or contractual constraints specifically require self-managed infrastructure for identity data.
Outside those cases, starting on IIQ in 2026 mainly defers the ISC migration project rather than avoiding it — which is worth weighing against the multi-quarter migration cost described above if cloud is the eventual destination anyway.
Related Reading
- SailPoint IdentityIQ BeanShell Rules, Workflows, and Tasks: A Developer’s Guide — the on-prem rule types this guide’s migration mapping is built against
- SailPoint IdentityIQ BeanShell Rule Cookbook: Provisioning and Certification Rules — working examples of the rule patterns that need rewriting for Cloud Rules
- SailPoint IdentityIQ Aggregation Troubleshooting: Complete Error Guide — the on-prem aggregation model that ISC’s SaaS/VA source connectors replace
