Migration

IdentityIQ to ISC: Why Migration Is Not a Lift-and-Shift

Why SailPoint IdentityIQ to Identity Security Cloud migration requires capability mapping, target-state architecture, redesign, testing, and operational validation.

September 11, 2026 · 2 min read

A mature IdentityIQ environment contains years of architecture decisions, connector behavior, custom logic, operational practices, role design, certification behavior, provisioning rules, and integration dependencies.

The migration problem is therefore not:

How do we copy IdentityIQ?

The better question is:

How should each required business capability be implemented in ISC?

Start With Capabilities, Not Objects

Inventory applications, identity attributes, lifecycle behavior, provisioning operations, rules, workflows, roles, certifications, integrations, reports, operational dependencies, and support processes.

Then classify each capability:

  • Recreate using native ISC configuration
  • Redesign for ISC architecture
  • Replace with an ISC-native pattern
  • Externalize to another integration
  • Retire because it is no longer required

Custom Logic Is Where Complexity Hides

BeanShell rules, workflows, provisioning-plan manipulation, plugins, forms, scripts, and application-specific exceptions often contain business requirements that are not obvious from the application XML alone.

Each one requires an explicit target-state decision.

Migration Sequencing Matters

Applications do not exist in isolation.

Identity attributes feed correlation.

Lifecycle state drives access.

Roles depend on entitlements.

Workflows call integrations.

Provisioning depends on infrastructure and target systems.

Migration planning should therefore account for dependency order and coexistence between IdentityIQ and ISC.

Validate Behavior, Not Just Configuration

A source that successfully connects is not necessarily migrated.

Validation should include:

  • Aggregation
  • Correlation
  • Account creation
  • Attribute updates
  • Disable and enable
  • Entitlement changes
  • Failure scenarios
  • Lifecycle processing
  • Access requests
  • Certifications
  • Operational recovery

The goal should be to preserve the business capabilities that matter while improving the target architecture rather than reproducing historical IdentityIQ complexity in a new platform.

Share this article LinkedIn Email

Have a question about this topic?

Ask how this applies to your environment or identity program.

Want to discuss this in your environment?

Schedule a consultation to talk through your architecture, implementation, testing strategy, or migration.

Schedule a Consultation →