Migrating from SailPoint IIQ to Identity Security Cloud

SailPoint Identity Security Cloud (ISC, formerly IdentityNow) is not IdentityIQ moved to the cloud - it is a different runtime with different extensibility patterns, different operational disciplines, and no one-to-one mapping for BeanShell rules, Task Definitions, or custom workflows. GCA leads SailPoint IIQ-to-ISC migrations with that distinction designed into the engagement from day one, so the migration is planned as a re-architecture, not a lift-and-shift.

Book a Consultation Explore Capabilities

Why Organizations Migrate from IIQ to ISC

Organizations running SailPoint IdentityIQ evaluate migration to Identity Security Cloud for a mix of reasons, and the driver shapes the migration plan more than most teams expect. Some are responding to SailPoint's product direction - IdentityIQ remains supported, but SailPoint's investment and new capability development are concentrated in Identity Security Cloud. Others are trying to reduce the operational burden of running and patching an on-premises or self-managed platform, shifting that responsibility to SailPoint's SaaS operations. Still others are pursuing ISC's API-first architecture and event-driven extensibility model because it fits better with a broader cloud and DevOps strategy than IIQ's BeanShell-and-XML customization model.

Whatever the driver, the constant across every IIQ-to-ISC migration we have led is that this is meaningfully different from a version upgrade. IdentityIQ and Identity Security Cloud are different runtimes, with different extensibility surfaces, different customization patterns, and different operational disciplines. Organizations that treat this as "IIQ but hosted by SailPoint" consistently underestimate the redesign work required and discover the gap mid-migration, when it is more expensive to correct.

This is a specific case of a broader pattern GCA sees across every IAM migration we lead, not only SailPoint engagements: a sound IAM migration strategy treats the target platform's native architecture as the design constraint, not the source platform's configuration as the template to replicate. The same discipline that governs an IAM cloud migration between any two identity platforms - honest inventory, artifact-by-artifact mapping, and phased cutover with audit continuity - applies here, adapted to what is specific about IIQ and ISC.

What's Actually Different

IdentityIQ is a Java application customized primarily through BeanShell scripting, XML-based Task Definitions, and a rule-based workflow engine, with broad extension points that let a developer run essentially arbitrary logic in-process. Identity Security Cloud is a multi-tenant SaaS platform extended through REST APIs, Transforms, Workflows built on a visual and JSON-based designer, and Event Triggers that respond to identity lifecycle events in near real time. These are not two dialects of the same language - they are different architectures for solving the same governance problems, and artifacts from one do not translate mechanically to the other.

The extensibility difference is the one that catches teams off guard. In IIQ, when configuration cannot express a requirement, you write a BeanShell rule and it runs. In ISC, SailPoint's own guidance is to reach for a Transform first - a declarative, JSON-based construct that any administrator can author, test, and change through the REST API with no vendor involvement. Code-based extension is the exception, not the default: ISC Cloud Rules run in a deliberately restricted context (they calculate values and read the identity model, but cannot commit transactions or save objects), and because a badly written rule could affect other tenants, SailPoint reviews every Cloud Rule before it is allowed to deploy. The practical consequence is that a meaningful portion of heavily customized IIQ logic has no drop-in ISC equivalent and must be re-architected around native platform features - SailPoint characterizes this as a redesign of a significant share of custom IIQ logic during migration, not a translation of all of it.

This is why GCA insists on an explicit artifact-mapping exercise before any ISC configuration work begins. BeanShell rules that implement custom identity attribute logic, provisioning decisions, or approval routing are decomposed into the right ISC construct for what each one actually does: a Transform for attribute calculation and reshaping, a Workflow for multi-step process and approval logic, an Event Trigger handler for reactive automation, and a reviewed Cloud Rule only for the narrow cases a Transform genuinely cannot cover. Some logic maps cleanly; some maps to a different construct than teams expect; and some has no equivalent and has to be rebuilt a different way or retired. Scheduled Task Definitions become either native scheduled operations in ISC or Workflow-driven processes, depending on whether the task was a batch operation or an event-driven process wearing a scheduled-task costume. Extended identity attributes, which IIQ handles through its identity cube schema, are rebuilt as ISC identity attributes shaped by Transforms - which requires understanding not just what data an attribute holds today, but where that data will come from once IIQ is no longer the system doing the calculation.

GCA's Migration Approach

Assessment of Existing IIQ

An honest inventory of what is actually running: the connector portfolio, custom BeanShell rules and workflows, the role and policy model, certification campaign design, upstream and downstream integrations, and the operational artifacts (scripts, scheduled jobs, monitoring) that keep the environment running today. This surfaces what is load-bearing, what is dormant and safe to leave behind, and what is technical debt the organization should not carry forward into ISC.

Full connector and application inventory with usage and criticality assessment
BeanShell rule and custom workflow catalog, categorized by function
Role model, SoD policy, and certification campaign documentation review
Identification of dormant configuration safe to retire rather than migrate

Mapping IIQ Artifacts to ISC

Every BeanShell rule, Task Definition, and extended attribute is mapped to its ISC equivalent - Transform, Workflow, Event Trigger handler, reviewed Cloud Rule, or native platform feature - before configuration work begins. Where an artifact has no ISC equivalent, that is documented as a re-architecture item rather than glossed over. GCA produces an explicit artifact-mapping document that the client's team reviews and approves, so there is a shared, written record of how each piece of custom logic is being rebuilt rather than an assumption that it "just moves over."

Artifact-by-artifact mapping: BeanShell rule to Transform, Workflow, Event Trigger, or reviewed Cloud Rule
Explicit flagging of logic with no direct ISC equivalent that must be re-architected or retired
Task Definition mapping to native ISC scheduled operations or Workflow-driven processes
Extended attribute redesign using Transforms and ISC identity attribute configuration
Written mapping document reviewed and approved before build begins

Phased Migration and Parallel Run

Most IIQ-to-ISC migrations are not a single cutover event. GCA typically phases the migration by source system or user population, running IIQ and ISC in parallel during the transition. This validates ISC's actual behavior against real production access patterns, surfaces and reconciles differences before they affect users, and keeps a narrow rollback path available if a phase does not behave as expected.

Phasing by connected system or user population rather than a single all-at-once cutover
Parallel-run validation comparing IIQ and ISC provisioning and certification behavior
Identity correlation continuity so identities are recognized consistently across both platforms during transition
Certification campaign continuity designed into the phased plan, not bolted on afterward

Audit Continuity Through Transition

Regulated organizations cannot pause their compliance program for the duration of a platform migration. GCA designs the migration sequence so certification cadence, segregation-of-duties enforcement, and the audit-evidence stream remain continuous throughout - reviewers see consistent campaigns regardless of which platform is running underneath, and auditors retrieve consistent evidence regardless of migration phase.

Certification campaigns scoped and scheduled against the organization's actual audit calendar
SoD policy parity validated between IIQ and ISC before cutover of each phase
Evidence production tested to confirm continuity across the platform transition
Migration plan reviewed against upcoming audit windows to avoid scheduling conflicts

Common Migration Pitfalls

Most of the migration problems we get called in to fix after the fact trace back to a handful of recurring mistakes. Treating the migration as a version upgrade rather than a re-architecture is the most common - it leads teams to underscope the effort, discover mid-migration that a meaningful share of their BeanShell logic has no direct ISC equivalent, and either rush a poor translation or blow the timeline. A close second is migrating technical debt wholesale: dormant connectors, unused custom rules, and role model cruft that nobody has questioned in years get carried into ISC simply because "that's what IIQ does today," when migration is precisely the moment to leave that debt behind.

Underestimating identity correlation complexity is another recurring issue - if IIQ's correlation logic depended on custom rule behavior that is not faithfully reproduced in ISC, identities can silently double-provision or fail to match during the parallel-run phase, and that failure mode is not always obvious until an access review surfaces it. Finally, skipping the audit-continuity planning step is a mistake regulated organizations specifically cannot afford: a certification campaign gap or an evidence-production interruption during migration is exactly the kind of finding a NERC, SOX, or HIPAA auditor will flag, migration notwithstanding.

GCA's assessment and artifact-mapping phases exist specifically to catch these failure modes before they become production incidents - the goal is a migration plan reviewed and approved by the client's team, not a set of assumptions discovered in production.

What GCA Brings

GCA's SailPoint practice covers both platforms - IdentityIQ and Identity Security Cloud - which matters directly for migration work. A migration team that only knows ISC cannot accurately assess what a BeanShell rule was actually doing before deciding how to rebuild it in a Transform or Workflow; a migration team that only knows IIQ cannot design an ISC target architecture that uses the platform the way it is meant to be used rather than recreating IIQ's patterns inside a different runtime. We bring both sides of that translation to every migration engagement, along with direct delivery experience across the regulated verticals - healthcare, financial services, energy and utilities - where migration cannot come at the cost of certification continuity or audit evidence.

Frequently Asked Questions

Is migrating from IdentityIQ to Identity Security Cloud the same as a version upgrade?

No. IdentityIQ and Identity Security Cloud are different runtimes with different extensibility models - BeanShell rules, XML Task Definitions, and rule-based workflows in IIQ versus Transforms, JSON/visual Workflows, Event Triggers, and a limited set of reviewed Cloud Rules in ISC. A migration requires re-architecting custom logic, not simply upgrading a version number. Organizations that treat it as an upgrade tend to discover the gap mid-project.

Do our custom BeanShell rules migrate automatically to ISC?

No. There is no automated, one-to-one conversion from BeanShell rules to ISC's extensibility model. Each rule needs to be understood for what it actually does - attribute calculation, provisioning decision, approval routing, or something else - and rebuilt using the appropriate ISC construct. SailPoint's guidance is to use Transforms first because they are self-service and require no vendor involvement; a Cloud Rule is used only when a Transform genuinely cannot do the job, and Cloud Rules run in a restricted, read-only context and must be reviewed by SailPoint before deployment. Some heavily customized BeanShell logic has no ISC equivalent at all and must be re-architected around native platform features. GCA's artifact-mapping phase makes that determination rule-by-rule before any ISC configuration begins.

Can we run IdentityIQ and Identity Security Cloud at the same time during migration?

Yes, and for most organizations we recommend it. A phased migration with IIQ and ISC running in parallel - by source system or by user population - lets you validate ISC's actual behavior against real production data before fully cutting over, and preserves a rollback path if a phase does not behave as expected. A single all-at-once cutover carries materially more risk for regulated environments.

How do we avoid a gap in certification campaigns or audit evidence during migration?

By designing the migration sequence around your existing audit calendar and certification cadence from the start, rather than treating compliance continuity as an afterthought. GCA validates SoD policy parity and certification behavior between IIQ and ISC before cutting over each phase, so reviewers and auditors see continuous, consistent evidence regardless of which platform is running the campaign at any given point.

Does all of our IIQ configuration carry over to ISC?

No, and treating migration as the moment to leave configuration behind is usually the right call. SailPoint's own guidance is that a meaningful share of heavily customized IIQ logic needs redesign in ISC because some BeanShell extension points simply do not exist in the multi-tenant SaaS model. GCA's assessment phase specifically flags dormant connectors, unused custom rules, and stale role model artifacts that are safe to retire, so the target ISC environment reflects what the organization actually needs today rather than two decades of accumulated IIQ configuration.

Plan Your IIQ-to-ISC Migration

From artifact mapping to phased, audit-continuous cutover - GCA leads SailPoint migrations with the platform difference designed into the plan from day one.

Book a Consultation All SailPoint Solutions