Moving from IIQ to ISC as an Experienced Developer: What Changes Day to Day

Most IIQ-to-ISC content is written for the enterprise buying the migration. This guide is written for the developer who will do the work: what you open in the morning, what you can no longer touch, and what you build instead. If you are still deciding between the platforms, read SailPoint IIQ vs ISC first; if you want the career and job-market angle, see IIQ to ISC migration skills. This page covers the daily-work angle, drawn from SailPoint’s developer documentation and threads on the SailPoint Developer Community (checked 5 November 2026).

What Actually Changes Day to Day for an IIQ Developer in ISC?

For a SailPoint IdentityIQ developer, moving to Identity Security Cloud changes the working surface more than the concepts: you stop editing XML objects and BeanShell on servers you control, and start configuring a multi-tenant SaaS platform through transforms, workflows, APIs and SailPoint-managed releases.

Your IIQ instincts about identity cubes, aggregation, correlation, roles and certifications still apply. What disappears is the freedom to reach into the platform. The table below puts the daily tasks side by side.

What Happens to Your BeanShell Rules in ISC?

SailPoint Identity Security Cloud still uses Java BeanShell for rules, but they are a last resort: cloud rules run in a restricted multi-tenant context, cannot commit transactions or save objects, and every cloud rule must be reviewed by SailPoint before deployment.

SailPoint’s developer documentation splits ISC rules into two families. Cloud rules run in the cloud, calculate values and can read the data model (for example IdentityAttribute and Correlation rules). Connector rules run on the virtual appliance, cannot query the ISC data model and cannot open new connections. Certification Exclusion, Identity Selector and Integration rules are deprecated, and any rule type outside the two families is unsupported.

The workflow change matters as much as the language. SailPoint states that cloud rule reviews require an expert services contract, target about 24 hours on weekdays, and that deployment windows need at least 48 hours’ notice. Approved rules can be promoted from a non-production tenant to production with the sp-config API. In IIQ you edited a rule and tested it in minutes; in ISC you design so that you rarely need one. Read SailPoint ISC transforms explained — most attribute logic you once wrote as an IIQ rule becomes a transform.

How Do Plugins, Workflows and Custom Objects Change?

SailPoint ISC does not support IIQ plugins, and custom objects and custom task definitions have no direct equivalent, so that functionality is redesigned with ISC workflows, REST APIs and external services rather than ported.

Two practitioners on the SailPoint Developer Community describe the same pattern. One notes that complex certification exclusion logic and identity-selector logic that depends on relationships between identities, such as a manager’s attributes, may not be feasible in ISC, and that policy rules are native configuration only. Another names architectural flexibility as the hardest thing to replace: custom objects, custom tasks and direct access to identity data usually have to be rebuilt as workflows, API calls and small external services.

A candid counterpoint from the same community: one developer who has worked with both says they miss IIQ’s customisation and that some complex processes ended up built outside the platform. Treat that as a design input, not a reason to avoid ISC. The skill that earns a premium is knowing early which requirement belongs in a transform, which in a workflow, and which needs an external service.

How Do You Debug and Deploy When You Cannot Touch the Server?

In ISC you debug through the admin console, search, aggregation and provisioning results and the SailPoint APIs rather than server logs and the database, and you deploy with Configuration Hub, the sp-config API and VS Code extensions instead of XML imports.

This is the biggest daily adjustment. One community architect describes ISC as a more controlled SaaS model with less of the direct inspection IIQ administrators are used to, and cloud-rule debugging depends on SailPoint Support because they hold access to the rules. A practical consequence: log your intent in transform and workflow names, keep configuration in version control, and promote between tenants rather than hand-editing production. A community checklist for building a tenant in stages starts with admin accounts and branding, then virtual appliances, the authoritative HR source and identity profiles, and only then connectors, access profiles, roles, workflows and certifications. For the on-premises piece, see what a virtual appliance is in SailPoint ISC.

Which IIQ Skills Carry Over to ISC?

Your IdentityIQ knowledge of application onboarding, correlation, lifecycle events, roles, policies and access certification carries over as concepts; what you rebuild is the implementation layer in transforms, workflows and APIs.

If you learned these topics through the 15-module IIQ curriculum, you already have the vocabulary. Our IIQ to ISC migration timeline explains why both skill sets stay in demand for years.

How Should an Experienced IIQ Developer Prepare for ISC?

An experienced IIQ developer can prepare for ISC by mapping existing IIQ customisations first, then learning identity profiles and transforms, then practising workflows and API calls, rather than trying to port rules line by line.

1. Inventory your IIQ customisations. List every rule, workflow, plugin and custom object, and tag each as transform, workflow, API/external service, or retire. Community advice is the same: map what your IIQ setup does before replicating it.
2. Learn identity profiles and transforms. This is where most attribute rules end up. Follow how to learn SailPoint ISC.
3. Practise workflows and REST calls. Rebuild one real IIQ process, such as a joiner or approval flow, as an ISC workflow plus an API call.
4. Learn the delivery path. Understand Configuration Hub, sp-config and when a cloud rule is unavoidable, since it needs SailPoint review.

IAM Careers’ live online SailPoint ISC course covers identity profiles, transforms, aggregation, access profiles and certification through trainer-led demonstrations and guided hands-on practice. It is independent training, not an official SailPoint programme.

Does Pay Change When an IIQ Developer Adds ISC?

Public salary aggregators do not show a clean ISC-versus-IIQ pay gap; Salary.com put the average US SailPoint developer salary at $100,844 on 1 November 2026, while AmbitionBox showed IIQ developers with 1–5 years of experience in India at roughly Rs. 2.9–10 lakh per year.

We found no comparable UK figure for this exact title, so none is quoted. Aggregators disagree widely (our dual-skill salary analysis used other sources and showed higher bands), which is why experience and employer matter more than any single number. See SailPoint ISC jobs in India for demand.