IDP - Employee Central Data Migration Strategy- V5.0 (2)

Implementation Design Principle
PUBLIC
SAP SuccessFactors Employee Central: Employee

Data Migration Strategy and Considerations
Document Details
Name Objective Audience
Employee This document provides critical SAP SuccessFactors Customers: IT and
Central: implementation recommendations to be HR professionals.
Employee Data considered for Employee Central based
Migration Strategy Employee Data Migration. SAP SuccessFactors Implementation
and Partners: Consultants, solution architects,
Considerations and project managers
Change Log
Version Date Author Description
1.0 15th July 2020 SAP SE Initial version
2.0 23rd August 2021 SAP SE Version was
updated with
details on time
data load (Section
6.3) and data
quality validation
post successful
migration (Section
6.6)
3.0 18th March 2022 SAP SE Updated Section
5.3.2.2 with the
comprehensive
import sequence
of employee
templates
5.0 2nd September SAP SE Broken links fixed
2022
Supported Releases
Product Release - From Release-Valid
till
SAP SuccessFactors Employee Central 2005
Contribution
Role Name Organization
Author / Owner SAP SuccessFactors Product Management SAP SE
Author Timothy McAlpine Rizing
Author Jeewan Patni Capgemini
Contributor Paul Nolan SAP PS
Contributor Tanya Page SAP PS
Contributor Victoria Cole SAP PS
Reviewer Anamarija Crncic-Samsa Pentos
Reviewer Prakash Saminathan E&Y LLP
Reviewer Gauthier De Smet Comentec
The recommendations in this document are based on the functionality available up to SAP
SuccessFactors release mentioned above. Future functionality can impact the recommendations
provided by this document. We strive to keep these recommendations up-to-date, however, in case you
find that recent new functionality has not yet been considered in the latest version of this document,
please reach out to your Customer Success Manager / Partner Delivery Manager or send an email to
SAPSuccessFactorsIDPDoc@sap.com.
Implementation Design Principles (IDPs) for SuccessFactors solutions are delivered by SAP for helping
customers and partners on how to choose the most appropriate strategy and solution architecture for
SuccessFactors implementations. IDPs are compiled taking into consideration the experience of many
implementation projects and addressing frequent business requirements as well as real-life
implementation challenges. They are continuously reviewed and updated as product functionality
evolves. In addition, the reader is advised to read and familiarize with essential and additional product-
related documentation which includes Implementation Guides, SAP Notes, SAP Knowledge Base
Articles, and additional assets as referenced in this document, see chapter 7.
2
TABLE OF CONTENTS
Table of Contents
IMPLEMENTATION DESIGN PRINCIPLE ........................................................................ 1
DOCUMENT DETAILS ................................................................................................................................................................................ 2
1 TERMINOLOGY........................................................................................................................................................................... 5
2 ABSTRACT .................................................................................................................................................................................. 5
3 INTRODUCTION ......................................................................................................................................................................... 5
4 BUSINESS REQUIREMENTS ........................................................................................................................................................ 5
4.1 PROJECT REQUIREMENTS ............................................................................................................................................................. 5
4.2 FUNCTIONAL REQUIREMENTS ....................................................................................................................................................... 5
4.3 TECHNICAL REQUIREMENTS.......................................................................................................................................................... 6
5 SOLUTION OVERVIEW AND CONCEPTS...................................................................................................................................... 6
5.1 PROJECT DESIGN ........................................................................................................................................................................ 6
5.1.1 Different Implementation Launch & Considerations ........................................................................................................ 6
5.1.2 High Level Data Migration Strategy ................................................................................................................................. 7
5.1.3 Freeze Period (Cut-Over) Considerations .......................................................................................................................... 7
5.1.4 Concerns While Handling Employee Data ........................................................................................................................ 8
5.1.5 Multiple Module Deployment ........................................................................................................................................... 8
5.1.6 Multiple Legacy Systems ................................................................................................................................................... 9
5.1.7 Data History Considerations ............................................................................................................................................. 9
5.2 FUNCTIONAL DESIGN ................................................................................................................................................................ 10
5.2.1 Active Employee Population ........................................................................................................................................... 11
5.2.2 Rehire of Previously Terminated Employees ................................................................................................................... 11
5.2.3 Multiple Employments .................................................................................................................................................... 11
5.2.4 Foundation Data ............................................................................................................................................................. 11
5.3 TECHNICAL DESIGN................................................................................................................................................................... 11
5.3.1 Data Transformation Considerations ............................................................................................................................. 12
5.3.2 Mass Upload Considerations .......................................................................................................................................... 13
5.3.3 Employee Central Settings for Optimal Imports ............................................................................................................. 18
5.3.3 Russian Data Privacy....................................................................................................................................................... 21
5.3.4 Implication of GDPR on Data Migration ......................................................................................................................... 22
6 DETAILED SOLUTION ................................................................................................................................................................ 23
6.1 EMPLOYEE MIGRATION BASED ON HR PROCESSES .......................................................................................................................... 23
6.1.1 Hire.................................................................................................................................................................................. 23
6.1.2 Rehire .............................................................................................................................................................................. 29
6.1.3 Multiple Employments .................................................................................................................................................... 31
6.1.4 Termination..................................................................................................................................................................... 34
6.1.5 Leave of Absence ............................................................................................................................................................ 35
6.2 HANDLING MIGRATION OF SPECIFIC EC ENTITIES ........................................................................................................................... 36
6.2.1 Dependents ..................................................................................................................................................................... 36
6.3 TIME-OFF DATA LOAD .............................................................................................................................................................. 37
6.4 HANDLING CONTINGENT WORKER MIGRATION ............................................................................................................................. 40
6.5 HANDLING PHASED DEPLOYMENT ............................................................................................................................................... 44
6.6 DATA QUALITY VALIDATION POST SUCCESSFUL MIGRATION............................................................................................................. 47
7 ASSUMPTIONS AND EXCLUSIONS ............................................................................................................................................ 52
8 REFERENCES............................................................................................................................................................................. 52
9 ADDITIONAL RESOURCES......................................................................................................................................................... 52
3
4
1 TERMINOLOGY
The following table explains some abbreviations used in this document.
Abbreviation Description
EC Employee Central
MDF Meta Data Framework
RBP Role Based Permissions
HRIS Human Resource Information System
2 ABSTRACT
Every Employee Central implementation will necessitate data migration of existing employee population
from a legacy system. This document describes in detail the strategies and considerations involved with
data migration and provides industry best practices on employee data migration specifically for green
field Employee Central implementation.
3 INTRODUCTION
When implementing Employee Central there is always a need to migrate existing employee data from
one or more legacy systems into the Employee Central environment. This can involve a number of
different scenarios depending on various types and statuses of the employees that are migrated. Some
of these data migration scenarios might include rehired employees, terminated employees, active global
assignments, active leave of absences, and so on. This will require different strategies as well as varying
levels of data that need to be included to ensure successful migration to EC. Successful data migration
is also affected by critical project decisions like history of data, multiple module deployment, multiple
legacy systems, phased implementation or big-bang approach among other functional and technical
considerations that are discussed in detail.
4 BUSINESS REQUIREMENTS
This document addresses critical project decisions, functional and technical requirements that are listed
in the below section during employee data migration. It provides best practices, recommendations and
solutions that are crucial to consider for a successful data migration to Employee Central.
4.1 Project Requirements
Data migration process is affected by critical project decisions made during the implementation phase
of the project. This includes the kind of Employee Central implementation/go-live planned (big bang or
phased rollout approach), multiple module deployment planned, multiple legacy systems, and if a
double entry or a freeze period is in place among a few others. These project considerations are
discussed in detail in section 5.1.
4.2 Functional Requirements
Employee Central based employee data migration includes various functional considerations of which
handling of active employee population, rehires, terminated employees, contingent workers as well as
5
employees on leave of absence are discussed particularly in this document from Employee Central
architecture point of view.
4.3 Technical Requirements
Various technical requirements are considered when carrying out employee data migration which are
based on the data model and architecture of Employee Central. Some of the salient requirements listed
below are discussed in this document among a few others:
• Handling Effective dated / non-effective dated EC entities
• MDF and Standard EC entities
• Handling Leading Zeroes in EC fields,
• Picklist Migration
• Sequence and the order of import templates
• Optimized EC setting for data migration (initial load)
• Batch size and Parallel loading
• Impact of GDPR
5 SOLUTION OVERVIEW AND CONCEPTS
5.1 Project Design
This section details the impact of strategic and project decisions that are made early in the
implementation namely big-bag implementation versus a phased rollout of EC, multiple module
deployment, freeze period handling, multiple legacy systems involved, and the considerations for these
during data migration.
5.1.1 Different Implementation Launch & Considerations
The cut-over approach needs to be considered and decided upon at the start of the data migration.
There are mainly two kinds of cut-over approaches namely; phased(staggered) rollout implementation
and big-bang implementation that are discussed below in terms of the context and criteria when one of
them is preferred over the other.
• Staggered/Phased Rollout of EC Implementation: In the staggered approach, the employee

population is split by relevant groupings, and based on this grouping, the go-live on Employee Central
is carried out in a phased manner. However, it should be noted that migration from SAP ERP HCM only
supports country based data migration. Some of the groupings on which data migration can occurs is:
▪ Payroll Areas
▪ Country
▪ Regions/Country Groupings
Staggered/Phased Rollout has a short migration period and lesser impact on the employee population
as a whole in a given go-live but can extend the timeline of the project based on the number of phases
(go-lives), which is usually based on the number of countries going live on a whole and how these are
grouped in different phases. This implementation approach also lessens the resource impact within the
individual project areas and the core team in the long run.
• Big-Bang EC Implementation:
6
With the big bang approach, all employees within the scope of the project are included from the start in
a single go-live approach. This employee population can span globally across multiple countries and all
of these go-live on EC system at the same time. This approach has advantages like it has the same
time of go-live for the complete population but will increase the resources required for thorough testing
and migration activities required across all legal entities simultaneously.
• Type of Go-live:
Within each approach there is also the option of how the launch will be handled in terms of user access
which is discussed as below:
▪ Soft Go-Live: This approach has the system going live for HRIS operations to input the data and
run payroll for a short amount of time before the entire employee population has access and
usage to Employee Central. This gives the administrators more time to input any additional data
that needs to be present post-migration as well as working out any go-live problems.
▪ Hard Go-Live: This approach has everyone gaining access to the system at the same time and
usage is higher from day one.
Both the above kind of go-live can be established through either one of the above mentioned Employee
Central implementation approaches.
5.1.2 High Level Data Migration Strategy
Below picture provides a high-level data migrations strategy in terms of what kind of data should be
imported to Employee Central using the tools available and how they should be imported. More details
are discussed in subsequent sections of the document.
Data Migration Strategy (Reference: Architecture Leading Practice (ALP))
5.1.3 Freeze Period (Cut-Over) Considerations
When migrating from a legacy system to SAP SuccessFactors Employee Central there will be a certain
timeframe at the time of going live on the new system and the end of the old system which is technically
called the cut-over or freeze period. There are mainly two different ways to handle the cutover (freeze)
period as discussed below:
• Freeze Period
7
A freeze period typically includes not entering data into the legacy HRIS but entering that data into
Employee Central system before the official go-live of the new EC system. To determine when the
freeze period should be and for how long, several different facts can affect this:
▪ Payroll period start dates: Depending on whether there are multiple payrolls in use or multiple
countries, the same consideration needs to be taken into account when determining the freeze
period to minimize the impact on the impending payroll processing.
▪ Integration requirements: If integration is being moved from the legacy HRIS to EC, the freeze
period may include the migration of the integration such that the new data needs to be available
in EC once the integration is turned on.
▪ Compensation cycles: If the go-live date of the EC system is near the compensation merit cycle,
different dates may need to be utilized for the freeze period to lessen the impact.
In addition to the above, there could be any other business or technical processes that may also affect
the freeze period, for example, if a performance optimization is planned then it can affect the feeze
period duration. Generally, freeze period duration should be kept to a minimum to avoid disruption to
HR processes. Different customer implementations have had a freeze period ranging between 3 days
to a few weeks.
• Double Entry
There could be valid business situations that require employee data update or entry that needs to be
made into the legacy system before the newly implemented EC system is made available for wider
administrative usage. During such a cut-over/freeze period, HR administrators are allowed access to
the legacy system to make necessary creation or update of employee data. Having done this, the new
data or the delta changes to employee data needs to be carried out additionally in the EC system thus
requiring a double entry in both these systems. This kind of situation should be minimized to prevent
data going out-of-sync between the two HR systems and wait until the new system is live. Therefore,
any double entry process should be handled cautiously to keep data in sync, especially in the new EC
system which will be the system of record going forward.
5.1.4 Concerns While Handling Employee Data
Working with employee data within any environment can be a concern and even regulated depending
on the country of data residence when dealing with Personally Identiable Information (PII) and other
sensitive data. Following considerations need to be taken into account while handling employee data
migration:
• Data Extraction: Obtaining the employee data in a format that is acceptable for import into Employee
Central and what transformation needs to take place.
• Data Storage: When transforming data for import into Employee Central, the data needs to be stored
in an appropriate and secure area as agreed with the customer. This needs to be handled cautiously
when dealing with personally identifying information, especially when dealing with multiple countries
and different privacy laws.
• Human Touch: In general, the minimum amount of human interaction is better in terms of data
manipulation. A computer program should extract and transform the employee data rather than manual
transformation.
• Documentation: Any transformation of data that is required from the legacy system to Employee
Central (either programatically or manually) should be properly documented in a technical specification
for audit purposes
• File Based: If you are using file based method to extract the data from the source system, it is advised
to keep the format of the file as text based to ensure that no data is corrupted especially with leading
zeroes or special characters.
5.1.5 Multiple Module Deployment
8
Along with Employee Central, there could be multiple SAP SuccessFactors modules either in existence
already or will be implemented at the same time as EC which is an important point of consideration
when migrating data. This can include considerations for objects like Positions, Job Classifications as
well as overwriting or merging of data from the User Data File (UDF) that is used by other talent modules
to either pull data from or populate data to.
5.1.6 Multiple Legacy Systems
Migrating data into Employee Central could potentially involve bringing in data from multiple sources.
Each source needs to be taken into account when looking at the overall strategy to make sure no data
is being overwritten or duplicated (cross-border managers or foundational data) when the data is being
added to Employee Central.
5.1.7 Data History Considerations
Importing historical data into Employee Central is an optional addition to the implementation project.
There are several advantages and disadvantages to including or excluding historical data. It is also
important to consider the scope of the historical data that will be included.
• Advantages:
▪ Single Point of Entry: The data is in a single system and doesn’t need to be tracked down. The
information is available based on permissions and can be accessed at any time without needing
an external involvement.
▪ Trend Reporting: Reporting is available as a seamless option within the system without having
to consolidate information externally.
▪ Retroactive Changes: Changes can be made before the go-live date and flow to the payroll as
needed without having to access to a third-party system.
• Disadvantages:
▪ Mapping: The historical information will need to be mapped to structures and data points that
might not be relevant to keep track of from a business standpoint, and thereby reduces the quality
of data that is stored in the system. This increases based on how far back in time the data goes.
▪ Time and Resources: This will extend the project timeline to enable a greater resource inclusion
for data migration.
▪ Limited to In-Scope: Information that is being captured for the scope of the project is what is
included for historical data, any additional sources of information would need to be included as
an independent source or custom object within the system.
▪ Organizational and Foundation Structure:Typically, with historical data, the further back the
history is needed to be migrated, the more mapping and transformation is required. This can
include greater provision for foundational information being imported into the new system. Most
of which would be made inactive at go-live and exist purely for historical inclusion. The other
consideration is the potential mapping of historical data points to current structures, this may not
be completely feasible and would require either customization to include data from a historical
perspective or the inclusion of “dummy” data on the current structure applying back to historical
data. It also means that you have to enable more picklist entries to ensure the mapping of values
between the legacy system and EC system matches.
Following is a list of potential reasons why history would need to be included in Employee Central:
• Trend Reporting: The ability to be able to use the history of the entities within the Company is
particularly useful when looking at reporting trends over time. This can be sourced within the
Reporting module independently or pulled directly from Employee Central if historical records have
been loaded.
• Compensation Merit Cycle: To perform a merit cycle within the Compensation module, a full year of
data needs to be present that Compensation can use to complete the cycle. Compensation data
can be a driving force for the inclusion of historical data. The current compensation merit cycle will
need one year of history to perform a merit cycle successfully. This can be obtained either through
historical inclusion of data as part of the data migration or creating manual imports into the
9
Compensation module for the inclusion of the merit cycle for the first year of the system going live.If
variable pay is inclued, then compensation history is mandatory.
• Legacy System Licensing: When moving from an existing legacy system into Employee Central
there can be issues with access to the legacy system once Employee Central is live. Having these
records available within Employee Central alleviates this concern.
• Country Specific Regulations: There are also legal/regulatory laws which may require several years
of history to be accessible in the new system such as union regulations in the US.
• Variable Pay: If Variable Pay is included then at least a years Compensation history is required.
• History Recommendation
The recommendation at this point is to only include 1 year of actual history to support the Compensation
Merit process for the year that the system is going live. This will include:
▪ Loading an independent Hire record dated before the year of go-live. The hire record must reflect
the users actual hire date.
▪ Including any historical changes that occur during the year which will affect:
o Job Information
o Compensation Information
o Personal Information
For the above EC entities, all the fields that are relevant for Compensation and Payroll needs to be
considered.
▪ Including any potentially inactive Foundation Objects that are referenced within the year of
history being loaded
▪ Including Terminated Employees that are referenced during the year of history being loaded
(Refer to section 6.1.4 for more details on handling Terminated Employees).
Alternative History Recommendation

An alternative recommendation could be to load history from the beginning of the go-live year. There
are customers who do not load any history at all, the first job info record after the hire record would also
be the first of the month of the go-live. With this kind of approach, the consideration is how the HR
admin can manage the retroactive changes in payroll. Therefore, it is important to have the employee
data of at least the number of months which after go-live the employee /HR admin/ have the provision
to still change and reflect the changes in payroll system for retroactive calculations.
5.1.6.1 Inclusion of History via MDF Solution

A viable option for inclusion of history while minimizing the impact on the migration schedule is to include
a custom object that holds the historical information. This object would consist of the most relevant
information that is needed for things like:
• Reporting
• Compensation Export
• Look up data
The custom MDF object is linked to the Employee via the User ID and can be accessed directly from
the Advanced Reporting functionality. The inclusion of any Foundation Objects are optional but
recommended in this approach for ease of reporting between live data and history.
Requirement of such a use case is when specific job information fields needs to be tracked for recall
of employees based on seniority. For example, when a customer needs to track 7 years of job history
only for a handful of fields such as position, seniority date, termination date, etc. then User, salary,
total salary, job grade, job title, legal entity can be included in the custom MDF.
5.2 Functional Design
10
This section details the impact of functional considerations that are involved in employee data migration.
Some of these functional considerations are active employee population, rehire of terminated
employees, global assignments, foundational data, and the amount of historical data.
5.2.1 Active Employee Population
Every implementation has existing employees that have an ʹA ctiveʹ status within the current legacy HRIS
system. These employees need to be migrated to the new implementation on Employee Central and
retain all pertinent information that is needed for the following business scenarios:
• Employee Life Cycle Events
• Reporting
• Payroll
• Third-Party Integrations
As part of the migration, this population needs to be loaded into Employee Central to maintain the
current status and provide a smooth transition into the EC system at the go-live. This will include moving
of data from one system to the other (exporting, re-formatting) as well as the mapping of data where
needed and potentially the creation of new data to support additional functionality within the newly
implemented system. This is discussed in more detail in Section 6.1.
5.2.2 Rehire of Previously Terminated Employees
An existing HRIS builds up a history of terminations for employees over time. This also brings to light
how terminated employees are migrated to the EC system and thus the possibility of rehires is
performed within the system. Migrating data to the new EC implementation needs to take into account
the strategy involved with rehiring a previously terminated employee within the new system (Employee
Central). Depending on the strategy and needs of the customer, there may not be a previously
terminated record for the employee being rehired within the new system. A solution needs to exist that
can take into account either having or lacking history for Terminated employees. This is discussed in
more detail in Section 6.1.4.
5.2.3 Multiple Employments
Global assignments and concurrent employment need to be taken into account for migrating multiple
employments (employee) data from the legacy system. All such active employments need to be
migrated to Employee Central and should follow the specific series of events to display and function
correctly. Part of this is making sure the main employment or home record is loaded initially followed by
additional employments or assignments. This is discussed in more detail in Section 6.1.3.
5.2.4 Foundation Data
Along with employee data, there is also foundational (organizational) data that needs to be migrated
into Employee Central. This can include many others of which a few are listed below:
• Positions
• Job Codes/Classifications
• Legal Entities
• Event Reasons
• Pay Components
Some of this data could be legacy information that is only used for historical purposes and will need to
be made unavailable to currently active employees as part of the migration process. This is discussed
in more detail in Section 6.1.1. You can also refer to the section Working with Foundation Objects in
Employee Master implementation guide on the SAP Help portal to understand foundation object in more
details .
5.3 Technical Design
11
Data migration from a legacy system can involve several functional scenarios that directly affect the
technical handling of the migration process. Some of these technical considerations are :
• Data Transformation
• Effective dated & non-effective dated EC entities
• Leading zeros
• Foundational Objects
• Multiple Employments
• Mass Upload
• Dependents
• Data Privacy
• Contingent Workforce
• Common File Corruption Issues due to Special Characters
Each of these aspects can alter how the overall solution is designed. Therefore, one needs to consider
the best practice and recommendations to follow while handling data migration. Migration can be a large
undertaking even with the basic EC templates and the design needs to be flexible in a way that is best
for the individual scenarios of employments as well as the overall migration of the entire employee
population.
5.3.1 Data Transformation Considerations
The following technical preparations are to be considered for the import of employee data into Employee
Central.
5.3.1.1 Effective Dated and Non-Effective Dated EC Entities
Depending on the legacy system, some portlets will need to be converted into an effective dated
structure or into a non-effective dated (point in time) structure based on the architectural design of
individual EC entities. You need to consider the following while handling these two different type of EC
entities while migrating an effective dated legacy data to non-effective dated EC entity and vice versa :
• Effective Dated to Non-Effective Dated: The most recent record needs to be used for importing non-
effective dated EC entities. Historical data (if needed) can be moved to a custom MDF portlet or
included in an existing effective dated portlet using custom fields that can retain the history.
• Non-Effective Dated to Effective Dated: The data to be included in the effective dated portlet using
the extraction date as an effective date or it can be spread across the period within the portlet if
multiple records are being utilized.
5.3.1.2 Leading Zeros
In a lot of legacy systems, there is the usage of leading zeros (000XXXX) within identifiers for employees
as well as Foundation Objects. This can be especially complicated when file manipulation is needed to
format or modify the data before loading into Employee Central. Whenever data is being manipulated,
always make sure to import the data into the editor being used and make sure to denote any ID field as
a data type of TEXT and not auto-format into a numeric number. Please refer to the Employee Central
Imports Guide (Administrative Guide) on SAP Help Portal under section Preparation of Import Data for
further details.
5.3.1.3 Foundational Objects
When migrating Foundation Objects to Employee Central there are several things to take into account.
Most of the time it‘s not possible to export organizational data from the legacy system and import directly
into the Employee Central without having to modify the import, include additional objects or do date
changes. These can include the following:
12
• Conversion values: When using an original hire record, some of the foundation data may be using a
conversion value that needs to be included in the system either as part of the import, post- extraction
or to be manually entered into the system
• Historical values: Any historical data that is being entered into SAP SuccessFactors that utilize the
Foundation tables will need to be included and the effective dates need to be set up in a way that
not only imports the employee data successfully but also potentially prevents a user from selecting
the historical objects that are no longer relevant for usage after go-live.
• Mapping: Sometimes the foundation data being used in Employee Central won’t map directly to a
single object in the legacy system or vice versa. In these cases, additional transformation and
mapping need to be done either as part of the extract or as a transformation process before data
import. Example of such a foundational object is Position.
• Validation checks: Several checks need to take place once the foundation data is loaded. These
include:
▪ Employee Data and Foundation Data: Any instance of foundation data in the employee files will
need to be included in the foundation objects along with its respective effective dates. The start
date value of a foundation object will define the date in which a given foundation object can be
assigned to an employee. Commonly the start date used in foundation object can be
01/01/1900.
▪ Associations: Associations set up between foundation objects will need to be checked against
the possible combinations coming out of the Employee data.
▪ Cyclic checks: Any data that uses itself as a parent and child needs to be checked for cyclic
redundancy where the parent cannot be assigned if the child occurs in the same hierarchy.
▪ Manager/Employee Relationship: It is also important to ensure employee and manager
relationships are imported correctly in the right sequence. This is a commonly observed
validation error while importing employee due to an invalid manager. So ensure the manager
exists already in the EC system before importing employee.
Please refer to the sections: Prerequisites for Employee Central Imports and Importing Foundation Data
of SAP Help Portal Administrative Guide: Employee Central Imports, for further details on foundation
data import features.
5.3.1.4 Picklist Migrations
Picklists work similarly to foundation objects in that they need to be migrated over from the legacy
system in a format that can be imported into Employee Central. This is entirely optional, only if a
customer is either (a) bringing over historical data or (b) wanting to continue to use these values. Some
customers opt to bring over only a subset of picklist values that are truly relevant to their business, or
choose to leverage the SF-recommended picklist values (which may have similar definitions to their
previous system values, but the labels are different), thereby requiring additional effort in transforming
their legacy system data. Some limitations will affect how the picklists are represented in the system.
• Labels on Import: While using the standard EC employee data import templates, the picklists are
represented in the load file as labels. When a single picklist has the same label used for multiple
instances, this can cause the system to pick the wrong value potentially when loading. In general, if
the label is the same when importing, the system will assign the Option ID of the first value that it
finds that matches the label. This is done irrespective of parent/child filters.
• Options Ids: It should be noted that each picklist value comes with an option id that is different in
each EC instance (test instance will have different value to production instance). Each picklist value
has a unique external code. This could be used in the value mapping from the legacy system to EC
system.
• Instance sync is a useful way to move some of this data between environments after initial
loading in lower environments specifically foundation object, MDF values and picklists.
5.3.2 Mass Upload Considerations
The following are important considerations while doing a mass import of data into Employee Central.
13
5.3.2.1 Understanding Import Templates
Each template within Employee Central is specific to the object that its being referenced. Each template
can be downloaded directly from the EC system once the data model configuration is in place which will
then provide the import template with the relevant columns to be included. You should take note of the
following when handling these import templates:
• Standard Portlet and MDF: Some data objects are stored within MDF which means the templates
look different and will behave differently when importing. Please refer to the Employee Central Import
guide for further details.
The below table shows the important considerations while handling data migration of standard EC
portlets and an MDF based portlet.
Validation Standard Portlet MDF Portlet

Picklist Validation Uses Platform Picklist and Uses MDF Picklist and
validates on Label within the validates on External Code
import file within the import file
Employee Central Import Employee Data Import/Export Data
Transaction
Functional Scope ➢ Basic ➢ Payment Information
➢ Person Info ➢ Deductions
➢ Personal Info ➢ Employee Time
➢ Employment Info ➢ Work Order (for Contingent
➢ Job Information Workers)
➢ Compensation
Information
➢ Pay Components
Recurring
➢ Pay Components Non-
Recurring
➢ Emergency Contact
➢ Dependents Info
➢ Global Info
➢ Global Assignment Info
➢ Termination Info
➢ Phone Info
➢ Email Info
➢ IM Info
➢ National ID Info
➢ Home Address Info
➢ Work Permit Info
➢ Job Relationships
Country-Specific Template Fields are shared within the Independent files exist for each
same template for different country's requirements.
country requirements
• MDF Object and BCUI: For some MDF objects (like Payment Info) the template will be based on the
base object rather than any changes made through the configuration UI that the user has access to.
Consider these changes to ensure successful employee data import.
• Country-Specific: Using standard portlets that support Country Specific fields will mean that the
same field can be utilized for multiple countries. In some cases (like Home Address) different
validation can occur in the same field between two different countries. To ensure that you download
the right import template for the country you are importing data, select the right value from the
dropdown of Select Country in the transaction Import Employee Data. The option Select Country is
only available when you have configured HRIS element to add a country-specific configuration. You
14
will also see a consolidated list of data fields (standard and custom) configured for each selected
country under the Available Data Fields column. You will see all the fields that are configured for the
countries you have configured. Therefore, please be careful while customizing your import template
by selecting only the required fields.
• Business Keys: are mandatory fields of a template and cannot be removed from the template. Each
of the templates has one or more business keys. In SAP SuccessFactors, each record is identified
by a unique identifier combination known as business keys. Business Keys are typically a
combination of the ID for the Person (Person ID / person_id_external) or Employment object (User
ID / user_id ) potentially combined with a type of record for the entity. Finally, if the entity is effective-
dated, the business key will include the start date and possible a sequence number. For example,
the address portlet is part of the person object and is effective dated. Additionally, you can have
several types of addresses (home, mailing). Therefore, in the Addresses template, the unique
combination of person_id_external, effective_start_date, and address_type make up the unique
business keys. However, the biographical information portlet is non-effective dated and does not
have multiple entries per user, so the business key is person_id_external. You must include the
business key fields and values in your import file. The business keys for the different entities can be
found in the Employee Central Imports guide on the SAP Help Portal.
• Full Purge and Incremental Import: When loading into standard portlets there are two options
available, Full Purge or Incremental.
▪ Full Purge:
This will replace the information based on the external codes present in the file being loaded with
the contents of the file. This will not remove information that isn’t directly referenced in the file
based on the external code key. This is only used if records need to be removed from the standard
portlets. The system treats the missing fields in a given object during import with blank values.
▪ Incremental:
Using standard portlets, the incremental load of a template can mean that columns can be
removed from the template to default the existing value to the new or update value being
imported at the time. Depending on the object, several columns need to be included regardless
but will vary by template. Please refer to the details discussed in the section below.
This will add new records based on the contents of the file where the key fields do not match
what is currently in the system. If the fields match, then it will update the values with the contents.
If any columns aren’t included in the file, then it will leave the data as is. To edit an existing record
using Incremental load, you will Export the template to find the existing business key, sequence
number & other values of the data records existing. Identify the row/rows in the exported file, and
ensure you make relevant changes you desire to those ones without making changes to buiness
keys and sequence number you will import the changed value to ensure any missing data has
been updated too.
Fields supporting NO_OVERWRITE get the default value, fields not supporting
NO_OVERWRITE are added with blank values during the import of the template of a given object
with missing fields. The NO_OVERWRITE is a feature of the columns of data import files which
when specified with the value &&NO-OVERWRITE&& then the values of those columns will
remain unchanged & hence retain the previously stored value (it might be null or not null).
To upload records using Partial imports (incremental import), before importing the CSV file, you’ll
need to specify the &&NO_OVERWRITE&& value in fields of the user data file. During the import,
all fields with values in the row will be overwritten with the new values. Fields for the business
keys and fields marked with &&NO_OVERWRITE&& will NOT be changed.
Partial Import is only supported for certain columns when you're importing the CSV file. They are
not supported on Address, Work Permit, Pay Calendar, Job Relationships, and Job Family.
Please refer to section Uploading Import Files in Employee Central Import Guide for further details.
15
5.3.2.2 Importance of Loading Order
Employee data import to Employee Central needs to be loaded in a specific, sequential order as
follows and is considered mandatory for hiring a employee:
• Basic Import (UDF file)
• PersonInfo Import (Biographical Info)
• Employment Info
• Job Information
• Compensation Information
• Personal Information
Once the above import templates are loaded, the remaining templates can be loaded independently in
any order except for dependent portlets such as:
• Pay Components Recurring requires Compensation Information
• Global Information requires Personal Information
• Termination Details requires Job Information
• Job Relationships requires Job Information (as well as Job Information for the referenced
relationship)
Apart from the above-mentioned templates, following are the EC templates relevant for employee
data loading:
• Extended Import
• Background Import
• Global Assignment
• Recruit Information
• Phone Information
• Email Information
• Social Accounts Information
• National ID Information
• Addresses
• Emergency Contact
• Personal Documents Information
• Pay Component Non-Recurring
• Consolidated Dependents
• Compound Non-Effective Dated Entities
• Compound Delete
This is how the order of upload of Employee Central employee templates can be considered on the whole:
• Basic Import (User Creation)

• Biographical Information
• Employment Details
• Work Eligibility
• Job History
• Job Relationships
• Compensation Info
• Pay Component
• Recurring
• Pay Component Non-Recurring
• Personal Information
• Global Information
• Phone Information
• Email Information
• National ID
• Addresses
• Emergency Contact
• Payment Information Details
16
5.3.2.3 Parallel Loading
Within the system it’s possible to load multiple files at the same time by the same user. While this is
possible, it is not generally recommended to load the data from the same object at the same time in
multiple files. Depending on the data being loaded, this can potentially cause issues with record locking
as well as validation on the files if concurrent loads are being done at the same time.
Following are considerations where parallel loading scenarios are:
• Foundational Loads: These can be done in parallel as long as there is no association that is required
on the files that is needed to be present in the system before the object can be loaded.
• Independent User Tables: When loading the Employee User objects, the initial record needs to be
created first in order for parallel loads to be allowed. This means the following tables need to have
some sort of presence or Hire record:
▪ UDF
▪ Person Info
▪ Personal Info
▪ Employment Info
▪ Job Info
Additional loads can be done into these objects independently and in parallel once the initial record is
present in the system.
5.3.2.4 Provisioning Job Follow Ups
When importing into specific portlets, some jobs are automatically run in the background once the
import is completed. For the HRIS Sync job, it is recommend that this is disabled for the initial data
conversion activity where additional modules are already live. This ensures that the existing BizX
modules experience no disruption until the EC data has been validated as accurate and complete.
Portlet Provisioning Job Names Description

Job Information/ HRIS Sync This will check the information
Compensation Information/ in UDF Profile for the default
Personal Information fields as well as any customized
mapping included and update
the UDF Profile accordingly
Follow up Processing This is applicable only to Job
Information.
Refresh Access Membership
Realtime Refresh DG This will update the Dynamic
Membership Groups that are in the system
based on changes made during
the import
Address HRIS Sync This will check the information
Information/Biographical in UDF Profile for the default
Info/Contact Info/Job fields as well as any customized
Relationship mapping included and update
the UDF Profile accordingly
17
5.3.3 Employee Central Settings for Optimal Imports
Following are some of the settings you can do in Employee Central to optimize import. In addition,
please refer to the section Defining Import Settings for Optimal Performance in Employee Central
Import Guide on SAP Help Portal.Also, check the section Additional Configuration in the same guide
to understand additional configuration settings that impact data imports in EC.
• Import Settings
Feature Description Optimal Setting

File Encoding Each file type can be encoded UTF-8
in different types in order to
preserve special characters
either from an interpretation of
non-standard characters or
different language script
support.
File Locale Within SuccessFactors the Use the file locale based on
various language packs the countries and languages in
determine how the file is scope.
interpreted. This can affect
decimal values as well as date
formats.
Real-Time Threshold This is the number of rows that 10
the system processes in real
time before sending the
remaining data to the server to
process and validate. This will
give a sanity check of the file
format as well as the contents
of the specified number of
rows.
18
• Position Management Settings
You need to access the EC transaction Position Management Settings to make the following settings.
Below is the image of this transaction from the Admin Center:
Also, it is suggested to follow the below sequence of maintaining position settings while you import
positions in the EC system:
1. In position management settings mark Adapt Reporting Hierarchy During Position Import as No. After
the initial load then set it as Yes.
2. In Position Management Settings make Adapt Hierarchy in Job Info Import as Yes
3. Validate Position Assignment During Job Information Import as Yes
4. Import your positions
5. Import your jobinfo file with supervisor field as ‘NO_MANAGER’ as you have set Adapt Hierarchy in
Job Info Import as Yes the JobInfoImportFollowUpProcessing .Job will be triggered and set the correct
manager, this saves you working all the logic out in the jobinfo file.
¹ - Caution as one should not just switch on the settings to Yes, without understanding what it does and
why it might be needed. Please refer to the section Execute Position Processes During Job Information
Import in SAP Help Portal Employee Central Position Management Guide for further details of how
these settings impact the Employee data imports.
Feature Description Import Setting Post-Import Setting

Adapt Reporting This allows the reporting No (off) Yes (caution¹)
Hierarchy During hierarchy (supervisor) to
Position Import be updated during a
position import based on
the relationship between
the incumbent of the
parent position and the
incumbent of the
position being imported
Validate Position This means the system No Yes(caution¹)
Assignment During will check to make sure
Job Information the position is available
Import when importing into Job
Info data of employee
19
Adapt the Position This writes a record to No Yes (caution¹)
“To Be Recruited” the position object based
Status During Job on the effective date of
Information Import the Job Information
record and sets the
Hired flag = False
Execute This will use the flag on No Yes(caution¹)
Reclassification or the event reason as
Transfer During Job Reclassification or
Information Import Transfer and compare
the information with the
Employee’s current
Position and potentially
change data or create a
new position
Adapt Hierarchy This allows the position No Yes(caution¹)
during Job hierarchy to be updated
Information Import during a Job Info import
based on the
relationship between the
manager, its position
and the employee being
imported
• Validation Settings
All validations should be ON during data migration. If is important that the data that is being imported
are of the highest quality possible, and these system checks help ensure this. If validations are not
performed during import, it will lead to potential negative system experience and usability of the system
should one try to add additional data to a portlet, only to receive a validation error that one did not touch.
There is also a drawback of keeping all the validations ON as this will cause performance impact on the
data being imported and hence may slow down the process.These validation are listed below:

Attach data to email This will attach the Off/On (caution on Off
for Import/Export results of the import performance)
Jobs with any errors to the
status email being
sent
Suppress update of If there are duplicate On On
identical records records being
during Employee imported in a single
Central import for file, this setting will
supported entities prevent the record
being updated multiple
times
Send result mail for There are a number of On On
Job Information post-processes run as
import follow-up a result of Job
processing only if an Information imports.
error occurred This will only send an
email if one fails
(results can still be
accessed through
Provisioning)
Enable CSF support With this checked, On On
for Address in individual countries’
Emergency Contact Address formats are
and Personal validated and used
20
Relationships instead of an
imports international format
Enable validations Dependents is made On On
for mandatory fields up of different portlets
in the Dependent’s within the Details, this
details section allows the mandatory
checks to take place
for them
Enable validations Emergency Contact is On On
for mandatory fields made up of different
in the Emergency portlets within the
Contact’s details Details, this allows the
section mandatory checks to
take place for them
Enable Address This includes Post/Zip Off/ On(caution on On9
Validations Code format performance)
validations
Enable National ID This includes the Off/On(caution on On
Validations check digit algorithm performance)
checks for some
countries
Enable Bank Account This checks the Off/ On(caution on On
Validations Routing Number and performance)
Account Number for
check digit algorithms
and formatting
Enable Payment This checks the Off /On(caution on On
Information percentage split of performance)
Validations records as well as the
Main bank account
present
• Batch Size Considerations
Batch sizes can affect the load of data depending on the complexity of the system and the contents
being loaded. Please refer to the section Performance Benchmarks of the Employee Central Imports
Guide in the SAP Help Portal for a detailed discussion on the data volume load guidelines and the
approximate time taken for successful data imports.
• Company System and Logo Settings

Maximum This is a parameter to 5
Threadpool size optimize and handle
better the incoming
request .
Batch size The number of data 500
records pooled in each
threadpool.
5.3.3 Russian Data Privacy
When dealing with an implementation that includes employees from Russia there is additional steps
that need to be taken. This includes setting up the Russia Data Residency Solution outlined in the
Implementation Guide – Implementing Russia Data Residency Solution. It also includes a different
process for loading Russia employees into the system. The main aspect of the residency law requires
that any personally identifying information (PII) that is entered into the system for Russia employees
need to originate within Russia.
21
In order to comply with this need, a secondary data center is created within the Russia Data Center that
is used as the originator of the data for Russia employees and the data is then sent to the global data
center being used for the rest of the world employees. This requires a different process to take place
for adding these employees to the system. This process adds the Job Information early which will
identify the employees as belonging to Russia based on the Legal Entity/Company field and the Country
that is associated to there.
• Please refer to the SAP Help Portal Guide Implementing Russia Data Residency Solution for more
details on implementing data load for Russian cusotmers.
5.3.4 Implication of GDPR on Data Migration
The General Data Protection Regulation is in effect to govern the availability and transference of
information that is Personally Identifying to an employee that resides within the European Union. This
applies to any organization that offers goods or services to, or monitor the behavior of EU data subjects
and those that process or hold the personal data of EU residents.
SAP provides a number of features that are used to keep in compliance with this regulation including
the following:
For Data Migration there are a number of factors to take into account:
▪ Access to PII Information: As part of the data migration, the employee information will be
moving from the legacy system to the implemented Employee Central system. It is therefore
important that permission and audits are placed as soon as the data migration is completed in
the EC system.
▪ File Transfers: If the migration includes the extract and load of information via files then these
files need to be limited in access based on secure transmission methods as well as limiting the
movement of the files as much as possible.
For more details, refer to the SAP Help Portal Guide Setting Up and Using Data Protection and Privacy.
22
6 DETAILED SOLUTION
6.1 Employee Migration based on HR Processes
6.1.1 Hire
Depending on the need of the customer, there are two main ways to approach a Hire record:
▪ Original Hire Record: This provides the basic amount of data needed to populate the record but
retains the original hire date and hire event reason (where possible) within the Employee Central
system
▪ Conversion Hire: This takes the go-live date and provides a hire record as a conversion to the
new system as a solid cutover point and isn’t included for any reporting or historical data. It is
always recommend that the customer uses the original hire record option for data migration and
loads dummy data into job info betweeen hire record and conversion record. If you use the
conversion hire approach then it's important to note that the hire date in employment info must
be the same as the conversion date/start date of the job info, personal info, comp info etc. The
customer then has to store the real hire date in the original hire date field or another date field.
This means that where SFSF uses hire date in standard processes this would need to be
changed. It is for this reason the original hire record method should be used. Therefore, we do
not recommend to use Conversion Hire approach of importing data records for Hiring employees
instead Original Hire Record approach is preferred.
Further consideration are discussed below for the above mentioned two approaches.
• Using Original Hire Record
Each active employee within the system will need to have an initial hire record in order to identify their
employment within EC. The following portlets will need to be used in order to avoid any issues of adding
additional data once the initial Hire record is in place:
▪ User Data File (UDF)

▪ Person Information (personInfo)
▪ Personal Information (personalInfo)
▪ Employment Information (employmentInfo)
▪ Job Information (jobInfo)
▪ Compensation Information (compInfo)
Each portlet will have a number of system-required fields as well as client-specific required fields. The
initial Hire record is used as a place holder of information for the Employee in order to establish their
presence within Employee Central and shouldn’t be used as a reporting source or source of truth for
historical data. In each portlet there are fields that are required to maintain the information from the
legacy source or provide an acceptable alternative in order to be able to import the record into EC.
Following is the portlet level breakdown of how the data import should be handled during migration:
1. User Data File (UDF)
In the UDF file, only required UDF fields should be imported with values. The rest of the fields will be
automatically updated after the initial HRIS Sync run. It is important to note, however, that this is
assuming the customer is going live with EC as their first SuccessFactors module. For customers going
live with EC into a landscape with existing SuccessFactors modules, the UDF should NOT be imported
first, unless it is only being used to import any newly active employees that were hired after the last
UDF import. Other the below mentioned fields are recommended to be imported and not the complete
list of field available in this template as HRIS sync will be used to sync all other data. Also, value for
MANAGER and HR would recommend not to be imported in case there are already some ongoing
processes in other modules, e.g. Performance, as this can shift the forms in case loaded manager is
not correct and they can be reloaded or corrected or synced from Position Hierarchy later on.
23
Field ID Standard Field Example Value Recommendation
Name
STATUS Status active, inactive Default to “active”
USERID User ID aaaa This should be populated with
the unique ID being used for
Employee Central
USERNAME User Name aaaa This should be populated with
the User Name that is being used
for SSO or default to the USERID
field
FIRSTNAME First Name John This should be populated with
the employee‘s first name from
the legacy system
LASTNAME Last Name Smith This should be populated with
the employee’s last name from
the legacy system
2. Person Information (personInfo)
Field ID Standard Field Name Example Data Recommendation

user-id User ID aaaa This should be
populated with the
unique ID being used
for Employee Central.
This user Id represents
the unique employment
of the person and not
the person
himself/herself.
person-id-external Person ID aaaa This should be
populated with the
for Employee Central.
This ID represents the
unique identity of
person and is
independent of
employment.
date-of-birth Date of Birth 01/01/1970 This should be
populated with the
Employee Date of Birth
from the legacy system
in MM/DD/YYYY format
Additional Client Option 1: Populate
Required Fields with the relevant legacy
system field
Caution: It is
recommended not to
Remove
mandatory property
and leave the values
blank during import
Additional Non- These can be left blank
Required Fields
24
3. Personal Information (personalInfo)
user-id User ID aaaa This should be populated with the

unique ID being used for Employee
Central
start-date Effective Start Date 01/01/2018 This should be populated with the
Hire Date being used for the
Employee
first-name First Name John This should be populated with the
Users’ First Name
last-name Last Name Smith This should be populated with the
Users’ Last Name
Gender Gender M This should be populated with the
Employee Gender
personInfo.person-id- Person ID External Aaaa This should be populated with the
external unique ID being used for Employee
Central
Additional Client Option 1: Populate with the
Required Fields relevant legacy system field
Caution: Removing Required status
and leave blank is not a
recommended option.
Required Fields
4. Employment Information (employmentInfo)
Field ID Standard Field Example Data Recommendation

Name
user-id User ID Aaaa This should be
populated with the
for Employee Central
person-id-external Person ID External Aaaa This should be
populated with the
originalStartDate Original Start Date 01/01/2017 This should be
populated with the
legacy Start Date, this
can sometimes be
different from their Hire
Date
Start-date Recruit Date 01/01/2018 This hire date should
be same as the start-
date in Personal Info,
Employment Info &
Compensation Info.
See KBA 2540053.
It is also valid that the

Hire date can be
different from Original
Hire date if the user
has some prior service
25
that needs to be taken
into account before
they actually started -
for example, from a
company merge.
Additionally, if the Hire
Date is the Last Date
the employee was
rehired, then the
Original Hire Date is
the actual first hire date
of the employee.
Additional Client Option 1: Populate
Required Fields with the relevant legacy
system field
Caution: The option to
Remove Required
status temporarily for
imports and leaving
the field blank is not
recommended.
Required Fields
5. Job Information (jobInfo)

Name
populated with the
unique ID being used for
Employee Central
start-date Effective Start Date 01/01/2018 This should be
populated with the Hire
Date being used for the
Employee
seq-number Sequence Number blank It is recommended to
leave the field blank to
avoid potential issues.
The system
automatically assigns a
value. For a starting
record, the value is set
to 1 whereas, for any
other record in the list,
the value is set as per
the following equation
which is
New sequence number =
last assigned sequence
number + 1.
company Legal Entity ABC This should be the
original Legal Entity or
Company at the time of
hire. If not available,
default to a conversion
entity
event-reason Event Reason HIRNEW This should be the
original hire reason from
the legacy system. If not
26
available, default to a
conversion hire reason.
It is also important to
note to use event
reasons that will be used
post-data conversion. It
is not suggested to
creating additional hire
event reasons that are
only used for data
conversion but not going
forward and can cause
reporting discrepancy.
manager-id Manager Bbbb This should be
populated with
NO_MANAGER for the
initial hire record
Additional Client Option 1: Populate with
Required Fields the relevant legacy
system field
Caution: It is
recommended not to
Remove Required status
and leave blank during
data import.
Required Fields
6. Compensation Information (compInfo)

Name
populated with the
unique ID being used for
Employee Central
start-date Effective Start Date 01/01/2018 This should be
populated with the Hire
Date being used for the
Employee and should be
the actual hire date of
the employee.
seq-number Sequence Number blank It is recommended to
leave the field blank to
avoid potential issues.
The system
automatically assigns a
value. For a starting
record, the value is set
to 1 whereas, for any
other record in the list,
the value is set as per
the following equation
which is
New sequence number =
last assigned sequence
number + 1.
event-reason Event Reason HIRNEW This should be the
original hire reason from
the legacy system. If not
27
available, default to a
conversion hire reason.
Also, do not create event
reasons that are only
used for initial data load
but not used going
forward. This could
cause reporting
discrepancy.
system field
Caution: It is not
recommended to
Remove Required status
and leave blank
Required Fields
• Using Conversion Record
As with the original hire record, the conversion hire record works on the same principle. Each active
employee within the system will need to have an initial hire record in order to identify their employment
within EC. The difference between using a conversion hire and an original hire record is the data that
is entered into the record in the system - the conversion hire will use the current information available
for mandatory fields in each portlet and will use a dedicated conversion hire event reason. Conversion
records can exist not only for Hire process but also for others too.
There is not a lot of difference between the data required for a Conversion Hire record versus the
Original Hire record. The decision points will be based on what information will be populated in the
client-based information that is being captured. For the Conversion Hire record, the same information
that is being used for the go-live conversion record can be used as the Conversion Hire record.
In addition to the Hire/Rehire record for an employee there needs to be a conversion record assigned
that will capture the most recent information for the employee at the time of the conversion effective
date. This information will need to be added to the original hire record for all effective dated portlets and
will include all mappable data from the legacy system. This information could also include portlets that
aren’t required from a system perspective in Employee Central (e.g. Phone Information, Home Address
Information etc.).
• Important Considerations for Conversion Record
There are no changes to how User Data File (UDF), Person Information (personInfo) in handling using
conversion record. However, there are certain EC entities that are affected as listed below:
▪ Personal Information (personalInfo): Effective Start Date should be set to either one of the
following:
o Go Live Date: If no conversion record is being used and the only record is the
Conversion Hire record, then this should be the go live date
o Go Live Date – N Day: If a conversion record is going to be used, then the Hire record
should occur before the Go Live date. N is the date of the legacy system freeze, the
last date when HR enters data in the previous HRIS legacy system.
▪ Job Information (jobInfo): The above holds true for this EC entity too.
▪ Compensation Information (compInfo): The above holds true for this EC entity also.
• Handling of Conversion Data in EC Portlets
28
The Effective Start Date needs to be set to the Conversion Date.This includes the following portlets:
▪ Compensation Information
▪ Personal Information
▪ Global Information
▪ Home Address
▪ Job Information
▪ Job Relationships Information
▪ Pay Component Recurring Information
• Job Information (jobInfo)
o The Event Reason needs to be set to a Conversion reason using the Data Change event
and have no Employment Status change associated with it (e.g. DTACNV)
• Comp Information (comInfo)
o The Event Reason needs to be set to a Conversion reason using the Data Change event
and have no Employment Status change associated with it (e.g. DTACNV)
• Additional Fields/Portlets
o All data should be based on the most recent information from the legacy system with
applicable mapping/transformation applied.
6.1.2 Rehire
Two data migration approaches for rehire employee records are discussed as below:
• Solution Approach 1: Using Recent Rehire (Recommended)
In the case of a Rehire within the system, this means that within the legacy system the following
information will exist:
▪ Original Hire Record
▪ Termination Record (source system can have one or more records)
▪ Rehire Record (source system can have one or more records)
In order to minimize the complexity and to keep the historical reporting consistent, the recommended
approach is to take the most recent Rehire record and convert this to their initial hire within Employee
Central. This is done by changing the Event Reason being used from a normal Rehire Event Reason
to one that is used for conversion purposes only that will have an Event of Hire.
• Personal Information (personalInfo)

▪ The Effective Start Date (start-date) needs to be the date of the most recent Rehire within the
legacy system
▪ All other information needs to be effective as of the recent Rehire date as opposed to the original
hire date
• Employment Information (employmentInfo)

▪ The Hire Date (start-date) needs to be the date of the most recent Rehire within the legacy
system. This date shoudl be aligned to the start-date of Personal information, Job Information
as well as Compensation Information.
▪ Adjusted Service Date (service-date) needs to be effective as of the most recent Rehire date
where any adjustments based on the Rehire have been made
▪ All other information can be retained based on the initial Hire record
• Job Information (jobInfo)

legacy system
29
▪ The Event Reason (event-reason) needs to be set to an Event Reason that has an Event of
“Hire” and can be identified as a conversion Rehire (e.g. HIRREH – Conversion Rehire)
▪ All other information needs to be effective as of the recent Rehire date as opposed to the
original hire date
• Compensation Information (compInfo)

legacy system
▪ The Event Reason (event-reason) needs to be set to an Event Reason that has an Event of
“Hire” and can be identified as a conversion Rehire (e.g. HIRREH – Conversion Rehire)
▪ All other information needs to be effective as of the recent Rehire date as opposed to the
original hire date
• Solution Approach 2: All Hire Records Retained
In the case of a Rehire within the system, this means that within the legacy system the following
information will exist:
▪ Original Hire Record
▪ Termination Record (source system with one or more data records)
▪ Rehire Record (source system with one or more data records)
The option to retain all the previous records for the Employee will require the inclusion of all of the
above records where the effective date and additional fields are based on the relevant event being
migrated to Employee Central. This method could be used if history is needed
Each portlet will be the same as the Original Hire record specifications based on the effective date of
the Rehire. There will be an additional portlet that will need to be added which is Termination
Information.
• Termination Information (employmentInfo)

Name
user-id User ID Aaaa This should be populated with
Employee Central
person-id- Person ID External Aaaa This should be populated with
external the unique ID being used for
Employee Central
end-date Termination Date 01/01/2000 This should be populated with
the Termination Date from the
legacy system
event-reason Termination Reason TERINV This should be populated with
the Termination Reason from
the legacy system
lastDateWorked Last Date Worked 01/01/2000 This should be populated with
the Termination Date from the
legacy system
Additional Client Option 1: Populate with the
Required Fields relevant legacy system field
Required Fields
However, for rehiring inactive employes with a new User ID, please refer to the SAP Help Portal Guide
Employee Central Imports under the section Rehiring former employees with Employee Central imports.
30
It is also important to understand and know the process of data loads of terminated employees who are
likely to be rehired in future in the EC system. This details of how terminated employees are loaded are
discussed in the section 6.1.4.
6.1.3 Multiple Employments
Employee Central supports the inclusion of multiple engagements being active for a single Employee
within the system. This will generate multiple User IDs that are in use or, in the case of Global
Assignments it will be split between active and dormant, in case of concurrent employment two active
User ID will exists and in case of international transfers, the User ID of the first employment will become
inactive and the subsequent User ID is active which is created for the new legal entity. You can also
refer to the Implementation Design Principle (IDP) document Employee Central: Managing
Employments in SuccessFactors Suite on employee identifiers and managing employments in EC.
Global Assignments can be loaded into the system as part of the data migration effort if there are active
assignments at the time of the system going live. These imports are treated almost like an independent
employee for the majority of portlets in use within Employee Central. Depending on the number of
Assignments active at the time of go-live, the effort required to manually assign these within the system
may be smaller than the load effort and needs to be considered on a case-by-case basis.
User ID Handling: When a Global Assignment is created in the system, a new User ID is generated.
The User Name field in the UDF remains the same as User ID or can be different based on the
configuration.. When the global assignment is created or imported, that new User ID is how the
additional portlets are loaded and created in the system and the Person ID External is how it links back
to the original User.
• Global Assignment Information
person-id-external Person ID External aaaa This is the unique

identifier of the person
that is going on Global
Assignment in the
system
user-id User ID aaaa-1 This is a unique ID that
identifies the Global
Assignment for loading
and tracking of data
independent of the
Users Home record. By
default, the system
uses -1, -2 etc. when
creating manually
start-date Start Date 01/01/2019 This is the start date of
the assignment
Additional Fields To be filled out
according to the legacy
data specifications
• JobInformation
user-id User ID aaaa-1 This is a unique ID that

identifies the Global
Assignment for loading
independent of the
31
Users Home record. By
default, the system
uses -1, -2 etc. when
creating manually
start-date Start Date 01/01/2019 This is the start date of
the assignment
event-reason Event Reason ADDGA This is the Event
Reason associated with
the starting of the
Global Assignment and
should be assigned the
Event of Add Global
Assignment
Additional Fields To be filled out
according to the legacy
data specifications
Optional Portlets: Global Assignments allows the independent tracking of the following portlets and is
based on the employment:
▪ Job Relationships
▪ Pay Component Recurring
▪ Pay Component Non-Recurring
▪ Work Permit Information
These can be imported from the legacy system in the usual way as long as the records are assigned
correctly to the Host record using the User ID explained above.
Also, note that new host address type is required for employees on active global assignment. When an
employee is on a Global Assignment, the new global address is added to the new address type host.
However, because the Import template does not include this field by default, certain changes need to
be made in the data model. This requires changing the Succession Data Model in Provisioning to
configure the <emp-users-sys-id> field. Once configured, the Address Info Import template will include
the emp-users-sys-id column as shown below. Note that the import of the host address would be
successful only for the employees with users_sys_id on a Global assignment.
Please refer to the section Importing Global Assignment in the SAP Help Portal guide Implementing
and Configuring Global Assignments in Employee Central for further details on how to import global
assignment in EC.
• Concurrent Employment
In much the same way as Global Assignment, the migration of Concurrent Employment is dependent
on the User being in the system and assigning a unique User ID to the concurrent employment(s) when
they are created.
The difference between Concurrent and Global Assignment is which portlet to load to create the
assignment. For Concurrent Employment, importing Employment Info with the correct set up will create
the secondary assignment and allow the additional portlets to be loaded using the new IDs.
Please refer to the SAP Standard guide Implementing and Configuring Concurrent Employment in
Employee Central for further details in the SAP Help Portal for complete details on how to setup
concurrent employment as well as the section Importing Concurrent Employments for Employees which
discusses details specific to importing concurrent employments of employees.
After an employee has been created initially in the EC system, and later adding the employment info as
mentioned below will create secondary employment for the person. We can now use this new UserID
created in the Employment Info to import other related data such as Job Information, Job Relationship,
Compensation Information, and so on specific to this new (secondary) employment.
32
Employment Info:
user-id User ID aaaa-c1 This is a unique ID that

identifies the Concurrent
Employment for loading
independent of the
Users master record
person-id-external Person ID External aaaa This is the unique
identifier of the person
that is going on
Concurrent Employment
in the system
originalStartDate Original Start Date 01/01/2000 This should be
populated with the
legacy Start Date of the
Concurrent Employment
system field
Do not use the option to
Remove Required
status and leave blank.
Required Fields
• International Transfers
International transfer is one when you manage employees when they transfer to a new country and
different legal entity within the company’s organization. The recommended procedure for such transfers
is a termination and rehire with a new employment as most payroll systems do not accept a legal entity
change within an active employment. However, it is important to note that the start date of the new
employment should be end date of the previoius employment to ensure the new employment records
are successfully created. The previous employment should be terminated and hence this employment
should be loaded with the termination template to complet this process. Such an employee is
considered inactive employee in Employee Central system. Therefore, when we need to create
international transfer for such employee, then it is rehiring the employee in the new legal entity.
From 1911 release onwards, it is possible to Rehire Inactive Employee with new user-id with which
we can add new employment details separately and also maintaining the historical record of their
previous job and employment details.
Below are the steps to Rehire Inactive Employees with the new user-id;
1. Enable the New Standard Field 'isRehire' in Manage Business Configuration>Employee

Central>HRIS Elements>employmentInfo,
2. Make Sure Permission for 'Rehire Inactive Employee with New Employment' is granted under
the Permission Role>Manage User,
3. Navigate to Admin Center>Import Employee Data',
4. Download the Template for Employment Details (Select the field 'isRehire' from the Available
Fields before downloading),
5. Fill the details in the downloaded template with the following details;
33
o 'person-id-external' – Enter the old person-id-external (which is for the system to
identity the inactive old user record) ,
o 'User ID'- Enter the New User ID
o isRehire - <isRehire> is a boolean field. It accepts a set of values for Yes. To set the
value as Yes, you can enter: <Y>, <Yes>, <T>, <True>, <1>. By default, the system
considers the field value as <1>.
6. Import the template back in Import Employee Data>Entity - Employment Details. If successful,
new user accounts are created in the system. To activate these accounts, you must execute
the following steps.
7. After the employment details are imported in the system, download a copy of the Job
History template from Admin Center> Import Employee Data,
8. Prepare data to be imported in the system. Along with other information, enter the new user id
of the rehired users in the <User ID> (Same USER ID which was used in Employment Details
Template above).
9. Upload the data into the system. After the scheduled HRIS SYNC job is completed
succesfully, the new user accounts are activated in the system.
After the successful rehire, you can see the profile switch option to switch between Old Profile and
New Profile.
Note: You can rehire users with a new user id, thereby keeping the user id of their previous employment
unchanged. However, you must ensure that there is no employment currently active in your system for
such users. In a case where a user being rehired has an active employment already, a concurrent
employment will be created for the user.
6.1.4 Termination
When migrating from a legacy HRIS system to Employee Central there should be consideration of those
Employees within the system that are Terminated. These employees exist in the legacy system with a
unique identifier which remains reserved within that system as well as the payroll attributed to it.
There are a number of situations where the rehiring of these terminated employees may come up. This
can cause issues in downstream systems if the same ID isn’t being used for the Rehire or if it’s not
known that the employee is a rehire, then too it can create problems. The rehire should link the
employee to their original records. The recommended approach is to have one year of termination
history included as part of the migration strategy if compensation merit cycle is required post-go live.
• Scenario 1: Load Basic UDF Data Only
In order to prevent reusing an User ID that might already be attributed to a terminated employee, one
approach is to pre-load the basic user information only for the terminated population that has been
decided upon. This will prevent any User ID based issues coming into play and avoids issues
downstream.
If an employee is identified as a Rehire their original User ID exists in the system and can be used to
match and provide the additional details that Employee Central requires for the hire. This will require
the use of a Hire-Rehire event reason which is needed in order to Hire the person into Employee Central
but still be able to identify them as a Rehire. The Event Reason itself needs to be set up as a Hire Event
but the Payroll Event for that Event Reason can be set to use a Rehire Event/Event Reason in order for
the Payroll system to identify this user as a true rehire instead of a fresh Hire.
However, one has to note that using such a method would mean that while doing the rehire, you will
have to purge the UDF records so that you can rehire the employee via the UI using their previous
User ID or you have to use the data import files to add the employee to the EC system.
• Scenario 2: Load Minimum Data Load
34
In addition to the load of the basic user file there is the option of loading the minimum required data for
the original Hire and Termination to be processed for the population of Terminated employees being
loaded into the system.
This is a more seamless integration of these Terminations as it will contain their original hire record as
well as their original termination and thereby allowing the Rehire to be processed by Employee Central
correctly and flow to the payroll systems without issue. This method will require the usage of the Original
Hire record outlined in the solution that will be included with the following :
▪ UDF
▪ Person Info
▪ Personal Info
▪ Employment Info
▪ Job Information
In addition, once the Original Hire is loaded, the Termination Information will need to be entered for this
population which will have them correctly listed as a Terminated employee and can be rehired as
needed.
While executing such a process, you may chose to load the terminated employees first and before doing
it you can disable any mandatory fields temporarily. After the terminated employees are loaded, the
mandatory field validations can be reapplied.
6.1.5 Leave of Absence
The Leave of Absence using Time Off has some restrictions on how the data is to be loaded into the
system. This is particularly noteworthy when making corrections and files need to be reloaded within
Job Information and existing data for Leave of Absence already exists. In order to load LOA records
into the system using Time Off for LOA then a record needs to be imported into the Employee Time
object rather than directly into Job Information
Recommended Settings for LoA Migration

o Workflow
It is not recommended to have workflow turned on during the loading of Leave of Absence records. This
can cause a large backlog of approvals required before the data can be entered in the system correctly
and may potentially affect further loads if the approval hasn’t been completed.
o Time off for LoA
Employee Time
In order to load LoA records, the Employee Time object is used. This means that records are imported
using the MDF Import/Export function. Once the record is imported into Employee Time then a Job
Information record is created as a post-import process.
Employee Time Portlet

Name
userId User ID aaaa This should be populated with
Employee Central
startDate Start Date 01/01/2018 The original start date of the
leave from the legacy system
externalCode External Code LOAaaaa01012018 A unique external code for
the object, usually can be
35
defaulted to LOACODE +
user ID + start date
approvalStatus Approval Status APPROVED This should default to
APPROVED for existing
LOAs
Editable Editable TRUE This should default to TRUE
loaExpectedReturnDate Expected Return 01/01/2019 The expected return date
Date from the legacy system where
possible
timeType.externalCode Time Type LOAMAT This should be the external
code of the Time Type set up
for the specific LOA reason
being used for the Employee
Post-Import Updates to Job Information
When using Time Off for LOA it’s important to note that any changes to Job Information should be
finalized before loading the Employee Time object. The reason for this is that once the Employee Time
has been entered for a user, importing the change information through Job Information is no longer
possible where it affects the LOA record. In order to modify Job Information through import after
Employee Time is loaded, its recommended to remove the Employee Time record either through a
Deletion load or manually through the system. This will allow the importing on Job Information to
continue with any required changes and then re-load the Employee Time records.
6.2 Handling Migration of Specific EC Entities
6.2.1 Dependents
Dependents are stored differently within Employee Central and follow different validation rules based
on the set up of the system. This can mean some fields that are required for a regular Employee may
not be relevant and shouldn’t be validated against a Dependent.
• Creating User Id
In order to create a Dependent within the system an ID needs to be created that exists independent of
the User that it is assigned to. In order to do that a Person Info record needs to be created where:
▪ Person ID External is the User ID of the Employee that the Dependent is being assigned to
▪ Related Person ID External is the unique identifier of the Dependent which can be used to
assign to the Employee
The system will assign a a dependent Id automaticallly if it is left blank on import. However, it is not
recommended to have the system automatically assign the ID as this will lead to issues if you need to
reimport dependents or insert additional records for dependents already in the system.
o Loading Additional Employee Data

o Person Relationship Information

Name
personInfo.person-id- Person ID External aaaa User ID of the
external Employee that the
dependent is being
assigned to
related-person-id- Related Person ID aaaa-d1 User ID created in
external External Person Info that is the
36
unique identifier of the
dependent
Additional Fields Filled out as needed
from legacy system
data
• Additional Dependent Information

Additional Dependent information can be imported later for the following portlets:
▪ National ID
▪ Home Address
▪ Global Information
These portlets can be filled out the same as a normal Employee, but specific fields can be included or
excluded based on the configuration of the dependents view respective of the Person Type. You can
also use the Consolidated Dependents template that includes data specifics to Person Relationship,
Biographical Information, Personal Information, National ID Information and Address entities. While
using Consolidated Dependents import template, ensure to assign a unique <person-id-external> in the
Related Person ID External column of the dependent’s record. You have to ensure atleast one non-
effective dated record exist per dependent.
6.3 Time-Off Data Load
Customers need to know the process to migrate Time Account balances and Leave Request history to
Employee Central at the time of Go Live. The history of Employee Time data directly depends on the
employee’s EC job history. The recommendation provided below provides a series of steps to migrate
these time objects. Mock testing cycles should be executed in test instance to avoid any surprises in
the production instance and to refine steps with more specifics & details.
Let's assume that the Go Live is planned for 1st January 2022 (or any future date) and 1 month history
of leave requests is required by the customer. We can divide the migration process under following
three headings, in the listed order:
1. Migration of Time Accounts

2. Migration of Time Account Balance
3. Migration of Employee Time (Leave Requests)
Migration of Time Accounts
Migration of Time Accounts need the Time Profile along with Time Types to be applied to each eligible
employee.
1. Time profile for employees will need to be applied effective 1st December of previous year. This is
because Time Accounts and Time Types must exist for leave history data to be uploaded.
2. Next step is to create Time Accounts for all employees. System generates the Time Accounts
automatically when Time Profile is assigned to employees. In case of Recurring Accounts, depending
on Account Creation Offset field value under Time Account Type settings, accounts for next year may
also get created.
3. Once the time accounts are created, it is necessary to validate Time Accounts for two aspects:
• They have correct validity and bookable period as per your Time Account Type configuration.
Figure 1: CSV Export Template for Time Account
37
• They are created for all eligible employees
To export Time Accounts to validate, follow these steps:
• Navigate to “Import and Export” data

• Select the action to perform- “Export Data”
• Select Generic Object - “Time Account”
• Do not include dependencies
• Export
• Navigate to “Monitor Job” and download “Time Account” file to validate the two aspects namely; - correct
validity and bookable periods and assignment to all eligible employees, as mentioned above.
• If Time Accounts for some employees did not get generated, execute the Time Account Creation
Calendar under Time-Off calendars for such employees.
When you assign time profiles as of Go-Live date along with time types, even the accruals are run for vacation
accounts automatically which you may have to adjust later. If you are migrating the balances as manual
adjustments, then you do not want the accruals for the migration year to run as balances are brought from external
system for that year.
Note that hire accruals are always created automatically, independent of the accrual automation setting on Time
Account Type.
It is advisable to assign empty profiles in job info and then add time types to these time profiles to avoid creation
of hire accruals. Due to empty profile assignment, Time Accounts will not be created. You will need to run Account
creation calendar manually for creating them.
Migration of Time Account Balance
Once Time Accounts are created for all eligible employees, next step is to upload closing balances as of 30th
Nov 2021(End of Day) .
To upload Time Account Balances, follow these steps:

• Select the action to perform- “Download Template”
• Select Generic Object - “Time Account – Time Account Details”
• Fill the template with Time Account Balance details for all eligible employees. Ensure to put the Posting
Date, 1 Dec 2021 and posting type as Manual Adjustment. Do not use ‘Accrual’ as posting type.
• Time Account Details template only contains external code for time accounts. There is no column for
User. Hence it is important to ensure that correct balances are loaded for correct users based on the
external code of Time Accounts generated for them.
• If the time account type is configured as “Entitled as transferred”, both accruals and entitlements will
need to be uploaded during migration as in Long Service Leave in Australia. Do not use ‘Accrual’ and
‘Entitlement’ as the posting type for initial account balance transfer. Instead, opening accrual and
Opening entitlement should be used as posting types.
To validate if the next transfer date for entitlement (post Go Live) is correct for all accounts, follow the
steps:

• Select the action to perform- “Export”
• Select Generic Object - “Time Account Type Accrual Transfer”
38
Note that the Time Account Type Accrual Transfer object is automatically created along with Time
Accounts, if applicable. Check the Next Transfer and Last Transfer dates for all accounts. The initial
accrual transfer date rule should have been set up as prescribed in the SuccessFactors Time
Management Configuration guide.
Migration of Employee Time (Leave Requests)
Next, Employee Time Data (Leave Request) needs to be uploaded.
Please be aware that no workflow is triggered on import. If you import with the Approved status,
then the leave is directly set to Approved without a workflow. Also, it is not recommended to use
the status Pending for import because no workflow is triggered. Please import with the Approved
status.
1. To prepare Employee Time Data for upload, identify:
▪ All leave records (with status approved) in your current HR system with cross over on 1 Dec
2021. Eg leave from 25 Nov to 5th Dec. Such records will need to be split into 2 records:
o One from 25th Nov to 30 Nov -This should not be uploaded as the this duration is already
deducted from Opening Balance uploaded for 1 Dec 2021
o Another from 1st Dec to 5th Dec- This should be included in Employee Time Upload Template
▪ All Leave records (with status approved) with Start Date on or after 1 Dec .
2. To upload Employee Time data,
▪ Navigate to “Import and Export” data

▪ Select the action to perform- “Download Template”
▪ Select Generic Object - “Employee Time”
▪ Fill details of all leave requests identified above as part of cross over and future leaves in the
template and upload
Figure 2: Leave History Upload
Note that there is no standard migration functionality of leave quota and Leave requests from ERP HCM to EC.
There is only replication iflow for it using data replication proxies.
39
6.4 Handling Contingent Worker Migration
Contingents are stored differently within Employee Central and follow different validation rules based
on the set up of the system. This can mean some fields that are required for a regular Employee may
not be relevant and shouldn’t be validated against a Contingent Worker. There are also additional data
elements around Work Orders that are specific to Contingent Workers that need to be included.
• Contingent Worker EC Templates

The following portlets are required for importing a Contingent Worker into Employee Central and need
to be loaded in this order:
▪ Basic Import (UDF)
▪ Employment Details
▪ Work Order Information
▪ Job Information
▪ Email Information (optional)
Apart from the Employment Details, each additional portlet can be configured in a way that includes or
excludes fields for contingent workers only. This means that any data that isn’t relevant for capture
against a contingent worker can be excluded from the view for the portlets that are already con figured
for normal employees. You can use Bussiness Configuration UI to achieve this distinction.
If a field is required in the data model, it should not be made optional in the Contingent Worker UI,
and it should be a required field for the Contingent Worker import process.
• Differences by Portlet
▪ Employment Information
o Inclusion of the additional field Is Contingent Worker (IsContingentWorker) which is a
Boolean data type of 1/0. In order to successfully import, this will need to be set to
TRUE.
▪ Additional Portlets
o Each of these portlets will be populated based on the inclusion or exclusion of fields
set up as a Contingent Worker Person Type. Person Types are visible in BCUI
(Business Configuration UI) only when the respective modules are enabled from
provisioning. For being able to see contingent worker as a dropdown option under
Person Type on BCUI, one has to enable Contingent Worker module from Provisioning.
40
You need to contact your implementation partner or SAP Cloud Support to request changes to
Provisioning. In order to understand which EC entities have the option of contingent worker person
type to configure the respective field configuration, please check the section Supported Person Types
in Business Configuration UI in the SAP Help Portal guide Setting Up and Using Business
Configuration (BCUI).
▪ Work Order: The start date of the work order, employment info and job info files should be
aligned else it would fail.

Name
userSysId User ID bbbb This should be
populated with the
effectiveStatus Effective Status A Should default to A for
Active
workOrderOwnerId Work Order Owner aaaa This should be
populated with the ID
of the user in the
system responsible for
the contingent worker
startDate Start Date 01/01/2016 Start date of the Work
Order from the legacy
system
workerType.externalCode Worker Type ContingentWorker Default to
ContingentWorker
workOrderID Work Order ID WKO1234 Unique identifier of the
Work Order
workOrderName Work Order Name Work Order 1234 Name of the Work
Order
Additional Fields Filled out as needed
from legacy system
data
Recommended Configuration Settings

Following are some of the critical configuration settings in Employee Central that affect the data
migration process.
• RBP
Basic User import can be controlled through the following settings and permissions can be then granted
via Manage User settings.
41
• Business Rules
▪ Rule Triggers on Import
Business rules that are defined on the field or portlet level can be triggered when an import is loaded
for that portlet. The triggering of these rules can be controlled through the Role Based Permissions area
which means whether or not the rule triggers can be made by Role. Business rules should be turned off
during the initial data loads. In addition, it is important that business rules are disabled for imports in
RBP.These portlets include:
o Personal Information
o Job Information
o Compensation Information
o One Time Payments /Non Recurring Payments
o Job Relationship (added this one)
o Termination Information
In addition to the RBP option there is also settings on the rule configuration within Manage Business
Configuration that can determine whether the rule should be triggered on import or other scenarios
within the system:
42
Most rules can trigger without issue on importing but the following scenarios should be avoided:
• Event Derivation: Importing into portlets that have an event derivation rule active would either have
to have the conversion Event Reason excluded or the rule not enabled for importing for data
migration
• Workflow: Importing into portlets that have a workflow rule active shouldn’t normally have the rule
enabled for importing unless there are specific reasons. If used for importing in other instances, it
should be turned off for data migration purposes
• Cross Portlet Rules: Some rules within Job/Compensation/Job Relationships can trigger an update
to the respective portlets as part of the rule. These should be turned off for data migration importing
• Basic Validation Checks
Validation Check Description

Cyclic Manager Reference Employee to Manager relationship is checked in the system. If at any
point the Manager refers to themselves or someone else lower in the
same branch of the hierarchy then an error is generated
Job Relationship References This will check to make sure the Employee references in the Job
Relationship is active during the entire period that the Job
Relationship exists for
Foundation Object This will check to make sure the Foundation Object is active for the
period
Picklists – Label When a picklist is used within the import files for the standard legacy
portlets (e.g. jobInfo) then the label of the picklist field is used as the
import data and is checked against the Picklist ID assigned to the field
to make sure it is active. NB: The Option ID assigned is the first one it
finds matching the label
43
Picklists – Parent/Child If a field is set up as a Parent/Child relationship to another picklist
then the association between the parent and child is checked based
on the label and an option ID is assigned. NB: The Option ID
assigned is the first one it finds that matches the label
Picklists – External Code When importing using an MDF object with a field that is defined as a
picklist then the External Code is used instead of the label and will be
compared to the picklist to make sure it is active
• EC Alerts and Notifications: Before importing employee data into EC, alerts & notifications job
should be disabled. In the cutover plan this is normally one of the last jobs that gets scheduled, just
before go-live.
6.5 Handling Phased Deployment
• Phases by country or Payroll areas
When going live with Employee Central across multiple countries and payroll groups, one option to
consider is a phased deployment which will mean staggering the go live and inclusion of data in
Employee Central across a longer period of time and split by country or payroll system.
This can affect timelines of the project but can potentially reduce overhead on the project team as the
deployment is not hitting all areas at the same time. It can reduce initial problems with the system or
data and allow more time to smooth out internal processes.However, this can also make it easier to
manage the downstream integrations that are being used by splitting up the development and
implementation to those that are going live in specific phases. This means the project team is only
looking at one payroll integration at a time.
The idea of phased rollout is to load an EC "mini" master record for all employees globally. Where
SuccessFactors is already implemented for talent and the employee profile is editable, as soon as EC
is enabled, the EP fields become read only, so the EP records can only be updated through import.
This adds weight to the approach of loading all employees into EC from the start and then expand their
records as the phased roll out continues..
• Cross-border Managers
When using a phased approach, a common occurrence is when a Manager or Direct Report is allocated
to a different country and subsequently a different phase than his direct reports. In this approach its
recommended to load the following information for these cross-border managers:
▪ UDF Profile
▪ Person Information – Hire Record
▪ Personal Information – Hire Record
▪ Job Information – Hire Record
This creates the user in the system in order for them to be assigned as a Manager to the employee that
is in the current phase without having to fully load the Manager and have to maintain them in two
systems until the Manager’s phase is completed.
• Example Employee A:
Country: Australia
Go Live Date: 01/01/2019
Manager: Employee B
44
Employee B:
Country: United States
Go Live Date: 03/01/2019
Manager: None
Load Requirements
Effective Date Employee Load Type Portlets
01/01/2019 Employee A & B Initial Hire ▪ UDF Profile
▪ Person Information
▪ Job Information
01/01/2019 Employee A Conversion ▪ Personal Information

Record ▪ Job Information
▪ Any additional non-essential
portlets
03/01/2019 Employee B Conversion ▪ Personal Information
Record ▪ Job Information
▪ Any additional non-essential
portlets
The Conversion Record load for Employee A will include the link to the Manager as Employee B who
will exist in the system as an initial hire record until the second phase is ready to go live. This way no
maintenance needs to be done on the cross-border manager in between phases.
• Global Assignment
Similar to a cross-border manager, the same can be said for Global Assignment where the Home or
Host record is in the current phase and the corresponding record is not. This can be approached the
same way as cross-border managers.
▪ Home Record in scope, Host Record not in Scope: If the Home Record for the Global
Assignment is in scope in the current phase and the Host Record is in a different country or
phase then the Global Assignment Host record can be included in the later phase and Home
record updated to reflect Away on Global Assignment where needed
▪ Host Record in scope, Home Record not in Scope: If the Home Record for the Global
Assignment is not in the current phase then additional loads need to be done in order to support
the Global Assignment Host record in the current phase. This will include loading the following
for the Home Record:
o UDF Profile
o Person Information – Hire Record
o Personal Information – Hire Record
o Employment Information
o Job Information – Hire Record
This will allow the creation of the Host record once the Home record has been established in
the system. When the Home record country becomes in scope then the additional files and
records can be updated
• HRIS Sync
The Human Resource Information System (HRIS) synchronization is the sharing of data from
Employee Central to the Platform account table User Data File (UDF). The information is determined
from basic mappings between EC and the UDF in order to maintain the source of information for the
other modules that are using the UDF as a User base. HRIS should not be configured until after EC
45
data loads are complete and validated. Please refer to the guide for additional information in the
Employee Central Master Guide on SAP Help portal.
• Real-Time Sync
When changes are made to Employee Central directly within the user interface then the synchronization
between EC and UDF is made immediately and the results will be seen directly on the UDF or
Organizational Chart.
• Off Cycle Event Batch
When processing off-cycle events that occur on a regular basis there is a job that is set up to run daily.
This accesses the Off-Cycle Event Batch MDF table to determine the details of the job that needs to be
running as well as how frequency. This job can potentially update or insert new records into Job
Information, Employment Information, Employee Time or Work Order portlets. Off Cycle Event Batch
should be turned on after data loads are complete and the data has been validated. To see if JobInfo
is in sync with Position Hierarchy, the standard Advanced report can be run, and issues can be identified
and corrected before this job is scheduled.
• Benefits
There are a number of Life Events that can be triggered within Employee Central that are set up
within Provisioning that will run based on changes made to the system. These include:
• New Hire (for Auto Enrolment)
• Birthday
• Service Anniversary
• EC Alerts and Notifications
When a rule is set up to use the SaveAlert or defined within the Post Save section of the MDF object
then it is creating an Alert within the system. A provisioning job is created that runs these jobs on a
scheduled basis based on the Effective Date of the alert.
• HRIS PayComponentGroupSums Sync
This is a job that is run on a daily basis to provide the totals of the Pay Component Groups in the
database for use in reporting.
• Additional Note on Provisioning Jobs

All jobs to be activated after data import and all data corrections done correctly. One has to take care
of the order of the most important EC scheduled jobs and have enough gap between each of them, so
the previous running job ends successfully. One of the of possible order of provisioning jobs are listed
below:
o HRIS Sync
o HRIS Pay Comps Sums
o BiZX Daily Rules (e.g. for adopting managers within Job Info to fit Position Hieararchy
& trigger Batch Rules)
o EC Alerts and Notifications
o Workflow Reminder
o Workfow Escalation
o Workflow Auto Approval
• Additional Tips for Successful Import
46
o Ensure that all the required fields are entered in the file. Also, verify that the value in each
column is correct/valid.
o Validate that the columns in your import file corresponds to the columns in the import template.
If not, you need to download a new import template from Import Employee Data.
o Verify that the field you have enabled for an HRIS-element is valid. To know more about field
configuration, see the Data Object Tables handbook on the SAP Help Portal.
o Check that the fields are configured correctly. For example, if the field is a picklist or an object
related field, ensure that the related picklist/object is configured to the HRIS-field.
o Make sure all the effective-dated records for Employees are in a single CSV file. This is
applicable only when importing multiple batches in parallel
6.6 Data Quality Validation Post Successful Migration
Data quality validation process generally involves data level validations and application validation. Below are some of
the ways that will help you form your data quality validation checklist.
Data validations have two checkpoints, first one is related to validating foundation data (prior to employee
data migration), followed by employee data.
Foundation Data: Foundation object data should be uploaded first along with their associations, followed by
Position data. Once the organization data is uploaded, next step is to upload employee data as Foundation data
is used to populate data at the employee level.
o MDF objects (Generic Objects, Migrated FO like legal entity, Division etc and custom Generic objects)
and their relationship should be validated using the import/export functionality after the migration. It is
highly recommended to validate all the uploaded foundation data because once the data is assigned to
employees it is a multi-step time consuming process to rectify the data.
o Legacy Foundation data like location, pay component and others (Foundation objects present in
corporate data model) should be exported using the Table reports (adhoc report) to validate the data.
o Position data should be validated next. It is recommended to engage business user to validate the
position structure using Position Org Chart or by exporting Position object using Import and Export
functionality. Only small sample should be validated but recommendation is to validate top 2-3 levels if
you are implementing rigid structure (example: objects - business Unit, Divisions and
department) rather than the lower-level position structure. It is easier to adjust the lower level as
compared to top level structure in such cases.
Organization Structure UI could be used by the business user to validate the corporate organization structure.
Employee Data:
Check Tool could be used to validate the data consistency in SuccessFactors system. This tool allows you to
validate data on almost all the objects. Check tool execution for following applications is explained below:
• Admin Alert 2.0

• Employee Central Core
• Position Management
• User Management Admin Alert 2.0 – Although designed for administrators for day-to-day use, it is a
very handy tool to highlight any data issues immediately after data migration. Admin Alert 2.0 is available
as an application within Check Tool for which configuration checks can be executed. Admin Alert 2.0
supports Job Information portlet’s foundation object issues as of today.
47
Below figure shows the admin alert:
If you find any issues, click and navigate to the detail pop-up window.
As you can see in the result screen shot above, alerts are generated for any data inconsistencies in the
system. All the alert types can be further explored in detail. For example, if we navigate to ‘Job Information
Issues’ below screen will pop-up with details.
48
We can see in this screen that either the configuration such as association is either missing or has been changed
or other data issues.
Within check tool there are several applications, but Employee Central Core is one of the important ones.
This checks for any configuration and data conflict. This tool also highlights issues along with severity and
recommended solution to address the issue.
As you can see in the below screenshot, Personal information has been checked by the tool and some issues
are found.
Clicking on the issues helps to navigate to the window where the error message is displayed and the proposed
solution as shown in the screen shot below:
49
It is recommended to execute Check tool for all the configured entities. Below screen shows the detail application
window. Below is an example for person object, with the issues and the proposed
result.
50
User Management: In addition to the Employee Central Core, this is another important object to check
for. Select ‘User Management’ in the Application and execute available checks. Results will show any users
with data issues such as manager cycle, duplicate email addresses etc.
Clicking the error message will open the details of the error, where you can also see the proposed solution.
Position Management: Check Position Management Application using Check Tool. Running checks can
highlight any issues with configuration, data inconsistencies in position object as shown below.
51
It is recommended to execute Check Tool for all configured applications based on your implementation.
7 ASSUMPTIONS AND EXCLUSIONS
This document specifically caters to green field implementation of Employee Central.
8 REFERENCES
SAP Help Portal: Standard Guides

• Mass Changes in Employee Central
• Implementation Guide: Employee Central Master
• Developer Guide: Data Object Tables in Employee Central
• Implementing the Metadata Framework (MDF)
• Managing Multiple Employments in SAP SuccessFactors
• Implementing and Configuring Global Assignments in Employee Central
• Implementing and Configuring Concurrent Employment in Employee Central
• Implementing and Managing a Contingent Workforce
Implementation Design Principles for SAP SuccessFactors Solutions

• Employee Central: Implementation Considerations for a Phased Rollout
SAP Notes / KBAs

• 2861759 - 1911 Rehire Inactive Employee with New Employment through import
• Employee Central: What is HRIS Sync?
• Employee Central: Data Imports FAQ
9 ADDITIONAL RESOURCES
Architectural Leading Practices (ALP)
52
53
Implementation Design Principle
www.sap.com/contactsap
© 2022 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.
The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/copyright for additional trademark information and notices.

IDP - Employee Central Data Migration Strategy- V5.0 (2)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IDP - Employee Central Data Migration Strategy- V5.0 (2)

Uploaded by

Copyright:

Available Formats

Implementation Design Principle

SAP SuccessFactors Employee Central: Employee

The following table explains some abbreviations used in this document.

MDF Meta Data Framework

RBP Role Based Permissions

HRIS Human Resource Information System

4.1 Project Requirements

4.2 Functional Requirements

4.3 Technical Requirements

5 SOLUTION OVERVIEW AND CONCEPTS

5.1 Project Design

5.1.1 Different Implementation Launch & Considerations

• Staggered/Phased Rollout of EC Implementation: In the staggered approach, the employee

5.1.2 High Level Data Migration Strategy

Data Migration Strategy (Reference: Architecture Leading Practice (ALP))

5.1.3 Freeze Period (Cut-Over) Considerations

5.1.4 Concerns While Handling Employee Data

5.1.5 Multiple Module Deployment

5.1.6 Multiple Legacy Systems

5.1.7 Data History Considerations

Alternative History Recommendation

5.1.6.1 Inclusion of History via MDF Solution

5.2 Functional Design

5.2.1 Active Employee Population

5.2.2 Rehire of Previously Terminated Employees

5.2.3 Multiple Employments

5.2.4 Foundation Data

5.3 Technical Design

5.3.1 Data Transformation Considerations

5.3.1.1 Effective Dated and Non-Effective Dated EC Entities

5.3.1.2 Leading Zeros

5.3.1.3 Foundational Objects

5.3.1.4 Picklist Migrations

5.3.2 Mass Upload Considerations

Validation Standard Portlet MDF Portlet

• Basic Import (User Creation)

5.3.2.4 Provisioning Job Follow Ups

Portlet Provisioning Job Names Description

Feature Description Optimal Setting

Feature Description Import Setting Post-Import Setting

Feature Description Import Setting Post-Import Setting

• Batch Size Considerations

• Company System and Logo Settings

Feature Description Import Setting Post-Import Setting

5.3.3 Russian Data Privacy

5.3.4 Implication of GDPR on Data Migration

6.1 Employee Migration based on HR Processes

▪ User Data File (UDF)

1. User Data File (UDF)

2. Person Information (personInfo)

Field ID Standard Field Name Example Data Recommendation

Field ID Standard Field Name Example Data Recommendation

user-id User ID aaaa This should be populated with the

4. Employment Information (employmentInfo)

Field ID Standard Field Example Data Recommendation

It is also valid that the

5. Job Information (jobInfo)

Field ID Standard Field Example Data Recommendation

6. Compensation Information (compInfo)

Field ID Standard Field Example Data Recommendation

• Using Conversion Record

• Important Considerations for Conversion Record

• Handling of Conversion Data in EC Portlets

• Job Information (jobInfo)