Migrate from Enterox Enterprise Cloud to Odoo ERP

Enterox Contact records map to Odoo res.partner with partner_type set to 'contact'. Standard fields (name, email, phone, street, city, country) migrate directly. Custom Contact properties discovered during schema discovery map to Odoo res.partner custom fields (x_ prefix on Community). The link to the parent Company (Enterox entity reference) resolves to the Partner record of type 'company' via email domain match during the Partner import phase.

Enterox Company records map to Odoo res.partner with partner_type='company' and is_company=True. The Company-Contact parent-child relationship migrates as the parent_id on the Contact Partner record. Company-level custom fields discovered during schema discovery map to custom fields on the company Partner. We create all Company Partners before Contact Partners to satisfy the parent_id foreign key.

Enterox Leads in the Sales Automation module map to Odoo CRM Lead (crm.lead). Lead status and assignment fields map to Odoo stage_id and user_id. The Enterox lead-to-Opportunity transition state migrates as a corresponding Odoo stage in the CRM pipeline. Lifecycle Stage from Enterox's entity properties is preserved in a custom Char field x_enterox_lifecycle_stage on the Odoo crm.lead record.

Enterox Opportunities map to Odoo crm.lead with type='opportunity'. Pipeline stage, amount, probability, expected closing date, and owner fields migrate directly. If Enterox uses multiple Sales Automation pipelines, we create corresponding Odoo CRM Teams and assign stage_id to the appropriate team pipeline. Closed-won and closed-lost reasons from Enterox custom fields become Odoo stage_exit_description custom fields.

Enterox Quotations with line items map to Odoo sale.order in draft state. Quotation validity dates migrate as validity_date. Enterox pricing rules from the price list engine map to Odoo pricelist_id and the sale_order_line price computation. Each quotation line requires a resolved Product.product product on the destination Odoo instance; we hold unresolvable lines in a reconciliation queue and report them during scoping.

Enterox Sales Orders map to Odoo sale.order in state=sale or done depending on fulfillment status. Order status from Enterox maps to Odoo state (draft, sent, sale, done, cancel). Line items migrate as sale.order.line with product_id, product_uom_qty, price_unit, and discount. Fulfillment tracking states that have no Odoo equivalent are recorded as custom fields; any multi-step approval workflows are flagged for rebuild in Odoo approval configuration.

Enterox Purchase Orders from the SCM module map to Odoo purchase.order. Vendor references resolve to Odoo res.partner records of type 'supplier' (created during the Partner import phase). Line items map to purchase.order.line with product_id, product_qty, and price_unit. Approval status from Enterox's multi-step approval workflow becomes a custom state field; Odoo's purchase approval workflow is configured separately post-migration using Odoo's Purchase Approval app.

Enterox Product/Service Catalog entries (SKU, name, description, category, list_price, standard_cost) map to Odoo product.template. Enterox product categories map to Odoo product.category via name match with parent_id resolved for nested categories. If Enterox products have multiple price lists, we map the primary list_price to Odoo's list_price and flag additional pricing as pricelist.items to be configured in Odoo. Variants (size/color) in Enterox require conversion to Odoo product.attribute and product.template.attribute.line structure.

Enterox Support Cases map to Odoo project.task if the customer does not install the Helpdesk app, or to helpdesk.ticket if the Odoo instance includes the Helpdesk module. Case priority and status map to Odoo priority and stage_id. Assignee maps to user_id. Conversations and thread history require a case-by-case assessment: if Enterox stores conversations as linked entities accessible via API, we map them to Odoo mail.message records linked to the ticket; if they are in a non-API-accessible format, we note this gap in the handoff document.

Enterox custom entities discovered during schema discovery are created as Odoo custom models via ir.model and ir.model.fields metadata before any data migrates. Each custom entity's fields are mapped by data type (Char, Integer, Float, Boolean, Date, Many2one, One2many, Text) to the equivalent Odoo field definition. Lookup relationships between custom entities and standard entities (Contact, Company, Product) are resolved as Odoo Many2one fields pointing to the corresponding res.model. Custom entity naming follows Odoo's x_ prefix convention for Community edition models.

Enterox user records (name, email, role, access profile) map to Odoo res.users. Role structures differ significantly: Enterox's entity-level access rules map to Odoo groups via application of the nearest-matching group (Sales / Purchase / Inventory / Project Manager). We flag the mapping in a role reconciliation table and note that the customer's Odoo admin must review and finalize group assignments post-migration because access control in Odoo is application-scoped per installed App.

GPSVT vehicle tracking data and IoT telemetry stored in Enterox's device layer are not accessible via the standard Developer API. This data does not migrate. We flag this gap in the discovery report and advise the customer that GPS history must be exported manually from Enterox's native UI or via a bespoke Enterox professional services engagement. Odoo has no native GPS or fleet telemetry module; fleet management requires a third-party Odoo partner app.