Migrate from Brightpearl to Odoo ERP

Brightpearl stores both customers and vendors as Contact records differentiated by a contact role flag. We map Brightpearl Contact to Odoo res.partner, setting the customer_rank or supplier_rank integer based on the role flag (a contact can have both). Address records (shipping and billing) migrate as res.partner address records with type set to 'invoice', 'delivery', or 'contact'. PCF_* custom fields map to res.partner custom fields that we create via Studio or XML before migration. Country names must be converted from Brightpearl's localisation strings (full country name, not ISO code) to Odoo's res.country lookup; we pre-load the country normalisation table during scoping.

Brightpearl Products map to Odoo product.product. The product type (stockable, consumable, service) maps from Brightpearl's product type. Multiple price list assignments per product in Brightpearl map to product.pricelist.item entries tied to the product. SKU (product code) becomes the product's default_code; the PCF_* custom fields migrate to custom fields on product.product. We export the full product catalogue including service items, and handle any Brightpearl product bundles as a separate mapping exercise because Odoo uses kit structures or bom lines for assemblies.

Brightpearl's four-level location hierarchy (Aisle / Bay / Shelf / Bin) under Zones maps to Odoo's stock.location tree using the parent_path pattern. Each Brightpearl location becomes a stock.location record with location_type = 'internal' and a parent_id pointing to the next level up. Brightpearl Zones map to stock.warehouse records, which own the top-level location under which picking locations sit. We reconstruct the full path as a string (Aisle-A / Bay-1 / Shelf-3 / Bin-12) in the location's complete_name field. Location-specific inventory levels (per-location stock) map to stock.quant records after both location and product are loaded.

Brightpearl inventory summary (total cost value per SKU) and inventory detail (per-warehouse, per-location levels) map to Odoo stock.quant. Each quant record holds product_id, location_id, quantity, and the lot/serial number if the product uses tracked inventory. We map Brightpearl's available and reserved quantities to Odoo's on_hand and reserved_quantity fields respectively. If Brightpearl uses FIFO costing, we set the product's costing_method to 'fifo' before quant import so that Odoo computes the same cost value.

Brightpearl price lists associate a price value with a product and a price list identifier, with multiple price lists per product being common. We map each Brightpearl price list to an Odoo product.pricelist with the corresponding currency (mapped from Brightpearl's currency code). Each price-list-to-product assignment becomes a product.pricelist.item with the computed price or percentage discount. Tiered pricing rules in Brightpearl map to multiple product.pricelist.item lines with different min_quantity thresholds.

Brightpearl sales orders map to Odoo sale.order. Order headers carry order number, order date, customer reference (mapped via res.partner), and owner assignment (mapped via res.users). Line items map to sale.order.line with product_id resolved from the product mapping, quantity from the order line, and price from the applicable product.pricelist. Discounts from Brightpearl order lines migrate as discount fields on sale.order.line. Order status (pending, confirmed, shipped, invoiced) maps to Odoo state (draft, sale, done, cancelled) with attention to Brightpearl's fulfillment status for partial-ship scenarios.

Brightpearl purchase orders map to Odoo purchase.order. The vendor assignment comes from the res.partner mapping (supplier-ranked contacts). Lead time and expected delivery dates migrate to purchase.order commitment_date. Received quantities and line-level received amounts map to Odoo's move_ids (stock moves) with the relevant product, quantity, and warehouse location. The purchase order state sequence (draft, sent, confirmed, done, cancelled) maps to Odoo's state field.

Brightpearl invoices and credit notes map to Odoo account.move with move_type set to 'out_invoice' for invoices, 'out_refund' for customer credit notes, 'in_invoice' for vendor bills, and 'in_refund' for vendor credit notes. Accounting data embedded in the Brightpearl invoice record (account code, debit/credit amounts, tax) maps to account.move.line entries with account_id resolved via the Chart of Accounts mapping. Brightpearl's invoice-to-sales-order linkage is preserved as a sale_line_id on the Odoo move line. We do not migrate locked accounting periods; the customer must open or close periods in Odoo after migration based on their reporting calendar.

Brightpearl's Chart of Accounts with account codes maps to Odoo account.account, using the account code as the dedupe key. Each account maps with its name, code, account_type (asset, liability, equity, revenue, expense), and reconcile flag set appropriately. We export the full account code list from Brightpearl and generate the Odoo XML or CSV import file during the pre-migration schema build. The customer validates the account structure before the production migration phase. If Brightpearl uses Sage's account code conventions (e.g., 1xxx assets, 2xxx liabilities), we map to Odoo's standard account types and allow the customer to adjust codes post-migration if their chart of accounts is non-standard.

Brightpearl staff members assigned as record Owners map to Odoo res.users. We extract the distinct owner list from Contact, Sales Order, and Purchase Order records and match by email against Odoo's res.users. Any Brightpearl owner without a matching Odoo user goes to a reconciliation queue for the customer's admin to provision before record import resumes. Owner references on migrated records resolve to the res.users id via the lookup table.