SailPoint IIQ to ISC: what nobody tells you about the migration

SailPoint is pushing everyone to Identity Security Cloud (ISC, formerly IdentityNow). The sales pitch is clear: "stop managing servers, we handle it for you, everything is easier." The reality is more nuanced. This article covers what the Sales Engineers do not tell you in the demo.

I have been through three IIQ-to-ISC migrations. Two went well. One did not. The difference was not the technology — it was understanding what actually changes when you move from an on-prem Java platform to a multi-tenant SaaS.

What you actually lose in the migration

Let me be direct: this is not a lift-and-shift. IIQ and ISC share a brand name and a conceptual model. The implementation is fundamentally different.

Custom Java rules. IIQ lets you write arbitrary Java and BeanShell code for provisioning, correlation, validation, and certification. ISC uses a much more constrained rule engine. Your 500-line Java provisioning rule does not migrate. It gets rewritten in BeanShell or replaced with a declarative workflow. That rewrite is the single largest cost item in the migration budget.

UI customization. In IIQ you can modify any JSP, any CSS, any page layout. ISC has a managed UI framework. Customizations go through SailPoint’s extension marketplace or approved connectors. Forget about that custom dashboard you built for the CISO.

Connectors. IIQ had first-class connectors for on-prem systems: JDBC, LDAP, PowerShell, custom connectors via the Connector SDK. ISC uses native SaaS connectors plus a Virtual Appliance (VA) for on-prem connectivity. The connector model is completely different. Some IIQ connectors have no ISC equivalent.

Workflows. IIQ workflows were Java objects with lifecycle hooks. ISC workflows are JSON/YAML declarations. Less powerful, more maintainable, but if you have complex multi-step provisioning with error handling and compensating transactions, prepare for a design rethink.

Reporting. IIQ ad-hoc reporting through BeanShell against the database is gone. ISC has a report builder and APIs. It covers 80% of what most organizations need. The remaining 20% requires custom development or third-party BI tools.

The Virtual Appliance: the SPOF you will not see coming

ISC needs an on-prem Virtual Appliance (VA) to connect to Active Directory, LDAP, databases, and legacy systems. This is the part of the "cloud" pitch they gloss over.

The VA is a single point of failure unless you configure it in HA. And configuring VA HA is not trivial — it requires a load balancer, shared storage, and careful network configuration. I have seen more ISC incidents caused by VA failures than by the ISC cloud itself.

Common VA failure modes:

• The VA loses connectivity to the ISC cloud. Provisioning clusters stall. No errors, no alerts — just a queue of requests that never complete.
• Disk fills up on the VA. Logging and audit data is cached locally before being shipped to the cloud. A full disk stops all processing.
• Certificate rotation on the VA is missed. The TLS handshake with ISC cloud fails silently.

"Cloud" does not mean "zero maintenance." The VA still needs patching, monitoring, disk management, and network troubleshooting — just like any other on-prem component.

The cost of customization

In IIQ, if a feature did not exist, you built it. Java, BeanShell, JSP, custom workflows, custom connectors. The platform was a toolkit. In ISC, you are limited to what SailPoint provides plus approved extensions.

A real example: a complex business validation in a provisioning workflow. Before granting access, the system had to check the user’s training records, their manager’s approval authority, and the application’s current license utilization. In IIQ, this was three hours of Java development with a custom rule. In ISC, the workflow builder supports conditional logic, but not at that depth. The workaround was a custom connector that exposed an API endpoint, plus a mediated workflow. Three days instead of three hours.

The SaaS model wins on maintenance, patching, and uptime. It loses on flexibility. If your organisation has genuinely complex identity processes, that loss of flexibility hurts. Budget for it.

The real migration timeline

SailPoint quotes 6 to 9 months. The reality for an organisation with 50+ managed applications and complex business logic: 12 to 18 months.

Discovery and assessment: 2–3 months. Inventory every application, every rule, every connector, every workflow. You cannot migrate what you have not catalogued.

Reimplementation of business logic: 4–6 months. This is the bottleneck. Rewriting rules, workflows, and connectors. There is no automated migration path for BeanShell to ISC.

VA setup and connectivity: 1–2 months. Installing, configuring, and testing the Virtual Appliance. Including HA if required.

Testing and UAT: 2–3 months. Regression testing every use case. Parallel run with IIQ to validate ISC output matches.

Cutover and stabilisation: 1–2 months. Phased migration of applications, user communication, and post-cutover fixes.

When to migrate and when to wait

Migrate now: small to medium organisation, fewer than 30 connectors, limited custom business logic, small IAM team, want to reduce operational overhead.

Wait or stay hybrid: large organisation with 100+ connectors, very complex Java-based business rules, custom provisioning workflows with error handling, complex ad-hoc reporting requirements, team deeply experienced in IIQ.

Hybrid approach: keep IIQ for complex use cases while migrating simpler processes to ISC. SailPoint supports this partially. It adds operational complexity but reduces risk.

---

ISC is the future of SailPoint. It is a better platform for 70% of organisations. But the migration is not a lift-and-shift — it is a reimplementation. Plan it as such, budget for the rule rewrite, and do not believe the optimistic timeline from the first demo.