ERP migration
Field-level mapping, validation, and rollback between Shipedge and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
Shipedge
Source
Epicor Prophet 21
Destination
Compatibility
7 of 12
objects map 1:1 between Shipedge and Epicor Prophet 21.
Complexity
BStandard
Timeline
6-10 weeks
Overview
Moving from Shipedge to Epicor ERP is a shift from a fulfillment-centric OMS/WMS to a manufacturing-and-distribution-focused ERP. Shipedge organizes data around Orders routed across Warehouses and Carriers with SKU-level Products; Epicor ERP organizes data around a Part master with revision control, multi-site warehouse bins, and Bill of Materials structures. We map Shipedge Customers to Epicor Customer and ShipTo records, Products to Part records (with unit of measure and stocking type resolved), and fulfillment history to Epicor OrderHed and OrderDtl records. Shipedge's Order Rules (automated routing logic), channel OAuth credentials, and 3PL client account structures do not migrate; we document all three for manual rebuild in Epicor's Data directives and BPM framework. Epicor ERP is designed for make-to-order, make-to-stock, and configure-to-order manufacturing operations; teams migrating from Shipedge's eCommerce fulfillment model should expect Epicor's greater operational depth in production scheduling, material requirements planning, and multi-entity financial consolidation.
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 Shipedge 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.
Shipedge
Customer
Epicor Prophet 21
Customer and ShipTo
1:manyShipedge Customer records (name, email, billing address, shipping address, contact info) map to Epicor Customer and one or more ShipTo records. Shipedge's per-customer carrier preferences and routing rules require Epicor Data directives to recreate as Customer ShipTo overrides or BPM-driven logic. The customer's primary billing address becomes the Customer record address; each unique shipping address becomes a separate ShipTo record with its own ShipToNum.
Shipedge
Order
Epicor Prophet 21
OrderHed and OrderDtl
1:1Shipedge Orders map to Epicor OrderHed (header: order date, customer, terms, PO number, ship via) and OrderDtl (lines: part number, quantity, unit price, warehouse, ship date). Shipedge's fulfillment status (pending, shipped, cancelled) maps to Epicor OrderRel.Status and OrderHed.OpenLine/OpenOrder flags. We preserve the original Shipedge order number as a user-defined field on OrderHed for audit traceability.
Shipedge
Product
Epicor Prophet 21
Part
1:1Shipedge Products (SKU, variant attributes, barcodes, supplier links) map to Epicor Part records. Shipedge variant attributes (size, color, style) map to Part character fields or user-defined columns depending on the Epicor field configuration. Barcode values migrate to Part.Large Picture or a user-defined barcode field. Shipedge's product type (kit, standard, bundle) influences the Part.TypeCode (Stocked, Make-to-Order, Configured) in Epicor.
Shipedge
Inventory
Epicor Prophet 21
PartBin and PartWhse
1:manyShipedge warehouse-specific inventory quantities map to Epicor PartWhse (per-warehouse stocking status) and PartBin (per-bin quantity). Each Shipedge warehouse maps to an Epicor Plant/Warehouse combination. Lot numbers and bin locations from Shipedge migrate to PartBin.LotNumber and PartBin.BinNum. Bin assignments not present in Shipedge default to the warehouse's standard receiving bin.
Shipedge
Kit
Epicor Prophet 21
Part and BOM (bill of materials)
lossyShipedge kit configurations (bundle structure and component links) map to Epicor Part records with Part.TypeCode = Phantom or Make and a corresponding BOM. Shipedge kitting type (on-the-fly assembly vs. pre-built) determines whether the BOM is a standard BOM (pre-built stock) or a Phantom BOM (explodes at job creation). The kit parent SKU becomes the Part; each component SKU becomes a BOM line with a quantity-per relationship.
Shipedge
Supplier
Epicor Prophet 21
Supplier and SupplierPP
1:1Shipedge Supplier records (name, contact, lead time, SKU associations) map to Epicor Supplier and SupplierPP (per-part supplier price breaks). Shipedge's supplier lead time per product maps to SupplierPP lead time or the Part.PurchasingFactor field. Supplier terms and payment methods migrate as Supplier records with default terms that can be overridden at the Purchase Order line level.
Shipedge
Shipment
Epicor Prophet 21
ShipHead and ShipDtl
1:1Shipedge shipment records (carrier, service level, tracking number, weight, dimensions) map to Epicor ShipHead and ShipDtl. Carrier and service level values from Shipedge (UPS Ground, FedEx 2Day, USPS Priority) migrate as Epicor ShipVia codes. Tracking numbers preserve in ShipHead.BOLNumber or ShipDtlTracking. We flag carrier accounts requiring reconnection in Epicor's Shipping transaction configuration.
Shipedge
Return
Epicor Prophet 21
RMA and RMADtl
1:1Shipedge Return Authorizations (RA number, reason codes, disposition) map to Epicor RMA and RMADtl records. Shipedge return reasons (defective, wrong item, changed mind) map to Epicor ReasonCode values that the customer configures before migration. Disposition codes (restock, dispose, repair) map to RMADtl.ReturnChargeType. We flag any disposition mapping that requires Epicor warehouse receiving workflow reconfiguration.
Shipedge
Warehouse
Epicor Prophet 21
Plant and Warehouse
1:1Shipedge warehouse records (site name, address, operating hours, carrier accounts) map to Epicor Plant and Warehouse entities. Shipedge's carrier rate profile associations per warehouse require Epicor ShipVia configuration per Plant. Multi-warehouse Shipedge accounts (common for 3PL clients) map to multiple Epicor Plant records if separate GL books are needed, or to multiple Warehouse records within a single Plant for shared inventory pools.
Shipedge
Batch
Epicor Prophet 21
JobHead and JobMtl
lossyShipedge batch fulfillment records (batch number, order count, SKU count, units, ship method) do not have a direct Epicor equivalent as batch records are specific to Shipedge's v11+ fulfillment workflow. We export batch metadata as a linked CSV file attached to the relevant OrderHed records and note that Epicor's Job (work order) or MPS scheduling replaces batch-level reporting in Epicor.
Shipedge
User
Epicor Prophet 21
User account
1:1Shipedge user accounts (name, email, role, warehouse assignment) map to Epicor User records. We export user name, email, and role for manual provisioning in Epicor. Authentication credentials cannot transfer; all users must be provisioned fresh in Epicor Identity with appropriate Plant and Warehouse security assignments configured by the customer's admin.
Shipedge
Order Rules
Epicor Prophet 21
Data directives and BPMs
lossyShipedge Order Rules (automated routing logic: warehouse selection, carrier assignment, split-order conditions) are Shipedge-specific workflow configurations stored in a proprietary format with no documented export mechanism. We flag all active Order Rules during discovery and deliver a written inventory with Epicor equivalent recommendations using Epicor Data directives (record-change rules) and BPMs (method-override logic). Rule recreation is a 1-3 day manual exercise depending on complexity and is outside the standard migration scope.
| Shipedge | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Customer | Customer and ShipTo1:many | Fully supported | |
| Order | OrderHed and OrderDtl1:1 | Fully supported | |
| Product | Part1:1 | Fully supported | |
| Inventory | PartBin and PartWhse1:many | Fully supported | |
| Kit | Part and BOM (bill of materials)lossy | Fully supported | |
| Supplier | Supplier and SupplierPP1:1 | Fully supported | |
| Shipment | ShipHead and ShipDtl1:1 | Fully supported | |
| Return | RMA and RMADtl1:1 | Fully supported | |
| Warehouse | Plant and Warehouse1:1 | Fully supported | |
| Batch | JobHead and JobMtllossy | Fully supported | |
| User | User account1:1 | Fully supported | |
| Order Rules | Data directives and BPMslossy | Mapping required |
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.
Shipedge gotchas
Order Rules do not transfer between platforms
Integration credentials require manual reconnection
Custom pricing obscures true cost of migration
Buggy software can corrupt order state during migration
Insufficient reporting for inventory lot tracking
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 Epicor edition assessment
We audit Shipedge across orders, products, inventory, suppliers, customers, shipments, returns, active Order Rules, channel integrations, and user accounts. We pair this with an Epicor ERP edition assessment (Essential for basic distribution, Advanced for standard manufacturing, Premium for configure-to-order and advanced planning) and module inventory (Financials, Distribution, Manufacturing, Supply Chain Management). The discovery output is a written migration scope document with record counts, a recommended Epicor edition and module set, and a preliminary object mapping matrix.
Part schema design and UDF definition
We design the Epicor Part master schema before any data extraction. This includes Part.TypeCode assignments (Stocked, Make-to-Order, Service, Misc, Phantom), unit of measure set configuration (each Part's UOM conversions must match Shipedge's product variant units), stocking type decisions (lot, serial, dimension tracking), and BOM structure for any kitting configurations identified in Shipedge. UDFs for Shipedge custom properties are defined on the relevant Epicor tables (OrderHed, OrderDtl, Part, Supplier) with data type and length confirmed against the Shipedge source values. Schema is deployed into an Epicor test environment first.
Epicor test environment migration and reconciliation
We run a full migration into the Epicor test environment using production-like data volume. The customer's operations lead reconciles record counts (Parts in, Customers in, Orders in, Inventory levels in), spot-checks 25-50 random records against the Shipedge source, and signs off the Part schema and mapping before production migration begins. Any Part type misclassifications, UDF mismatches, or BOM structure errors are corrected in this phase. Epicor requires Data directives and BPMs to be configured and tested in the test environment before production deployment.
Supplier and customer master migration
We migrate Shipedge Supplier and Customer records first because they are prerequisite lookups for OrderHed (Customer and ShipTo references) and Part (Supplier references on SupplierPP). Suppliers map to Epicor Supplier records with default payment terms; Customers map to Epicor Customer and ShipTo records. Carrier and ship-via values from Shipedge are mapped to Epicor ShipVia codes during this phase. Any unmapped carrier values are flagged for Epicor ShipVia configuration before order migration.
Product and inventory migration
We migrate Shipedge Products to Epicor Part records using the pre-designed Part schema from Phase 2. Part stocking types, UOM sets, and BOM structures are applied per-part during the transform. Inventory quantities from each Shipedge warehouse are loaded into Epicor PartWhse (per-warehouse) and PartBin (per-bin) records. Lot numbers and bin locations are preserved where present in Shipedge. Any inventory locations in Shipedge without a corresponding Epicor bin are created during import or flagged for the customer's warehouse admin to assign.
Order, shipment, and return migration
We migrate Shipedge Orders (OrderHed and OrderDtl), Shipments (ShipHead and ShipDtl), and Returns (RMA and RMADtl) in that dependency order. OrderHed references Customer and ShipTo records resolved in Phase 4; OrderDtl references Part records resolved in Phase 5. Shipment tracking numbers and carrier service levels are mapped to Epicor ShipVia codes. Return dispositions are mapped to Epicor ReasonCode values. Historical orders (older than the retention period defined in Phase 1) are excluded from active migration and noted in the archive documentation.
Cutover, validation, and Order Rule handoff
We freeze Shipedge 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 Order Rules inventory document (with Epicor Data directive and BPM equivalents) and the channel integration reconnection checklist to the customer's admin team. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's operations team. Order Rules, channel OAuth reconnection, and Epicor Data directive/BPM rebuild are outside the standard migration scope and are handled by the customer's Epicor functional consultant or implementation partner.
Platform deep dives
Shipedge
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 3 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Shipedge and Epicor Prophet 21.
Object compatibility
3 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
Shipedge: Not publicly documented.
Data volume sensitivity
Shipedge 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 Shipedge to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your Shipedge 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 Shipedge
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.