ERP migration

Migrate from AltheaSuite to Odoo ERP

Field-level mapping, validation, and rollback between AltheaSuite and Odoo ERP. We move data and schema; workflows are rebuilt natively in Odoo ERP.

AltheaSuite logo

AltheaSuite

Source

Odoo ERP

Destination

Odoo ERP logo

Compatibility

67%

8 of 12

objects map 1:1 between AltheaSuite and Odoo ERP.

Complexity

BStandard

Timeline

6-10 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

AltheaSuite logo

AltheaSuite

What's pushing teams away

  • Prospective customers and app reviewers cite opaque pricing as a primary friction point — AltheaSuite requires booking a demo to get any pricing information, which creates a barrier for self-service evaluation.
  • The Shopify app reviewer notes that after installing the app, they discovered they cannot create an account independently and must go through a sales-driven demo process first.
  • Customers requiring enterprise-scale reporting, multi-entity consolidation, or complex multi-currency accounting often find AltheaSuite's analytics insufficient compared to NetSuite or Odoo.

Choosing

Odoo ERP logo

Odoo ERP

What's pulling them in

  • Modular pay-as-you-grow model with 80+ apps under one database — teams start with CRM and add Accounting, Inventory, or Manufacturing without switching platforms.
  • Free Community edition lets businesses validate Odoo fit before committing to Enterprise licensing costs that scale with user count.
  • Lowest per-user pricing among mid-market ERPs, with a published free tier for one app and Standard plans starting around $24.90 per user per month.
  • Native integration between modules — a confirmed Sales Order automatically updates inventory, invoicing, and accounting without manual re-entry.
  • Strong Odoo Gold Partner ecosystem provides local implementation support, reducing risk for companies without in-house developers.

Object mapping

How AltheaSuite objects map to Odoo ERP

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

maps to

Odoo ERP

Product (product.template + product.product)

1:1
Fully supported

AltheaSuite 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

maps to

Odoo ERP

Custom Fields on product.template

lossy
Fully supported

AltheaSuite 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

maps to

Odoo ERP

res.partner (customer=True)

1:1
Fully supported

AltheaSuite 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

maps to

Odoo ERP

res.partner (supplier=True)

1:1
Fully supported

AltheaSuite 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

maps to

Odoo ERP

purchase.order + purchase.order.line

1:1
Fully supported

AltheaSuite 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

maps to

Odoo ERP

sale.order + sale.order.line

1:1
Fully supported

AltheaSuite 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

maps to

Odoo ERP

mrp.production + mrp.workorder

1:1
Fully supported

AltheaSuite 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

maps to

Odoo ERP

mrp.bom + mrp.bom.line

1:many
Fully supported

AltheaSuite 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

maps to

Odoo ERP

stock.lot

1:1
Fully supported

AltheaSuite 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

maps to

Odoo ERP

stock.lot + shelf_date (expiry)

1:1
Fully supported

AltheaSuite 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

maps to

Odoo ERP

stock.warehouse.orderpoint

lossy
Fully supported

AltheaSuite 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

maps to

Odoo ERP

product.supplierinfo + product.pricelist

lossy
Fully supported

Vendor-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.

Gotchas + challenges

What specifically takes care here

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 logo

AltheaSuite gotchas

High

Pricing is not publicly available

High

No public API or documented export endpoints

Medium

Custom fields on Items must be explicitly enumerated

Medium

Serialized and lot-controlled inventory requires traceability reconciliation

Odoo ERP logo

Odoo ERP gotchas

High

No rollback for CSV imports

High

External ID conflicts on re-import

Medium

Many2many field encoding in CSV imports

Medium

Large export timeouts require batching

Medium

Version schema drift between Odoo releases

Pair-specific challenges

  • AltheaSuite has no public API — export is vendor-mediated

    Research found no publicly documented REST API, GraphQL endpoint, or bulk export endpoint for AltheaSuite. All export pathways appear to require direct engagement with the AltheaSuite team. We handle this during the discovery phase by requesting a structured data dump directly from AltheaSuite and validating the dump's schema completeness before mapping begins. If no structured export is available, the migration scope must include manual extraction steps with the customer's AltheaSuite account team, which adds time to the discovery phase.

  • Multi-level BOMs require flattening and structural redesign

    AltheaSuite Work Orders carry nested sub-assembly BOM structures that are deeply integrated into the Item definition. Odoo treats BoM as an explicit, separately configured object (mrp.bom) linked to a Product but not embedded in it. We flatten AltheaSuite's multi-level BOM hierarchies during migration mapping and reconstruct them as separate mrp.bom records with parent-child relationships. This requires an explicit BoM redesign step that is more than a field mapping — it is a structural transformation. We flag any AltheaSuite BOM logic (scrap rates, yield assumptions, phantom BOMs) that does not map cleanly to Odoo's BoM types (kit, manufacture, subcontract) for customer review.

  • Serial and lot records can be orphaned if parent Item mapping fails

    AltheaSuite tracks serial numbers and lot numbers as separate assignment records linked to Items. If the parent Item fails to map to an Odoo product.product record (due to missing SKU match, duplicate product creation, or variant resolution issues), the associated serial or lot record becomes orphaned in the migration. We extract the full serial-to-item and lot-to-item mapping as child tables, run parent-record validation before each batch of lot/serial inserts, and flag any orphaned records for manual resolution before finalizing the import.

  • Odoo Inventory and Manufacturing are paid apps not included in free Community

    Odoo's Inventory and Manufacturing apps (required for the serial/lot tracking and BOM structures that map from AltheaSuite) are paid applications at $31/user/month per app on the Standard plan. The free Odoo Community edition ships without these apps, and enabling them on an existing Community instance requires upgrading to a paid plan or self-hosting the apps from the Odoo Store. We confirm the destination Odoo edition and active apps during scoping so that the migration mapping targets the correct object set. If the customer migrates to Community intending to add Inventory later, we flag this as a configuration gap in the handoff document.

  • Historical data quality in vendor-mediated dumps is variable

    Odoo ERP migration best practices (Baker Tilly, Stellar One) consistently identify legacy data quality as the most common cause of post-migration operational problems. AltheaSuite data exported via a vendor-mediated dump may contain inconsistent address formatting, duplicate customer records, stale Item definitions, or incomplete Work Order histories depending on how long the system has been in use. We run a pre-migration data audit against the AltheaSuite dump, produce a data quality report (duplicate detection, missing required fields, inactive Items with open orders), and present it to the customer before migration mapping begins. Cleaning dirty data before migration costs less than cleaning it after.

Migration approach

Six steps for a successful AltheaSuite to Odoo ERP data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

AltheaSuite logo

AltheaSuite

Source

Strengths

  • Deep inventory tracking with serial numbers, lot control, expiry dates, and reorder level automation.
  • Modular architecture allowing SMBs to adopt only the modules they need and expand over time.
  • Integrated POS and inventory in a single platform for retail-facing businesses.
  • Multi-level BOM support for discrete manufacturing and assembly operations.
  • Cloud-based with mobile access on iOS and Android for field and floor teams.

Weaknesses

  • Pricing is not publicly disclosed — customers must contact sales or book a demo to receive a quote, limiting self-service evaluation.
  • No public API documentation or developer portal found in research, making programmatic data export uncertain without direct vendor engagement.
  • No self-service signup available — even the Shopify app requires linking to an existing AltheaSuite account after a demo booking.
  • Limited independent review volume (9 reviews across major platforms) makes it difficult to assess long-term reliability and support quality at scale.
  • Customization is praised but the effort and cost of that customization is not transparent, leading some customers to feel locked into the vendor for ongoing changes.
Odoo ERP logo

Odoo ERP

Destination

Strengths

  • Modular architecture with 80+ apps sharing one database — add Sales, Accounting, Inventory, and Manufacturing incrementally.
  • Free Community edition for self-hosting with no per-user license cost, backed by an active open-source community.
  • Per-user pricing starting around $24.90/month on Standard, significantly lower than comparable ERPs like NetSuite or SAP.
  • Automatic workflow propagation across modules — a confirmed sales order updates inventory, triggers invoicing, and posts accounting entries without manual steps.
  • Odoo.sh provides a managed cloud hosting environment with CI/CD for custom module deployment and staging databases.

Weaknesses

  • Performance suffers under heavy customization — large implementations with many active modules require dedicated optimization.
  • No single-click migration between Odoo major versions; each release introduces ORM changes, deprecated API calls, and schema revisions requiring manual adaptation.
  • Per-user and per-module licensing costs can escalate unpredictably for growing teams adding multiple apps.
  • Steep learning curve with hundreds of configuration options across dozens of modules creates adoption friction and training requirements.
  • Support tiers on Enterprise have inconsistent response times, pushing some customers toward alternatives with more reliable SLAs.

Complexity grading

How hard is this migration?

Standard ERP migration. 3 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across AltheaSuite and Odoo ERP.

  • Object compatibility

    B

    3 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    AltheaSuite: Not publicly documented.

  • Data volume sensitivity

    B

    AltheaSuite doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your AltheaSuite to Odoo ERP migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about AltheaSuite to Odoo ERP data migrations

Answers to the questions buyers ask most during AltheaSuite to Odoo ERP migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between six and ten weeks for accounts under 5,000 Items, 2,000 Customers, and 1,000 Work Orders with clean data and a straightforward BOM structure. Migrations with multi-level BOMs (5+ nesting levels), large serial/lot histories (over 50,000 lot records), multi-location inventory, or complex Purchase Order histories move to ten to eighteen weeks because of BOM restructuring, lot traceability reconciliation, and vendor-mediated export coordination during discovery.

Adjacent paths

Related migrations to explore

Ready when you are

Move from AltheaSuite.
Land in Odoo ERP, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day