Migrate from Sage 500 to Epicor Prophet 21

Sage 500 stores GL Account codes and segment values in standardized SQL tables with clear foreign-key relationships to journal entry tables. We extract account number, description, account type, and all segment values. Epicor GL Account requires matching segment structure—Epicor supports up to 10 segments per account code. If Sage 500 uses fewer segments, we pad the Epicor structure with empty segments or consolidate; if Epicor uses fewer, we collapse the source segments and document the mapping for the customer's admin.

Sage 500 Customer records (IM_Customer table and related address, payment terms, and 1099 configuration tables) map to Epicor Customer. We assemble the customer header, billing address, shipping addresses, and credit limit fields into a single Epicor Customer record. Epicor Customer has a built-in ShipTo child table that we populate from Sage 500's multiple shipping address records. Payment terms and 1099 configuration map to Epicor's TermsCode and 1099 flag fields. We resolve the AR clerk and owner references against Epicor's User table during migration.

Sage 500 Vendor records (AP_Vendor table with address, payment terms, and 1099 configuration) map to Epicor Supplier. Tax IDs, 1099 flags, and payment terms carry forward. Epicor Supplier supports a PO Williamson or IRS 1099 flag that we set based on the Sage 500 vendor type. Vendor 1099 categories map to Epicor's 1099 Form Type field. Any EDI vendor identifiers stored in Sage 500 custom fields map to Epicor Supplier XRef records.

Sage 500 open AR aging records (invoice headers with line items, aging buckets, and payment application history) map to Epicor AR Invoice and AR InvoiceMsc records. We match Sage 500 aging period configuration to Epicor's AR Period definition before migration so that aging bucket assignments are consistent post-cutover. Sage 500 credit memos and adjustments map to Epicor AR Adjustment records with a negative amount sign. Customer invoice numbers from Sage 500 carry into Epicor InvoiceNum as reference only; Epicor generates its own InvoiceNum on insert.

Sage 500 open AP aging records map to Epicor AP Invoice and AP Adjustment. We extract invoice headers, line items, tax schedules, and payment application records. Epicor's AP Invoice requires a VendorNum reference resolved from the Supplier mapping. Sage 500 credit memos to vendors map to Epicor AP Adjustment records. All open AP records must be in Epicor before the general ledger period is closed for the migration date.

Sage 500 Sales Order records (order header with customer reference, order date, ship-to address, terms, and order total) map to Epicor Sales Order. We extract order status, order hold flags, and the original Sage 500 order number as a reference field. Epicor requires a CustomerNum reference resolved from the Customer mapping before insert. Open orders migrate with their current status preserved; completed orders with remaining backorder lines are flagged for the customer's review before Epicor shipment processing begins.

Sage 500 order detail records (line items with part number, quantity ordered, quantity shipped, unit of measure, pricing, and tax schedule) map to Epicor OrderDtl. We resolve the PartNum reference against Epicor's Part table; if the part does not exist in Epicor yet, we create a placeholder Part record during migration and flag it for the customer's item master build. Line-level warehouse assignment from Sage 500 maps to Epicor's WarehouseCode. Pricing migrates with a flag indicating whether it should be treated as override or calculated from Epicor's price list.

Sage 500 Purchase Orders map to Epicor PO Header with PO Release child records. VendorNum resolves from the Supplier mapping. Open PO line quantities and expected receipt dates migrate as Epicor PO Release records. Sage 500 PO line status (open, closed, partially received) determines Epicor PO Release status. Purchase orders that are fully received in Sage 500 but not yet invoiced are flagged as receiving-only in Epicor to prevent duplicate receipt.

Sage 500 inventory item records (item number, description, UOM, costing method, and warehouse assignments) map to Epicor Part records. The costing method from Sage 500 (Standard, FIFO, LIFO, Average) maps to Epicor's cost element structure, but we confirm the destination costing method with the customer's Epicor administrator before committing. Multi-warehouse setups in Sage 500 generate one Epicor Part record with multiple PartPlant rows, one per warehouse. On-hand quantities from Sage 500 map to PartWhse QuantityOnHand after Part and PartPlant are created.

If Sage 500 uses FIFO or LIFO cost layers with transactional cost tiers, historical unit costs are stored per transaction. We extract the cost layer detail, but Epicor does not maintain open FIFO/LIFO layers in the same structure. Standard cost environments extract cleanly and reload as Epicor PartCost records. For FIFO/LIFO environments, we recommend a cost-carryover strategy that posts historical cost as an opening inventory layer in Epicor's PartTran table and closes the source cost tiers, rather than attempting to reproduce the full layer history in Epicor. The customer's Epicor administrator must confirm the costing engine selection before we proceed.

Sage 500 Fixed Asset records (asset number, class, acquisition date, cost, depreciation method, accumulated depreciation, and book value) map to Epicor Asset records. Depreciation schedules from Sage 500 (straight-line, declining balance, units of production) map to Epicor Depreciation Method. Sage 500 depreciation history in the FA_Depreciation table migrates as Epicor AssetRegistration records, preserving the accumulated depreciation and remaining book value at migration date. Sage 500 asset location and cost center assignments map to Epicor AssetPlant and AssetCost records.

Sage 500 GL journal entries (batch number, journal number, source module, posting date, account, debit, credit, and originating source reference) map to Epicor GL Journal Entry records. Epicor requires a fiscal period that matches the Sage 500 posting date; we validate that the Epicor fiscal calendar covers the Sage 500 journal date range before migration. Source module references (AP, AR, Inventory, Sales, Purchasing) map to Epicor's JournalCode. Detailed line items with explanations and reference fields carry forward. We do not migrate inter-company journal entries if Sage 500 uses them and Epicor does not have the Inter-Company module configured.

Sage 500 tax codes and rates per jurisdiction (stored in tax master and tax detail tables) map to Epicor Tax Code and Tax Entity records. Nexus assignments from Sage 500 map to Epicor Tax Connect or tax jurisdiction configuration depending on the Epicor edition. Customer-specific tax exemptions and override rates are flagged as manual items requiring the customer's tax administrator to review and re-enter in Epicor because these are typically stored as transaction-level overrides rather than master-level records.

Sage 500 bank account codes, reconciliation records, and GL account linkages from the bank module map to Epicor BankAcct. Account numbers, bank names, and GL reconciliation account numbers carry forward. Sage 500 bank reconciliation history (cleared transactions and statement matching) does not migrate as Epicor tracks reconciliation at the transaction level; the customer's Epicor administrator starts fresh reconciliation in Epicor post-cutover. Bank reconciliation rules and bank-specific formats for EDI or BAI2 feeds require separate configuration in Epicor.

Sage 500 does not natively store Bill of Materials or routing records in its standard database schema. If the customer has BOM data stored in a custom Sage 500 table or an external MRP system, we extract it and map to Epicor JobMtl (material) and JobOper (operation) records. If BOM data is not available in Sage 500, we flag this as a data gap and deliver a BOM reconstruction worksheet that the customer's engineering and Epicor implementation team completes before production migration. This is a common gap in Sage 500-to-Epicor migrations for manufacturing companies.

Sage 500 warehouse assignments on inventory items map to Epicor Warehouse and WarehseBin records. Multi-bin warehouses in Sage 500 (if configured) map to Epicor bin locations with Zone and Plant assignments. We extract warehouse codes, bin codes, and the bin type (staging, bulk, picking) from Sage 500 item warehouse tables. If Sage 500 does not maintain bin-level inventory, we create the Epicor warehouse structure without bin assignments and flag for the customer's warehouse administrator to configure bins post-migration.