Migrate from Deskera ERP to Acumatica

Deskera Customer maps to Acumatica Customer (AR). CompanyName becomes Name, email maps to Email, phone to Phone. Multi-currency CuryID preserved per customer if enabled. Primary address and shipping address split into separate address records. CustomerClassID derives from Deskera customer type, controlling default payment terms and tax zone assignments in Acumatica. Credit limit and tax registration ID migrate to CreditLimit and TaxRegistrationID respectively.

Deskera Vendor maps to Acumatica Vendor (AP). VendorName becomes Name, email to Email. Payment terms (Net-30, Net-60, etc.) map to Acumatica PaymentTermsID using the same term-value lookup as customers. Remit-to address migrates as a separate address record linked to the vendor. CuryID and TaxRegistrationID carry forward from Deskera. One-time vendor flags and vendor class assignments require mapping to Acumatica's VendorClassID if configured.

Deskera Item (stock and non-stock) maps to Acumatica InventoryItem. The StockItem checkbox on InventoryItem derives from Deskera's 'track inventory' flag. TemplateID is assigned for stocked items; Non-Stock flag is set for non-inventoried products. UnitCost maps to StandardCost, BasePrice to BasePrice, and reorder point to ReorderLevel. LotSerialClass configuration in Acumatica must be reviewed if Deskera uses lot/serial tracking to ensure compatibility with existing lot number formats.

Deskera SalesOrder maps to Acumatica SOOrder with direct field correspondence: OrderNbr to OrderNbr, OrderDate to OrderDate, CustomerRef to CustomerOrderNbr. Line-level tax codes map to Acumatica TaxCategoryID. BranchID is assigned based on the source warehouse or shipping site in Deskera. Status values (Draft, Confirmed, Shipped, Invoiced) require value mapping to Acumatica's Pending, Open, Completed, and Cancelled statuses. LineDiscountSequence and SeparateTax flags are preserved where configured.

Deskera PurchaseOrder maps to Acumatica POOrder. POLine quantities and UOMs migrate with UnitCost preserved. Expected delivery dates map to ExpectedDate; promised dates map to PromisedDate. Status mapping converts Deskera status values to Acumatica equivalents (Pending, Open, Completed, Cancelled). ShipTo address and terms assignment follow the same patterns as SOOrder. Line-level account assignments map to expense or inventory accounts in Acumatica's distribution schema.

Deskera AR Invoice maps to Acumatica ARInvoice. DocType preserves invoice versus credit memo distinction using Acumatica's DocType enumeration. Line descriptions, quantities, and unit prices migrate directly. CuryID is carried forward to preserve multi-currency amounts. PaymentTermsID applies terms configured in Acumatica's PaymentTerms table. DocDesc maps to DocDesc. TaxTotal and LineDiscount amounts are preserved where applicable. BranchID assignment follows the source document's branch or warehouse context.

Deskera AP Invoice maps to Acumatica APInvoice. VendorRef becomes VendorRefNbr for invoice matching and reconciliation. Line-level GL account assignments map to Acumatica expense or inventory account fields based on account type in Deskera. Prepayments are tracked via the Pay In Advance flag on the APInvoice record. Terms applied via PaymentTermsID using the same lookup as vendor master data. CuryID and tax amounts carry forward to preserve multi-currency invoice details and tax calculations.

Deskera Journal Entry maps to Acumatica BatchModule combined with GLTran lines. BatchNbr is created per journal run. TranDate, TranDesc, and account lines (AccountCD, DebitAmt, CuryDebitAmt) are preserved. BatchModule (GL) is assigned based on account type classification. Each GLTran line inherits BatchNbr and Module (GL) for traceability. CuryCreditAmt and CuryDebitAmt preserve multi-currency amounts where CuryID is configured on the batch header.

Deskera Account (code, name, type) maps to Acumatica Account (AccountCD, Description, Type). Active and Inactive status is preserved. Subaccounts in Deskera map to SubID via the subaccount mask configured in Acumatica's Subaccount mask screen. Class and location data map to BranchID and ClassID respectively. Account type mapping uses the same Asset, Liability, Income, and Expense classifications in both systems. Currency codes (CuryID) on accounts carry forward for multi-currency-enabled accounts.

Deskera BOM maps to Acumatica BOMHead plus BOMDetail. BOMRevision and BOMLevel are handled via revision sequence in Acumatica. Material and overhead cost elements map to the closest Acumatica cost element (material, labor, overhead). Routing lines may require manual routing definition in Acumatica's Production Routing screen if Deskera used routing labor with operation sequences. The finished-good item links via BOMID to InventoryItem.ItemCD.

Deskera Work or Manufacturing Order maps to Acumatica ProductionOrder. ItemID, BOMID, Quantity, and status are preserved through migration. InventoryIssuePolicy and material allocations are reflected in the production order's material allocation lines (BOMDetail). Operation sequence and labor hour data from Deskera routing lines export as a reference document for manual configuration in Acumatica's ProductionRouting screen if detailed scheduling is required. Start and due dates map to ScheduledDate and DueDate fields.

Deskera People (employee) maps to Acumatica EPEmployee. EmployeeName becomes the Acronym for display purposes; FirstName and LastName are stored separately in the EPEmployee record. DepartmentID maps from Deskera department name to Acumatica EPDepartment using the migrated department list. EmploymentHistory is preserved in EPEmployee as a custom field note if available from Deskera. Employee type (full-time, contractor) may map to EmployeeType if configured in Acumatica.

Deskera department name maps to Acumatica EPDepartment with DepartmentID as the code identifier and Description as the name field. Active and Inactive status is carried forward from Deskera. The EPDepartment structure must be created before employee migration so that DepartmentID references are valid. Parent department assignments in Deskera, if any, can be documented for manual hierarchy setup in Acumatica's department tree view.

Deskera leave requests map to Acumatica EPTimeOffRequest. LeaveType maps to EarningType based on the leave category configured in Deskera. StartDate, EndDate, and status (Approved, Pending) migrate to the corresponding fields in Acumatica. The employee is linked via EmployeeID to the EPEmployee record created during employee migration. Approval history and notes from Deskera are preserved in the DocDesc or a custom UDF on the time-off request.

Deskera CRM Leads map to Acumatica CRLead. LeadID, FirstName, LastName, Email, Phone, Source, Status, and Rating are preserved through direct field mapping. Deskera lead qualifications and custom fields migrate to CRLead UDFs created before the CRM data load. The conversion process (Lead-to-Contact and Lead-to-Opportunity) is available post-migration using Acumatica's built-in lead conversion workflow. Address and contact method fields map to the standard CRLead address schema.

Deskera Opportunity maps to Acumatica CROpportunity. OpportunityName becomes CROpportunity.Subject; StageName maps to StageID from the configured sales process in Acumatica. CloseDate, CuryAmount, and Probability are preserved. CROpportunity is linked to Contact via ContactID and to the related Account via CustomerID. Line items and products from Deskera opportunities map to CROpportunityDetails if line-level detail tracking is required. Campaign source and lead quality indicators migrate to custom UDFs if configured.

Deskera CRM Cases map to Acumatica CRCase. CaseID becomes CaseID; Subject and Description migrate directly. Priority and Severity levels in Deskera map to CaseStatus and Priority fields in Acumatica. AssigneeID links to the Acumatica Owner (Employee) record. Creation date and last-modified date are preserved as CreatedDateTime and LastModifiedDateTime. Deskera case resolution notes and time tracking migrate to CRCase resolution details or custom UDF fields.

Deskera custom properties across all modules are created as Acumatica User-Defined Fields on the corresponding Data Access Class (DAC) before migration. Field type mapping follows direct equivalence: text properties become string(255) UDFs, decimal properties become decimal UDFs, date properties become date UDFs, and pick-list properties become selector UDFs with a value list. Notes field on each DAC carries the original Deskera custom field label for traceability. Manufacturing-specific custom fields (operation rates, cost elements) require BOMDetail UDF creation before BOM lines can be imported.

Deskera automations, approval chains, and workflow rules are not migratable to Acumatica. FlitStack AI exports workflow definitions as a reference document including screen screenshots and logic summary for your Acumatica admin or implementation partner to rebuild using Acumatica's Screen automation or an external workflow engine.