Migrate from Oracle PeopleSoft to Epicor Prophet 21

PeopleSoft ACCOUNT_TBL with DT_EFFECTIVE rows maps to Epicor Kinetic GL Account records. We extract all active and historical effective-date rows and load them into Epicor with effective dates stored as a user-defined date field since Epicor has no native temporal row model. SetID relationships to DEPT_TBL are preserved as a lookup reference on the Epicor account record. Multi-company PeopleSoft installations map each SetID to a separate Epicor Company or Division within the shared company structure.

PeopleSoft GL_JRNL_HEADER and GL_JRNL_LINE map to Epicor GL Journal with fiscal period calendar alignment as the primary reconciliation point. PeopleSoft's fiscal year and accounting date fields must map to Epicor's Fiscal Year and Journal Date. We preserve the source journal ID and line number as Epicor custom fields. Closed and locked periods in PeopleSoft require Epicor fiscal year security to be configured before migration to prevent postings to historical periods.

PeopleSoft AP_INVOICE_HEADER and AP_INVOICE_LINE (voucher schema) map to Epicor AP Invoice. We resolve PeopleSoft vendor IDs against the vendor migration (VENDOR_TABLE), preserve payment status, GL distribution lines, and invoice hold flags. PeopleSoft holds invoices in multiple workflow states; open and approved invoices load as ready-for-payment in Epicor, while pending-approval items are flagged for the AP supervisor to review post-migration rather than bulk-loaded with errors.

PeopleSoft AR_BILL_LINE and related records map to Epicor AR Invoice with customer ID resolved from the customer migration. Payment terms, billing cycle, and amount fields transfer directly. Epicor's AR Invoice does not support the same invoice-number generation logic as PeopleSoft; we preserve the original PeopleSoft AR invoice ID in a custom field for customer service and collections reference.

PeopleSoft CUST_TABLE from FSCM and CRM modules de-duplicates across modules before loading to Epicor Customer. Sold-To and Ship-To addresses, credit limits, and customer profile flags transfer to Epicor's customer master with a separate ShipTo address table per customer. We match by customer ID and flag any duplicate Epicor Customer records already present before inserting.

PeopleSoft VENDOR_TABLE maps to Epicor Vendor with addresses, payment terms, W-9 status, and tax IDs preserved. The vendor hierarchy (parent-child vendor relationships) maps to Epicor's Vendor Group structure. Routing rules tied to PeopleSoft business units become Epicor purchasing agent assignments or approval routing groups. We extract the full vendor hierarchy before migration so that parent-child relationships are created in the correct sequence.

PeopleSoft PO_HDR and PO_LINE map to Epicor PO Header and PO Line with approval status, buyer ID, and schedule dates preserved. Open and closed PO history both migrate; Epicor distinguishes between closed (Received or Closed status) and open POs in its order management. PO IDs and line numbers are preserved in Epicor custom fields. PeopleSoft multi-business-unit POs map to Epicor's Plant and Company hierarchy based on the BU-to-Plant mapping defined during scoping.

PeopleSoft INV_ITEM_MASTER and INV_ITEMS_CF map to Epicor Part with unit of measure, standard cost, and category codes. PeopleSoft's business-unit-specific inventory flags map to Epicor PartPlant records, which store plant-level data (on-hand quantity, reorder point, default warehouse) separately from the Part master. Category codes from PeopleSoft's inventory structure map to Epicor's Part Class and Product Group hierarchies. We flag any PeopleSoft lot and serial control configurations for Epicor lot/serial setup post-migration.

PeopleSoft EMPLOYEES and PERSONAL_DATA map to Epicor Employee records with hire date, termination date, HR status, and manager hierarchy. The PeopleSoft EMPLID (sequential numeric identifier) has no intrinsic business meaning but is often referenced in downstream integrations and spreadsheets. During scoping we decide whether to preserve the EMPLID as a custom Epicor field (hrd_id__c), map it to a new Epicor Employee ID, or run both identifiers during a coexistence period. Manager hierarchy reconstructs from EMPLOYEES.MGR_ID mapped to the target Epicor Employee record.

PeopleSoft JOB and JOBCODE_TBL with effective-date sequences map to Epicor JobCode and Job records. The effective-date history is the most compliance-sensitive part of a PeopleSoft HR migration: each change in job, compensation, grade, or location generates a new dated row. We load the current effective row as the active Epicor Job record and archive historical rows in a custom Job History table with effective dates, job code, and department stored as structured fields for audit queries. We flag any PeopleSoft position-based rows for the customer's HR team to decide whether position-to-job mapping is required.

PeopleSoft POSITION_DATA stores position details with incumbent assignment, budgeted headcount, and department. Where organizations use a position-management HR structure (common in government, education, and large healthcare systems), we extract the position hierarchy and budgeted headcount separately from the incumbent Job records. Epicor does not have a native position data model; we create a Position custom table with position number, department, budget headcount, and current incumbent as a lookup to the Employee record. Organizations with job-based rather than position-based HR structures skip this object entirely.

PeopleSoft DEPT_TBL with effective-date rows and setIDs maps to Epicor Department. The department hierarchy tree (parent DEPTID to DEPTID relationships) reconstructs from DEPT_TBL.SETID and DEPT_TBL.EFFDT ordering. SetID relationships governing security access in PeopleSoft map to Epicor Business Unit or Resource Group assignments. We extract the full tree in dependency order so that parent departments exist before their children are inserted.

PeopleSoft BENEFIT_PARTICIPATION and related records store enrollment, plan assignments, and coverage dates. Epicor ERP does not have a native Benefits Administration module comparable to PeopleSoft HCM. We extract current benefit elections and plan assignments as a structured lookup table attached to the Employee record (benefit_elections__c as a UD table or JSONB field depending on Epicor edition). We map PeopleSoft plan names to customer-defined plan type codes for the Epicor administrator to reconcile against their HRIS configuration. Full Benefits Administration requires a separate migration to a dedicated HR platform.

PeopleSoft PAY_EARNINGS and DEDUCTION_RESULT with pay group and FLSA status map to a custom payroll summary table attached to the Employee record. Year-to-date amounts and last pay date transfer as Epicor UD fields (ytd_earnings__c, ytd_deductions__c, last_pay_date__c). Epicor Kinetic payroll is limited compared to PeopleSoft Payroll (TrustRadius: 6.6/10 vs 7.8/10) and direct deposit file generation scores 1.8/10 vs PeopleSoft's 9.0/10. We recommend organizations requiring full payroll functionality evaluate Epicor Payroll or a dedicated payroll platform post-migration. We migrate the payroll history as a reference archive only.

PeopleSoft Content References store documents in file systems, Oracle Content Manager, or third-party repositories (SharePoint, network drives). The database contains only the URL and metadata pointer. We extract and preserve the full list of Content Reference URLs, file names, and storage locations as a written inventory document. Binary file transfers require a separate file migration process outside the database migration and are scoped as a parallel workstream. Customers with thousands of stored documents (offer letters, contracts, tax forms) must budget additional timeline and tooling for the file transfer phase.