Migrate from Visibility ERP to Epicor Prophet 21

Visibility multi-level BOMs map to Epicor Kinetic PartMtl records under the parent Part number. We walk the parent-component tree recursively, mapping each level's MaterialQty, ScrapFactor, and BOMRevision reference. Phantom BOMs use the PartKit flag in Epicor. Configure-to-order BOMs from Visibility's Product Configurator store rule-driven configurations that have no direct Epicor equivalent; we preserve the configuration code as a custom UD column (CfgCode_c) and document the reconstruction path using Epicor's CPQ or Product Configuration module. P

Visibility Routings define operation sequences, work centers, and standard times. We map Routing Operation records to Epicor PartOpr rows, preserving OpCode, LaborHours, MachineHours, and WorkCenterID. Custom operation-level user fields from Visibility require UD column creation in Epicor before import. Multiple routings per part (alternate routings) map to Epicor's PartOpr records flagged with PrimaryOperation = false.

Visibility Work Orders carry routing steps, labor estimates, material allocations, and status histories. We map open Work Orders (Released, In Process status) to Epicor JobHead with linked JobMtl and JobOper rows. JobNum is generated at import. The linked BOM revision is explicitly mapped using our revision-mapping table to ensure JobMtl references an active PartMtl revision. Closed Work Orders migrate as historical job records with JobHead.JobComplete = true.

Visibility Production Orders reference BOM and Routing to generate material and labor requirements. We map Production Order headers to Epicor JobHead with JobType = MTO and the linked PartMtl revision resolved via the BOM revision map. The operation step sequence migrates as JobOper rows in the same import batch as JobMtl to ensure material and routing data are available simultaneously.

Open Sales Orders with configured lines, pricing, discounts, and shipment schedules migrate to Epicor OrderHed and OrderDtl. Visibility's configured lines carry Product Configurator data that maps to OrderDtl with a CfgCode_c reference and the configuration revision preserved. Customer and ship-to addresses map to Epicor ShipTo and Customer records resolved at import time. OrderRel schedules map to OrderRel with ship-by dates preserved.

Open Purchase Orders with line items, vendor assignments, scheduled receipts, and unit costs map to Epicor POHeader and PODetail. Vendor references resolve to Epicor Supplier records during import. Line-level detail including due dates, quantities, and unit costs migrate to PODetail. POs with link to a parent Work Order or Production Order in Visibility carry a JobNum reference as a UD field since Epicor PO linkage to Jobs is module-specific.

Visibility lot numbers, serial numbers, expiration dates, and bin locations map to Epicor PartLot (lot attributes), PartBin (bin-level quantity), and PartTran (transaction history). Lot-controlled items require mapping at the PartTran level, not just the Part master. On-hand quantities by site and warehouse map to PartBin. We flag any expiration-date-based FIFO logic for manual reconfiguration in Epicor's inventory costing setup.

Visibility's hierarchical GL code structure maps to Epicor GLAccount with account segments preserved. We extract the full account tree from Visibility, validate that the destination segment structure in Epicor matches (segmented vs. flat), and map AccountType and PostingEdit controls. Balance-forward accounts require GL Account opening balances migrated as Epicor GLJrnDtl records.

Open invoices, credit memos, and payment records carry customer/vendor references, due dates, and aging buckets. We map open AP by vendor and aging period to Epicor APOpen, and open AR by customer and aging period to AROpen. Original invoice numbers migrate as InvoiceNum for reference. Post-cutover transactions accrue in Epicor only.

Visibility QC inspection results, non-conformance records, and corrective actions link to Work Orders and inventory transactions. We map QC records as related children of the migrated JobHead/JobMtl, with inspection results stored in a custom JobOper extension table or as QCNC records linked via NonConfNum. The mapping depends on whether the destination Epicor environment includes the Quality Management module.

Visibility allows user-defined fields across most objects. The custom field schema is not exposed in public API documentation, so we request a database-level export or Visibility-supported report during scoping. Each UDF is mapped to an equivalent Epicor UD column (character, numeric, date, or checkbox) with the same name where possible. Custom fields that require runtime calculation (e.g., BOM rollup costs) map to a BPM in Epicor rather than a stored value; this is documented in the migration workback.

Visibility User accounts, role profiles, and security permissions migrate with role-to-permission mapping preserved where Epicor has an equivalent role. Role names map to the closest Epicor Kinetic security group (e.g., Shop Supervisor, Production Planner, Order Entry). We extract the user roster from Visibility and match by username or email against Epicor's Ice.User table. Active users without a destination account are flagged for provisioning before record migration.

Visibility's Document Management module stores binary files linked to entities across the system with no publicly documented bulk export endpoint. We do not include binary document content in the automated migration scope. We do extract document metadata (filename, revision, linked entity, creation date) as a cross-reference index CSV so the customer can manually re-upload files to Epicor's Document Management or Knowledge Management module post-migration. File count and average file size inform the manual effort estimate.