Oracle Fusion · HCM · Master data

    Oracle Fusion Worker Data Migration

    Migrate workers into Oracle Fusion HCM, covering person records, work relationships, assignments, effective-dated history and the dependencies that gate the load.

    Object overview

    Oracle Fusion separates the person from the employment. A person record describes the human being; a work relationship describes their relationship with a legal employer; an assignment describes the job they do within it. Someone rehired twice with a concurrent second job is one person, several work relationships and several assignments.

    Everything is effective-dated with explicit start and end dates, and HDL rejects gaps and overlaps outright. Reconstructing a legacy history as a clean, contiguous set of dated rows is the bulk of the work on this object.

    What data is typically migrated

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

    Data areaTypical information
    PersonName, date of birth, gender, national identifiers, person number
    Contact informationAddresses, phones, emails, emergency contacts
    Work relationshipLegal employer, hire date, worker type, termination date
    AssignmentJob, position, grade, department, location, manager, FTE, working hours
    Assignment historyEffective-dated rows for every job, transfer and status change
    SalarySalary basis, amount, effective dates
    DocumentsDocument records and attachments where in scope

    Object relationships

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

    Legal employer
    └─ Person
    └─ Work relationship
    └─ Assignment
    └─ Assignment supervisor (manager)
    └─ Salary
    └─ Person address / contact
    └─ National identifier

    Object migration flow

    Source WorkersDataMoveMap & transformValidateOracle Fusion WorkersDataVault reconciliationSign-off

    Before you migrate this object

    Confirm each of these before the first migration cycle.

    Legal employers and business units are configured
    Jobs, positions, grades, departments and locations exist
    The person numbering strategy is agreed
    History depth is agreed with HR and signed off
    The rehire and concurrent-assignment model is agreed
    Country-specific mandatory fields are identified per legal employer
    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.

    PeopleSoft Production-provenPaycom Production-provenOracle EBS HR SupportedSAP SuccessFactors SupportedWorkday SupportedUKG SupportedOracle JD Edwards Supported

    Source-to-target mapping examples

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

    Source systemSource entityTarget object
    PeopleSoftPERSONAL_DATA + JOBFusion Person + Work Relationship + Assignment
    PaycomEmployee + job recordsFusion Person + Assignment
    SuccessFactorsPerson + Employment + job_infoFusion Person + Work Relationship + Assignment
    JD EdwardsAddress Book + Employee Master (F060116)Fusion Person + Assignment

    Migration methods for this object

    HCM Data Loader (HDL) — pipe-delimited .dat files per business object, zipped

    HCM Spreadsheet Data Loader (HSDL) for smaller or corrective loads

    Worker REST services for incremental updates after go-live

    Extraction considerations

    History depth is a decision, not a defaultHow many years of assignment history migrate is agreed with HR before extraction. Full history multiplies row counts and is often better archived than loaded.
    Terminated and rehired workersA rehire is a new work relationship, not an update to the old one. Sources that model it as a status change need reconstructing into separate relationships.
    Concurrent assignmentsSomeone holding two jobs is two assignments under one work relationship or under two, depending on the legal employer. Collapsing them loses a real employment fact.
    Manager references that moveSupervisor is itself an assignment reference, and it changes over time. Historical manager data has to resolve to whoever held the role at that effective date.
    Sensitive dataNational identifiers, date of birth and dependants are personal data. Extraction runs under access controls and the scope is minimised deliberately.

    Transformation rules

    Employee ID to person numberRetain the legacy number or generate new with the legacy value held as a person identifier. This decision propagates into payroll and every downstream integration.
    Company to legal employerSource company codes map onto Fusion legal employers, which is a legal-entity decision rather than a data mapping.
    Department, job, position and location crosswalksEach is a separate reference object that must exist before the assignment references it.
    Effective-date reconstructionSource history is converted into contiguous, non-overlapping dated rows with explicit start and end dates.
    Manager hierarchyResolved in a second pass once the full population exists, because a manager's assignment must be loaded before it can be referenced.

    Data quality and validation

    Person uniqueness

    Matched on national identifier, name and date of birth to avoid duplicate people.

    Effective-date continuity

    No gaps and no overlaps across assignment rows.

    Reference objects exist

    Job, position, grade, department and location all present before the assignment.

    Manager exists at the effective date

    Not merely at the current date.

    Hire date precedes every dependent record

    Assignments and salary cannot start before the work relationship.

    Mandatory country-specific fields

    Vary by legal employer country and are enforced per country.

    Load sequence and dependencies

    What has to exist before this object can load.

    1. 1Legal employers and business units
    2. 2Locations, departments, grades
    3. 3Jobs
    4. 4Positions
    5. 5Person records
    6. 6Work relationships
    7. 7Assignments
    8. 8Manager (supervisor) second pass
    9. 9Salary
    10. 10Payroll and absence objects

    Common migration errors

    What actually fails on this object, and why.

    Effective-date gap or overlapHDL rejects the assignment set outright rather than loading part of it.
    Job or position not foundThe reference object was not loaded before the assignment.
    Manager not found at the effective dateCommon when the hierarchy is loaded in one pass instead of two.
    Duplicate personTwo source records for the same human being, typically a rehire modelled as a new employee.
    Assignment before hire dateThe work relationship starts later than the assignment it contains.
    Missing country-specific identifierThe legal employer's country requires a national identifier the source did not carry.
    Source key collisionTwo source systems in a consolidation using the same employee number.

    Reconciliation

    Counts alone rarely prove this object migrated correctly.

    Headcount at cutover: active workers in source vs loaded, by legal employer

    Total worker records including terminated, which is normally far higher than active headcount

    Assignment count against the expected worker-to-assignment ratio, allowing for concurrent jobs

    Manager coverage: every worker who should have a supervisor has one

    Effective-date span per worker compared to the agreed history depth

    Key field comparison on a sample: hire date, job, department, FTE, salary

    Should all historical records be migrated?

    Detailed employment history for long-terminated workers is a common archive candidate. Retention obligations often run seven years or more, but the new HCM only needs the population it will administer. Migrating active and recently terminated workers and archiving the rest keeps the tenant clean and licensing honest.

    Frequently asked questions

    How much worker history should be migrated to Oracle Fusion?
    Enough to support HR operations and statutory reporting — commonly current assignment plus a few years of history. Deeper history multiplies row counts, slows every migration cycle, and is usually better preserved in an archive.
    How are rehired employees handled?
    As a new work relationship rather than a reopened one. Sources that model a rehire as a status change on the original record need that reconstructed, or the employment history in Fusion will misrepresent the break in service.
    Why do assignments fail with effective-date errors?
    HDL requires contiguous, non-overlapping dated rows with explicit start and end dates. A gap or overlap causes the whole assignment set for that worker to be rejected, not just the offending row.
    How is the manager hierarchy loaded?
    In a second pass. A supervisor is itself an assignment, so the full population has to exist before manager references can resolve — and historical manager values must resolve to whoever held the role at that effective date.
    What has to exist before workers can load?
    Legal employers, business units, locations, departments, grades, jobs and positions. Fusion rejects an assignment whose referenced objects have not been created.

    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.