Hello folks, I was wondering how you guys set up synchronization when using multiple platforms ISC and IIQ at the same time? Do you have the authoritative application on both platforms or only in IIQ? - Looking to know more about the best bractices.
Hi @eberteo
In my experience with IIQ to ISC migrations, managing authoritative sources requires a very disciplined approach to avoid data conflicts. Here is how I usually handle it:
-
The Best Case Scenario: Utilize a lower environment for your authoritative source. You can then disable Attribute Sync in one environment (e.g., IIQ) while actively testing the other (ISC).
-
The Single-Source Alternative: If you only have one environment for your source, controlled testing with a specific test identity is the only viable path. This allows you to validate the logic without affecting the broader population.
I strongly advise against running Attribute Sync in both environments simultaneously. I have yet to see a scenario where dual-syncing doesn’t cause significant data integrity issues.
Hey @trettkowski thanks for your prompt reply.
So you would say is better to have one auth source either in ISC or in IIQ but not in both? And avoid sync at all cost, huh?
In your experience have you seen organizations that can keep up with both platforms at the same time?
Ideally, having separate authoritative sources for every environment would be best (as it allows Attribute Sync to be enabled everywhere), but most organizations can’t accommodate that level of infrastructure.
In reality, IIQ and ISC usually share a lower environment source during the migration period. Here is how I’ve successfully managed that:
-
The Go-Live Plan: Keep Production pointed at IIQ, then perform a hard cutover to ISC during the migration window.
-
The Testing Strategy: For lower environments, I’ve found it manageable to share a source as long as the engineer onboarding the app to ISC is diligent.
-
The Protocol: You must disable Attribute Sync in IIQ whenever you are actively testing sync logic in ISC.
Because this is happening against a lower-level authoritative source, the risk is relatively low, provided there is clear communication within the team to avoid “data flapping” between the two systems.
I feel like your responses are going in a slightly different direction. Not sure if you have used AI, but sounds like. I’m trying to get a personal POV on how to keep up both platforms at the same time?
Sorry for the confusion, I may have misunderstood your question.
When you say keep up, do you mean having both IIQ and ISC live in production at the same time? Typically, IIQ→ISC migrations are done where IIQ is live in production then at the same time, you are onboarding those apps into ISC (lower environment). Once everything is onboarded into ISC, you switch over and turn off IIQ.
Initially I was thinking to keep both sync, IIQ and ISC at the same time, but I don’t see no point of doing so. Therefore, I was wondering if you, in your expertise do you go from IIQ to ISC or from ISC to IIQ most of the times. Or under what scenario we keep both environments in production.
Let’s say the system depends on AD, Workday datasets.
It’s always been IIQ to ISC. I’ve heard orgs ask about potentially running them in parallel since IIQ has some features that ISC still doesn’t have, but in practicality, I’ve never seen an org attempt it.
The only scenarios that I would envision you would run in parallel would be if you had some piece of customization in IIQ that wouldn’t work in ISC. For example, you had some complex LCS workflow or Certification process that involves heavy amounts of code and logic that is not yet possible with ISC.
Ideally, you still would want users to come to one central place for certifications, access requests, etc. so any backend only processes could be handled in IIQ while users go to ISC or vice-versa.
In summary, running both in parallel long term has more downsides than upsides in my opinion. The main advantage of moving to ISC is that you don’t need to maintain upgrades and infrastructure, but you lose that advantage when still having IIQ live.
My recommendation is to have setup and configure all authoritative sources configured in IIQ. Setup ISC authorities source as IIQ.
Thanks Tyler, appreciate the update. I’m currently working on an integration with ServiceNow, and noticed that there are plugins available on SNow side, however they are expensive. Have you happened to do that integration using Portal or other resources? - Not looking to acquire another SN licenses for now
Are you referring to the Service now Service Config plugin which is basically used as request interface to place requests from service now while the fulfilment happens through SailPoint
Hello @uday_kilambi , thanks for reaching out. Yes, am looking for the SN interface while fulfillment happens in SP.
I believe the interface that you’re referring to it’s the ISC Service Catalog (Which I think it’s a Portal Interface w widgets). However, it is a paid service and am not looking to invest in another license. Are you familiar with a different work around?
