SAP SuccessFactors · HCM · Master data

    SAP SuccessFactors Employee Data Migration

    Migrate employee records into SuccessFactors Employee Central, covering basic user information, biographical and personal data, national identifiers, addresses and the dependencies that gate the load.

    Object overview

    The employee in Employee Central is not one record. It is a set of related entities — basic user information, person, biographical information, personal information, national ID, addresses, contacts — loaded in a defined sequence through separate import templates.

    Person ID External is the key decision on this object. It ties every subsequent entity together and determines whether history stays traceable back to the legacy system, so it is settled before any template is built.

    What data is typically migrated

    Scope is agreed in discovery; this is the shape of the object.

    Data areaTypical information
    Basic user informationUser ID, Person ID External, username, status, email
    PersonThe person container that employment and biographical data attach to
    Biographical informationDate of birth, country of birth, gender
    Personal informationName, marital status, nationality — effective-dated
    National IDIdentifier, card type, country, primary flag
    AddressesHome and mailing addresses, country-specific formats, effective-dated
    ContactsEmergency contacts and dependants where in scope

    Object relationships

    Dependency drives load sequence: a child cannot exist before its parent.

    Basic user information (Person ID External)
    └─ Person
    └─ Biographical information
    └─ Personal information (dated)
    └─ National ID
    └─ Address (dated)
    └─ Emergency contact

    Object migration flow

    Source EmployeeDataMoveMap & transformValidateSAP SuccessFactors EmployeeDataVault reconciliationSign-off

    Before you migrate this object

    Confirm each of these before the first migration cycle.

    Foundation Objects and picklists are configured
    The Person ID External strategy is agreed
    Country-specific mandatory fields are identified per legal entity
    Address formats are configured for every country in scope
    Effective-dating scope for personal data is agreed
    Personal data handling and access controls are in place

    Common source systems

    Production-proven means we have delivered this object from that source. Supported and custom-mapping describe capability, not delivery history.

    Oracle JD Edwards Production-provenPeopleSoft SupportedSAP HCM SupportedWorkday SupportedOracle HCM Cloud Supported

    Source-to-target mapping examples

    Object-level equivalence. Field-level mapping is produced per engagement.

    Source systemSource entityTarget object
    JD EdwardsAddress Book (F0101) + Employee Master (F060116)Basic user + Person + Biographical
    PeopleSoftPERSONAL_DATA + PERS_NIDPerson + Biographical + National ID
    SAP HCMInfotypes 0002 / 0006 / 0021Biographical + Address + Dependants

    Migration methods for this object

    Import Employee Data — CSV templates per entity

    Full purge for the initial load, incremental for subsequent cycles

    OData API for post-go-live maintenance rather than bulk migration

    Extraction considerations

    Person versus employmentLegacy systems usually hold the two together. Separating who the person is from their employment relationship is the first extraction decision, because Employee Central models them apart.
    Effective-dated personal dataName and marital status changes are dated records in Employee Central. Sources holding only current values produce a single dated row, which is a scope decision to make consciously.
    Country-specific identifiersNational ID requirements differ per country and are mandatory in several. Missing identifiers block the load for those populations.
    Address format by countryEmployee Central validates addresses against country-specific formats, so free-text legacy addresses need parsing.

    Transformation rules

    Legacy employee number to Person ID ExternalThe anchor decision. Retaining the legacy number keeps history traceable; generating new requires a cross-reference that every downstream entity uses.
    Name componentsLegacy single-field names split into the components Employee Central expects, which vary by country.
    Gender and marital status crosswalksMapped to the picklist values configured in the target instance.
    Date conversionSource date encodings — JD Edwards CYYDDD in particular — converted to calendar dates with the century handled correctly.
    Address parsingInto the structured components each country's format requires.

    Data quality and validation

    Person ID External uniqueness

    Duplicates break every dependent entity.

    Mandatory fields per country

    Which differ by legal entity country.

    Picklist values exist

    Gender, marital status, nationality and ID card type all resolve to configured values.

    Date validity

    Date of birth is plausible and precedes hire date.

    Address completeness

    Per the country-specific format.

    National ID format

    Where the country enforces one.

    Load sequence and dependencies

    What has to exist before this object can load.

    1. 1Foundation Objects and picklists
    2. 2Basic user information
    3. 3Person
    4. 4Biographical information
    5. 5Personal information
    6. 6National ID
    7. 7Addresses
    8. 8Emergency contacts and dependants

    Common migration errors

    What actually fails on this object, and why.

    Duplicate Person ID ExternalTwo source records mapped to the same key.
    Missing mandatory national IDThe country requires an identifier the source did not hold.
    Picklist value not foundGender, marital status or nationality value is not configured.
    Invalid address for countryMissing or malformed components against the country format.
    Date of birth after hire dateUsually a date-conversion error rather than bad source data.
    Person loaded without basic user informationThe entities were loaded out of sequence.

    Reconciliation

    Counts alone rarely prove this object migrated correctly.

    Employee count: source population in scope vs loaded, by legal entity

    Entity coverage per person: biographical, personal, national ID and address counts

    Country-specific completeness for populations with mandatory identifiers

    Key field comparison on a sample: date of birth, name components, national ID

    Rejected records categorised by entity and reason

    Frequently asked questions

    What is Person ID External and why does it matter?
    It is the key that ties every Employee Central entity for a person together. The decision to retain the legacy employee number or generate a new one determines whether history stays traceable to the source, and it propagates into every downstream entity and integration.
    What order do employee entities load in?
    Basic user information, then person, then biographical, personal, national ID and addresses. Loading out of sequence produces records with no parent, which Employee Central rejects.
    Are national identifiers mandatory?
    In several countries, yes. Requirements are country-specific and enforced by legal entity, so populations with missing identifiers are identified during profiling rather than at load.
    How much personal-data history should migrate?
    Name and marital status are effective-dated in Employee Central, but most programmes migrate current values as a single dated row unless there is a specific reason to carry the change history.

    Planning a similar data migration?

    Tell us your source application, target system, object scope, volume and migration timeline. We can discuss the recommended migration approach and relevant Syntra ETL project experience.