Migrate from Pilot ERP to Epicor Prophet 21

Pilot ERP Customer records map directly to Epicor ERP Customer. The customer number, name, address, payment terms, and credit limits transfer. We use the Pilot ERP customer number as the dedupe key and verify that every Invoice or Bill referencing a migrated Customer resolves to the new Epicor Customer ID at import time. If the customer's Epicor configuration uses Company-level multi-entity, we flag this during scoping for the admin to configure the Customer's Company association before the financial data loads.

Pilot ERP Vendor master records map to Epicor ERP Vendor with vendor number, name, address, payment terms, and bank details preserved. Outstanding Bills in Pilot ERP reference their Vendor; we resolve the Vendor ID at migration time so Bills attach to the correct Vendor on import. If Pilot ERP uses a different vendor-numbering scheme than Epicor's standard length, we pad or truncate during transform and document the mapping for the customer's AP team.

Pilot ERP Items map to Epicor ERP PartMaster records. Part number, description, unit of measure, costing method, and current stock levels transfer. The barcode-labelled inventory linked to Items by part number is verified against the PartMaster; any barcode records pointing to non-existent Items are flagged as orphans for the customer to resolve before import. Epicor PartMaster supports multiple sites; if Pilot ERP uses a single-site model, we configure the primary site during schema setup.

Pilot ERP Work Orders map to Epicor ERP Job records. Each Work Order links to a finished-good Item and optionally to a Purchase Order for raw materials. We preserve the Work Order number as the Job number reference, the linked Item as the PartNum on the Job, and the job status (open, closed, cancelled). Epicor Job revision control introduces a complexity: Pilot ERP Work Orders do not carry a revision layer, so we create Job revision 1 for each migrated Work Order and flag any Jobs with a non-current revision for the customer's Epicor admin to validate.

Pilot ERP Purchase Orders map to Epicor ERP POHeader and PODetail records. Vendor, PO number, status, line items, and quantities transfer. We audit all PO-to-Work-Order references during the migration audit phase and flag any orphaned or invalid links — Pilot ERP POs often reserve raw materials for a specific Work Order, and if that Work Order is closed or cancelled, the link becomes stale. The customer reviews and resolves these before the destination system goes live to prevent receiving and inventory discrepancies in Epicor.

Pilot ERP Invoices map to Epicor ERP Invoice records linked to Customers and Items. We import open invoices with payment status and remaining balance. Historical paid invoices transfer with full line-item detail for audit trail completeness. The Customer ID on each Invoice is resolved via the Customer migration mapping; if a Pilot ERP Invoice references a Customer that failed migration, the Invoice is held in a reconciliation queue.

Pilot ERP Bills from Vendors map to Epicor ERP Vendor Invoice records with outstanding balance and payment terms preserved. We maintain the relationship to the originating Vendor record via the Vendor mapping, and any partial-payment history is carried as payment records against the Vendor Invoice in Epicor. If Pilot ERP uses a different invoice-numbering scheme, we map it to Epicor's InvoiceNum with the original Pilot ERP number preserved in a reference field.

Pilot ERP Job Costing breaks costs into material, labor, and overhead components per job or Work Order. Epicor ERP represents these as JobMtl (material), JobOper with labor clock entries, and burden or overhead allocations. We create a costing matrix during discovery that maps each Pilot ERP cost category to Epicor's equivalent structure. Any cost types that do not map automatically — such as custom overhead pools or non-standard labor classifications — are flagged for manual configuration in Epicor before the financial data load. The costing matrix is a written deliverable, not an automated migration step.

Pilot ERP maintains a Chart of Accounts used across all financial modules. We extract the full account structure (account number, name, type, and active status) and map it to Epicor ERP GL Account records. Accounts with transactions that do not exist in the Epicor destination are flagged for the customer to create or consolidate before the GL data load. Epicor's account segments (such as division, department, or cost centre) may not align with Pilot ERP's segment structure; we document the segment mapping and configure Epicor GL Account templates before import.

Pilot ERP's barcode data collection module links barcode scans to Items by part number. Epicor ERP handles inventory tracking through its warehouse management and MES modules rather than a separate barcode layer. We map barcode-labelled inventory transactions to Epicor PartTran records, preserving transaction type, quantity, and part number. Any barcode records with unresolved Item references are flagged as data-quality issues in the migration report.

Pilot ERP supports user-defined custom fields on standard objects, but there is no documented schema export or API endpoint for custom field definitions. We inventory custom fields during the discovery call by reviewing Pilot ERP's field configuration screens with the customer. We then recreate these as Epicor Kinetic UD fields (using UD101, UD102, or similar configured UD tables) before importing data, and map them to the corresponding records during the load phase. The customer must confirm field types and validation rules for each custom field during discovery.

Pilot ERP's user manual references document attachment capability but does not expose a documented public API endpoint for binary file export. Epicor ERP stores documents in Azure File Share (cloud) or on the server file system (on-premise), with access paths that changed during the 2025.2 Linux container migration. We cannot programmatically extract binary attachments from Pilot ERP without a direct database connection. We document every attachment reference encountered during discovery (drawings, photos, PDFs linked to Work Orders, Customers, or Items) and request that the customer manually export or provide database access for files that are migration-critical. If neither option is available, we migrate the record metadata but flag the missing files explicitly in the deliverable.