ERP migration
Field-level mapping, validation, and rollback between AltheaSuite and Odoo ERP. We move data and schema; workflows are rebuilt natively in Odoo ERP.
AltheaSuite
Source
Odoo ERP
Destination
Compatibility
8 of 12
objects map 1:1 between AltheaSuite and Odoo ERP.
Complexity
BStandard
Timeline
6-10 weeks
Overview
Moving from AltheaSuite to Odoo ERP is a structural migration for businesses in furniture, appliances, and manufacturing that have outgrown a vertical-specific platform. AltheaSuite's Item-centered data model with serial numbers, lot tracking, and multi-level BOMs requires careful schema translation because Odoo manages these objects differently: Products use Product Category hierarchies, serial numbers live in stock.lot with a lot_id reference on stock.move.line, and BOMs are explicit Odoo BoM records that must be reconstructed from AltheaSuite's nested structure. We request a vendor-mediated data dump from AltheaSuite during discovery (no public API exists), validate the dump's schema completeness, then map every object in dependency order. We do not migrate Workflows, Automations, or vendor-specific customizations; we deliver a written inventory of these for your admin to rebuild in Odoo Studio or with an Odoo partner.
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 AltheaSuite 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.
AltheaSuite
Item
Odoo ERP
Product (product.template + product.product)
1:1AltheaSuite Items map to Odoo product.template for the base product definition and product.product for variants (if serial-controlled or lot-controlled). Item code maps to product.default_code, Item name maps to product.name, and standard cost maps to product.standard_price. Custom Item fields discovered from the vendor-mediated schema export map to custom fields on product.template using Odoo Studio field types. Reorder levels from AltheaSuite map to product.rule_ids (stock.route_rule) if the Odoo Reordering Rules app is active.
AltheaSuite
Custom Item Fields
Odoo ERP
Custom Fields on product.template
lossyAltheaSuite custom fields on Items (dropdown, text, numeric types) are discovered during schema profiling by requesting the full custom field definition list from the customer and verifying against the live system during the profile walkthrough. We create equivalent custom fields in Odoo using ir.model.fields with the matching field type (selection for dropdown, char/text for text, float for numeric). Field labels, help text, and placeholder values are preserved. Type mismatches (e.g., AltheaSuite numeric string vs Odoo float) are handled with explicit cast transforms before import.
AltheaSuite
Customer
Odoo ERP
res.partner (customer=True)
1:1AltheaSuite Customer records map directly to Odoo res.partner with customer_rank set to distinguish from Vendors. Customer name, contact email, phone, and address fields map to the corresponding res.partner fields. If AltheaSuite stores multiple contacts per customer account, we create a primary res.partner record for the account and additional contact records linked via parent_id.
AltheaSuite
Vendor
Odoo ERP
res.partner (supplier=True)
1:1AltheaSuite Vendor records map to Odoo res.partner with supplier_rank set. Vendor contact info, addresses, and supplier-level flags (vendor-managed inventory indicator) preserve as boolean properties. Purchase vendor code maps to product.supplierinfo for use in Purchase Orders.
AltheaSuite
Purchase Order
Odoo ERP
purchase.order + purchase.order.line
1:1AltheaSuite Purchase Orders map to Odoo purchase.order (header) and purchase.order.line (line items). PO number, date, and vendor reference map to their Odoo equivalents. Line item quantities and unit costs map to product_uom_qty and price_unit. Multi-currency fields in AltheaSuite require mapping to the Odoo currency_id on the PO header. Landed cost fields do not migrate directly; we flag these for manual setup in Odoo Purchase Configuration.
AltheaSuite
Sales Order
Odoo ERP
sale.order + sale.order.line
1:1AltheaSuite Sales Orders map to Odoo sale.order and sale.order.line. Order number, order date, and customer reference preserve. Fulfillment status (partial vs. complete) maps to the Odoo delivery state via picking_ids. Delivery assignments linked to the Sales Order in AltheaSuite create linked stock.picking records in Odoo via the sale.order.picking_ids relation.
AltheaSuite
Work Order
Odoo ERP
mrp.production + mrp.workorder
1:1AltheaSuite Work Orders map to Odoo mrp.production (the production order) and mrp.workorder (individual routing steps). The source Item linked to the Work Order becomes the mrp.production.product_id. Production status from AltheaSuite (pending, in-progress, complete) maps to mrp.production.state. Step-level labor and machine time entries migrate as a child table to mrp.workorder time-tracking records if the Odoo Timesheets or Manufacturing Timesheets app is active.
AltheaSuite
Multi-level BOM
Odoo ERP
mrp.bom + mrp.bom.line
1:manyAltheaSuite multi-level BOMs (nested sub-assemblies) are flattened during migration mapping: each BOM level becomes a separate mrp.bom record in Odoo. The top-level BOM references the finished product; sub-assemblies reference their respective intermediate product as product_id, with bom_line_ids pointing to component Items. We preserve the quantity-per-unit at each level in mrp.bom.line.product_qty. Routing operations (work centers, cycle times) map to mrp.routing.workcenter records linked to the BOM if the Odoo MRP Routing or Work Orders app is active.
AltheaSuite
Serial Number Record
Odoo ERP
stock.lot
1:1AltheaSuite serial number assignment records map to Odoo stock.lot. Each stock.lot record stores the lot_name (serial number), product_id (linked to the migrated Product), and the ref field for any supplier or manufacturing lot reference. The serial-to-item linkage is preserved by resolving the parent Item to the correct product.product in Odoo. We extract the full serial-to-item mapping as a child table during the pre-migration dump and re-associate each lot record at the destination. Orphaned serial records (no parent Item) are flagged for manual resolution before finalizing the import.
AltheaSuite
Lot Number Record
Odoo ERP
stock.lot + shelf_date (expiry)
1:1AltheaSuite lot-controlled Items with lot number and expiry date metadata map to Odoo stock.lot with lot_name set to the lot number and shelf_date set to the expiry date. We migrate lot assignment records with their parent Items and preserve expiry date fields for destinations running FEFO (First Expired First Out) logic in Odoo Inventory. Lot traceability reports in Odoo (track.productionLot) use stock.move.line records linked to the lot to reconstruct the full genealogy.
AltheaSuite
Item Reorder Level
Odoo ERP
stock.warehouse.orderpoint
lossyAltheaSuite reorder level automation per Item maps to Odoo stock.warehouse.orderpoint records (Reordering Rules). We extract the reorder point quantity and minimum/maximum quantities from AltheaSuite Item settings and create corresponding orderpoint records per warehouse in Odoo. If the destination Odoo instance does not have the MRP Multi-Level or Stock apps active, reorder rules are preserved as a configuration inventory document for the customer's admin to set up post-migration.
AltheaSuite
Price List / Vendor Cost
Odoo ERP
product.supplierinfo + product.pricelist
lossyVendor-specific cost prices in AltheaSuite map to product.supplierinfo records linked to the Vendor (res.partner) and the Product. Standard selling price lists map to Odoo product.pricelist records. Multi-currency vendor costs in AltheaSuite require mapping to the corresponding Odoo currency on the product.supplierinfo record. We flag any pricing rules that use AltheaSuite-specific discount logic for manual conversion to Odoo Pricelist Rules.
| AltheaSuite | Odoo ERP | Compatibility | |
|---|---|---|---|
| Item | Product (product.template + product.product)1:1 | Fully supported | |
| Custom Item Fields | Custom Fields on product.templatelossy | Fully supported | |
| Customer | res.partner (customer=True)1:1 | Fully supported | |
| Vendor | res.partner (supplier=True)1:1 | Fully supported | |
| Purchase Order | purchase.order + purchase.order.line1:1 | Fully supported | |
| Sales Order | sale.order + sale.order.line1:1 | Fully supported | |
| Work Order | mrp.production + mrp.workorder1:1 | Fully supported | |
| Multi-level BOM | mrp.bom + mrp.bom.line1:many | Fully supported | |
| Serial Number Record | stock.lot1:1 | Fully supported | |
| Lot Number Record | stock.lot + shelf_date (expiry)1:1 | Fully supported | |
| Item Reorder Level | stock.warehouse.orderpointlossy | Fully supported | |
| Price List / Vendor Cost | product.supplierinfo + product.pricelistlossy | 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.
AltheaSuite gotchas
Pricing is not publicly available
No public API or documented export endpoints
Custom fields on Items must be explicitly enumerated
Serialized and lot-controlled inventory requires traceability reconciliation
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
Discovery and export coordination with AltheaSuite
We request a structured data dump from the AltheaSuite team covering Items, Customers, Vendors, Purchase Orders, Sales Orders, Work Orders, serial number records, lot number records, and any custom Item field definitions. We audit the dump's schema completeness and record counts against what the customer expects. We also confirm the destination Odoo edition (Community free vs. paid apps for Inventory, Manufacturing, Purchase), the Odoo version target, and which modules are active. The discovery output is a written migration scope and data quality gap report.
Data quality audit and deduplication
We run duplicate detection across Customers (by name, email, phone), Vendors (by name, tax ID), and Items (by SKU, name). We flag inactive Items with open Work Orders, customers with missing addresses, and Items with inconsistent reorder levels. The customer resolves data quality issues in the AltheaSuite source (or approves the duplicates for manual resolution post-migration) before we begin schema mapping. Skipping this step transfers dirty data into Odoo, where duplicate records compound across Orders and Inventory.
Odoo schema preparation and BOM restructuring
We create the destination Odoo schema: product.template and product.product records for Items, res.partner records for Customers and Vendors, purchase.order and sale.order models for orders, and mrp.bom records for BOM structures. Multi-level BOMs are flattened into separate Odoo BoM records with parent-child linkage. Custom Item fields from AltheaSuite are created as Odoo custom fields with type-matched field definitions. If the Odoo Inventory and Manufacturing apps are not yet active in the destination instance, we configure them during this step.
Sandbox migration and reconciliation
We run a full migration into an Odoo Sandbox using production-like data volume. The customer's operations lead reconciles record counts (Items in, Customers in, Vendors in, Work Orders in, Lot/Serial records in), spot-checks 25-50 random records against the AltheaSuite source, and validates that serial-to-item and lot-to-item associations are intact. BOM structure is validated by checking that all component Items in each mrp.bom record resolve to valid product.product records. Any mapping corrections are applied before production migration.
Production migration in dependency order
We run production migration in record-dependency order: product.product (from Items), res.partner (Customers then Vendors), mrp.bom (from BOM structures), purchase.order (from Purchase Orders), sale.order (from Sales Orders), mrp.production (from Work Orders), and stock.lot (serial and lot records last, because they require parent product.product resolution). Each phase emits a row-count reconciliation report. We use Odoo's XML-RPC API with batch chunking and exponential backoff on rate-limit responses. Active AltheaSuite writes are frozen during the cutover window.
Cutover, validation, and workflow handoff
We run a final delta migration of any records modified during the cutover window, then enable Odoo as the system of record. We validate serial and lot traceability by running Odoo's lot genealogy report against a sample of migrated Work Orders. We deliver a written inventory of AltheaSuite automations, reorder rules, and vendor-specific customizations for the customer's Odoo admin or partner to rebuild using Odoo Studio or Odoo Workflow Designer. We support a one-week hypercare window for reconciliation issues. We do not rebuild automations as Odoo Workflows inside the migration scope; that is a separate engagement.
Platform deep dives
AltheaSuite
Source
Strengths
Weaknesses
Odoo ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 3 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across AltheaSuite and Odoo ERP.
Object compatibility
3 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
AltheaSuite: Not publicly documented.
Data volume sensitivity
AltheaSuite 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 AltheaSuite to Odoo ERP migration scoping. Not seeing yours? Book a call.
Walk through your AltheaSuite 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 AltheaSuite
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.