Migrate from Embrace ERP to Epicor Prophet 21

Embrace's Chart of Accounts structure maps directly to Epicor Kinetic's GL Account (COA) using the account code as the natural key and the account description as the account name. Embrace's cost-center dimension maps to Epicor's Department, Division, or Site segment depending on the customer's account structure. We extract the full account tree, identify any inactive accounts flagged in Embrace for deactivation, and configure the Epicor COA segment structure during initial Epicor setup before any transaction data lands.

Embrace's SARS-compliant tax codes (VAT, withholding tax, and any custom statutory rates) map to Epicor Kinetic's Tax Connect configuration. We extract all active tax codes with current effective rates and jurisdictions, then configure Tax Connect in Epicor with matching tax types, rates, and applicability rules. Note that Epicor Kinetic's Tax Connect supports multiple tax authorities per jurisdiction; any Embrace tax code with custom calculation rules (compound tax, reverse charge, or third-party withholding) is flagged for manual review during scoping.

Embrace customer master records map to Epicor Kinetic Customer records with billing address, ship-to address, contact details, and tax registration number preserved. We resolve the customer's payment terms from Embrace's terms code to Epicor's Terms master. Customer credit limits and hold status migrate as Customer Credit records. Multiple ship-to addresses per customer in Embrace become Epicor ShipTos attached to the same Customer record.

Embrace vendor master records map to Epicor Kinetic Supplier records. Supplier-specific fields including banking details (bank name, account number, SWIFT/BIC) and tax registration migrate to Epicor Supplier and Tax Registration records. Payment terms resolve from Embrace terms codes to Epicor Terms master. We flag any Embrace vendor marked as inactive for manual review before final import to avoid creating suppliers with zero open purchase orders.

Embrace inventory items map to Epicor Kinetic Part records with stock code as Part Number, description as Part Description, and costing method (standard, average, FIFO) preserved via the Epicor Costing Lot Select field. Warehouse locations from Embrace map to Epicor Warehse records within the Epicor Site. We extract reorder parameters (reorder point, safety stock, economic order quantity) and configure Epicor's MRP and planning settings to match the Embrace planning logic. Any Embrace item with a non-standard unit of measure (UOM) set requires Epicor UOMClass configuration before the item imports.

Embrace BOM hierarchies (multi-level, single-level, and phantom) map to Epicor Kinetic BOM and Method of Manufacture (MOM) records. We extract the full BOM tree from Embrace, identify the top-level manufactured part, and construct the Epicor BOM with the correct part revisions and bomrev records. Routing sequences from Embrace (work centers, operation sequences, standard times) map to Epicor JobMtl and JobOper records. Phantom BOMs in Embrace become Epicor Part master records flagged as Phantom. We rebuild BOMs in Epicor before any inventory or transaction data loads so that production orders can reference the BOM on day one.

Outstanding AP invoices in Embrace must be reconciled at migration cutover. We extract open AP items with full aging detail (invoice number, vendor reference, due date, amount, and any partial payment history) and load them into Epicor as AP Invoice records with status set to open. Any invoice with a partial payment applied in Embrace receives a corresponding AP Payment record in Epicor at cutover. We flag AP records with mismatched vendor account codes between Embrace and the Epicor Supplier master for manual resolution before import.

Outstanding AR invoices in Embrace migrate to Epicor Kinetic AR Invoice records with aging preserved. We extract open AR items (invoice number, customer reference, due date, amount, and any credit note offsets) and load them with status open. Any Embrace credit notes applied against an open invoice become Epicor AR Credit Memo records linked to the parent invoice. Customer balances are reconciled in Epicor AR before go-live; we flag any AR record with an unmatched Epicor Customer to avoid orphaning invoices against deleted customers.

Historical posted journals and batch details from Embrace can migrate to Epicor Kinetic GL Journal entries if the customer requires fiscal-year depth in the new system. We scope the required fiscal-year range with the customer during discovery and extract posted batches with full line-item detail. We do not migrate unposted transactions or any transaction type that has not been fully approved in Embrace. Epicor Kinetic stores historical journals in the GLJrnHed and GLJrnDtl tables; we load via Epicor's Journal Entry import with the original posting date, batch description, and source module preserved. Very large transaction histories (over 500,000 journal lines) may be scoped to the last two to three fiscal years with older history archived separately.

Documents linked to transactions or master records in Embrace's document management layer are extracted via the file export path identified during scoping. We extract what can be reached programmatically and organize the file set by record type (customer, vendor, part, order) for reattachment in Epicor's Document Management module or as external file references. Any Embrace document stored in a non-filesystem location (embedded in a custom database field) is flagged for manual retrieval. We do not migrate the document management configuration itself; the customer's admin rebuilds any folder structure, security, and retention rules in Epicor's Document Management settings.

Embrace user-defined fields on customer, vendor, part, and transaction records map to Epicor Kinetic UD fields (UD05 through UD99) using the equivalent data type (character, numeric, date, checkbox). We discover the complete custom-field schema during scoping by querying the Embrace database for non-standard column names on master and transaction tables. Any Embrace custom field with an unsupported data type (e.g., bespoke picklist values not matching an Epicor drop-down) is flagged for manual review before final import. Epicor UD fields are configured per table in Kinetic before any record import.

Embrace user accounts and role-based permissions map to Epicor Kinetic User records and Business Unit / Security Role assignments. We extract Embrace user definitions (username, display name, email, active/inactive status) and map each to an Epicor Kinetic User with the equivalent access level. Any Embrace permission set without a direct Epicor Kinetic equivalent is documented in the handoff report for the customer's Epicor admin to assign using Kinetic's security model (Company, Site, Warehouse, Business Unit scoping). Passwords do not migrate; the customer's admin resets credentials or uses SSO configuration post-migration.

Workflows defined in Embrace's native workflow engine or the iMBrace companion platform do not migrate as executable code to Epicor Kinetic BPM. Epicor BPM uses a different process model (event-driven triggers, service-connector routing, and form personalization) that cannot be directly translated from Embrace's workflow definition format. We export workflow rules as structured definitions in a written inventory document that describes each workflow's trigger event, conditions, approval chain, and downstream actions. The customer's Epicor admin or a Kinetic implementation partner rebuilds these in BPM post-migration.

Embrace report customizations holding business logic are not captured by standard data exports and do not migrate as report definitions to Epicor. We document every active custom report during scoping: the report name, base template, custom fields included, calculated columns, grouping logic, and branding elements. The customer's Epicor admin rebuilds these reports in Kinetic's Report Designer or Crystal Reports, referencing the migrated data fields. We provide a data dictionary that maps each Embrace custom field to its Epicor UD field equivalent so the admin can rebuild the calculations correctly.