Migrate from Everwin to Epicor Prophet 21

Everwin Customer records map to Epicor ERP Customer table, which is linked to a Party record representing the natural person or organization. The Everwin Customer primary key maps to Epicor Customer.CustNum, and the corresponding Party.PartyID is resolved by matching the customer's email or name. Payment terms, credit limits, and the primary contact's email and phone migrate to Customer-level fields. Address data splits into Epicor's separate Address table with a CompanyAddr or ShipTo relationship.

Everwin Vendor records map to Epicor ERP Supplier table with an analogous Party relationship. Vendor payment terms, bank details, and the primary contact's email migrate to Supplier-level fields. The same name-matching and Party resolution logic used for Customer records applies. Vendors without a resolved Party record go to a reconciliation queue for manual resolution before Supplier import.

Everwin User accounts with roles and permissions map to Epicor ERP User records, with role assignments translated to Epicor Security Role grants. If Everwin user records include employee attributes (department, manager, hire date), those migrate to Epicor Employee. Epicor Cloud requires User provisioning through its identity management layer; we export the Everwin user list, resolve by email match against the target Epicor tenant, and flag any users without a matching Epicor account for admin provisioning before record migration.

Everwin Item records map to Epicor ERP Part master with SKU as PartNumber, description as PartDescription, and unit cost as StandardCost. Everwin custom Item attributes migrate to Epicor UD Fields on Part. Unit of measure (UOM) from Everwin maps to Epicor's UOMClass and UOM structures. If Everwin uses multi-site inventory, PartPlant records are created per site with site-specific quantities and reorder points.

Everwin Project records migrate to Epicor ERP Project with ProjectCode, Description, and Phase-level structure. Everwin custom Project fields require UD table extension in Epicor because Epicor's native Project does not expose a generic custom field surface for all attributes. We pre-create the UD table and UD fields to match the Everwin custom field schema during schema design, then map values during the Project import. Project status workflows require manual configuration in Epicor Project Maintenance post-migration.

Open Everwin AP and AR records migrate as live Epicor ERP AP Invoice and AR Invoice records. Fully paid historical transactions migrate as read-only GL Journal entry records with a 'Migrated Historical' source flag. The distinction is made using Everwin's payment status field. GL account assignments from Everwin invoice lines map through the Chart of Accounts reconciliation matrix. Historical journal entries are not reactivated as open invoices because Epicor's AR/AP modules do not support re-opening fully settled records.

Everwin's Chart of Accounts requires a full account code mapping matrix before Epicor load. We export the Everwin account structure (account code, name, type, parent) and present a reconciliation matrix to the customer for account code mapping to Epicor's GL Account segment structure. Active historical GL balances (year-to-date and prior period) load as Epicor GL Journal entries with a migration source flag, establishing opening balances. Accounts with no Epicor mapping destination are flagged for customer decision before load.

Everwin tax codes are tied to jurisdiction and must map to Epicor ERP's Tax Service configuration. We export the Everwin tax code set with applicable rate, jurisdiction type, and description, then build a mapping table referencing the destination Epicor company's tax configuration. EU VAT codes require mapping to Epicor Tax Service tax codes with the correct tax regime. Tax code mapping is validated against Epicor's Tax Service before production load to avoid rate mismatches on AP and AR transactions.

Everwin custom objects vary by installation with no standard public schema. We introspect the Everwin v3 API schema at scoping time to enumerate all custom object definitions and their field types, then pre-create equivalent Epicor UD Tables with matching UD Fields during schema design. Lookup relationships between custom objects map to Epicor UD KeyField references. Any UD table that references standard Epicor entities (Customer, Supplier, Part) must have the parent record loaded before the custom object import. Custom object migration is scoped last in the migration sequence because of these interdependencies.

Everwin document attachments are binary blobs linked to parent entities (Customer, Project, Transaction). We export documents with their parent reference, filename, and metadata, then load them into Epicor ERP's Document Management (DMS) system attached to the equivalent parent record. Binary format and file size vary by Everwin installation; large binary files may require batch chunking during upload. Documents without a resolvable parent record in Epicor are archived to a dedicated migration folder for manual attachment post-migration.

Everwin Owner references on transactional records (Customer, Project, Transaction) are resolved by email match against the Epicor User table. Any Owner without a matching Epicor User record is held in a reconciliation queue pending admin provisioning. This step is a prerequisite for transactional record migration because Epicor requires a valid OwnerId reference on most transaction types.

Open sales orders and purchase orders in Everwin migrate to Epicor ERP OrderHed and POHeader records with corresponding line items. Order and PO status (open, on-hold, closed) is preserved. The Everwin customer and vendor lookups on order headers resolve to Epicor Customer.CustNum and Supplier.SupplierNum via the Party resolution step. Any Everwin order with an unresolved Customer or Vendor reference is flagged in the reconciliation report before order import begins.