Migrating Between Authoritative Sources

Migrating Between Authoritative Sources


For a variety reasons, customers sometimes have a need to switch the authoritative (HR) source that underpins the identity profiles within their tenant. During implementation, this can be due to the true HR source not being available on the same project timeline as the customer’s IdentityNow project, and the customer wants to get started with a “dummy” representation of the data. Or, even after going live, customers' HR teams may choose to replace their previous system with another one.

Whatever the reason, switching authoritative sources can have a significant impact on the customer’s IdentityNow tenant. This guide highlights some things to consider when planning a migration of authoritative sources, and provides some best practices for how to accomplish it successfully.


The most critical piece to plan out when attempting this migration is ensuring that there is correlative data between the existing HR system and the new one. Simply put: there must be some uniquely identifying attribute on users' account records which can indicate that Worker A in the existing HR system is the same person as Worker B in the new HR system.

Most often, the correlative data is something like an employee number or company ID which can be replicated across both HR systems. As long as it is a unique value that only one person in the organization can hold at any given time, and it is consistently captured in both sources, we can be used. Note that we do not recommend using personally identifiable information such as Social Security Numbers or other forms of government ID – the chosen data will be getting read into IdentityNow, so customers should be aware of which data elements can be shared with SailPoint per their organization’s data security policies.

If customers have role-based access control programs in place which automatically assign/revoke access based on job information, we strongly encourage that IdentityNow admins undertake a data comparison exercise to ensure that the information referenced in the role membership criteria remains consistent between both HR sources. If there are variations in the data, this should be captured ahead of time and the impacted roles should be adjusted to accommodate for those differences.

It is recommended that customers plan this migration to take place at a day and time that would impact the least number of users within their organization. If all goes according to plan, the migration should appear seamless to end users. However, should there be any issues, IdentityNow admins will want to ensure they have proper rollback plans in place and sufficient time available to execute those rollbacks.

Lastly, it is always a good idea to engage with SailPoint’s Expert Services organization for migration planning and/or support if there is any part of the process which is unclear.

Migration Steps


  1. Onboard the new HR source.

    1. Just like any new source, customers will want to ensure that they have proper connectivity to the new HR system. It is a good idea to review any out-of-the-box schemas on the new connector to make sure all required attributes are present and/or mapped. And, whether using a direct connection or a delimited file source, we recommend allowing several days' worth of regular aggregations to run to ensure that connectivity/orchestration operations are reliable.

    2. Also, do not forget to configure the proper manager correlation for the new HR source.

  2. Make sure accounts in the new HR source correlate to existing identities.

    1. For both the existing HR source and the new one, set up correlation to the identity attribute which has been identified as correlative during the planning phase. For example, if employeeNumber is going to be the same in both sources, and it is currently mapped to the Employee Number identity attribute for the existing identity profile, then the configuration depicted below should accomplish the proper correlation:image-20210424-135310.png


    2. The new HR source is not authoritative yet, so looking at the uncorrelated accounts report in the new source can help identify problem accounts.

  3. Create a new identity profile based off the new HR source. This will automatically be created with a lower identity profile priority at first, which we will switch shortly. However, before that’s done, we want to ensure that appropriate identity profile values are mapped. From the profile’s Mappings tab, mimic the same mappings from the old HR source's identity profile initially. I.e., for the Source dropdown on each attribute, select the existing HR source, then select the existing HR source attribute and any transforms which are configured for it.

  4. Change the priority of the new identity profile to take precedence over the old identity profile. This is done via the steps documented in this Compass article.

    1. At this point, identities' attributes will still reflect the existing HR data, so there should be no perceived changes to identities yet.

  5. Verify that identities have migrated from the old identity profile to new identity one. You can easily check this by looking at the identity counts for each profile from the Identity Profiles page. You can also leverage Search, as well as spot-checking individual identities.

  6. If role changes are needed (as identified during the planning stage), now would be a good time to make those changes. We recommend adding an “OR” clause to each role which needs updating so that an identity with either the job data associated with the previous HR system or with the new HR system will still qualify for membership. This is critical for the next step, as it will ensure that any data mismatches between systems do not remove users from roles that they should still have.

  7. Start introducing updated attribute changes on the new identity profile. I.e., for a subset of attributes, change the Source dropdown to the new HR source and its related attribute.

    1. We recommend using firstValid transforms on these attributes that first look for data within the new HR system, but will return data from the old HR system if it is not found. Roll these out in a slow controlled manner.

    2. We also recommend updating the more innocuous attributes first before attempting to update those which drive access. Attributes such as Lifecycle State, Job Title, Department, etc., are often inputs into role membership criteria, so those should be updated last (once the migration of less critical attributes is confirmed as working properly).

  8. As a final cleanup item, if all identities have been successfully migrated to the new HR source’s identity profile, the previous profile may be deleted from the system. Also, at the customer’s discretion, the previous HR source can be deleted from the tenant.



Hello Sailors,

Question: we are on IdentityIQ 8.2p1.  Switching authoritative sources.  Is it a good idea to change names of the existing identities before deleting the old authoritative connector? since the old names are ids from the old authoritative source.


The IdentityIQ system seems handling identity renaming well (references, etc.). If you see any potential issues, please let me know. Appreciate it!

Sorry  I do not have an option to delete my previous comments... not to mislead people.

Renaming identities has to be done when all work items and identity requests are completed/closed, otherwise error referencing the identities.  Also I have noticed that after renaming, "Identity History/Snapshots" are not loaded/displayed since IdentitySnapshot is referenced by old identity name. 

Version history
Revision #:
4 of 4
Last update:
‎Jun 05, 2021 07:15 AM
Updated by: