Pre-built peoplesoft data migration for HCM and FSCM. PS_ table extractors, ChartField/SetID crosswalks, PeopleCode-aware discovery, FBDI Journal/Payables/Supplier emitters, HDL Worker/Job loaders, row-level reconciliation evidence at every load.
The hard part isn't pulling rows from PS_LEDGER. It's translating PeopleSoft's ChartField/SetID/PeopleCode data model into Fusion's COA/BU/AMX model without breaking the audit chain that connects a GL journal to its original supporting voucher.
PeopleSoft 9.2, on Premier Support through 2034 with PeopleTools 8.6x continuing to receive PUM updates, remains the deepest enterprise data model in the Oracle portfolio. Decades of customization sit in PS_ table extensions, PeopleCode events, Application Engine jobs and Integration Broker service operations. ChartField design varies wildly customer to customer — same Account values mean different things across SetIDs, same Department codes carry different cost-center semantics across Business Units. A typical PeopleSoft FSCM 9.2 installation has 40K+ active tables when extensions are counted.
Every peoplesoft data migration to Oracle Fusion has to bridge those gaps without breaking the audit chain that connects a posted GL journal back to its originating PS_VOUCHER row and the attached supporting documentation. Custom SQR scripts, ad hoc nVision exports and one-off Component Interface clients can do it — but every PS_ table becomes a multi-week negotiation between functional, technical and compliance teams. Syntra ETL replaces that with pre-built crosswalks refined across dozens of PeopleSoft conversions.
The same engine handles three deployment scenarios: full PeopleSoft replacement (HCM + FSCM → Fusion), single-pillar migration (Finance to Fusion while HCM stays on PeopleSoft, or vice versa, with Integration Broker keeping the two in sync), and Campus Solutions co-existence where Student Financials integrates with Fusion AR while academic records remain on PeopleSoft.
The transformations Syntra ETL ships pre-built. No more multi-month bespoke SQR or Component Interface development.
PSTREEDEFN, PSTREESELECT06 and PSTREELEAF walked to extract every active tree. Required ChartFields collapse to Fusion COA segments; optional ones route to segment qualifiers or DFFs; reporting-only ones go to OTBI dimensions.
PeopleSoft SetIDs (data-sharing partitions for vendor/customer/asset/item master) re-modeled as Fusion Business Units and Set ID assignments. Each PS_VENDOR row routed to the correct Fusion supplier site by SetID context.
PSPCMPROG and App Designer XML exports walked. PeopleCode events (SaveEdit, FieldChange, Workflow) classified by business purpose. Fusion-equivalent recommendation per object — Application Composer rule, BPM flow, DFF default, or OIC integration.
PS_LEDGER, PS_LEDGER_BUDG and PS_LEDGER_ADB extracted per BU/Ledger/Year/Period. ChartField crosswalk applied. FBDI GL Balance Import partitioned by ledger and period. Trial Balance reconciles to the cent.
PS_EMPLOYEES, PS_PERSON, PS_NAMES, PS_ADDRESSES, PS_PERSONAL_DATA joined into Fusion Worker entities. Effective-dated history preserved. HDL Worker.dat + Assignment.dat + WorkRelationship.dat emitted with assignment hierarchy intact.
nVision report definitions and SQR report metadata catalogued. Classified by business value. Fusion replacement plan: OTBI for ad-hoc, BI Publisher for pixel-perfect, Smart View for Excel-tethered. 40–60% typically retired.
A repeatable load order that respects Fusion's data dependencies. Skip a step and your journal load fails on missing ledgers or your worker load fails on missing positions.
Fusion enterprise structures, ledgers, BUs, COA segments, calendars, currencies, AMX approvals, HCM legal employers and position structures configured via FSM. Loaded before any peoplesoft data migration step — everything downstream depends on this layer.
PS_VENDOR → FBDI Supplier Import. PS_CUSTOMER → FBDI Receivables Customer Import. PS_PERSON + PS_NAMES + PS_ADDRESSES → HDL Worker.dat. PS_POSITION_DATA → HDL Position.dat. PS_DEPT_TBL → Fusion Department setup. Loaded in dependency order — workers before assignments, positions before jobs.
Open PS_VOUCHER (un-paid AP), open PS_VCHR_DST (distribution lines) → FBDI Payables Invoice Import. Open PS_AR_ITEM → FBDI Receivables. In-flight PS_PO_HDR/LINE → FBDI Procurement Open PO. Approval state and approver chain preserved through AMX.
PS_LEDGER (and PS_LEDGER_BUDG/ADB) per BU/Ledger/Year/Period → FBDI GL Balance Import. PS_JRNL_HEADER + PS_JRNL_LN for current and prior fiscal year → FBDI Journal Import. Older history routes to long-term PeopleSoft archive.
PS_JOB effective-dated history → HDL Assignment.dat. PS_PAY_CHECK and PS_PAY_EARNINGS → HDL Element Entries for current FY only (older payroll history routes to archive for IRS 4–7 year retention). PS_TL_RPTD_TIME → Fusion Time and Labor.
Final delta replay through Integration Broker REST clients, parallel-period reconciliation, signed sign-off pack (Trial Balance, AP aging, AR aging, Worker headcount — PeopleSoft vs Fusion to the cent and to the person). Production cut to Fusion; PeopleSoft moves to read-only archive mode.
Every peoplesoft data migration load produces signed drill-downable reconciliation reports. Internal audit signs off the pack directly.
Source PS_ table row count vs Fusion-loaded row count per business unit per period. PS_LEDGER, PS_JRNL_LN, PS_VOUCHER_LINE, PS_JOB, PS_PAY_CHECK all reconciled separately. Variance threshold zero.
Posted amount, base-currency amount, tax amount and per-currency totals reconciled per period per ledger. Headcount totals per legal employer per effective date. Variance flags surface before any subsequent load is allowed.
Each PS_ table row content-hashed at PeopleSoft source and re-hashed post-Fusion-load. Hash drift indicates transformation bug or corruption — surfaced with row-level diff including original PSOPRDEFN audit fields.
PeopleSoft Trial Balance per period per ledger per BU vs Fusion Trial Balance to the cent. Drill from Fusion GL line through Journal Import batch back to originating PS_JRNL_LN row and supporting PS_VOUCHER.
PeopleSoft AP aging per supplier per BU vs Fusion AP aging. Same for AR aging per customer. Open balance reconciled to the cent — no posted amount lost in the peoplesoft data migration.
PeopleSoft headcount per legal employer per effective date vs Fusion headcount. Active/Terminated/Leave status reconciled per worker. Position-to-Worker mapping preserved with PSOPRDEFN audit context.
PeopleSoft data migration is the end-to-end process of moving GL ledger balances and journals, AP vouchers and payments, AR customers and receipts, HR worker records, Payroll history, Position and Job data, Time and Labor records, plus the long tail of PS_ tables — PS_LEDGER, PS_JRNL_HEADER, PS_VOUCHER, PS_VENDOR, PS_CUSTOMER, PS_EMPLOYEES, PS_JOB — out of PeopleSoft 9.2 and into Oracle Fusion Cloud Financials and HCM. Technically it's a four-stage pipeline: extract from PS_ tables and Component Interface APIs, map ChartFields and SetIDs to Fusion's COA segments and value sets, validate every record against Fusion 26x business rules, then emit FBDI ZIPs for finance loads and HDL bundles for HCM loads. Syntra ETL ships the whole pipeline pre-built — including PeopleCode-aware extractors and Integration Broker REST clients.
A typical full-scope PeopleSoft data migration covering HCM (Core HR + Payroll + Time & Labor + Absence) and FSCM (GL + AP + AR + Asset Management + Procurement) with 7–10 years of history runs 16–28 weeks on Syntra ETL versus 12–24 months on consultant-led programmes. Single-module work (Payroll-only or Finance-only) completes in 10–14 weeks. The acceleration comes from pre-built PS_ table extractors with PeopleCode-aware schema discovery, governed crosswalks between PeopleSoft ChartFields/SetIDs and Fusion's 6-segment COA, App Engine job orchestration that respects existing PSOPRDEFN security, and FBDI/HDL emitters validated against the current Fusion release. Campus Solutions adds 4–6 weeks; complex multi-business-unit consolidations with intercompany add 3–5 weeks for the parallel reconciliation cycle.
All the production tables that matter. Financials: PS_LEDGER (GL balances), PS_JRNL_HEADER and PS_JRNL_LN (journals with full SetID + Business Unit + ChartField context), PS_VOUCHER and PS_VOUCHER_LINE (AP vouchers), PS_VENDOR (supplier master with VNDR_LOC and VNDR_ADDR), PS_CUSTOMER and PS_CUST_OPTION (AR customers), PS_PYMNT_VCHR_XREF (payment reconciliation), PS_ASSET and PS_BOOK (fixed assets with full depreciation history). HCM: PS_EMPLOYEES, PS_JOB, PS_PERSON, PS_NAMES, PS_ADDRESSES, PS_PERSONAL_DATA, PS_POSITION_DATA, PS_TL_RPTD_TIME (time entry), PS_PAY_CHECK and PS_PAY_EARNINGS (payroll history), PS_ABSENCE_HIST. Campus: PS_STDNT_CAR_TERM, PS_STDNT_ENRL, PS_ITEM_SF (Student Financials). Plus PSXLATITEM (translate values) and the full PSDBFIELD catalog for metadata-aware extraction.
PeopleCode itself doesn't migrate — Fusion doesn't run PeopleCode. But the business outcomes PeopleCode enforced (derivation rules, default values, validation logic embedded in SaveEdit, FieldChange and Workflow events) are inventoried, classified by business purpose and replaced with Fusion-native equivalents during migration. Syntra ETL's discovery engine crawls every active PeopleCode object using the PSPCMPROG catalog plus App Designer XML exports, classifies each by domain (validation rule, derivation rule, integration trigger, workflow rule) and produces a Fusion-equivalent recommendation: Fusion Application Composer rule, Fusion Approvals Management (BPM) flow, Fusion FBDI default-value rule, or Fusion Integration Cloud (OIC) flow. Customers commonly find 30–50% of PeopleCode is dead code or redundant under Fusion's native rules engine.
ChartFields and SetIDs are the structural heart of PeopleSoft's data model and the biggest source of pain in any peoplesoft data migration. PeopleSoft's ChartField design (Account, Department, Fund, Program, Class, Project, Operating Unit plus a dozen optional fields) maps into Fusion's 6-segment Chart of Accounts but never 1:1. Syntra ETL's ChartField analyzer walks PSTREESELECT06, PSTREEDEFN and PSTREELEAF to extract every active tree, then proposes a target COA shape: required ChartFields collapse into Fusion COA segments, optional ones route to Fusion segment qualifiers or descriptive flexfields, reporting-only ones move to OTBI dimensions. SetIDs (PeopleSoft's data-sharing partition mechanism) get re-modeled as Fusion Business Units and Set ID assignments per supplier/customer/asset record. Output: a complete crosswalk reviewed and signed off before any load runs.
Yes — PS_LEDGER migration is one of the most common peoplesoft data migration scenarios. The extractor pulls PS_LEDGER (and PS_LEDGER_BUDG for budget ledgers, PS_LEDGER_ADB for average daily balances) per Business Unit per Ledger per Fiscal Year per Accounting Period, preserves the full ChartField combination, applies the ChartField-to-COA crosswalk, and emits Fusion GL Balance FBDI Import payloads partitioned by ledger and period. Period-end totals reconcile to the cent: PeopleSoft Trial Balance per period per ledger matches Fusion Trial Balance per period per ledger. For 7–10 years of monthly balances across 20+ Business Units and 5+ ledgers (typical mid-size customer), the full PS_LEDGER load completes in 2–4 days with row-level reconciliation evidence.
Syntra ETL emits Fusion-native load formats for every PeopleSoft data domain: FBDI Journal Import for PS_JRNL_HEADER/LN, FBDI GL Balance Import for PS_LEDGER, FBDI Payables Invoice Import for PS_VOUCHER/LINE, FBDI Supplier Import for PS_VENDOR, FBDI Receivables Customer Import for PS_CUSTOMER, FBDI Asset Mass Additions for PS_ASSET/BOOK. HCM: HCM Data Loader (HDL) for Worker.dat (PS_EMPLOYEES + PS_PERSON), Assignment.dat (PS_JOB), WorkRelationship.dat, plus HDL Element Entry for payroll history. REST API payloads handle incremental delta loads during parallel run and post-cutover. Every payload validates against the current Oracle Fusion 26x release schema before submission — validation errors surface locally, not in a four-hour Fusion ESS job that fails on row 47,000.
PeopleSoft customers carry a heavy compliance load — SOX 7-year financial retention, FERPA indefinite transcripts for Campus Solutions, HIPAA 6-year minimum for healthcare HR, plus state public-records statutes that run 10–30+ years for government entities. Syntra ETL's peoplesoft data migration preserves the full evidence chain: every PS_ table row is hash-signed at extraction, every transformation is logged, every FBDI/HDL load produces a signed reconciliation manifest, and any history not migrated to Fusion routes to a long-term PeopleSoft archive (Parquet on object storage, queryable, tiered) with the same audit trail. Auditors get drill-through from a Fusion GL line all the way back to the originating PS_VOUCHER row plus the original PeopleSoft attachment — without standing up the PeopleSoft environment.
30-minute call. We'll walk through your PeopleSoft footprint (modules, customizations, ChartField design, PS_ table volumes, retention requirements) and give you a concrete peoplesoft data migration timeline, scope and budget before the call ends.