Migrate from Prowess ERP to Epicor Prophet 21

Prowess ERP's Chart of Accounts (account codes and descriptions) maps directly to Epicor GL Account records. We preserve the Prowess account code as the GL Account number and the Prowess description as the GL Account description. Prowess Cost Centre codes map to Epicor GL Segment values or reporting dimension codes depending on the customer's Epicor chart design. We extract the Cost Centre hierarchy at scoping time and design the GL Segment structure before import so that balance reporting remains intact after cutover.

Prowess Cost Centres are implementation-specific hierarchies that have no canonical Epicor equivalent. We extract the full Cost Centre schema from the Prowess database at scoping, then map each Cost Centre to either a GL Segment value or a reporting dimension code in Epicor depending on how the Epicor GL has been configured. Any Cost Centre without a destination mapping is flagged in the scoping report for the customer and their Epicor consultant to resolve before import.

Prowess Customer records map to Epicor Customer (custpart, payment terms, credit limit) and ShipTo (address, contact). GST registration details from Prowess migrate as UD fields on Customer. We use Prowess customer code as the Epicor Customer ID for dedupe key integrity. Multiple Prowess ship-to addresses per customer become multiple Epicor ShipTo records linked to the same Customer.

Prowess Vendor records map to Epicor Supplier (vendor code, payment terms, tax ID) and SupplierPerson (contact details). GST/Tax registration details preserve as UD fields on Supplier. We use Prowess vendor code as the Epicor Supplier ID. Vendor-specific credit limits require manual confirmation with the customer's Epicor consultant post-import because Epicor enforces a different credit-limit model than Prowess.

Prowess Item masters map to Epicor Part records with standard fields (number, description, type, class, uom) transferred 1:1. Manufacturing-specific attributes — BOM structures, work centre assignments, and uom conversions — vary by Prowess implementation and require field-level mapping for each attribute. We flag BOM and routing associations as custom dependencies in the reconciliation report; the customer's Epicor consultant rebuilds BOMs in Epicor's Engineering Workbench post-migration. BOM structures do not migrate as code because BOM modelling is implementation-specific.

Outstanding payables in Prowess ERP map to Epicor AP Invoice records with current balance, due date, and vendor reference preserved. We extract open invoice status, allocation details, and partial payment history from Prowess and map them to Epicor's AP Invoice and AP Payment application model. AP invoices require manual balance confirmation against the Prowess open-balance report before Epicor go-live because AP balance integrity affects vendor payment runs.

Outstanding receivables in Prowess ERP map to Epicor AR Invoice records with customer, amount, due date, and invoice reference preserved. We extract open AR balance, allocation status, and credit memo history from Prowess and map them to Epicor's AR Invoice and AR Payment model. AR invoices require open-balance validation against the Prowess AR aging report before cutover; any discrepancy over $100 per customer is flagged for manual resolution.

Prowess Purchase Order headers and lines transfer to Epicor PO Header and PO Release records. PO status flags (Open, Closed, Cancelled, Partially Received) map to Epicor PO status values. Where Prowess uses custom workflow states not present in Epicor's PO status list, we map to the nearest Epicor equivalent and flag each record in the import log for the customer's review. Line items (part number, quantity, unit cost, due date) transfer with standard field mapping; any custom Prowess line properties become UD fields on PO Release.

Prowess Sales Order headers and lines migrate to Epicor OrderHed and OrderDtl. Pricing, discounts, and fulfilment status transfer with standard fields. Back-ordered lines are flagged separately in the import report because Epicor handles backorder allocation through its own allocation engine rather than a fixed status flag. Custom fields added by the Prowess implementing partner require field-level mapping; we pre-create UD fields in Epicor before import so that custom data is not silently dropped.

Prowess Work Orders map to Epicor Job records with header and line structure preserved. BOM links and routing data from Prowess migrate as Epicor JobMtl (material) and JobOper (operation) records. We resolve Part numbers to Epicor Part records and Operation numbers to Epicor Workstations at migration time. Prowess work order sequencing maps to Epicor Job Priority. Any Prowess work order with an unresolved Part reference is held in the reconciliation queue until the customer's Epicor consultant creates the Part record in Epicor.

Owner and user assignments in Prowess ERP use internal numeric IDs that differ by implementation. We resolve owners and users by email address match against the Epicor destination User table. Any Prowess user assignment without a matching Epicor User goes to the reconciliation queue for the customer's admin to provision before record import resumes. User provisioning is a prerequisite step because OwnerId is required on most Epicor transactional records.

Custom fields created during Prowess implementation are fully implementation-specific with no canonical schema reference. We run a full schema inventory against the customer's live Prowess database at the start of every engagement, extract every custom field with its data type and table assignment, then pre-create matching UD fields in Epicor using the ZDataTable metadata layer before any data import. This step prevents silent data loss for any custom property the customer relies on for reporting or compliance.

Binary document attachments stored in Prowess ERP's file system or blob storage are not accessible via a documented public API. Epicor's document attachments (stored via EDMS or file system integration) similarly require a separate file-level migration process. We do not migrate binary attachments as part of the data migration scope. We deliver a written file-level migration plan that uses the implementing partner's Prowess file export to extract attachments, which the customer's admin then imports into Epicor's document management system.