Migrate from Lead Commerce to Epicor Prophet 21

Discovery and export method assessment

We audit the Lead Commerce account for record volumes across Orders (open vs fulfilled), Inventory Items (per SKU and per warehouse), Warehouse Locations, Customers, Purchase Orders, and Suppliers. We assess the available export mechanism — CSV from within the application where available, or authorized database query for bulk extraction. We document any custom app data and flag any reporting snapshots that the customer must export manually before the cutoff. The discovery output is a written migration scope with record counts per object, the confirmed export method, and a data quality pre-assessment identifying duplicates, zero-quantity items, and orphaned foreign keys.

Destination schema design in Epicor

We design the Epicor destination schema based on the customer's target configuration (single plant vs multi-plant, lot tracking vs. standard inventory, and whether manufacturing modules are in scope). This includes configuring Plant and Warehouse records, creating Part records with PartWhse assignments, defining the Customer and Supplier hierarchies, and designing the Sales Order and Purchase Order type codes and status workflows. We deploy the base schema into the Epicor environment before any data migration begins. Any custom fields required for Lead Commerce data that does not map directly to a standard Epicor field are added at this stage.

Data profiling and cleansing

We run a data profiling pass against the extracted Lead Commerce data before loading into Epicor. This includes deduplicating customers by email, resolving supplier names to a canonical list, flagging inventory items with zero or negative quantities, normalizing SKU formats, and identifying any orders with missing customer or item references. The profiling report goes to the customer for review and sign-off. No data loads into Epicor until the customer approves the quality report. This step is where Lead Commerce's SMB-era data issues are surfaced and resolved before they can cause Epicor import rejections.

Warehouse and location setup

We configure Epicor Plant and Warehouse records to match the Lead Commerce warehouse structure. Each Lead Commerce warehouse location maps to an Epicor Plant or PlantWarehouse record. If Lead Commerce tracks bin-level locations within a warehouse, we configure the corresponding bin records in Epicor's warehouse management module. Warehouse configuration must be complete and validated in Epicor before any Part or inventory transaction records insert, because PartWhse records depend on a valid WarehouseCode.

Parent record migration — Parts, Customers, Suppliers

We migrate the master data layer in dependency order: Parts first (with PartWhse records per warehouse), then Customers, then Suppliers. Part insert validates PartNum uniqueness and creates PartPlant records for each active site. Customer insert uses the customer email as the dedupe key and resolves any duplicate entries flagged in profiling. Supplier insert runs after Customer because Purchase Orders reference Suppliers. Each phase emits a row-count reconciliation report and a spot-check comparison against the source data before the next phase begins.

Transactional migration — Purchase Orders and Sales Orders

We migrate Purchase Orders (open and closed) into Epicor POHeader and PODetail, resolving Supplier Num from the Supplier mapping. We then migrate Sales Orders — fulfilled orders insert as completed SalesOrders with shipped OrderRel records; open orders insert as Held or Pending status per the customer's Epicor workflow configuration. Order lines map PartNum to the Part records loaded in the prior phase. We separate fulfilled from open orders so that Epicor's inventory impact is correct and historical reporting reflects completed transactions accurately.

Inventory transaction reconstruction and cutover

We reconstruct implied inventory transactions from fulfilled order data — for each shipped order line in Lead Commerce, we generate a corresponding Epicor PartTran record with TranType of SHIP and the correct warehouse and quantity. This runs after Part, PartWhse, and SalesOrder are confirmed loaded. We then run the cutover delta export: any Lead Commerce records modified between the penultimate export and the go-live date are captured, profiled, and loaded into Epicor. We freeze Lead Commerce writes at cutover, run the final delta, and validate the Epicor record counts against the source totals before declaring the migration complete.

Inventory and handoff

We deliver a final reconciliation report comparing Epicor record counts to the approved Lead Commerce source totals for every object migrated. We deliver a written inventory of Lead Commerce Custom Apps (data only, with schema documentation) and a written inventory of Lead Commerce saved reports for the customer to export manually. We do not rebuild Lead Commerce custom app logic, workflows, or reports as part of the migration scope — those are documented separately for the customer's team or an Epicor consultant to rebuild post-migration. We support a one-week post-cutover reconciliation window to resolve any discrepancies reported by the customer's operations team.