SF EC to SAP HCM Core hybrid: What really happens to employee data during go-live?

Introduction:

Customers choose SuccessFactors Employee Central, EC from hereon, for a myriad of reasons. The most common amongst those is the creation of a Global HR system. Global HR system creates the necessary boundary between HR functions and non-HR utility functions like Payroll/Time etc. Whilst such a boundary is great for business, it breaks the Hire to Pay business process into two systems – this necessitates an integration.

With EC earmarked as the global HR system, employees are hired and terminated from this system. If the Payroll system is an SAP payroll system, the integration goes through a well established integration pattern called the “Core Hybrid” Integration. This integration is supported by a time tested yeomanly infrastructure called the Business Integration Builder (BIB) that comes with the add-on PA_SE_IN. Much has been discussed and debated about BIB on this forum and elsewhere. The focus of this blog is not about the intricacies of BIB, but rather how SAP has designed BIB to behave during go-live.

                                                      [Image source: Self made]

BIB supports both Migration and integration:

Customers going live often start their go-live process with a migration from SAP HCM to EC followed by a subsequent integration load from EC to SAP HCM.

Entities commonly involved in the go-live process:

1. Org Objects – Business Unit, Division, Department, Team, custom objects
2. Positions
3. Jobs
4. Employees
5. Interlinked associations

User Persona:

Mary Mustermann: Is an example persona that we will use through-out this blog to articulate the migration/integration runs. Mary has been working for nearly 30 years now. The table shows her job slices (drawn from infotypes 0000/0001 on SAP HCM.)

Event	Start Date	End Date
Hire	01.01.1991	31.12.1998
Data Change	01.01.1999	31.08.2002
Data Change	01.09.2002	31.12.2014
Data Change	01.01.2015	31.12.2018
Data Change	01.01.2019	31.12.2021
Data Change	01.01.2022	31.12.9999

---

Migration :

Migration brings in data from SAP to SF via SAP Infoporter (BIB). Migration brings in only restricted historical data. It’s recommended not to go too far into the history during migration. The extent of data that’s brought in via migration is controlled with the cut-off date.It’s prudent to bring in as little baggage as possible – so, the cut-off date should not be too far away in the past from the date of run.

Migration has two types of runs: full migration and delta migration run.

• Full migration run brings in all data from the cut-off date to the high-date. After the migration run, the SF system is expected to become the master data of records system.
• When that doesn’t happen (e.g. deferred go-live where customers take one legal entity at a time to the cloud) data on SAP continues to grow thereby rendering data on SF stale.
• To solution such a scenario, delta migration is used where only the delta between SAP from date of first migration run is replicated.

Migration deep dive:

• Let’s say Migration run has a cut-off date of 01.01.2021.
• On the date of migration, all objects (O/S/P/C/…) are replicated from SAP to SF. Org objects go in without much fan-fare. Therefore, our focus is on the employee.
  1. All employee records whose end-date is less than the cut-off date is ignored
  2. All future dated employee records are replicated as is.
  3. The employee records where the begin date is less than cut-off date and the end date is greater than the cut-off date – let’s call them current records – are split at the cut-off date. Only the slice with the cut-off date as the begin date is transferred.
  4. The recruit date on SF is defaulted to the cut-off date. This wrecks Talent Modules. To resolve this, it’s a common practise to bring in an initial job slice for all employees from the hire date till the cut-off date. Whilst doing so, we can either choose to have a dummy mass position on SF or flag the position optional during migration. The latter option allows for employee job migration before cut-off date without a position.
  5. The initial job record thus becomes the initial hire record. The event on this record is H and the event reason can be anything to uniquely denote migration. Can be called “MIGRATION” as well.
  6. In wake of all these information, let’s see how Mary gets migrated.

Event	Event Reason	Start Date	End Date
Hire	MIGRATION	01.01.1991	31.12.1998 31.12.2020
Data Change	ignored	01.01.1999	31.08.2002
Data Change	ignored	01.09.2002	31.12.2014
Data Change	Ignored	01.01.2015	31.12.2018
Data Change	Split & ignored	01.01.2019	31.12.2020
Data Change	Data Change Cut-off slice	01.01.2021	31.12.2021
Data Change	Data ChangeFuture dated slice (comes in as is)	01.01.2022	31.12.9999

• Delta Migration Runs: The actual date of migration run can technically be any date on or after the cut-off date. After the migration run, the entities participating in the integration (O/S/P) of the legal entities for which the migration has been done should now be mastered in SF. If not, data continues to grow on SAP necessitating another migration (perhaps delta) run.

---

Integration:

Upon migration, integration runs from SF to SAP. Dubbed the core-hybrid integration, this integration brings in org and employee data regularly to SAP. Akin to migration, integration also starts with a cut-off date. The integration cut-off date is the date after which data changes are replicated to SAP.

Again as with migration, integration also has two types of runs. The very first integration run that levels data between both the systems and subsequent delta replication runs that bring in data on a regular basis. At this stage it’s important to note that:

• Delta runs have to be mandatorily preceded by an initial run.
• The initial run doesn’t necessarily split infotype records at the cut-off date.

Integration deep dive:

1. Let’s say, Integration also has a cut-off date of 01.2021. Integration should have a cut-off date that’s same as migration or later than migration – certainly not before.
2. Full Transmission Start Date: FTSD/Cut Off
   1. Also known as Cut-off date, this is the date from which data slices are transferred to SAP.
   2. This is infact the cut-off date that’s maintained on the transformation template that’s used to query for EC objects (Employee/Org/Position/…)
   3. The cut-off dates on org and employee templates should be the same.
3. Initial Run: Initial run is a data levelling run between EC and HCM. Initial run replicates data slices from the FTSD to high date (31.12.9999) for all entities. This is mandatory. There can’t be a delta run without the initial run.
   1. Data Slices before FTSD are ignored.
   2. Infotype data slices with begin dates before FTSD and end dates after FTSD are by default NOT cut at FTSD. This is as against popular perception. Whether it gets cut or not is purely based on how identical the data is between SAP and SF. Data is sliced ONLY if data in SF has been worked on/changed post the last successful delta migration run => Migrated data is not the same as integrated data.This picture from SAP documentation is often used to misconstrue that Infotypes will be split at the cut-off date. Infotypes will be split only if the data migrated and the data integrated aren’t the same. SAP has even issued an addendum offering clarity on the same.
      
         [Image source of both images : SAP help documentation]
      
   1. So, When does the infotype really split?
      1. It’s possible to migrate all data for legacy reasons, but integrate only parts of data. E.g. 0009 – it’s possible that the migration template copies all 0009 fields as is to SF. But, during integration only IBAN and payment mode (e.g. Uberweisung) is integrated.
      2. Upon migration, a company-wide employee update is performed e.g. username change. This will result in a split of 0105 on SAP.
      3. A future dated slice freshly created in the SF system (that wasn’t a part of migration) after migration will always lead to an infotype split of the currently effective data slice.
      4. Lastly, if it’s explicitly split on SF with a “First Event after Migration” event. Or it’s already split on SAP with a similar event before it’s migrated. Infotype splitting was the norm up until BIB came in. This resulted in retro-payroll issues and downstream interfaces were unnecessarily activated leading to further complications. Hence SAP came up with the initial run concept with BIB that doesn’t necessarily require an explicit infotype split.
4. So, what else does the initial run actually do?
   1. As mentioned earlier, it selectively splits infotype records.
   2. Establishes a last run date for the entities participating in the integration.
5. What is Last Run Date: LRD
   1. The very first last run date is created at the end of the initial run.
   2. Let’s say, the initial run runs on the 1^th Jan 2021 at 13:30, then the LSRD is recorded as 01.01.2021 13:30:00.
   3. During the next run, any delta data growth in EC that occurred after the LSRD is passed on to HCM and again an LRD is recorded. This is used in the subsequent run. Such runs are called Delta Runs.
6. Delta runs: Explained above, these are runs that occur after initial run. The anchor point for the LRD run is the Initial run and hence the FTSD. Without fixing a FTSD there’s no possibility of a delta run.
7. At any point in time, if in case needed, the initial run can be run again. This will again refer to the same FTSD. Hence, FTSD is set in stone for an integration. Once set it can’t be changed.

---

Final Standing of Mary Mustermann’s Data Slices upon Integration:

Migration	Integration
Event	Event Reason	Start Date	End Date	Event	Start Date	End Date	Comments
Hire	MIGRATION	01.01.1991	31.12.1998 31.12.2020	Hire	01.01.1991	31.12.1998	untouched
Data Change	ignored	01.01.1999	31.08.2002	Data Change	01.01.1999	31.08.2002	untouched
Data Change	ignored	01.09.2002	31.12.2014	Data Change	01.09.2002	31.12.2014	untouched
Data Change	Ignored	01.01.2015	31.12.2018	Data Change	01.01.2015	31.12.2018	untouched
Data Change	Split & ignored	01.01.2019	31.05.2020	Data Change	01.01.2019	31.12.2021	If data between SF and SAP differ, then there’s a split. It’s possible that some Infotypes split, whilst others don’t.
Data Change	Data Change Cut-off slice	01.01.2021	31.12.2021	Data Change
Data Change	Data ChangeFuture dated slice (comes in as is)	01.01.2022	31.12.9999		01.01.2022	31.12.9999

---

Conclusion:

• All that is written here is purely based on our (INTEGRTR’s) experiences with LE and upper SME clients.
• Our experience with migration is also purely based on SAP’s BIB/Infoporter. Other migration contrivances like Accenture’s Clone and Test are designed different and could behave different.
• Finally, every customer’s path to migration and succeeding integration is unique. Business sensibilities and ground realities dictate and trump all known wisdom.