Syntra ETL is the productised pipeline that moves Sage People to Oracle Fusion HCM in 10–14 weeks. Salesforce Bulk API extractors, pre-built crosswalks, HDL emitters, reconciliation engine, audit evidence — shipped, not built.
Sage People is a Salesforce org. Oracle Fusion is its own world. Generic ETL bridges nothing about either reality. The Oracle Fusion migration tool for Sage People bridges both.
Generic ETL tools (Informatica, Talend, MuleSoft, custom Python) can technically extract from Salesforce and load into anything — and customers who have tried that route can tell you what the bill looks like. Every Sage People custom object becomes a bespoke SOQL design exercise. Every HDL business object becomes a hand-rolled template. Every reconciliation rule is reinvented. Every API rate-limit incident is debugged from scratch at 2 AM. Six months later, the team has built half of what Syntra ETL ships out of the box.
The Oracle Fusion migration tool for Sage People is purpose-built at both ends. Source side: Salesforce-platform-native extractors that know Worker__c's effective-date pattern, Employment_Record__c's parent-child link to Worker, Salary__c's pay-component composition, Leave_Request__c's accrual relationship. Target side: HDL business object emitters validated against Fusion 26x, dependency-ordered file packaging, REST submission with poll-to-completion logic, post-load row count reconciliation. Middle: pre-built crosswalks for every standard Sage People field, configurable extensions for custom fields, governed reconciliation that produces audit-grade evidence.
The Oracle Fusion migration tool for Sage People also handles the UK-specific path that breaks most generic ETL approaches: extracting the existing Sage People → Sage 50 Payroll / third-party RTI integration spec and re-emitting it as a Fusion Payroll for UK configuration so HMRC RTI, P11D, P60, P45, and TPR pension feeds land working on cutover day one rather than triggering a separate, sequential 'payroll integration' project.
A productised pipeline — not a methodology, not a slide deck, not a 'we'll build it together' promise.
Bulk API 2.0 + REST + Metadata API integration. Daily-limit-aware throttling. Integration User pattern. Sharing-rule visibility honoured. API budget pre-flight.
Every Sage People standard object → Fusion HDL business object mapping shipped on day one. Custom fields configurable via metadata, not code.
Worker.dat, WorkRelationship.dat, WorkTerms.dat, Assignment.dat, Salary.dat, Element.dat, AbsencePlan.dat, AbsenceEntries.dat — validated against Fusion 26x schema.
Reads the existing Sage People → Sage 50 / third-party HMRC RTI integration and emits the equivalent Fusion Payroll for UK config spec.
Source vs target row counts, hash matches, headcount sums, salary sums, leave balance hours — signed and timestamped per run.
SystemModstamp-based incremental capture. Nightly delta replay through HDL or REST. Supports 1–2 pay cycle parallel-run cutover pattern.
Six stages, no surprises. Each stage produces evidence the next stage and the auditor can rely on.
Tool reads Sage People schema via Metadata API, inventories custom fields, custom objects, Apex/Flow/Visualforce customizations. Output: sized migration plan with API budget, HDL business object list, and per-object timeline.
Pre-built crosswalks applied; customer-specific custom-field mappings configured. Output: full mapping spec, signed by HR, payroll, and audit. UK payroll integration spec extracted in parallel.
Salesforce Bulk API extraction of all in-scope custom objects. Output: Parquet stage files with row hashes, partition manifests, source row counts. API consumption within pre-flight budget.
Crosswalks applied. HDL bundles generated, validated against Fusion 26x schema locally. Output: validated HDL .dat files in dependency order, ready to submit.
HDL bundles submitted via REST, polled to completion, post-load row counts pulled. Reconciliation matrix produced: Sage People vs Fusion at row, headcount, salary-sum, leave-balance level. Errors triaged and re-emitted.
Nightly delta replay during 1–2 pay cycle parallel run. Final reconciliation, sign-off pack, cutover. Tool transitions into archive-only mode; source org goes read-only or decommissions.
Direct comparisons against the four other paths customers seriously evaluate when planning a Sage People to Fusion migration.
Consultants typically quote 8–12 months and £600k–£1.5M for a custom-coded Sage People to Fusion migration. The Oracle Fusion migration tool for Sage People delivers in 10–14 weeks at 40–60% lower cost — because the pipeline is built once and reused.
Custom scripts work for a one-off extract but provide no reconciliation, no audit evidence, no delta-replay, no HDL validation. The tool ships all of that productised.
Generic ETL has no notion of Sage People custom objects or Fusion HDL semantics. Every crosswalk is built from zero. The tool ships the crosswalks and the HDL semantics built in.
Oracle Consulting can do the project but typically subcontracts the source-side Salesforce extraction. The tool owns the source side natively, removing the handoff seam where most projects slip.
Hand-built HDL from spreadsheets technically works for 50-employee migrations. For 2,000+ employees with 7+ years of history, it fails on reconciliation, audit evidence, and delta-replay during cutover.
Some customers just keep Sage People running parallel to Fusion indefinitely. The licence cost compounds. The tool delivers a clean cutover plus cloud-archive in 10–14 weeks instead.
The Oracle Fusion migration tool for Sage People is Syntra ETL — a purpose-built ETL platform that extracts data from Sage People (a Salesforce-platform HCM, formerly Fairsail) via the Salesforce Bulk API 2.0 and REST API, transforms it through governed crosswalks tuned to Sage People's custom-object schema (Worker__c, Employment_Record__c, Salary__c, Leave_Request__c, Position__c), and emits HCM Data Loader (HDL) bundles that load cleanly into Oracle Fusion HCM. It replaces the consultant-led 'write custom SOQL and hand-roll HDL templates' approach with a productised pipeline that ships pre-built converters, reconciliation engines, and audit evidence. The Oracle Fusion migration tool for Sage People is what makes a 10–14 week migration timeline possible instead of the 8–12 months a custom-coded approach takes.
Carefully. Sage People orgs have Salesforce daily API limits (typically 15,000 calls for Enterprise Edition, more with add-ons). A naive Worker__c + Employment_Record__c + Salary__c + Leave_Request__c extract would exhaust limits in hours and impact live users. The Oracle Fusion migration tool for Sage People uses Salesforce Bulk API 2.0 — one API call per bulk job regardless of row count — and chunks each job into 10,000-record batches. A full extraction for a 5,000-employee Sage People customer consumes ~200–400 standard API calls and 4–8 Bulk API jobs, well inside daily limits, run during off-hours windows that we coordinate with your Salesforce admin team. We provide a pre-flight API budget per migration and never exceed it.
The Oracle Fusion migration tool for Sage People ships extractors for every standard Sage People object: Worker__c, Employment_Record__c, Position__c, Salary__c, Bonus__c, Allowance__c, Leave_Request__c, Absence_Policy__c, Timesheet entries, Project__c allocations, Performance_Review__c, Goal__c, Succession_Plan__c, Candidate__c, Application__c, Offer__c, Onboarding_Checklist__c, plus reference data (Department, Location, Cost Centre, Job, Grade, Pay Component). Custom fields and any custom objects your org has added on top of the standard model are discovered via the Salesforce Metadata API and extracted automatically — no schema configuration required. The tool reads the live schema, not a stale assumption about what 'standard' Sage People looks like.
The transform stage produces HCM Data Loader business object files validated against the current Oracle Fusion release (Fusion 26x as of writing): Worker.dat, WorkRelationship.dat, WorkTerms.dat, Assignment.dat, Salary.dat, Element.dat, AbsencePlan.dat, AbsenceEntries.dat, plus reference business objects (Department.dat, Location.dat, Job.dat, Grade.dat, Position.dat). Each file is validated locally against the HDL schema before submission — typos, missing mandatory fields, invalid lookup values are caught in seconds rather than after a 4-hour HDL job fails. Bundles are zip-packaged in the format Fusion expects, with file order honoured per HDL dependency rules. The tool then submits via the HCM Data Loader REST endpoint, polls to completion, and pulls the result log for reconciliation.
A custom-coded Sage People to Fusion migration writes one-off SOQL extracts, hand-rolls HDL templates, and reinvents reconciliation per object — typically 6–9 months of consultant time before a single row reaches Fusion test. Syntra ETL's crosswalks are pre-built, version-controlled, and refined across multiple Sage People-to-Fusion engagements: Worker__c → HDL Worker, Employment_Record__c → HDL Assignment, Salary__c → HDL Salary, Leave_Request__c → HDL AbsenceEntries, Position__c → HDL Position, Department / Location / Job / Cost Centre → HDL reference objects. Customer-specific extensions are layered on top via configuration rather than code changes — typically 10–20% of the mapping work goes into customisation, 80–90% is handled by the shipped crosswalks. The Oracle Fusion migration tool for Sage People is what lets a small team execute what previously needed an army.
Yes — and this is where most non-UK-aware tools fall over. Sage People customers in the UK typically have an integration layer between Sage People and either Sage 50 Payroll or a third-party HMRC RTI provider (Iris, Moorepay, ADP), often built on MuleSoft, Salesforce Data Loader, or a bespoke Apex callout. The tool extracts the field-mapping spec from that integration — accrual rules, P11D inputs, pay component definitions, auto-enrolment pension feeds, salary sacrifice arrangements — and emits an equivalent configuration spec for Fusion Payroll for UK so HMRC RTI submission, P11D, P60, P45, and TPR pension feeds land working from cutover day one rather than requiring a second 'payroll integration' project after the HCM migration.
Every run of the Oracle Fusion migration tool for Sage People emits a signed evidence bundle: source row counts per Sage People object, transform row counts per intermediate stage, HDL row counts per business object file, Fusion post-load row counts pulled back via REST API. Reconciliation matrices (Sage People active headcount vs Fusion active workers, Sage People total annualised salary vs Fusion total salary, Sage People open leave balance hours vs Fusion absence entitlement balance). Error reports per failed row with field-level diagnostics. SHA-256 hashes of every Parquet stage file and every HDL bundle. Run timestamps signed against a trusted timestamp authority. This evidence pack is what auditors (Big-4 external, internal audit, SOX, ISAE 3402) and the FCA SMCR governance regime expect — and it's what removes 'how do we know this loaded right?' from the post-migration conversation.
Yes. After the initial bulk load, the tool captures Sage People deltas via SystemModstamp watermarks on each custom object and replays them into Fusion via HCM REST APIs or short HDL incremental bundles. This supports the standard parallel-run pattern: Sage People continues taking production HR traffic for 1–2 pay cycles, deltas flow nightly into Fusion, both systems are reconciled to the cent at the close of each pay cycle. When HR, payroll, and (in the UK) HMRC RTI all reconcile clean, traffic cuts to Fusion and the Oracle Fusion migration tool for Sage People shifts into archive-only mode — the live org goes read-only or decommissions, and historical deltas continue flowing to the long-term cloud archive.
Book a 30-minute working demo. We'll spin up your Sage People sandbox connection, run a sample extract against your real schema, and emit a sample HDL bundle — so you can see exactly what the tool produces against your data before you commit to a project.