Migration route

    PeopleSoft→Oracle HCM Cloud

    PeopleSoft to Oracle HCM Cloud Data Migration

    Migrate core hr, absence, payroll from Oracle PeopleSoft to Oracle Fusion HCM Cloud using a controlled process for extraction, mapping, transformation, validation, loading and reconciliation.

    Discuss Your MigrationAll Migration Routes

    Migration overview

    PeopleSoft to Oracle Fusion HCM is the best-supported path in the Oracle HCM estate, and the one where the source system's effective-dated model does most of the work — and causes most of the difficulty.

    Organisations take this route when PeopleSoft's cost of ownership and customisation burden outweigh the disruption of moving, usually alongside a payroll decision that determines how much history has to come with it.

    Typical data scope

    Scope is agreed in discovery. On this route it usually covers:

    Core HR

    Domain in scope for a typical PeopleSoft to Oracle HCM Cloud programme.

    Absence

    Domain in scope for a typical PeopleSoft to Oracle HCM Cloud programme.

    Payroll

    Domain in scope for a typical PeopleSoft to Oracle HCM Cloud programme.

    Historical records

    Domain in scope for a typical PeopleSoft to Oracle HCM Cloud programme.

    Migration architecture

    One controlled pipeline, run as repeatable cycles.

    PeopleSoft→DataMove→Transformation & validation→Oracle HCM Cloud→DataVault reconciliation→DataLens

    Extracting from PeopleSoft

    What the source platform makes available, and the constraints that shape the extraction design.

    Effective-dated rows are the data modelPeopleSoft stores history as effective-dated, effective-sequenced rows. JOB in particular is a row per change, and the current record is whichever row is latest as at a date — not a flag. Extracting only current state throws away the history most HCM targets want.
    SetID and TableSet sharingReference data is scoped by SetID, so the same department or job code can mean different things in different business units. Flatten it and organisational structure silently merges.
    Translate valuesShort codes validate against the translate table rather than storing labels. Pulled with the transactions or the target inherits codes nobody can interpret.
    EMPLID, EMPL_RCD and concurrent jobsA worker is EMPLID plus employment record number. Someone with two concurrent jobs is two rows, and treating EMPLID as the unique key collapses them.
    Component interfaces vs direct SQLComponent interfaces apply PeopleSoft's own business rules and are slow at volume; direct SQL against the tables is fast and bypasses those rules. Migration extraction generally reads the tables, which means the rules have to be reimplemented in validation.
    Custom and bolt-on recordsA long-lived PeopleSoft estate carries customised records and bolt-ons holding data the business depends on. Profiling finds them; a standard object list does not.

    Source-to-target mapping

    A mapping workbook carries every field in scope from its PeopleSoft source through its transformation rule to the Oracle HCM Cloud target object and field. It is reviewed and approved with the business before the production migration, and applied identically in every cycle so a decision made once is not re-made under cutover pressure.

    Transformation challenges on this route

    The differences between PeopleSoft and Oracle HCM Cloud that create most of the work.

    Effective dating on both sides, but not the same way

    PeopleSoft uses effective date plus effective sequence; Fusion HCM uses effective start and end dates per object. Translating between them, without gaps or overlaps, is the core of the work.

    EMPLID and EMPL_RCD to person and assignment

    A worker with concurrent jobs is multiple PeopleSoft rows. Fusion models this as one person with multiple assignments, so the identity design is decided before mapping.

    SetID-scoped reference data

    Departments, jobs and locations are scoped by SetID and can mean different things per business unit. Flattening them merges organisational structure that should stay separate.

    Payroll history scope

    Balances required for statutory reporting come across; detailed pay result history is usually archived instead, because loading years of it into Fusion Payroll rarely pays for itself.

    HDL dependency order

    Jobs, grades, locations and departments, then positions, then person and assignment, then salary. HDL rejects a child whose parent has not loaded.

    How Oracle HCM Cloud accepts the data

    Load order is part of the design, not an implementation detail.

    1. 1HDL — HCM Data LoaderThe primary bulk mechanism. Pipe-delimited .dat files, one per business object, zipped and loaded through the Import and Load Data process.
    2. 2Business object dependency orderJobs, grades, locations and departments, then positions, then person and assignment, then salary and payroll. HDL rejects a child object whose parent has not loaded.
    3. 3GUIDs and source keysObjects are matched on source keys carried in the .dat file. Getting the source key strategy right is what makes a second load an update rather than a duplicate.
    4. 4Effective dating is explicitEvery dated object carries its effective start and end. Overlaps and gaps are rejected, so date sequencing is validated before load.
    5. 5Load, then review the process logImport and Load Data reports per-object success and failure with reason codes; failures are categorised, corrected in transformation and reloaded.
    6. 6Payroll balances as a separate passBalance initialisation runs after core worker data, against the payroll definitions already in place.

    Validation and reconciliation

    Validation before load

    Mandatory fields, referential integrity, format checks, business-rule validation and duplicate detection run on the prepared data, so problems surface as reportable exceptions rather than as failed loads in Oracle HCM Cloud.

    Reconciliation after load

    Source counts, transformed counts, rejected records and target counts, with control totals where the data supports them. Every discrepancy is categorised so the migration is approved on evidence rather than assertion.

    Migration cycles

    The pipeline is run end to end more than once before anything touches production. A typical structure is a first rehearsal that surfaces the bulk of mapping and data-quality corrections, a second that applies them and demonstrates production readiness, and the production cutover itself. How many cycles a programme needs depends on data quality and scope, which is established during discovery.

    1. 1Mock / PPR 1First full extract, transform, load, reconcile and exception analysis. Expect the largest correction list here.
    2. 2Mock / PPR 2Corrections applied, re-extract, re-run. Intended to closely replicate the production migration.
    3. 3Production cutoverFinal extract, data freeze, load, reconciliation, business validation and sign-off.

    Common risks on this route

    Customised PeopleSoft records missed

    Bolt-ons and customised records hold data the business depends on and are invisible on a standard object list.

    Manager hierarchy loaded in one pass

    Self-referencing supervisor data needs either dependency-ordered loading or a second pass.

    Translate values assumed stable

    Site-specific translate values must be crosswalked explicitly, not mapped by name similarity.

    How Syntra ETL supports this route

    DataMove

    Extraction, mapping, transformation and load preparation for Oracle HCM Cloud.

    Explore DataMove →

    DataVault

    Source-to-target reconciliation, migration lineage and audit evidence for every cycle.

    Explore DataVault →

    DataLens

    Migration status, data quality and exception visibility across cycles.

    Explore DataLens →

    Proven experience on this migration

    PeopleSoft→Oracle HCM CloudMigration complete

    PeopleSoft to Oracle Fusion HCM for an Irish local council

    A published case study covering this exact source-to-target route.

    View Case Study

    Related migration routes

    PeopleSoft→Workday

    PeopleSoft to Workday data migration

    Workers, Job data, Compensation, Absence

    View route →    PeopleSoft→SAP SuccessFactors

    PeopleSoft to SAP SuccessFactors data migration

    Core HR, Job history, Compensation, Organisational data

    View route →    Oracle EBS→Oracle Fusion

    Oracle EBS to Oracle Fusion data migration

    Financials, Procurement, SCM

    Case study available →    Oracle HCM Cloud→Workday

    Oracle HCM Cloud to Workday data migration

    Workers, Assignments, Compensation, Absence

    View route →    SAP SuccessFactors→Oracle HCM Cloud

    SAP SuccessFactors to Oracle HCM Cloud data migration

    Workers, Job history, Compensation, Organisational data

    View route →

    Planning this migration?

    Tell us your source system, target platform, modules, data volumes and timeline. We can discuss the closest relevant migration experience and the recommended approach.

    Discuss Your MigrationSee Delivered Projects