Migrate from Circle Commerce to Odoo ERP

CircleHub Orders map to Odoo sale.order records with full header detail, line items (sale.order.line), fulfillment status, and payment references. The Circle order number becomes the Odoo name field, and the customer's CircleHub custom order fields are mapped during the scoping field map. Status values from Circle (pending, processing, shipped, delivered, cancelled) map to Odoo sale.order state values (draft, sent, sale_order, done, cancelled). Historical timestamps on orders are preserved as order_date and commitment_date fields.

CircleHub Customer records map to Odoo res.partner. Every Circle customer with a contact role becomes a Partner record with type=contact; account-role customers become type=delivery or invoice addresses linked to the parent contact partner. Custom fields on the customer record map to typed res.partner fields (char, integer, float, date, selection) based on the Circle field data type introspected during scoping. Email maps to email, phone to phone, and address fields to the Odoo address format (street, city, state, zip, country).

CircleHub Company records map to Odoo res.partner with is_company=True. If the customer uses both Company and Customer objects in CircleHub, Companies become the top-level Partner record and Customers attach as child contacts with type=contact and parent_id pointing to the Company Partner. This preserves the account hierarchy from CircleHub in the Odoo Partner tree structure.

CircleHub Products map to Odoo product.template for the shared product definition (name, description, type, categ_id, list_price, standard_price) and product.product for the variant-level records (combinations of attributes). Circle product variants map to Odoo product variants via the attribute values. Bundle and kit relationships from CircleHub are preserved as Odoo BoM (bill of materials) records if the destination Odoo instance includes Manufacturing, or as kits via product.type=service and extra line items for simpler setups.

CircleHub inventory quantities per channel (online, BOPIS, warehouse) export as separate records. We consolidate multi-channel inventory into Odoo stock.quant per location. If the destination Odoo instance needs channel-level granularity preserved, we create Odoo stock.location records for each Circle channel and populate stock.quant per location rather than collapsing to a single quantity. This preserves the omnichannel allocation model CircleHub natively provides.

CircleHub Shipment records map to Odoo stock.picking with carrier, tracking number, and delivery status preserved in the picking record and in stock.move lines. Partial shipments and backorder records from CircleHub migrate as separate Odoo stock.picking records with backorder_id pointing to the original picking. Tracking URLs migrate to the picking's note field or carrier_tracking_ref if the destination Odoo version supports it natively.

CircleHub Purchase Order records map to Odoo purchase.order with vendor assignment, expected date, and line items. Where vendors exist only as free-text in CircleHub, we flag them during scoping for manual review and resolve them to res.partner records before import because Odoo purchase.order requires a partner_id link to a Supplier Partner. Any unresolvable vendor names are held in a reconciliation queue for the customer's admin to create Partner records for before PO import proceeds.

Every custom field defined by the customer on any CircleHub object (order, customer, product, shipment) is included in the migration field map. We pre-create the Odoo custom field definition (ir.model.fields with name ending in __c) with the correct field type (char, text, integer, float, date, datetime, selection, many2one, one2many, many2many) before data import. Relational custom fields in CircleHub (links to other entities) are mapped to Odoo many2one or many2many relationships with the lookup resolved at migration time.

CircleHub Purchase Orders frequently store vendors as free-text string fields rather than linked records, especially in custom-configured schemas. We identify all free-text vendor fields during scoping, extract the unique vendor name values, and group them for the customer's admin to create as res.partner records with supplier=True before PO import. This is a manual step flagged in the migration scope because Odoo's purchase module requires a valid partner_id on purchase.order lines.

Custom reports and KPI definitions built within CircleHub on the customer's own field definitions have no documented export API and cannot be migrated as data records. We capture report metadata (report name, referenced fields, calculation logic, chart type) during discovery and include it in the Migration Inventory Document. The customer's admin rebuilds reports in Odoo Reporting using the migrated fields; Odoo partners can assist with complex reporting rebuilds if needed.

All historical date fields on CircleHub Orders (order date, ship date, delivery date, last modified) migrate to the corresponding Odoo sale.order date fields (date_order, commitment_date, effective_date, write_date) and are preserved as read-only in the destination to maintain audit trail integrity.