Migrate from Base ERP to Epicor Prophet 21

Base ERP Products (Offers) carry SKU, name, description, images, and dimensions. We map sku to PartNum, Name to PartDescription, and the product description to the Part's search and marketing text fields. Weight and dimension fields map to Part's UOMClass and the PartWhse on-hand tracking. Large catalogs are chunked into batches of 500-1,000 parts and loaded via Epicor's REST or OData API with part revision control initialized at RevType = new/main. Custom product fields from Base ERP migrate to UD fields on the Part table.

Base ERP real-time stock quantities per Warehouse per Product map to Epicor PartWhse records. We resolve each Base ERP Warehouse to an Epicor WarehouseCode, then create one PartWhse row per Part-Warehouse combination with OnHandQty set to the Base ERP stock snapshot taken at migration start time. Bin locations in Base ERP map to PartBin if the customer uses bin tracking; otherwise stock lands at the warehouse level.

Base ERP Warehouses map directly to Epicor Warehse records with WarehouseCode and Name preserved. Multiple warehouses are supported in both platforms but Base ERP naming conventions vary widely between accounts; we run a pre-migration audit, standardize warehouse names to alphanumeric codes compatible with Epicor's schema, and map the full Warehouse list so that each source location resolves to a target location entity.

Base ERP Orders carry customer details, line items, shipping address, payment method, and fulfillment status. We map OrderHed fields (CustomerNum, ShipToNum, OrderDate, DueDate) and create OrderDtl rows per line item linking to the PartNum resolved from the source product catalog. Completed orders include fulfillment tracking fields that map to OrderRel for ship detail. We export open and historical orders; completed orders preserve their historical status.

Base ERP pricing rules defined per marketplace channel or quantity tier require translation into Epicor's PriceLbr (labor pricing) and PricePerBreak (quantity breaks) tables. The flat key-value pricing export from Base ERP may need expansion into per-channel price lists; we create Epicor Price Lists (PartPlant pricing) and link them to the relevant Customer or Customer Group. Quantity-tier pricing becomes PricePerBreak records on the Part.

Base ERP marketplace connector profiles store channel-specific listing IDs and account credentials for eBay, Amazon, Allegro, and regional channels. These credentials cannot be exported via standard API or CSV. We export the connector configuration (channel type, listing IDs, sync rules) as a written document, map the source channel-to-offer relationships to a channel-reconnection checklist, and note that the customer's team must manually re-enter credentials in their e-commerce integration layer post-migration.

Base ERP allows user-defined additional fields per product (custom dimensions, certifications, seasonal flags) exported as extra columns. We map these to Epicor Part UD fields using the UD Column Map approach documented in Epicor user forums. Field types are inferred from Base ERP export column types (text, number, date, boolean) and cast to the nearest Epicor UD data type. Type mismatches are flagged for manual review before import.

Base ERP user accounts carry roles (Admin, Operator, Warehouse Manager). We map Users to Epicor Employee records and preserve role assignments as a custom field (UserRole__c) since Epicor's security model uses the Employee table with RoleCode assignments rather than a separate user object. Any Base ERP Owner without a matching Epicor Employee goes to a reconciliation queue for manual provisioning.

Base ERP does not have a native invoice generation module; invoicing is handled by an external accounting tool integrated via BaseLinker. We do not migrate invoice records. Customers should export invoices from their external accounting platform separately if invoice history is required in Epicor; invoice data can be imported into Epicor's AR Invoice entry post-migration as a separate data load.

Base ERP does not natively support Bills of Materials or production routings. If the customer uses third-party manufacturing add-ons or manual BOM records stored in custom fields, we extract them as part of the custom field audit and map them to Epicor JobMtl (material requirements) and JobOper (operations/routings). If no BOM data exists in Base ERP, this object is omitted from migration scope and Epicor's BOM entry is handled by the customer's engineering team post-migration.

Base ERP's Inventory Control module is explicitly in public beta with a schema that may change without notice. We run a pre-migration audit of any records stored in this module. If the module has reached general availability by migration time, we include the data in PartWhse migration under a versioned schema snapshot. If it remains in beta, we flag the records, extract them under a timestamped schema snapshot, and store them in a staging table for the customer to evaluate post-migration.

Base ERP accounts accumulate duplicate product entries over years of use—variants with slightly different spellings, formatting, or abandoned test listings. The CSV export does not deduplicate these. We run a pre-migration similarity analysis on product names and SKUs using Levenshtein distance matching, surface duplicates for customer review, and either merge them (consolidating to a single Part with multiple customer IDs) or archive the inactive duplicates before transfer so the Epicor parts master stays clean.