Migrating Between Authoritative Sources

[#1]

Overview

For a variety reasons, customers sometimes 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 they want to get started with a “dummy” representation of the data. Or, after going live with IdentityNow, 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.

Planning

The most critical aspect of planning a migration is establishing correlative data between the existing HR system and the new one. Simply put, there must be a unique 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, organizations correlate with data like an employee number or company ID that 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, it 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 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 that automatically assign or 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, they should be captured ahead of time and the impacted roles adjusted to address those differences.

It is best practice to schedule the migration for a day and time that impacts the least number of users within your organization. If all goes according to plan, the migration is seamless to end users. However, in case of any issues, IdentityNow admins should ensure that proper rollback plans are in place and sufficient time is available to execute those rollbacks if needed.

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. As with any new source, ensure that you 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.

   2. Whether using a direct connection or a delimited file source, allowing several days' worth of regular aggregations to run lets you confirm that connectivity and orchestration operations are reliable.

   3. Be sure to configure the proper manager correlation(s) for the new HR source.

2. Correlate accounts in the new HR source to existing identities.

   1. For both the existing HR source and the new one, set up correlation to the identity attribute that your planning phase identified as correlative data. For example, if employee number is going to be the same in both sources and it is currently mapped to the Employee Number identity attribute in the existing identity profile, then the configuration below accomplishes the proper correlation.

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

3. Create a new identity profile based on the new HR source. At first, the new identity is automatically created with a lower identity profile priority. Before switching priorities, make sure that the appropriate identity profile values are mapped.

   1. Navigate to the profile’s Mappings tab and mimic the same mappings from the old HR source's identity profile. In 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 by following the steps documented in this Compass article.

   1. At this point, the identities' attributes still reflect the existing HR data, so changes to identities are not perceived yet.

5. Verify that identities have migrated from the old to the new identity profiles.

   1. Easily check 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 change needs were identified during the planning stage, now is a good time to make those changes.

   1. Add an “OR” clause to each updated role so that an identity with either the job data associated with the previous HR system or with the new HR system will qualify for role membership. This is critical for the next step, as it ensures 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. For a subset of attributes, change the Source dropdown to the new HR source and its related attribute.

   1. Best practice is using firstValid transforms on these attributes. They 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. Update 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 after the migration of less critical attributes is confirmed to be working properly.

8. As a final cleanup item after all identities have been successfully migrated to the new HR source’s identity profile, delete the previous profile from the system. At your organization's discretion, the previous HR source may also be deleted from the tenant.