A US local government organisation moved its workforce data off Oracle JD Edwards onto SAP SuccessFactors. Syntra ETL owned the migration lifecycle end to end — source discovery and profiling, source-to-target mapping, transformation, validation, reconciliation and the final production load — run across three structured cycles over roughly six months, so the migration was rehearsed twice before anything touched production.
Moving an HR system is not really a software problem. The employee record is the payroll record, the org chart, the manager relationship and the compliance file all at once — and in local government it is also a public record. Getting it wrong is not a data-quality issue, it is a payroll issue and an audit issue.
Oracle JD Edwards and SAP SuccessFactors model that information very differently. JDE holds legacy codes, effective-dated structures and organisational values accumulated over years of operation; SuccessFactors expects its own objects, its own reference values and its own validation rules. Every legacy code has to be crosswalked, every date sequence has to survive the move, and every manager has to exist in the target before the employee who reports to them can be loaded.
The other constraint was the implementation timeline. The migration could not become the thing that delayed the SuccessFactors go-live, which meant the process had to be repeatable — run once, correct, run again, and prove readiness before the production window opened.
A JDE-to-SuccessFactors migration for a government employer has to be exact about codes, dates, hierarchy and access.
JDE estates accumulate extracts, copies and shadow reports. The first job was identifying the authoritative JDE tables and extracts, confirming data ownership, and agreeing the employee population and the active/inactive worker rules before a single record moved.
Profiling surfaced nulls, duplicates, invalid dates, orphaned records, inconsistent organisational values and historical employee identifiers — before the first load, where they are cheap to fix, rather than during cutover, where they are not.
Business units, legal entities, jobs, positions, locations, departments, cost centres and pay status all had to be converted from JDE values to approved SuccessFactors values, with the mapping reviewed and approved jointly before production.
Historical job changes, transfers, position changes, manager changes and compensation changes only mean anything in order. Start dates, end dates, overlapping records and chronological sequencing were validated as a category of their own.
SuccessFactors rejects an employee whose manager, position, department, job classification or location does not yet exist. Load order and pre-load referential checks were built into the process rather than discovered through load errors.
Role-based access, controlled extracts, encryption in transit and at rest, sensitive-data handling, a migration audit trail, mapping version control and formal per-cycle sign-off — treated as requirements, not options.
One repeatable pipeline, run three times. Traceability is maintained from the original JD Edwards source record through transformation and into SuccessFactors.
Scope was agreed during discovery against the SuccessFactors modules being implemented and the historical-data requirements set by the customer.
JD Edwards stores HR data in a way that pre-dates every convention a modern HCM platform assumes. Four characteristics drive most of the extraction design.
F060116 — Employee MasterThe employee master in JD Edwards EnterpriseOne. It holds the employment record, but not the person: name and contact details live separately, so the extract has to join across before it has anything resembling a SuccessFactors worker.F0101 — Address Book Master / AN8JD Edwards models an employee as an Address Book entity. The Address Book Number (AN8) is the spine that connects the employee master, the person record and the organisational assignment. Lose AN8 and the record set falls apart.F0005 — User Defined Codes (UDC)Almost every meaningful value in JDE — employment status, pay status, job type, employee class — is a UDC, stored as a short code against a product code and code type. UDCs are site-specific by design, so they cannot be assumed and must be extracted as reference data in their own right, then crosswalked to SuccessFactors picklist values.F0006 / F0010 — Business Unit Master, Company ConstantsThe organisational skeleton. Business units and companies here become SuccessFactors Foundation Objects, and they have to exist in the target before any worker can be assigned to them.Julian dates — CYYDDDJD Edwards stores dates as a century-year-day-of-year integer, not a date type. Every hire, rehire, termination and effective date needs converting before SuccessFactors will accept it, and the conversion has to be right about the century digit or a 1998 hire date silently becomes 2098.Blank vs. null vs. zeroLegacy JDE data distinguishes poorly between an unset value, a blank and a zero. What SuccessFactors treats as a mandatory-field violation is often a legacy default that meant "not applicable" thirty years ago — which is why profiling runs before mapping, not after.Employee Central is effective-dated and heavily referential. It will reject a worker whose department, position, job classification or manager does not already exist, which makes load order part of the design rather than an implementation detail.
This dependency chain is the reason the programme ran two full rehearsal cycles. A referential failure at step 6 is usually caused by a mapping decision made at step 1, and the only way to find that cheaply is to run the whole sequence end to end before the production window.
A mapping workbook carried every field from JD Edwards through its transformation rule to the SuccessFactors target object and field. It was reviewed and approved jointly before the production migration.
| JD Edwards source | Transformation | SuccessFactors target |
|---|---|---|
| Employee Number | Retain / cross-reference | Person ID / User ID |
| Business Unit | Map to approved values | Business Unit |
| Home Company | Map to legal entity | Company |
| Job Type | Crosswalk | Job Classification |
| Supervisor ID | Validate manager exists | Manager |
| Pay Status | Convert to SuccessFactors status | Employment Status |
| Location Code | Crosswalk | Location |
The migration was rehearsed twice at full scale before the production window. Each cycle ran the same pipeline and produced its own reconciliation report.
Reconciliation ran for every cycle, at three levels, with every discrepancy categorised so the customer could approve the migration on evidence rather than assertion.
One platform, three products, each doing a distinct job on the same programme.
JDE extraction, mapping, transformation, validation and SuccessFactors load-file preparation.
Preserves source, transformed and target states for reconciliation, lineage and audit evidence.
Migration dashboards covering total and processed records, validation errors, load status, reconciliation and outstanding exceptions per cycle.
Measured against the success criteria agreed at the start of the engagement.
Whether the target is SAP SuccessFactors, Oracle Fusion or Workday, tell us your source system, the modules in scope and your cutover date.
Similar Projects
Selected by shared source platform, target platform, industry and project type.