Migrate from Oracle PeopleSoft to Microsoft Dynamics 365 Business Central

PeopleSoft stores the Chart of Accounts in ACCOUNT_TBL and related tables with EFFDT effective-date rows and SETID security scoping. We extract all active and historical account rows preserving DT_EFFECTIVE and SETID. Each PeopleSoft account becomes a Dynamics 365 MainAccount with a legal entity assignment. SetIDs controlling security access map to a combination of Dynamics 365 Financial Dimension structures and role-based security scopes that the customer configures post-migration.

PeopleSoft FSCM business units (BU) are the primary organizational and accounting segmentation unit. Each BU in PS_BUS_UNIT_TBL with its associated SETID, currency, and fiscal calendar maps to a Dynamics 365 Legal Entity. We preserve the BU code as a reference field and map the BU-level GL ledger to the corresponding Dynamics 365 Ledger. Multi-company migrations with intercompany journals require additional ledger and intercompany setup coordination.

PeopleSoft DEPT_TBL stores cost center hierarchies with EFFDT rows and setID linkages to the Chart of Accounts. We extract the full department tree preserving EFFDT, setID, and manager hierarchy. Dynamics 365 Department uses a dimension-based structure aligned to the Financial Dimension framework. We map the PeopleSoft department cost center to a Dynamics 365 Department dimension value and link it to the appropriate legal entity.

PeopleSoft EMPLOYEES and PERSONAL_DATA hold the core HCM record with hire date, termination date, HR status, manager EMPLID, and emergency contacts. We map EMPLID to a new Dynamics 365 PersonnelNumber or carry it forward as a custom field (ORIG_EMPLID__c) if integrations and spreadsheets reference it as a foreign key. Manager hierarchy maps to the Worker hierarchy in Human Resources. Birth date and national ID require field-level encryption handling in Dynamics 365 HCM.

PeopleSoft JOB is the temporal HR record with EFFDT and EFFSEQ sequences capturing every job data change including position assignment, compensation grade, department, supervisor, and FLSA status. We establish a cutoff policy during scoping (current snapshot only or full effective-date history) because Dynamics 365 HCM uses valid-from and valid-to on PositionWorkerAssignmentV2 rather than a sequential EFFDT model. Full history migrations require multiple PositionWorkerAssignment records per worker, which increases load complexity and requires validation with the customer HR team.

PeopleSoft POSITION_DATA stores position definitions with budgeted headcount, department, job code, and incumbent EMPLID. Position-based organizations must reconstruct the incumbent-to-position linkage across POSITION_DATA, JOB, and EMPLOYEES records before mapping to Dynamics 365 Position entities. We separate mixed position-based and job-based structures during extraction, because Dynamics 365 HCM requires explicit Position type configuration that differs from PeopleSoft's setID-scoped position management.

PeopleSoft JOBCODE_TBL stores job code definitions with grade, step, pay range, and FLSA category. We extract active and historical job code rows preserving EFFDT. Dynamics 365 Job is a less granular structure focused on position classification rather than pay administration. Custom job code extensions built in PeopleSoft PeopleTools require field-level enumeration during scoping and reimplementation as Dynamics 365 Job attribute fields or compensation fixed plan configurations.

PeopleSoft GL journals map to Dynamics 365 GeneralJournalEntry with AccountType, MainAccount, and FinancialDimensionValue segments. We preserve the source journal ID and line number as reference fields, and map PeopleSoft Ledger codes to Dynamics 365 Ledger. Fiscal period calendars frequently differ between the systems, requiring period-status validation during load. Historical GL data (more than two years) may be archived rather than migrated into the live Dynamics 365 ledger based on customer data-retention policy.

PeopleSoft AP vouchers (voucher is the PeopleSoft AP term for an invoice) map to Dynamics 365 VendorInvoice with header-level vendor, invoice date, and terms, and line-level account distribution with business unit cost center and project references. We preserve the PeopleSoft voucher ID as VENDORINVOICENUMBER and payment status, mapping PeopleSoft payment terms codes to Dynamics 365 terms IDs. Open invoices migrate with full detail; historical paid invoices migrate as reference records unless the customer requires a clean slate.

PeopleSoft AR bill lines map to Dynamics 365 CustomerInvoice with customer, billing cycle, and amount fields. We preserve Sold-To and Ship-To address relationships from CUST_TABLE and map PeopleSoft payment terms codes to Dynamics 365 terms. PeopleSoft AR uses a separate billing interface (BI Publisher reports) that generates invoices differently from AP vouchers, so we handle AR and AP as separate extraction jobs. Open AR items migrate as outstanding invoices; paid historical invoices migrate as posted records with a reference number.

PeopleSoft maintains customer records across FSCM CUST_TABLE and CRM tables, requiring de-duplication during extraction. We preserve Sold-To and Ship-To addresses, credit limits, and customer profile flags. Dynamics 365 Customer is a DirParty-based entity requiring the party record created first, then the customer record linked to it. Customer account numbers map as external reference fields to maintain continuity with PeopleSoft-based integrations.

PeopleSoft VENDOR_TABLE stores vendors with addresses, payment terms, W-9 tax ID, and routing rules tied to purchasing BU setIDs. We extract the full vendor hierarchy preserving parent-vendor relationships and map vendor IDs to Dynamics 365 Vendor account numbers. PeopleSoft vendor withholding tax status and 1099 flagging map to Dynamics 365 Vendor tax registration fields. Vendor hierarchy routing rules tied to PeopleSoft SetIDs require reimplementation as Dynamics 365 procurement categories or workflow routing.

PeopleSoft PO_HDR and PO_LINE store purchase order headers and lines with approval status, buyer ID, schedule dates, and distribution lines. We extract open and history PO rows preserving PO ID and line numbers. Dynamics 365 PurchaseOrderHeader and PurchaseOrderLine map directly, with PeopleSoft BU and setID map to legal entity and procurement category. PO approval workflows built in PeopleSoft Workflow Engine do not migrate; we document approval thresholds and routing for rebuild in Dynamics 365 Power Automate or procurement workflows.

PeopleSoft INV_ITEM_MASTER and INV_ITEMS_CF store item definitions with unit of measure, standard cost, category codes, and business-unit-specific inventory flags. We map PeopleSoft business-unit inventory flags to the Dynamics 365 legal entity item storage and warehousing configuration. Item lot and serial number settings map to InventBatch and InventSerial tracking configuration in Supply Chain Management.

PeopleSoft BENEFIT_PARTICIPATION and related enrollment, plan assignment, and coverage date records map to Dynamics 365 HCM Benefit records. We extract current benefit elections and carry forward plan names mapped to the destination benefit plan structure. PeopleSoft's multi-plan-version and rate-effective-date model differs from Dynamics 365's benefit plan and coverage period configuration, so we migrate current election data as a snapshot rather than attempting to replay the full enrollment history.

PeopleSoft Payroll stores pay calculations with pay group, FLSA status, and year-to-date accumulators. We extract year-to-date gross, taxes, and deductions as of the last payroll date, mapping pay components to Dynamics 365 pay statement detail lines. This is a snapshot carryforward rather than a full payroll history migration, because PeopleSoft payroll processes and calculation logic require reimplementation in Dynamics 365 Payroll. We do not migrate tax setup, garnishments, or direct deposit routing without explicit configuration review.