The characteristics that shape every migration off this platform.
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.