ERP migration
Field-level mapping, validation, and rollback between VISCO and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
VISCO
Source
Epicor Prophet 21
Destination
Compatibility
10 of 15
objects map 1:1 between VISCO and Epicor Prophet 21.
Complexity
CModerate
Timeline
6-10 weeks
Overview
Moving from VISCO to Epicor ERP is a data-model migration that must address VISCO's lack of a documented export API, its unique landed cost allocation engine, and its lot-tracking audit trail for regulated-industry compliance. VISCO structures landed costs as per-shipment allocations across freight, duty, insurance, and brokerage categories; Epicor ERP stores these across the Part Cost, Landed Cost, and Supply Chain Cost layers, which we decompose and reassemble during migration. VISCO's shipment and container tracking records must map to Epicor's Shipment or Job Tracker depending on whether the destination is configured for manufacturing or distribution workloads. Lot records, including expiration dates, source shipment references, and warehouse location assignments, migrate to Epicor Part Lot records with all traceability data preserved. VISCO's integrated CRM inquiry data (stored separately from contact records) migrates as activity or case records against the Contact object. We do not migrate workflows, custom alerts, compliance checklists, or document generation templates; we deliver a written inventory of every active configuration for the customer's admin to rebuild in Epicor.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a VISCO object lands in Epicor Prophet 21, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
VISCO
Products/Items
Epicor Prophet 21
Part
1:1VISCO product records carry landed cost allocation fields, unit-of-measure conversions, and product identification metadata (SKU, HS codes, country of origin). We map these to Epicor Part with PartCost, PartWhse, and PartPlant records. Unit-of-measure conversions in VISCO map to the Epicor UOMClass and UOMConv table. HS tariff codes and country of origin store in Part custom fields or UD columns for trade compliance. Part number becomes the dedupe key; PartClass and PartGroup map to Epicor's commodity and product group structures.
VISCO
Customers
Epicor Prophet 21
Customer
1:1VISCO customer records include company details, ship-to and bill-to addresses, QuickBooks-linked fields, and payment terms. These map to Epicor Customer with CustCnt (contact) and ShipTo records. The QuickBooks-linked identifier stores as a custom field for reconciliation. Customer credit limits and payment terms map to Epicor's Credit Hold and Terms logic. Customer is created before any Order or Quote import so the CustNum reference is satisfied.
VISCO
Contacts
Epicor Prophet 21
Contact (CustCnt)
1:1VISCO contact records from the CRM module map to Epicor CustCnt records linked to the Customer. VISCO contact assignments for inquiry workflows map as an Epicor custom field or UD column on CustCnt to preserve the assignment relationship. The contact's role (purchasing, logistics, finance) maps to the Epicor RoleCode or a custom picklist field. Primary contact flag migrates directly.
VISCO
Land Costs
Epicor Prophet 21
Part Cost + Landed Cost + Supply Chain Cost
1:manyVISCO Land Costs are structured per-shipment allocations across freight, duty, insurance, and brokerage categories assigned per product. Epicor separates these across PartCost (standard and current costs), LandedCost (allocation screens for incoming receipts), and Supply Chain Cost (freight and handling on PO lines). We decompose VISCO's landed cost record into component allocations and map each to the appropriate Epicor cost layer. Allocation percentages from VISCO become Epicor's LandedCost allocation basis (quantity, weight, volume, or value). This is the most complex transformation in the migration and requires a per-category mapping matrix validated during sandbox testing.
VISCO
Shipments
Epicor Prophet 21
Shipment or Job (context-dependent)
lossyVISCO shipments track containers, ports, carriers, dates, and status from origin through destination. For distribution-configured Epicor environments, VISCO shipments map to ShipHead and ShipDtl records. For manufacturing-configured environments with job-based delivery, VISCO shipment status and container data map to Job Traveler notes or a custom Shipment UD table. Container number, vessel name, port of loading, port of discharge, and carrier reference store in ShipHead UD columns or as shipment notes. The customer's Epicor module configuration (distribution vs. manufacturing) is confirmed during scoping.
VISCO
Inventory Lots
Epicor Prophet 21
PartLot
1:1VISCO lot records include lot number, expiration date, source shipment reference, warehouse location, and quantity on hand. These map to Epicor PartLot with Plant, Warehouse, Bin, LotNumber, LotDescription, ExpirationDate, and MakeOrBuy fields. Source shipment reference stores as a PartLot UD field for traceability. Quantity on hand per lot per warehouse creates PartBin records with allocated and unallocated quantities. For regulated industries (food, chemical), the FDA or USDA compliance attributes (lot age, quarantine status) map to Epicor PartLot custom fields.
VISCO
Sales Orders
Epicor Prophet 21
OrderHed + OrderDtl
1:1VISCO sales orders carry customer references, line items, pricing, quantity, and landed cost allocations. We map OrderHed (order header with Customer, PO number, terms, ship date) and OrderDtl (order lines with Part, quantity, unit price, discount). Landed cost allocations from VISCO lines migrate as OrderDtl custom fields or UD columns, not as native Epicor landed cost records (which apply at receipt, not order). Open orders and historical orders migrate in separate batches; closed orders migrate as historical records without workflow triggers.
VISCO
Purchase Orders
Epicor Prophet 21
POHeader + PODetail
1:1VISCO purchase orders reference suppliers, products, quantities, expected landed costs, and order-to-receipt relationships. POHeader maps to supplier, terms, and FOB; PODetail maps to the line items with PartNum, Quantity, UnitCost, and landed cost allocation. The expected landed cost fields from VISCO map to PODetail UD columns since Epicor's native landed cost screen applies at receiving. PODetail lines link to Receipt records after goods receipt, which we reconcile during the receiving-phase migration.
VISCO
Documents
Epicor Prophet 21
Document Master ( EDM)
1:1VISCO generates and stores bills of lading, commercial invoices, certificates of origin, and customs forms. Document files and metadata are exported separately and associated with the corresponding VISCO shipment, customer, or supplier record. We map document metadata (type, date, reference number) to Epicor EDM Document Management with links to Shipment or Customer via the DocumentReference table. The actual document files (PDFs, images) migrate as binary blobs attached to the Epicor document record.
VISCO
CRM Inquiries
Epicor Prophet 21
Case or Activity (Task)
1:manyVISCO's CRM module stores customer inquiries separately from contact records, with inquiry status, assigned user, and follow-up history. We map VISCO inquiry records to Epicor Case (Service Track) if the customer licenses the Service module, or to Task records attached to the Contact if Service is not licensed. Inquiry status maps to Case Status or Task Status; assigned user maps to the Epicor User by email match; follow-up history becomes sub-Task or Case Activities. The inquiry-contact relationship is preserved by linking to the migrated CustCnt record.
VISCO
Warehouses
Epicor Prophet 21
Plant + Warehouse + Bin
1:1VISCO warehouse location assignments on lot records map to Epicor's Plant, Warehouse, and Bin hierarchy. Each VISCO warehouse location becomes a combination of Epicor Plant (or site), Warehouse code, and Bin number. Multi-warehouse configurations require separate Plant records in Epicor if the sites have distinct inventory parks or costing profiles.
VISCO
Suppliers
Epicor Prophet 21
Supplier
1:1VISCO supplier records referenced on purchase orders map to Epicor Supplier with SupplierID, Name, PaymentTerms, ShipVia, and address records. Supplier country and currency map to Epicor's supplier payment and currency defaults. Supplier lead times map to PartVend records for MRP scheduling.
VISCO
Carriers
Epicor Prophet 21
Carrier
1:1VISCO carrier references on shipment records map to Epicor Carrier with CarrierID, Description, and shipping mode. Carrier SCAC codes and freight terms map to Carrier freight class and terms fields. Carrier is referenced on ShipHead and POHeader records.
VISCO
Port and Location References
Epicor Prophet 21
UD Table or customization
lossyVISCO stores port of loading, port of discharge, country of origin, and destination country as shipment attributes. Epicor does not have a native ports-of-trade table. We map these to a UD table (UD01 or equivalent) linked to the Shipment record, or as ShipHead custom fields if the customer's Epicor environment has pre-configured port fields. The customer confirms the preferred approach during scoping.
VISCO
Alert and Checklist Configurations
Epicor Prophet 21
Written inventory (no migration)
lossyVISCO's automatic container tracking alerts and compliance checklist configurations are user-defined rules that do not have a direct Epicor equivalent. We extract every active alert and checklist configuration from VISCO (trigger condition, recipient, message template, frequency) and deliver them as a written inventory document for the customer's admin to rebuild in Epicor using BPMs, alerts, or the Kinetic Workflow Designer. This is not a data migration deliverable; it is a configuration handoff.
| VISCO | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Products/Items | Part1:1 | Fully supported | |
| Customers | Customer1:1 | Mapping required | |
| Contacts | Contact (CustCnt)1:1 | Mapping required | |
| Land Costs | Part Cost + Landed Cost + Supply Chain Cost1:many | Mapping required | |
| Shipments | Shipment or Job (context-dependent)lossy | Fully supported | |
| Inventory Lots | PartLot1:1 | Fully supported | |
| Sales Orders | OrderHed + OrderDtl1:1 | Mapping required | |
| Purchase Orders | POHeader + PODetail1:1 | Mapping required | |
| Documents | Document Master ( EDM)1:1 | Mapping required | |
| CRM Inquiries | Case or Activity (Task)1:many | Fully supported | |
| Warehouses | Plant + Warehouse + Bin1:1 | Fully supported | |
| Suppliers | Supplier1:1 | Fully supported | |
| Carriers | Carrier1:1 | Fully supported | |
| Port and Location References | UD Table or customizationlossy | Fully supported | |
| Alert and Checklist Configurations | Written inventory (no migration)lossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
VISCO gotchas
No publicly documented migration API
Pricing cited varies significantly across sources
CRM module stores inquiry data separately from contact records
Epicor Prophet 21 gotchas
Third-party bolt-on integrations complicate migration scope
Dirty data without standardized processes compounds migration risk
SDK customizations and BPMs may not survive platform upgrades
Report-based export only for non-technical users
Per-user pricing model requires accurate user count before migration planning
Pair-specific challenges
Migration approach
Discovery and VISCO export-path validation
We audit VISCO across all active modules: products, customers, contacts, land costs, shipments, inventory lots, sales orders, purchase orders, suppliers, carriers, documents, and CRM inquiry records. Because VISCO lacks a documented API, we simultaneously coordinate with VISCO's technical contacts to establish the export path for each object type (direct database access, UI export, or support-generated dump). We also confirm the destination Epicor environment (Kinetic cloud vs. 10.2 on-premise), active modules, plant configuration, and any existing UD tables or customizations. The discovery output is a written migration scope, an export-path confirmation for each object, and an Epicor module-readiness checklist.
Epicor schema setup and landed cost matrix design
We configure the destination Epicor schema in a sandbox environment. This includes Part setup with costing layers (PartCost, LandedCost, Supply Chain Cost), Plant and Warehouse hierarchy, Customer and Supplier records with payment terms and shipping defaults, Carrier setup, and any UD tables for ports, compliance attributes, or VISCO-specific fields. The landed cost mapping matrix is designed here: each VISCO cost category (freight, duty, insurance, brokerage) maps to a specific Epicor cost layer, allocation basis, and either a PO-level or receipt-level trigger. We also define the CRM inquiry migration path (Case or Task) based on whether the customer licenses Epicor Service Track.
Sandbox migration and reconciliation
We run a full migration into the Epicor sandbox using production-like data volume. The customer's operations lead reconciles record counts (Parts in, Customers in, Land Costs in, Shipments in, Lots in, Orders in, Purchase Orders in), spot-checks landed cost totals against VISCO reports, validates lot traceability links, and reviews the inquiry-to-contact mapping. Any corrections to the landed cost matrix, UD field mapping, or object split rules happen here. The customer signs off the sandbox reconciliation before production migration begins.
VISCO database export and data extraction
We execute the VISCO export path confirmed during discovery. For direct database access, we run read-only queries against the VISCO tables in dependency order: reference data (products, customers, suppliers, carriers) first, then transactional data (orders, shipments, landed costs), then inventory (lots, bins). For UI-based exports, we coordinate with the customer's VISCO users to generate the export files. We validate record counts and field completeness at export time and flag any data anomalies before transformation begins.
Production migration in dependency order
We run production migration in record-dependency order: reference data (Parts, Customers, Suppliers, Carriers), Plant and Warehouse setup, PartLot records (pre-pass for traceability integrity), Sales Orders and Purchase Orders (with landed cost fields as UD columns), Landed Cost allocations (decomposed into Epicor cost layers), Shipment records, Inventory transactions, Document metadata and files, and CRM Inquiry records (as Cases or Tasks). Each phase emits a row-count reconciliation report before the next phase begins. We use Epicor's REST or OData API for record inserts with batch chunking and error logging.
Cutover, validation, and compliance configuration handoff
We freeze VISCO writes during cutover, run a final delta migration of any records modified during the migration window, then enable Epicor ERP as the system of record. We deliver the compliance checklist and alert configuration inventory to the customer's trade compliance team for rebuild in Epicor. We deliver the landed cost allocation report comparing VISCO totals to Epicor totals for sign-off. We support a one-week hypercare window for reconciliation issues. We do not rebuild VISCO compliance workflows or alerts as Epicor BPMs or alerts inside the migration scope; that is a separate trade compliance engagement or an internal admin task.
Platform deep dives
VISCO
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Moderate ERP migration. 4 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across VISCO and Epicor Prophet 21.
Object compatibility
4 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
VISCO: Not publicly documented.
Data volume sensitivity
VISCO doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during VISCO to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your VISCO to Epicor Prophet 21 migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave VISCO
Other ways to arrive at Epicor Prophet 21
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.