Migrate from proALPHA ERP to Epicor Prophet 21

proALPHA treats Customers as Business Partner records with address, contact, classification, and payment term data. These map to Epicor Customer records with a shared Epicor Party record for the address book and contact information. We use the proALPHA partner number as the Epicor Customer ID and the partner name as the Party name. Credit limits, payment terms, and tax registration numbers transfer to Epicor Customer and TaxRegion tables. The Customer is created after the Party so that the PartyID foreign key is satisfied at insert.

proALPHA Vendor records map to Epicor Supplier records with a shared Epicor Party record, paralleling the Customer mapping. Vendor-specific fields including bank details, W-9/W-8 status, and 1099 categorization transfer to Epicor Supplier and PartVendor tables if the migration scope includes purchasing data. We deduplicate addresses that are shared between Customer and Vendor partners in proALPHA by creating a single Party record referenced by both Customer and Supplier in Epicor.

proALPHA Items with bill of materials, routings, and variant configurations decompose into Epicor Part (the base product master), PartPlant (site-specific inventory and costing data), and PartRev (revision and BOM structure). proALPHA's multi-level BOMs require tree flattening: we extract each BOM level from proALPHA and create Epicor PartMtl rows at the correct indent level, resolving the parent Part number and the material Part number at insert time. Variant configurations from proALPHA's product configurator map to Epicor Configurator tables including Part TPM. Standard cost, average cost, and last cost from proALPHA transfer to PartPlant for each site.

proALPHA's structured COA with cost center and department assignments maps directly to Epicor GL Account records. Account number, account description, account type, and posting key classification transfer cleanly. We verify account type mappings (Asset, Liability, Equity, Revenue, Expense) against Epicor's segment structure during import, flagging any accounts that use a posting key not present in the destination COA. Cost center assignments from proALPHA transfer to Epicor GL Account segments or department-level groupings depending on the customer's chosen account segment configuration.

proALPHA Work Orders and Production Orders contain operation sequences, work center assignments, material allocations, and backflush records tied to APS scheduling. We extract order status, material requirements, operation sequences, and backflush quantities and map them to Epicor JobMtl (material requirements), JobOper (operations), and PartTran (backflush transactions). proALPHA's scheduling constraints and APS bottleneck data do not transfer as APS metadata; they are noted in the migration documentation for the customer to reconfigure in Epicor's production scheduling module post-migration. Open versus closed status determines whether Job records are created as Planned, Firm, or Released.

Fixed asset records in proALPHA include acquisition cost, depreciation schedules, useful life, location assignments, and asset class. These map to Epicor Asset records with the depreciation method (straight-line, declining balance, units of production) preserved as a configuration field. Depreciation periods and accumulated depreciation amounts transfer to the Epicor AssetGlTrans table linked to the GL integration. We flag any Fixed Assets with proALPHA-specific depreciation conventions that Epicor cannot natively represent and document them as exceptions for the customer's financial team to validate before GL reconciliation.

Outstanding payables in proALPHA carry vendor reference, invoice number, invoice date, due date, payment terms, and partial payment allocations. We extract open AP items at a fixed cutover timestamp and map them to Epicor APInvoice header records with APTran detail lines. Prepayments and credit memos transfer as APInvoice records with negative amounts. Payment terms from proALPHA map to Epicor PaymentTerms, and vendor references map to the Supplier record created from the Vendor partner mapping. We flag any AP items with proALPHA-specific cost center or project assignments that require custom dimension mapping in Epicor.

Outstanding receivables in proALPHA carry customer reference, invoice number, invoice date, due date, payment terms, and partial allocations. We extract open AR items at the same cutover timestamp and map them to Epicor ARInvoice records with ARTran detail lines. Credit memos, debit memos, and prepaid invoices transfer as ARInvoice records with the appropriate docType. Customer references resolve to the Epicor Customer record created from the Customer partner mapping. We preserve the original proALPHA invoice number as a reference field on the Epicor ARInvoice for audit trail purposes.

Stock quantities, warehouse locations, and lot/serial numbers in proALPHA span multiple sites under its multi-location planning model. We extract PartBin equivalents (stock by part number and warehouse location) and map them to Epicor PartBin records, resolving the proALPHA site code to the Epicor Site and Warehouse codes in the destination company. Lot-controlled items migrate to Epicor Lot records with the original lot number, expiration date, and any lot attributes preserved. Serial number records migrate to PartLot with the serial number stored as lot number or as a separate SerialNumber table depending on Epicor configuration. Multi-site inventory in proALPHA creates separate PartBin rows per site in Epicor.

Historical journal entries and transaction records in proALPHA span multiple years and may use formats that changed across major version upgrades. We scope which fiscal years to migrate versus archive based on the customer's reporting requirements and the volume of historical records. proALPHA's own documentation acknowledges that legacy data must be evaluated for compatibility with the target platform; we perform this evaluation as part of the pre-migration data audit and flag records with deprecated values, orphaned references, or incompatible data types. GL journal lines migrate to Epicor GLJrnLine with fiscal period and year preserved; very old entries (typically more than five fiscal years) are recommended for archival rather than active migration.

proALPHA's integrated document management stores binary files linked to business objects including Customers, Vendors, Items, Work Orders, and Accounts. The documents themselves are not exported through standard data extraction. We extract document metadata (file name, description, link type, creation date, author) and map it to Epicor ERIDocRef external document references or as native Epicor attachments on the equivalent record (Customer, Supplier, Part, Job). The binary file transfer runs as a parallel bulk file operation to the Epicor document repository, with file paths preserved as external references or uploaded to the Epicor Kinetic file store depending on the customer's chosen document strategy.

proALPHA supports user-defined fields per module with naming conventions and data types defined per-customer during implementation, making every proALPHA schema instance unique for custom properties. We document every custom field encountered during the discovery scan, capture its data type and current values, and map each one to Epicor's User-Defined field layer (UD Fields on the equivalent Epicor table). For custom fields that have no Epicor equivalent table, we create a shadow UD table and document the relationship for the customer's admin to validate post-migration. The mapping of each custom field is stored in the migration field map delivered alongside the migrated data.