Skip to main content
Version: On prem: 15.0.3

HR migrations

A best practice guide to changing the HR integration.

This document is a guide on migrating from one HR source to another. As such, there are two different relevant scenarios covered by this document:

  1. Switching from one HR source to another.
  2. Switching the collector/connector to the same HR system (e.g. custom SSIS to standard REST).

The scenario of adding a secondary HR source is not covered by this document. In terms of the steps required to migrate the HR data source, both scenarios work very similarly. The main differences are the following:

Scenario 1:

  • Key matching: Ensure that any objects that need to be taken over have an identical key value in both systems.
  • Object deletion: Delete any objects which are not taken over by the new HR system. Pay special attention to the following:
  • When deleting identities, make sure to follow identity deletion best practices and make any relevant stakeholders aware of the consequences.
  • Before deleting contexts, ensure that any references to them are considered carefully. This is especially relevant for the following objects:
    • Assignments policies
    • Event definition filter conditions
    • Relevance in RoPE calculations

Scenario 2:

  • Filtering: It is important to ensure that filtering is set up in the same way for the old and the new system so that no irrelevant objects are created and no existing objects are deleted.
  • Custom logic: Any custom logic built into the old collector must be replaced by import expressions or event definitions.

Principles and configuration areas​

The following principles are relevant when performing an HR migration:

  1. Take over existing objects.

    • Take over as many of the existing objects with the new system as possible. This will ensure continuity in reports and minimize data handling maintenance.
    • Where this is not possible ensure proper deletion of the old objects and replacement of any references.

  2. Join new identities to old records.

    • Set up the identity join rules and identity picker settings to join incoming identities from the new HR system to the records originating from the old HR system.
    • This will keep the “one primary identity per person” rule intact and make sure the identities are taken over both on the enterprise server and in ODW.

  3. Ensure property value congruence.

    • When taking over objects with the new system, make sure that the property values on those objects are mapped to be identical. This will ensure that no unintended changes are provisioned to downstream systems.
    • Where this is not possible, impacts on downstream systems and processes in Omada must be analyzed to avoid unintended behavior.

The following areas are most relevant when configuring the migration:

  • Warehouse to portal mappings: It is recommended to create new mappings for all objects imported from the new system, and filter them to only include objects from that system.
  • Identity join rules: Identity join rules must be set up to ensure proper identity joins in ODW.
  • Customer settings: The identity picker customer settings must be configured to account for having two HR systems in ODW.
  • System onboarding page: The new HR system must be onboarded as per usual. Import mappings should be configured so that property values are congruent with the old system.

Configuration steps​

Configure new HR system​

  1. Onboard the new system as usual.
  2. When importing the property values, ensure they line up with the existing values already in the solution.
  3. When creating the queries and mappings, ensure that the key values line up with the keys of the existing values in the solution. The keys are relevant for matching the imported objects with the existing objects.
  4. Do not run an import until step 2 is completed.

Configure identity joins​

  1. The identity join is used to make Omada understand that two identity records originating from different systems are actually the same identity. This is done by providing a key value that is evaluated across systems.
  2. Ensure that the column stated in the Identity join rules on the Omada Identity system contains the same value for the old and new identity records. This will ensure that the new records join to the old ones, using the same OISID. The standard column is UID.
  3. Identity picker rules (ODWIdentityPickerRules customer setting):
    • Remove ValidFromTo from the customer setting if present to allow for out-of-validity records to be joined. This setting determines which of the joined records can "win" and become the primary record pushed to the enterprise server. When present, it prevents any out-of-validity records (outside valid from – valid to) from becoming primary.
    • Remove ActiveStatusValues from the customer setting if present to join all records regardless of status in ODW. This setting determines which of the joined records can "win" and become the primary record pushed to the enterprise server. When present, it prevents records that don’t have one of the specified statuses from becoming primary. The statuses are specified in the ODWRulesActiveStatusValues customer setting.
    • Ensure SourceSystemNames is present in the customer setting.
  4. Source system names (ODWSourceSystemNames customer setting) - ensure that the new HR system is listed first.
Joining expired records

Omada will never consider expired records in ODW for the identity join. This leads to an issue in the below scenario:

  • Identity is onboarded and offboarded as per usual in the old HR system.
  • The row for this identity in ODW is expired.
  • The identity is rehired in the new HR system.
  • The new record does not join to the old record, as the old record is expired.
  • A new identity is created on the enterprise server (this might fail if the identity IDs are the same)
  • The person now has two identities on the enterprise server, one active, one terminated.
  • The above scenario can not generally be avoided.
  • DO NOT run an “empty” import from the old HR system to expire all records, as this will increase the occurrence of this issue.

Configure Warehouse to Portal mappings​

  1. Create a new mapping for each relevant object type. Filter each mapping to only import objects from the new HR system. Use ODWSourceSystemName for filtering as it is always aligned between environments. Avoid using ODWSourceSystemId.
  2. Create each mapping with a MIGRATION prefix or similar to make it easy to distinguish the old and the new mappings.
  3. For identities, make sure you use OISID as the key to ensure that the right identity objects are updated/created on the enterprise server.

Configure other features not yet covered​

Configure any other features that need to be handled by the new integration (for example: writeback).

Test​

  1. Run imports:

    • Staging only to validate data is coming in as expected
    • Staging and ODW to validate identities join correctly and context assignments are handled correctly.
    • Full import. Here it is advisable to filter each new warehouse to portal mapping down to one specific object you test with. This is done to avoid polluting the test environment with faulty data in case of configuration mistakes which would need to be cleaned up.

  2. End-to-end/regression testing:

    • Test all functionality that is used in the solution. As the HR data is the source data for most IGA processes, it is imperative that this testing is as thorough as possible to catch any issues.

Go-live (production implementation)​

Prerequisites and best practices:

  • Make a backup of all databases (ESARC, Omada Data Warehouse, Omada Data Warehouse Master, Omada Data Warehouse Staging, OISES, Omada Provisioning Service, RoPE, Source System Data DB).
  • Put all systems where provisioning is enabled in review mode.
  • Disable the old Import profile for the previous HR system. Make sure no imports of the old HR system are run automatically going forward.
  • If any systems are already in “Review mode” the provisioning queue must be emptied.
  • The latest rows from the old HR system should not be expired. If they are expired, the new data will not be taken over in ODW. If all rows have already been expired, a new import from the old HR system should be performed.

Example runbook​

  1. Import changesets – your changesets should be recorded in a configuration environment and transferred to a testing environment.

  2. Confirm your connection details.

  3. Verify that all old HR W2P mappings are disabled. Only relevant old mappings like system, resources, etc. should be kept enabled. Make sure all new W2P mappings are enabled.

  4. Verify your join rules - make sure you are joining on the correct property. You can have more than one rule.

  5. Run a staging import – the store data for reporting checkbox should not be selected.

  6. Perform a data check:

    • Compare the data between the old HR and the new HR.
    • The identity count should look similar in magnitude.

  7. Perform an ODW import with RHW– store data for reporting checkbox selected. The checkbox Prepare data for processing must NOT be checked.

    • Make sure the identities are joining. They should have the same OISID.
    • Check all the columns in the database to see if all the data is there and is correct.

  8. Enable any value-generating event definitions that are part of the configuration.

  9. Run a full import – verify that the checkbox Store data for reporting is selected. Tick the Prepare data for processing checkbox. This will import data into the portal.

  10. In the portal, check that all Data object types were correctly imported (identities, Org. units, locations, etc.).

  11. If the import returns with warnings then there may be some data issues that need to be corrected by the HR system owners.

  12. Confirm that identities are coming in with the new system ID (business key). There should be a change to every active identity, as the business key changed.

  13. Disable all task mappings if not yet done – note which are enabled so you can revert the changes later. (for on-premise: stop the OPS service).

  14. Expire all provisioning claims and clear the OPS queue.

  15. Reenable TMs.

  16. Run imports from all target systems.

  17. Recalculate all identities.

  18. Review OPS queue with the Customer – verify that no unintended jobs caused by changes to the HR data are present.

  19. Remove review mode from the target systems.