ERP migration
Field-level mapping, validation, and rollback between BusinessCloud and Odoo ERP. We move data and schema; workflows are rebuilt natively in Odoo ERP.
BusinessCloud
Source
Odoo ERP
Destination
Compatibility
11 of 12
objects map 1:1 between BusinessCloud and Odoo ERP.
Complexity
CModerate
Timeline
5-8 weeks
Overview
Moving from BusinessCloud to Odoo ERP requires navigating a platform with no publicly documented API surface, no confirmed bulk export endpoint, and limited third-party tooling. We approach every BusinessCloud migration by first requesting a full database export directly from BusinessCloud support, then probing the exported schema to map core entities to Odoo's modular app structure. BusinessCloud's core modules (accounting, inventory, sales, purchasing, CRM) align to Odoo apps but the mapping requires manual schema discovery per customer because BusinessCloud's data model is not publicly documented. We migrate transactional history (open orders, outstanding invoices, current inventory levels, active supplier records) and we do not migrate BusinessCloud workflows, automations, or custom reports as code. We deliver a written inventory of these for the customer's admin to rebuild in Odoo's automation framework post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a BusinessCloud object lands in Odoo ERP, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
BusinessCloud
Company / Entity
Odoo ERP
res.partner (company type)
1:1BusinessCloud Company or Entity records map to Odoo res.partner with partner_type set to company. The company name, registration number, tax ID, website, and address fields map directly. BusinessCloud multi-entity setups (parent-subsidiary structures) require Odoo multi-company configuration to be enabled and a parent_id link set on the subsidiary partner record. We resolve the company identifier from the exported database schema during the discovery phase since BusinessCloud's entity model is not publicly documented.
BusinessCloud
Contact / Person
Odoo ERP
res.partner (individual type)
1:1BusinessCloud Contact records (individuals linked to companies) map to Odoo res.partner with partner_type set to individual and a parent_id pointing to the linked company partner. Email, phone, mobile, job title, and address fields migrate directly. Any BusinessCloud contact notes or custom fields map to res.partner custom fields created during schema design.
BusinessCloud
Product / Item
Odoo ERP
product.product
1:1BusinessCloud product or item records map to Odoo product.product (storable product) or product.template depending on whether the customer uses variants. Product name, SKU code, barcode, unit of measure, standard cost, and list price map to Odoo standard fields. We determine product type (stockable, consumable, service) from BusinessCloud inventory category flags in the exported schema.
BusinessCloud
Inventory / Stock
Odoo ERP
stock.quant
1:1BusinessCloud inventory records map to Odoo stock.quant for on-hand quantity tracking by product and location. We extract current stock levels per warehouse from the BusinessCloud export, then create stock.quant records linked to the corresponding product.product and stock.location (defaulting to Odoo's Physical Locations view if no multi-warehouse setup exists). The inventory valuation amount maps to product.standard_price on the product template.
BusinessCloud
Purchase Order
Odoo ERP
purchase.order
1:1BusinessCloud purchase order headers map to Odoo purchase.order with partner_id resolved to the supplier res.partner, order_date mapped to date_order, and order reference preserved in the Odoo origin field. Purchase order lines map to purchase.order.line with product_id, product_qty, price_unit, taxes_id, and discount fields resolved. Open and draft POs migrate; cancelled POs are not migrated unless the customer requests historical audit records.
BusinessCloud
Sales Order / Invoice
Odoo ERP
sale.order
1:1BusinessCloud sales order records map to Odoo sale.order. The customer partner, order date, and order reference map directly. Sale order lines migrate with product_id, product_uom_qty, price_unit, tax_id, and discount preserved. If BusinessCloud records include confirmed invoices rather than just orders, we migrate sale.order with the invoiced status flag set and create account.move records for posted invoices. We resolve any outstanding amounts against the customer account balance.
BusinessCloud
Supplier Invoice
Odoo ERP
account.move (vendor bill type)
1:1BusinessCloud vendor or supplier invoices map to Odoo account.move with move_type = in_invoice. Partner_id resolves to the supplier res.partner, invoice_date maps to invoice_date, and invoice number maps to ref. Line items map to invoice_line_ids with product_id, quantity, price_unit, and tax tags resolved. Outstanding amounts on open invoices carry over as account.move line entries with matching partner_credit values.
BusinessCloud
Customer Invoice
Odoo ERP
account.move (customer invoice type)
1:1BusinessCloud customer invoices map to Odoo account.move with move_type = out_invoice. The customer res.partner, invoice date, due date, and invoice number migrate. Invoice line items map with product_id, quantity, unit price, tax tags, and discount preserved. Open invoices carry their outstanding balance as a credit or debit line in Odoo's accounts receivable account.
BusinessCloud
Chart of Accounts
Odoo ERP
account.account
1:1BusinessCloud chart of accounts structure maps to Odoo account.account records. Each account's code, name, account_type (asset, liability, equity, income, expense), and reconcile flag migrate. We map account codes directly when they align to Odoo's account type taxonomy; accounts that do not map cleanly require the customer's accountant to review and assign the correct Odoo account type before data import. This is the most accounting-sensitive mapping in the migration and is done in collaboration with the customer's finance team.
BusinessCloud
Journal Entries
Odoo ERP
account.move (entry type)
1:1BusinessCloud journal entries (general ledger transactions) map to Odoo account.move with move_type = entry. We migrate posted entries only unless the customer requests draft entries for audit. Each journal entry line maps to account.move.line with account_id, debit, credit, partner_id, and analytic account resolved. The account references must be validated against the migrated chart of accounts before journal entry migration begins.
BusinessCloud
CRM / Lead
Odoo ERP
crm.lead
1:1BusinessCloud CRM leads or prospects map to Odoo crm.lead (Odoo's unified lead/opportunity model). Contact name, email, phone, company name, lead source, and stage/status fields migrate to crm.lead standard fields. Any BusinessCloud lead scoring or priority flags map to custom fields on crm.lead. Odoo's crm.lead does not split into separate Lead and Contact objects like Salesforce; it uses a single model with type toggle between lead and opportunity.
BusinessCloud
Custom Objects / Fields
Odoo ERP
ir.model / ir.model.fields
lossyBusinessCloud custom fields or extended entity records map to Odoo's dynamic ORM model extension. We create ir.model records for any BusinessCloud entity that has no Odoo standard equivalent, then add ir.model.fields to define the custom fields. This requires schema discovery from the BusinessCloud export to identify extended fields not present in the standard BusinessCloud data model. Custom object naming in Odoo follows the standard ir.model approach and does not require code-level module development unless the custom object requires custom business logic.
| BusinessCloud | Odoo ERP | Compatibility | |
|---|---|---|---|
| Company / Entity | res.partner (company type)1:1 | Fully supported | |
| Contact / Person | res.partner (individual type)1:1 | Fully supported | |
| Product / Item | product.product1:1 | Fully supported | |
| Inventory / Stock | stock.quant1:1 | Fully supported | |
| Purchase Order | purchase.order1:1 | Fully supported | |
| Sales Order / Invoice | sale.order1:1 | Fully supported | |
| Supplier Invoice | account.move (vendor bill type)1:1 | Fully supported | |
| Customer Invoice | account.move (customer invoice type)1:1 | Fully supported | |
| Chart of Accounts | account.account1:1 | Mapping required | |
| Journal Entries | account.move (entry type)1:1 | Fully supported | |
| CRM / Lead | crm.lead1:1 | Fully supported | |
| Custom Objects / Fields | ir.model / ir.model.fieldslossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
BusinessCloud gotchas
Name collision: 'BusinessCloud' refers to multiple unrelated products
No public API or bulk export documentation
Saudi banking and Muqeem Portal integrations do not map to non-MENA destinations
Per-user pricing model means user count drives migration cost
Odoo ERP gotchas
No rollback for CSV imports
External ID conflicts on re-import
Many2many field encoding in CSV imports
Large export timeouts require batching
Version schema drift between Odoo releases
Pair-specific challenges
Migration approach
Export negotiation and schema discovery
We contact BusinessCloud support to request a full database export covering Companies, Contacts, Products, Inventory, Purchase Orders, Sales Orders, Invoices, Journal Entries, and any custom entities. If the export is granted, we receive SQL dump, CSV, or XML files. If not, we document the exportable reports available in the BusinessCloud web interface and design a multi-session extraction plan. We then reverse-engineer the schema from the exported files: table names, column names, foreign key candidates, and custom field detection. This phase produces the BusinessCloud-to-Odoo object mapping matrix and identifies any data quality issues (duplicates, missing required fields, inconsistent dates) before we write the first import script.
Odoo environment provisioning and schema design
We provision the target Odoo environment (Odoo Online for SaaS, Odoo.sh for managed PaaS, or self-hosted Community for maximum control) and configure the initial company settings including fiscal year, currency, and multi-company flags if applicable. We then deploy the Odoo module structure: we install the apps in scope (Sales, Purchase, Inventory, Accounting, CRM), create custom fields on standard models where BusinessCloud custom fields exist, and create ir.model records for any BusinessCloud entity with no standard Odoo equivalent. We configure the chart of accounts using the mapping matrix from discovery, and we set the inventory valuation method to match BusinessCloud.
Data cleansing and reconciliation queue
We run the BusinessCloud export through a data quality pipeline: duplicate detection on Contacts (by email and phone), inactive record retirement (closed/cancelled orders older than three years can be archived rather than migrated at the customer's choice), missing required field flagging (Contacts without email, Products without SKU), and currency code normalization. We deliver a cleansing report to the customer with a decision checklist: archive or migrate old records, how to handle duplicate contacts, and which invoices are considered open versus closed. No import begins until the customer approves the cleansing decisions.
Sandbox migration and validation
We execute a full migration into an Odoo test environment (a second Odoo Online database, Odoo.sh staging branch, or a local Community sandbox) using production-like data volume. The customer's finance team reconciles: account count and balance on the chart of accounts, open invoice totals by customer and supplier, inventory on-hand values by warehouse, and open PO and SO counts. We reconcile row counts and spot-check ten to twenty random records per object type against the BusinessCloud source. The customer signs off the sandbox validation before production migration begins.
Production migration in dependency order
We run production migration in strict dependency order: chart of accounts first (all other records reference accounts), then Companies and Contacts (all transactional records reference partners), then Products (sales and purchase lines reference products), then Inventory stock.quant records, then Purchase Orders, then Sales Orders, then Invoices, then Journal Entries, then CRM Leads. Each phase emits a row-count and balance-reconciliation report. We run Odoo migrations in low-activity windows to minimize business disruption. Any records rejected by Odoo's validation rules during import are routed to a correction queue and reprocessed before the next phase begins.
Cutover, validation, and automation handoff
We freeze writes on the BusinessCloud side during cutover, run a final delta migration of any records modified during the migration window, then close the BusinessCloud migration scope. We deliver the Automation and Report Inventory document to the customer's Odoo admin. We support a one-week hypercare window to resolve reconciliation issues surfaced by the customer's team during the first business week in Odoo. We do not rebuild BusinessCloud workflows as Odoo ir.actions.server or Studio automations inside the migration scope; that work requires a separate Odoo implementation engagement.
Platform deep dives
BusinessCloud
Source
Strengths
Weaknesses
Odoo ERP
Destination
Strengths
Weaknesses
Complexity grading
Moderate ERP migration. 8 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across BusinessCloud and Odoo ERP.
Object compatibility
8 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
BusinessCloud: Not publicly documented.
Data volume sensitivity
BusinessCloud doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during BusinessCloud to Odoo ERP migration scoping. Not seeing yours? Book a call.
Walk through your BusinessCloud to Odoo ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave BusinessCloud
Other ways to arrive at Odoo ERP
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.