Migrate from Adaptive to Epicor Prophet 21

Adaptive Customer records (name, address, contact details, tax IDs, payment terms) map directly to Epicor Customer. The Adaptive Customer ID becomes the Epicor Customer_cd; the billing address and ShipTo addresses map to Epicor Customer and ShipTo records respectively. We preserve linked addresses as child ShipTo records and flag any Adaptive-specific credit limit or payment term codes that require reconfiguration in Epicor's credit management module.

Adaptive Supplier records mirror Customer records structurally. We map Suppliers to Epicor Supplier with supplier code, bank details, and payment terms preserved. Adaptive's supplier-specific fields (tax ID, W-9 status, 1099 flag) map to Epicor SupplierTaxConnect or equivalent fields depending on the Epicor configuration. We flag any EDI-specific supplier mappings that require a separate EDI translation layer in Epicor.

Adaptive account codes and names transfer to Epicor GLAccount with type flags (Asset, Liability, Equity, Revenue, Expense). Epicor supports segmented account structures with entity, division, and department segments; we map the flat Adaptive account code to the primary segment and flag any multi-segment account requirements for the customer's Epicor admin to configure post-migration. Account code integrity is critical for fiscal period reconciliation.

Adaptive open AR invoices (line-item documents with status flags) map to Epicor ARInvoice. The status field must be explicitly mapped because Epicor's invoice status (Open, Closed, Void) uses different enumeration values than Adaptive's. We preserve outstanding balance, invoice date, due date, and currency code. Invoice numbers must be unique in Epicor; we handle duplicates by pre-pending a prefix or appending a sequence suffix during import.

Adaptive open AP invoices map to Epicor APInvoice with vendor reference, invoice number, amount, and due date preserved. Epicor's AP invoice matching workflow (two-way or three-way match) may require configuration post-migration if the customer relies on purchase order matching. We flag any pre-paid invoices and retainage amounts for separate handling.

Past journal entries carry fiscal period and date metadata that Epicor maps to GLFiscalPeriod. We flag any Adaptive journal entries that span Epicor's fiscal year boundaries and require period re-assignment during import. Epicor's versioned ledger supports audit trails; we preserve the original posting date and journal number for reconciliation. Entries without a matching fiscal period in Epicor are held in a staging table for the customer's controller to resolve.

Adaptive Stock Items (SKU, description, unit cost, current quantity) map to Epicor Part records. We flag custom attributes, BOM structures, and warehouse-specific quantities for manual post-migration review because Epicor's part master supports multiple sites, stocking UOMs, and revision controls that Adaptive may not expose in the same way. Part-specific cost layers (standard, average, FIFO) must match between systems or be revalued in Epicor post-migration.

If Adaptive stores Bill of Materials as part of Stock Item configuration, we map these to Epicor BOM tables (BOMHead, BOMDetail). Epicor's BOM supports multiple revisions, alternate methods, and configured parts; we preserve the BOM structure and flag any phantom BOMs, co-products, or by-products that require Epicor's manufacturing module configuration. BOM revisions must align with Epicor's revision control lifecycle.

Adaptive document attachments (invoices, purchase orders, statements) referenced by path or stored as blobs migrate to Epicor's native attachment tables or DocStar ECM if licensed. We map attachments to their parent record (Customer, Supplier, Order, Invoice, Part) and flag any that exceed typical size limits in Epicor's attachment storage. Epicor's attachment versioning is preserved where the source supports it.

Adaptive user accounts (name, email, role assignments) map to Epicor User with the Adaptive role hierarchy translated to Epicor's security roles (Plant, Company, Sales, Production). We map active users to active Epicor User records and flag inactive or archived Adaptive users that may not have a direct equivalent in Epicor's user model. Epicor's Employee table may be required if HR data is also migrating.

Adaptive purchase orders map to Epicor POHeader and PODetail records with vendor reference, order date, terms, and line items preserved. Open purchase orders are prioritized for migration; closed and cancelled POs are archived without Epicor records. We resolve supplier references using the Supplier mapping and flag any Adaptive PO-specific fields (approval workflow, cost center) for Epicor configuration.

Adaptive sales orders map to Epicor OrderHed and OrderDtl with customer reference, order date, and line items preserved. Open orders are migrated first with line fulfillment status preserved; completed orders are archived without full Epicor record creation. Epicor's Order Management module supports multiple order types (Quote, Order, Blanket, Contract) that may require OrderHed.OrderQuoteFlag or OrderHed.OrderHeld configuration based on the Adaptive order status.

If Adaptive stores job or work order data, these map to Epicor JobHead and JobMtl records with job number, part number, quantity, and material requirements preserved. Epicor's job status (released, complete, closed) may differ from Adaptive's enumeration; we map the status explicitly. We flag any job-specific routing and labor data that requires Epicor's labor tracking module configuration.

Adaptive custom field extensions do not have a direct Epicor equivalent in the standard schema. We map Adaptive custom properties to Epicor User-Defined (UD) columns in the relevant tables (Customer, Supplier, Part, OrderHed, etc.) using Epicor's ZDataTable framework. Post-migration, the customer's Epicor admin configures BPM logic to populate UD fields as needed, similar to the custom field population described in the Epicor user forum (e.g., using BPMs to populate UD fields from related table data).