Hi All,
I’d like to provide some context around our planned cutover approach and seek your advice.
We are currently planning the cutover for a new cohort of users that does not yet exist in our production SailPoint tenant (ISC).
As part of the preparation, we have already configured several target sources specifically for this cohort on prod, including:
- Active Directory Source
- Azure Source
- eLearning Source
The schema mappings have been completed, correlation rules have been configured, and aggregations are already scheduled and working to pull accounts/entitlements from the target systems.
At this stage, all accounts remain uncorrelated because we have not yet performed the aggregation of the trusted source.
In addition, we have already configured the Identity Profile, roles, and the required access profiles. The only remaining step is to start the trusted source aggregation which also configured and done the mapping.
Our planned cutover approach is to initiate the trusted source aggregation, with the expectation that when the identity records are created, SailPoint will automatically correlate the existing uncorrelated accounts that were
previously aggregated from the target systems.Could you please let us know whether this is considered a logical and recommended cutover strategy?
During our testing (doing trusted aggregation for one record), we observed that when a trusted source account was aggregated, the identity was created successfully and all existing uncorrelated accounts were automatically correlated (without doing target source aggregation)—except for the Azure account.
The key difference is that Azure accounts are not provisioned by SailPoint. They are created through Azure AD Connect (AADC) synchronization, and SailPoint simply discovers them during aggregation.
Interestingly, if we manually correlate the Azure uncorrelated account through the SailPoint UI, the correlation succeeds without any issues.
Could someone help explain why the Azure account is not automatically correlated when the identity is created, whereas the other sources are?
We would also appreciate any recommendations on how to address this behaviour, along with any best practices for performing this type of cutover.
Thank you in advance for your guidance.
Hi @lalithajay,
Your cutover approach looks reasonable to me and is actually a common way of onboarding a new population into ISC.
In most implementations, we configure the target sources, complete the schema mappings, configure the correlation logic, and perform the target source aggregations first. At that stage, it’s expected that all accounts remain uncorrelated because the identities don’t exist yet.
Once the trusted source is aggregated, ISC creates the identities and attempts to correlate the previously aggregated accounts based on the configured correlation criteria.
The Azure behavior is the interesting part here. I wouldn’t expect the fact that the account is created through AADC instead of SailPoint provisioning to prevent automatic correlation. Since the account can be manually correlated, it confirms that the account itself is eligible to be linked to the identity. However, I would still validate that the configured correlation criteria for the Azure source are correct and that the identity attributes used for correlation are populated before Azure correlation is evaluated.
As part of the cutover, I’d also include an unoptimized aggregation for the Azure source after the trusted source aggregation. This ensures that previously uncorrelated Azure accounts are re-evaluated using the configured correlation criteria.I’ve seen this included as a post-cutover validation step, especially when target accounts have already been aggregated before the authoritative source.
Overall, your approach looks sound. I would just make sure to validate the correlation results after the trusted source aggregation and review any remaining uncorrelated accounts before considering the cutover complete.
Hello Lalitha. Your cutover sequence looks good: aggregate the target sources first, then run the trusted source aggregation to create identities.
On why AD correlates but Azure doesn’t: when ISC creates an identity and provisions an AD account (through roles or access profiles), it’s actively working with that AD account. So correlation gets evaluated as part of that process. With Azure, ISC isn’t doing anything to those accounts because AADC created them. And since nothing changed on the Azure side, a regular optimized aggregation just skips over them.
The fix is to run one unoptimized aggregation on Azure after the trusted source aggregation. This tells ISC to go through every Azure account again and check correlation, even if nothing changed.
Cutover flow: target aggregations → trusted source aggregation → one unoptimized Azure aggregation.
I would also validate the Azure correlation configuration before cutover. Manual correlation only confirms the account can be linked. It doesn’t confirm the automatic criteria will match.
Hi @ssowmya567
Thanks for the feedback given, it helps,
I will try out this in Sandbox region see how it goes
As you suggested plan is to have a unoptimized aggregation for the Azure in the end
Thank you for the answer and detailed explanation.
I was thinking along the same lines regarding Azure, as it is not currently part of any ISC role or access profiles, which limits some of the functionality and options you described.
Given that we have a large number of accounts in Azure, my only concern is how long the unoptimized approach will take to complete. Based on my understanding, this may require a longer processing time.
I will test this approach in the Sandbox environment first and monitor the outcome.
I will provide an update here once I have the results.
An unoptimized aggregation can take longer because ISC reprocesses every account instead of skipping unchanged records. SailPoint does not provide a fixed runtime, so testing it in Sandbox first is the right approach.
I would check the Aggregation History for the duration, accounts scanned, optimization status and any warnings. This should give you a useful baseline before running it in production.
The disableOptimization=true setting applies only to that API call, so your later scheduled or manual aggregations will continue to run optimized.
Hi @punna0001 I just ran an unoptimized aggregation, and it completed within a few seconds. I was expecting it to take at least as long as a scheduled aggregation.
Although this wasn’t an exact production cutover scenario in terms of no of uncorelated accounts, I still didn’t expect it to finish that quickly.
I then recreated a production cutover scenario with (for one user with) two target accounts (Azure and AD) in an uncorrelated state before creating the Identity record. As expected, the AD account correlated immediately, while the Azure account did not. After running the unoptimized aggregation, the Azure account was successfully correlated, which is the expected outcome.
My only question is why the unoptimized aggregation completed so quickly. Other than that, it performed exactly as expected.
The next step is to determine how long the same process will take in the Production environment.
The Azure behavior is somewhat clear purely because similar to AD it does not have roles, etc.
Importantly unoptimized aggregation worked
Good to hear it worked, Lalitha.
The quick completion should be fine as long as Aggregation History shows Optimization disabled, the expected Azure account count was scanned, and the task completed successfully.