ERP migration
Field-level mapping, validation, and rollback between WinMan ERP and Epicor Prophet 21. We move data and schema; workflows are rebuilt natively in Epicor Prophet 21.
WinMan ERP
Source
Epicor Prophet 21
Destination
Compatibility
12 of 13
objects map 1:1 between WinMan ERP and Epicor Prophet 21.
Complexity
BStandard
Timeline
8-12 weeks
Overview
Moving from WinMan ERP to Epicor ERP is a structural migration for manufacturing shops that need deeper production management, broader HR coverage, and a larger partner ecosystem. WinMan's product configurator with feature/option matrices does not map directly to Epicor's Part and BOM structure — we decompose configured products into their component BOM lines and link them explicitly in Epicor so the parent-child relationship survives the move. Work Orders with routing steps, labour allocations, and work-centre assignments require field-level mapping; WinMan's work order structure varies by manufacturing mode (job, batch, or flow), and we handle each variant separately. Batch and serial traceability graphs export from WinMan and reload into Epicor's lot and serial number registers so recall and compliance reporting remain intact post-migration. Open and current transactions migrate last, near go-live, to prevent the dual-entry window where both systems receive live orders simultaneously. We do not migrate workflows, automations, or ERP-native integrations; we deliver a written inventory of these for the customer's admin team 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 WinMan ERP 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.
WinMan ERP
Chart of Accounts
Epicor Prophet 21
GL Account
1:1WinMan maintains a fully integrated financial module with chart of accounts, journal entries, and AP/AR. Accounts map 1:1 using WinMan account codes to Epicor GL Account numbers. We preserve cost-centre assignments where multi-entity structures exist by mapping WinMan site-specific accounts to Epicor GL Account segments. Any intercompany elimination accounts require manual Epicor configuration post-migration.
WinMan ERP
Item
Epicor Prophet 21
Part
1:1WinMan Items map to Epicor Part records. WinMan's item type classification (Stocked, Non-Stocked, Service, Labour) maps directly to Epicor Part Type. The WinMan Item Code becomes Epicor Part Number; the description maps to Part Description. Stock UOM, Purchasing UOM, and Sales UOM from WinMan map to Epicor UOMClass and UOM records, requiring a UOM conversion table where they differ.
WinMan ERP
Bill of Materials (Multi-level)
Epicor Prophet 21
Part Bill of Materials
1:1WinMan multi-level BOMs map to Epicor Part BOM records with parent Part linked to child Part via BOM lines. We preserve the full BOM hierarchy (WinMan allows up to 99 levels) by performing a recursive export from WinMan and loading into Epicor's BOM Master with the correct BOM Level and Sequence. Operation numbers, work centres, and scrap percentages from WinMan map to Epicor JobMtl and JobOper records during Work Order creation.
WinMan ERP
Configured Product
Epicor Prophet 21
Part + Part BOM (decomposed)
1:manyWinMan's product configurator allows complex feature/option matrices with rules and dependencies that do not have a direct Epicor equivalent. We decompose each configured product into its component BOM lines in WinMan, map the parent configured item to an Epicor Part record, and create child BOM lines for each option. The parent-child linkage is preserved through explicit BOM reference rather than relying on a single exported configuration string. The customer's Epicor admin rebuilds the configure-to-order rules in Epicor's CPQ or Product Configurator module post-migration using the WinMan feature/option export as a reference.
WinMan ERP
Customer
Epicor Prophet 21
Customer
1:1WinMan Customer records map to Epicor Customer including addresses, contact details, and credit terms. Customer-to-site mappings from WinMan become Epicor ShipTo records attached to the Customer. Multi-currency assignments migrate to Epicor Currency and Exchange Rate records. We use WinMan Customer Code as the dedupe key during import.
WinMan ERP
Vendor
Epicor Prophet 21
Supplier
1:1WinMan Vendor records map to Epicor Supplier with purchasing terms, lead times, and vendor part numbers preserved. Vendor addresses migrate as SupplierShipTo records. Any consignment or subcontract vendor setups require manual Epicor configuration post-migration.
WinMan ERP
Sales Order
Epicor Prophet 21
Sales Order
1:1Open and historical Sales Orders migrate to Epicor OrderHed (header) and OrderDtl (detail) records. WinMan order status maps to Epicor OrderHed.OrderStatus. WinMan guidance specifies that live orders migrate last; we handle this by exporting a snapshot of open orders immediately before cutover, then replaying any delta transactions that occurred during final testing. Order lines referencing configured products use the decomposed BOM linkage from the configured product mapping step.
WinMan ERP
Purchase Order
Epicor Prophet 21
PO Header / PO Detail
1:1WinMan Purchase Orders and associated goods-received notes export to Epicor POHeader and PODetail records. Where purchase orders reference WinMan configured BOMs or multi-level BOMs, we preserve the item-link relationship during migration by resolving WinMan BOM references to Epicor Part BOM records at migration time. Purchase order status in WinMan (Open, Released, Closed) maps to Epicor POHeader.POStatus.
WinMan ERP
Work Order
Epicor Prophet 21
Job Entry
1:1WinMan Work Orders with routing steps, labour allocations, and work-centre assignments require field-level mapping to Epicor JobMtl (material) and JobOper (operation) records. WinMan's work order structure varies by manufacturing mode (job, batch, or flow), and we handle each variant separately. Estimated labour hours, work-centre codes, and operation sequences from WinMan map to Epicor JobOper with the correct Work Centre reference and cycle times. Released, complete, and closed statuses from WinMan map to Epicor JobHead.JobReleased, JobHead.JobComplete, and JobHead.JobClosed.
WinMan ERP
Inventory / Stock
Epicor Prophet 21
PartBin (on-hand quantity)
1:1WinMan current stock levels, bin locations, and batch/serial numbers export to Epicor PartBin records. WinMan's WMS integration means stock records include warehouse-zone assignments that map explicitly to Epicor Warehse and Bin records. Batch and serial numbers migrate to Epicor PartLot and PartNumLotTrak records respectively, preserving the traceability graph linking incoming materials to finished goods. Multiple WinMan sites map to multiple Epicor warehouse records with separate PartBin entries.
WinMan ERP
Batch and Serial Traceability Records
Epicor Prophet 21
PartLot / PartTrace
1:1WinMan batch/serial traceability links between incoming materials and finished goods require careful sequencing to preserve the graph in Epicor. We export WinMan traceability records as a linked set (lot number, source document, material used, finished goods produced) and load into Epicor PartLot with LotNbr, LotDescription, and the PartTran records that represent each movement. Post-migration recall and compliance reporting rely on this graph being intact.
WinMan ERP
Custom Fields
Epicor Prophet 21
UD Fields (User-Defined)
1:1WinMan user-defined fields on standard objects export with their definitions and values. Epicor supports UD fields on Part, OrderHed, OrderDtl, JobHead, JobMtl, and other standard tables. We extract WinMan custom field definitions, map their values to equivalent Epicor UD columns, and flag any custom fields with no Epicor equivalent for manual entry or custom Epicor extension (BPM or customization) post-migration.
WinMan ERP
User and Roles
Epicor Prophet 21
User and Security
1:1WinMan user accounts with role-based permissions export by email and mapped to Epicor User records. Role definitions vary between ERP systems; we map WinMan roles to the closest Epicor equivalent (Plant, Production, Sales, Engineering, etc.) and flag any security differences that require manual configuration in Epicor Employee and UserAccount tables. Inactive WinMan users can be migrated as inactive Epicor users for historical reference.
| WinMan ERP | Epicor Prophet 21 | Compatibility | |
|---|---|---|---|
| Chart of Accounts | GL Account1:1 | Fully supported | |
| Item | Part1:1 | Fully supported | |
| Bill of Materials (Multi-level) | Part Bill of Materials1:1 | Fully supported | |
| Configured Product | Part + Part BOM (decomposed)1:many | Fully supported | |
| Customer | Customer1:1 | Fully supported | |
| Vendor | Supplier1:1 | Fully supported | |
| Sales Order | Sales Order1:1 | Fully supported | |
| Purchase Order | PO Header / PO Detail1:1 | Fully supported | |
| Work Order | Job Entry1:1 | Fully supported | |
| Inventory / Stock | PartBin (on-hand quantity)1:1 | Fully supported | |
| Batch and Serial Traceability Records | PartLot / PartTrace1:1 | Mapping required | |
| Custom Fields | UD Fields (User-Defined)1:1 | Mapping required | |
| User and Roles | User and Security1:1 | 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.
WinMan ERP gotchas
Open transactions migrated last creates dual-entry window
Per-feature pricing model means new modules cost extra
Product data cleanup is required before migration
Configured products and multi-level BOMs require schema mapping
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 WinMan version audit
We audit the source WinMan ERP instance across installed modules, version, licensed features, and custom field definitions. We identify the available export mechanism (REST API, direct database read, or staged flat-file extraction) by engaging WinMan directly. We inventory the product catalogue including configured products and multi-level BOM depth, open order volumes by type (Sales, Purchase, Work), and any batch/serial traceability records. We also capture the WinMan chart of accounts structure and multi-currency setup. The discovery output is a written migration scope document with a data-cleanup checklist and a WinMan-to-Epicor object mapping draft.
Epicor schema preparation and DMT configuration
We provision the Epicor destination environment (typically in a sandbox first) including Part records (with UOMClass), Part BOM, Customer, Supplier, and GL Account structures. We configure Epicor UD fields to match WinMan custom field definitions, and write BPM scripts or DMT transformation rules to populate them during load. For configured products, we create placeholder Epicor Part records and BOM lines for the decomposed component structure, leaving the CPQ rule rebuild as an explicit post-migration task. We coordinate with the customer's Epicor admin to grant the migration user appropriate roles and disable validation rules that would block bulk inserts during the migration window.
Data cleanup phase
We run a data-quality pass on WinMan export data before loading into Epicor. This includes identifying and merging duplicate Customer records, deduplicating Item records on part number, removing inactive items and vendors, standardising product categorisation, and flagging any Customer or Item records with missing required fields. The customer reviews and approves the cleanup decisions before we proceed to load. This phase typically runs two to three weeks in parallel with Epicor configuration and prevents the common ERP migration failure of importing bad data into the new system.
Sandbox migration and reconciliation
We run a full migration into the Epicor sandbox using production-like data volumes. The customer's manufacturing and finance leads reconcile record counts (Parts in, Customers in, BOM levels in, Orders in, Work Orders in, on-hand quantities in, batch records in), spot-check twenty-five to fifty random records against the WinMan source, and verify that BOM roll-up calculations produce expected costs in Epicor. Any mapping corrections, UOM conversion issues, or BOM decomposition errors surface here before production migration begins. We do not touch production data until this sandbox pass is signed off.
Production migration in dependency order
We run the production migration in record-dependency order: GL Accounts (static), Parts and Part BOMs (with BOM levels resolved top-down), Customers and Suppliers, open Sales Orders and Purchase Orders (last among orders, per WinMan guidance), Work Orders, and inventory on-hand quantities. Batch and serial traceability records load last, after PartBin is populated, to ensure that lot numbers exist in Epicor before traceability links are written. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, delta capture, and post-migration handoff
We freeze WinMan writes during cutover, run a final delta migration of any records created or modified during the migration window, then enable Epicor as the system of record. We deliver a written inventory of WinMan workflows, automations, and native integrations that require rebuild in Epicor — this is an admin rebuild task outside our standard scope. We include the decomposed configured-product documentation and a reference export of WinMan feature/option matrices to guide the customer's Epicor CPQ rebuild. We support a one-week hypercare window to resolve post-migration data reconciliation issues raised by the manufacturing and finance teams.
Platform deep dives
WinMan ERP
Source
Strengths
Weaknesses
Epicor Prophet 21
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 2 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 WinMan ERP and Epicor Prophet 21.
Object compatibility
2 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
WinMan ERP: Not publicly documented.
Data volume sensitivity
WinMan ERP 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 WinMan ERP to Epicor Prophet 21 migration scoping. Not seeing yours? Book a call.
Walk through your WinMan ERP 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 WinMan ERP
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.