Migrate from Extensiv Order Manager to Odoo ERP

Extensiv Orders map to Odoo Sale Order records. We preserve order number, order date, customer reference, shipping address, warehouse assignment, and line items with SKU, quantity, and unit price. Order status from Extensiv (processing, shipped, cancelled, etc.) maps to Odoo picking status via a status translation table agreed upon during scoping. Extensiv's Custom Order Info fields migrate to custom fields on the sale order model (x_extensiv_*) provided the admin has enabled custom fields in Extensiv before extraction.

Extensiv Customer records map to Odoo Contact with name, email, phone, and address fields. Extensiv's multi-address support (billing vs shipping) maps to the Contact record with dedicated address records using Odoo's partner model. Pre-configured custom fields under Customers migrate as custom fields on the contact model only if Enable custom fields is activated in Extensiv Admin > Settings before extraction.

Extensiv Products with SKU, name, description, cost, and price map to Odoo Product Template records. Product type in Extensiv (storable, consumable, service) maps to the corresponding Odoo product type field. Extensiv's cost field maps to Odoo's standard cost field, used for inventory valuation. If the Extensiv product has variants (size, color), we create Odoo Product Variants under a single Product Template using the variant attribute system.

Extensiv bundle and kit products with component-level SKU tracking require decomposition into an Odoo BoM. Each component SKU becomes a BoM line under a finished-good Product Template. Bundle pricing overrides from Extensiv migrate as a custom pricing rule on the Product Template. Component-level inventory from Extensiv does not automatically populate Odoo BoM quantities; the customer specifies whether Odoo should use phantom-type BoM (for kits shipped as one) or kit-type (for individually tracked components) during scoping.

Extensiv inventory levels are warehouse-specific. Each Extensiv warehouse maps to an Odoo Warehouse, and per-warehouse stock positions map to Odoo Stock Quants. If the customer maintains inventory in multiple Extensiv warehouses, we create corresponding Odoo Warehouses and map each location's stock to its Odoo equivalent. Open Stock Transfers between Extensiv warehouses are mapped to Odoo internal transfers using the source and destination warehouse mapping.

Extensiv Warehouses map to Odoo Warehouse records with the same name, ID mapping preserved in a custom field (x_extensiv_wh_id__c) for reconciliation. Odoo Warehouse must be configured with the correct incoming and outgoing routing rules to match Extensiv's fulfillment logic, which we document in the post-migration configuration guide rather than implementing as code inside the migration scope.

Extensiv Shipment records map to Odoo Stock Picking records of type outoing. Carrier, tracking number, shipment date, and shipping cost transfer to Odoo. The picking is linked to the originating Sale Order via the sale_id relation. Tracking URLs are stored in a custom char field on the picking because Odoo standard tracking fields reference delivery provider integration rather than raw URL storage.

Extensiv Purchase Orders map to Odoo Purchase Order records with vendor, status, and line items. Vendor reference and incoming receipt records migrate to Odoo as PO line notes. Inbound receipt records from Extensiv map to Odoo incoming Stock Pickings, linked to the corresponding PO. We flag any Extensiv PO with an open inbound receipt as requiring a pending Odoo receipt during scoping.

Extensiv Stock Transfers move inventory between warehouses and map to Odoo internal Stock Pickings with type internal. Source warehouse and destination warehouse map to the Odoo picking's location_id and location_dest_id using the warehouse mapping established during discovery. Line-item quantities migrate with the transfer. If a transfer is in-progress in Extensiv at migration time, we flag it as pending in Odoo for the customer's operations team to complete or cancel.

Extensiv Custom Order Info and pre-configured customer custom fields require the Enable custom fields admin setting to be active before extraction. We confirm this during discovery and flag any records where the setting is inactive. Custom field types (text, number, date, checkbox) map to Odoo custom field types of equivalent type. Ad-hoc order-level custom fields migrate as line-level custom fields on the sale order line model. We do not configure Odoo's custom field schema; we deliver a written list of all custom fields requiring Odoo schema creation before import.

Extensiv Sales Channels (Shopify, Amazon, Walmart, etc.) are stored as order-level attributes but have no direct Odoo equivalent. We migrate channel assignment as a custom tag on the Sale Order (x_sales_channel__c) or as a project/team tag. The customer's Odoo admin assigns orders to the correct internal team or warehouse based on channel during post-migration configuration. We do not rebuild channel routing logic inside Odoo.

Extensiv FIFO cost basis, inventory value, SKU profitability, and inventory aging reports export as static data. These map to Odoo Inventory Valuation reports, Costing reports, and the product margin report. We do not migrate the Odoo reporting configuration; the report structures in Odoo are rebuilt by the customer based on the imported data. The Extensiv reporting data itself (the numbers) is migrated as a product-related export mapped to custom fields on Product Template for margin and cost history.