Migrate from Deskera ERP to Epicor Prophet 21

Deskera COA with account codes, names, and standard account types maps directly to Epicor GL Account. We preserve account types (Asset, Liability, Equity, Revenue, Expense), tax codes, and currency assignments during the import. GL Account codes in Epicor follow a segment structure; if Deskera uses multi-segment account codes, we split them into Epicor's configured GL Segment logic before import to avoid code-format rejections in the DMT template.

Deskera's /v1/account endpoint with type filter (customer) maps to Epicor Customer table. We preserve billing and shipping addresses, credit limits, payment terms, and the primary contact reference. In Epicor, Customer is tied to a Company and must exist before any Order or Quote referencing that customer is imported. We run Customer migration as the second phase after COA.

Deskera Vendors (also from /v1/account with type filter) map to Epicor Supplier. Address, payment terms, bank details, and tax ID transfer to the Supplier table. Epicor's Supplier maintains a separate credit limit and payment hold flag that does not exist as a direct field in Deskera — we map any vendor payment-status flag in Deskera to Epicor's Hold field and flag the discrepancy for manual review during cutover.

Historical Deskera journal entries with debit/credit amounts, account references, and optional dimensions (Class, Location, Department) map to Epicor GL Journal Entry. Deskera dimension values map to Epicor GL Control values if the customer has GL Control segments configured. Journal date and fiscal period transfer directly; reversal entries are not created during migration but are documented in the handoff package for the customer's Epicor admin to handle per their accounting policy.

Deskera Items (SKU, name, unit of measure, standard cost, on-hand quantity) map to Epicor Part with PartType = ItemPart. Lot and serial tracking settings migrate as Part.LotSh追踪 and Part.Serialized configuration. On-hand quantities map to PartBin quantity records per warehouse. Epicor's Part does not have a native description field separate from Part Number; we set Part.PartDescription to the Deskera item description to preserve text content that Deskera stores independently.

Deskera multi-level BOM structures (assembly, sub-assembly, component) require flattening for Epicor. We extract the Deskera BOM as a parent-to-child item association and write either Epicor PartMtl records (for make-to-stock BOMs) or JobMtl records (for job-specific material requirements). Multi-level routing is preserved as a flat material list per top-level assembly; the Epicor admin rebuilds the production routing (work centers, labor hours, machine time) inside Epicor Kinetic's production management module post-migration. This is a known limitation of BOM migration from any SMB ERP to Epicor and is documented in the handoff package.

Open Deskera Sales Orders with customer linkage, line items, pricing, and expected ship dates map to Epicor Order. OrderHed and OrderDtl are created from the Deskera order and order-line records. Deskera's order-to-invoice workflow maps to Epicor's Order-to-Ship-to-Invoice cycle; pricing rules migrate as OrderDtl unit prices. Closed historical orders are not migrated unless the customer specifies a historical cutoff; we document this decision in the scope and flag any compliance or audit requirement for historical order access.

Open Deskera Purchase Orders map to Epicor POHeader and PODetail with vendor linkage, expected receipt dates, and line-item quantities. Closed historical POs migrate only if the customer specifies an accounting cutoff or regulatory requirement. Epicor's PO Release structure (POHeader -> PORel) means Deskera PO lines with partial receipt history generate PORel records at the received quantity with the remaining balance as an open receipt expectation.

Deskera People employee records with name, department, position, hire date, and compensation map to Epicor Employee. Pay rate and benefit deductions do not migrate directly because Epicor's HR capabilities are more limited than Deskera People; we import the employment record and flag payroll data as requiring manual setup in Epicor or a separate payroll integration. Organizational hierarchy from Deskera maps to Epicor's Employee Department and Class structure.

Deskera CRM contacts with name, email, phone, company association, lifecycle stage, and custom properties map to Epicor CRM Person records linked to the matching Customer record via the CustNum foreign key. Lifecycle stage and custom contact properties migrate as UD fields on the Person table, provisioned via Epicor UD Column Map before import. Deskera contact-to-account linkage is resolved by matching the Deskera company reference to the Epicor Customer record created in phase two.

Deskera custom fields on any supported object migrate to Epicor User-Defined (UD) fields on the corresponding Epicor business object. We pre-provision UD columns via Epicor's UD Column Map interface before data import begins. Custom field type mapping is type-by-type: text to string, number to decimal or int, date to date, checkbox to logical. Epicor's UD field naming convention requires a UD prefix; we handle the rename during schema provisioning. If a Deskera custom field references a lookup to another object, we document the relationship for manual reconfiguration in Epicor since UD field cross-object lookups require custom BAQ configuration.

Deskera tax codes and their rate assignments map to Epicor Tax Region configuration with corresponding Tax Code and Tax Rate entries. We preserve tax applicability (sales vs. purchase) and the associated GL account. If Deskera uses compound tax structures (tax on tax), we flatten these into single Epicor tax rates per line and document the original structure for the customer's Epicor admin to configure in Tax Maintenance post-migration.