Migrate from Deskera ERP to Odoo ERP

Deskera's Chart of Accounts (with account codes, names, and standard account types) maps directly to Odoo Accounting's account.account records. We extract the full COA export, map account codes and names verbatim, and preserve Deskera's account_type as Odoo account type (asset, liability, equity, revenue, expense). Multi-currency settings on accounts carry over as currency_id references. If Deskera stores tax codes separately, we provision Odoo account.tax records alongside the COA before any journal entry migration begins, because Odoo requires tax accounts to exist before journal lines referencing them can post.

Deskera Customer records from /v1/account (type filter) migrate to Odoo res.partner with contact_type = contact and customer_rank set to positive for deduplication. We map billing_address and shipping_address from Deskera's address block to Odoo street, city, state_id, zip, and country_id fields. Email, phone, and tax ID carry over verbatim. We deduplicate by email match before insert to avoid Odoo's partner ranking producing duplicate customer records. Vendor records route through the same pipeline with contact_type = vendor and vendor_rank set accordingly.

Deskera Vendor records share the same /v1/account API endpoint with a type filter. We separate vendor from customer records at extraction time using the entity type flag, then load into Odoo res.partner with contact_type = vendor and vendor_rank set. Vendor-specific fields (payment terms, bank details if stored) map to Odoo property fields on the partner record. The same deduplication-by-email logic applies to avoid creating duplicate vendor records when a contact also appears as a customer in Deskera.

Deskera journal entries with debit/credit line amounts and account references map to Odoo account.move records. We provision the target Odoo journal (purchase, sale, general, miscellaneous) and its sequence (defining the move_name prefix-number format) before any move creation, because Odoo enforces sequence integrity at insert time. Deskera's optional Class, Location, and Department dimensions carry over as custom fields on account.move.line since Odoo Accounting does not have native multi-dimensional accounting. We migrate the account.move.line records with debit, credit, account_id, and analytic_distribution references preserved.

Deskera Item records (SKU, name, unit of measure, cost, on-hand quantity) map to Odoo product.template and product.product records. We map Deskera's item type (stockable vs. service vs. consumable) to Odoo's product_type. Category mapping routes Deskera's item_category to Odoo product.category. On-hand quantities from Deskera's stock module post to Odoo stock.quant records at the relevant warehouse location. Lot and serial number data from Deskera's batch/serial tracking migrates to Odoo stock.lot records, with a supplemental reconciliation report documenting any lot numbers that span multiple Deskera warehouses.

Deskera Sales Order records link to customer and line items with pricing rules. We map the order header (customer reference, order date, payment terms) and all line items (product, quantity, unit price, tax) to Odoo sale.order and sale.order.line. The customer reference in Deskera becomes the Odoo Client Order Reference field. Closed orders are migrated selectively per the customer's accounting cut-off preference; open orders migrate in full with state set to sale_order. Note that Deskera's order-to-invoice workflow may differ from Odoo's sale_order-to-account_move pipeline; we document the discrepancy so the admin can align the invoicing policy post-migration.

Deskera Purchase Order records migrate to Odoo purchase.order with vendor linkage and expected receipt dates preserved. Line items map to purchase.order.line with product, quantity, and unit cost from Deskera's cost field. Open POs migrate with state = purchase to allow further receipt processing in Odoo. Closed historical POs migrate selectively based on the customer's accounting cut-off period; any PO with an invoice date before the cut-off is documented in the supplemental migration report rather than loaded. Vendor lead times in Deskera carry over to Odoo's supplier info on the product form.

Deskera multi-level Bills of Materials with component items, quantities per assembly, and production routing migrate to Odoo mrp.bom records with mrp.bom.line children. We preserve multi-level BOM nesting (parent assembly with child sub-assemblies) by sequencing parent BOM creation before child BOM creation to satisfy Odoo's foreign-key constraint. Deskera MRP operations and work-center assignments migrate as supplemental routing records in a separate migration table because Odoo separates workcenter operations from BOM components differently than Deskera's combined MRP approach. The routing map is delivered as a written handoff document for the customer's Odoo partner or manufacturing admin to reassemble in the Manufacturing app.

Deskera People employee records (name, email, department, job title, manager relationship) map to Odoo hr.employee. We extract organizational structure as hr.department and parent_id links. Current compensation record and leave balance values migrate to Odoo as supplemental fields on the employee form or as entries in an attached migration table. Effective-dated historical payroll records are flagged for manual reconciliation because Deskera's payroll engine and Odoo's HR module handle salary structures and run payroll differently. Attendance and timesheet data from Deskera (if used) can be migrated as hr.attendance or account.analytic.line records depending on the Odoo apps installed.

Deskera custom field definitions and their values migrate to Odoo's ir.model.fields registry and onto the target records. We capture the Deskera custom field name, data type, and applicable objects during scoping, then pre-create the Odoo custom field via the ORM or directly in the database before importing values. Multi-select, date, number, and text types map to their Odoo equivalents (selection, datetime, float/integer, char/text). Custom field values that cannot map directly to a typed Odoo field are stored in a supplemental JSON field on the target record and delivered with a data dictionary so the admin can decide on post-migration field splitting.