Migrate from Priority ERP to Epicor Prophet 21

Priority Customers map to Epicor Kinetic Customer records. Priority's multi-address hierarchy (bill-to, ship-to) maps to Epicor's Customer and CustomerShipTo records with address records linked by ShipToNum. Customer price lists map to Epicor PriceLst records with PriceLstLines. We extract credit limit, payment terms, and the customer account representative from Priority's CATEGORY table and map them to Epicor Customer fields noting that Customer.TerritoryID requires mapping from Priority's sales representative assignment logic.

Priority Vendors map to Epicor Kinetic Vendor records. The purchasing address hierarchy (pay-to, ship-from) maps to Epicor Vendor and VendorPP records. We extract purchasing terms, payment day, and the buyer assignment from Priority's VENDOR table and map them to Epicor Vendor fields. Vendor catalog UOMs map to Epicor PartUOM records if the vendor ships in non-stock units.

Priority Items map to Epicor Kinetic Part records with PartNum, PartDescription, TypeCode (Stock, Non-Stock, Service), and UnitOfMeasure. BOM links from Priority items map to Epicor PartMtl records with the bill of materials structure preserved as PartMtl sequences. Warehouse-specific quantities and stocking dimensions from Priority map to PartWhse records. Priority's stocking dimensions (length, width, height) map to Part.UPCCode or Part.UOM fields as applicable. Multi-company item numbers from Priority may require a PartCrossReference or the customer's part number as the primary PartNum in Epicor.

Priority BOM structures (parent item with component lines, quantities, and scrap percentages) map to Epicor PartMtl records. We decompose the Priority BOM levels and insert them as Epicor PartMtl rows with material type, quantity per, and bom sequence preserved. If Priority BOMs use phantom assemblies or co-products, we map those to Epicor's PartMtl.MtlType (MT, PH, SA, CO) with the corresponding PartRev setup. BOM revisions in Priority map to Epicor PartRev ECOs.

Priority Sales Orders map to Epicor Kinetic OrderHed (header) and OrderDtl (line) records. The Priority order header fields (customer reference, order date, terms, freight) map to Epicor OrderHed fields (CustomerPO, OrderDate, Terms, ShipVia). Order lines with pricing, discounts, and tax allocation map to OrderDtl with PartNum, OrderedQty, UnitPrice, DocUnitPrice, and DiscountPercent preserved. Priority's multi-release sales orders (contract orders with scheduled releases) map to Epicor OrderRel records with the release schedule preserved as OrderRel rows. We flag any Configure-to-Order lines for manual configuration review in Epicor CPQ or Product Configurator.

Priority Purchase Orders map to Epicor Kinetic POHeader and PODetail records. PO headers with vendor reference, terms, and shipping instructions map to Epicor fields. Line items with part numbers, quantities, and prices map to PODetail. Priority's multi-release POs map to Epicor PORel records. We extract the buyer assignment from Priority and map it to Epicor POHeader.BuyerID with the UserID from Epicor's ice.SysUserRow table.

Priority's multi-segment account codes (for example, 01-100-320 representing company-department-cost-center) require structural decomposition. We extract the full Priority account tree and decompose the segments into Epicor's flat account code structure with the first segment as GLAccount.AcctCDE and subsequent segments mapped to GLAccountExt records (ExtCompany, ExtCostCenter, ExtDepartment). The customer must approve the segment-to-dimension mapping before account migration because Epicor's dimension model varies by site configuration. We flag any Priority accounts where segment semantics cannot be cleanly represented in Epicor's dimension model.

Outstanding payables and receivables in Priority carry aging calculated from due dates. We extract open invoice totals, due dates, and aging buckets from Priority and map them to Epicor APTran (for open AP) and ARTran (for open AR) records. Open documents are inserted after Customers and Vendors are loaded so that VendorNum and CustomerNum references are satisfied. We validate aging totals against Priority's open invoice aging report post-load. Closed AP/AR history is archived rather than migrated live because loading years of historical transaction lines into Epicor increases database size and slows the production environment.

Priority Projects with budgets, WBS rows, milestones, and billing records map to Epicor Kinetic ProjectHed, ProjectCst, WBSPhase, and Job records. We extract project headers and associated work breakdown structure rows, time entries, and billing details and map them to Epicor ProjectHed and WBSPhase. Phase-level budgets map to Epicor ProjectCst.BudgtConSup and ProjectCst.BudgtLbrCost fields. Project-linked sales orders in Priority map to Epicor ProjectCst.JobNum references. We flag any project with a revenue recognition method that requires review in Epicor's billing and revenue recognition configuration.

Priority Employee records with org unit assignments and roles map to Epicor Kinetic EmpBasic records. We extract employee number, name, department, and role from Priority's EMPLOYEES table. Salary and benefits data require explicit customer sign-off due to data sensitivity and are typically excluded from the standard migration scope. Role-based permissions from Priority map to Epicor Kinetic UserID associations with the customer's admin reviewing access levels in the Kinetic Role Management screen post-migration.

Priority GL Journal Entries with debit and credit lines linked to account codes map to Epicor Kinetic GLJrnGrp and GLJrnLine records. We extract full entry details including posting date, period, fiscal year, journal number, and description from Priority's ACCHIST table and map them to Epicor GLJrnGrp.BatchDesc, GLJrnLine.JournalCode, GLJrnLine.Acct, GLJrnLine.DebitAmt, and GLJrnLine.CreditAmt. Reversing entries and recurring templates from Priority are noted for manual rebuild in Epicor GL Recurring Journal or Journal Entry templates. Historical GL entries beyond the current and prior fiscal year are archived rather than migrated live.

Priority stores document attachments as file references linked to Customers, Orders, and Projects. We export attachments to a cloud file store (S3 or Azure Blob) and create URL link records in Epicor Kinetic. Link records are inserted with the parent record reference (Customer, OrderHed, or Project) so that users can access the file store from Epicor's attachment context. We validate attachment integrity during extraction and log any files that cannot be retrieved, excluding them from the migration package with an explicit count in the final validation report. Epicor's document storage path length limits require shortening file names that exceed 260 characters.

Priority's form generator and workflow builder create business logic embedded in the UI layer that does not export via API or p-level procedures. We document the existence, trigger conditions, and logic of every custom form and workflow during the discovery phase and deliver a written inventory with screenshots and configuration notes. The customer's Epicor admin or an Epicor implementation partner rebuilds these in Epicor's Configuration and Customization Framework, Business Process Management (BPM) tools, or Kinetic Customization Framework post-migration. This rebuild work is outside the standard migration scope and is quoted separately.