ERP migration

Migrate from AI Works to Odoo ERP

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

AI Works logo

AI Works

Source

Odoo ERP

Destination

Odoo ERP logo

Compatibility

70%

7 of 10

objects map 1:1 between AI Works and Odoo ERP.

Complexity

BStandard

Timeline

4-6 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from AI Works to Odoo ERP is a structural migration that requires rethinking how business records map into Odoo's modular application architecture. AI Works stores core entities (Accounts, Invoices, Purchase Orders, Products, Custom Fields) in a flat-to-moderately-relational schema, while Odoo separates these into distinct apps (Accounting, Purchase, Inventory, Product variants) with strict foreign-key constraints and account-type classification. We resolve the parent-record dependency chain first — Accounts before Invoices, Products before Inventory moves — and register any AI Works custom fields as Odoo module fields via the res.partner or ir.model.fields inheritance before import. Multi-currency and tax-code mapping require explicit configuration because Odoo enforces chart-of-accounts structure that AI Works does not. Workflows, approval chains, and custom automation built inside AI Works do not migrate as code; we deliver a written inventory of every active workflow and its Odoo Studio equivalent for the customer's admin to rebuild post-cutover.

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

AI Works logo

AI Works

What's pushing teams away

  • No public product documentation or schema reference — customers needing to migrate data cannot self-serve and must rely on direct vendor engagement.
  • Not a packaged ERP in the conventional sense — companies needing a system of record with published modules and roadmap typically move to NetSuite, Acumatica, or Microsoft Dynamics 365.
  • No published pricing, no integrations directory, and no public API surface available on the corporate website.
  • Small-vendor risk for finance-critical workflows; customers outgrowing the team typically migrate to better-supported platforms.
  • Limited third-party reviewer coverage — there is no G2/Capterra/Software Advice presence to validate fit or compare against alternatives.

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 AI Works objects map to Odoo ERP

Each row shows how a AI Works 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.

AI Works

User

maps to

Odoo ERP

User

1:1
Fully supported

AI Works User records map to Odoo res.users. We match by email address as the dedupe key and carry over display_name, login, and active status. Access groups and security roles in AI Works require a manual mapping step during scoping because Odoo's access-rights model (record rules, groups per app) is configured in Settings > Users > Access Rights and must align with the Odoo apps the customer purchases.

AI Works

Account

maps to

Odoo ERP

Partner (res.partner)

1:1
Fully supported

AI Works Account records map to Odoo res.partner, with company-type distinction (is_company flag) separating vendors from customers. address fields (street, city, state, country) map to Odoo's address fields using standard CSV column headers. The account_type field in AI Works determines whether the Odoo partner is created with customer=True, supplier=True, or both. Partners are imported before any related Invoice or Purchase Order records to satisfy foreign-key constraints.

AI Works

Invoice

maps to

Odoo ERP

Account Move (account.move)

1:1
Fully supported

AI Works Invoice records map to Odoo account.move with move_type distinction: customer invoices map to out_invoice, vendor bills to in_invoice, credit notes to out_refund and in_refund. The invoice_date maps to date, invoice_number to name, and amount_total to amount_total with tax handled separately via Odoo's tax-code mapping. Line items map to account.move.line with account_id resolved from the AI Works line-account field to an Odoo account. If AI Works stores multi-currency, we configure Odoo's multi-currency on the res.currency and set rate locks on the migration date.

AI Works

Purchase Order

maps to

Odoo ERP

Purchase Order (purchase.order)

1:1
Fully supported

AI Works Purchase Orders map to Odoo purchase.order. PO status (Draft, Sent, Confirmed, Received) maps to Odoo's state field (draft, sent, purchase, done). Vendor account lookup resolves to the res.partner record created from the AI Works Account. PO lines map to purchase.order.line with product_id resolved from the Product mapping and qty_ordered mapped to product_qty.

AI Works

Product

maps to

Odoo ERP

Product (product.product)

1:1
Fully supported

AI Works Product records map to Odoo product.product (the stockable variant object) and product.template (shared attributes). We separate product_name, description, and list_price onto product.template while handling multi-variant products as separate product.product records with their own product_tmpl_id. If AI Works stores product_type (goods vs service), it maps to Odoo's type field (product vs service). Cost price maps to standard_price for inventory valuation.

AI Works

Inventory / Stock

maps to

Odoo ERP

Quant (stock.quant)

1:1
Fully supported

AI Works inventory balances map to Odoo stock.quant records, with location_id resolved to the destination warehouse (or the default stock warehouse if AI Works uses a single-location model). quantity maps directly to Odoo's inventory_quantity or qty field. We configure the inventory valuation method (Standard Price, Average Cost, FIFO) before import because Odoo locks valuation entries at product.template level. Lot/serial number tracking requires additional mapping if AI Works stores these attributes.

AI Works

Custom Field

maps to

Odoo ERP

Custom Field (via custom module)

lossy
Fully supported

AI Works custom fields on any core entity require registration as Odoo module fields. We create a Python model inheriting the target Odoo model (res.partner, account.move, etc.) with the field defined at the ORM level, and add the field to the corresponding XML view using xpath inheritance. This ensures custom fields persist across Odoo version upgrades. We document each custom field's Odoo type mapping (Char, Integer, Float, Selection, Many2one, etc.) during the scoping phase before writing any module code.

AI Works

Approval / Workflow Chain

maps to

Odoo ERP

Written Inventory (no code migration)

1:1
Fully supported

AI Works approval chains and document workflows are not migrated as Odoo automated actions. We audit every active approval chain, document its trigger conditions, approver assignments, and downstream actions, and deliver a written map recommending equivalent Odoo Studio or server action configurations for the customer's admin to implement post-migration. This is a documentation deliverable, not a data migration.

AI Works

Contact / Address

maps to

Odoo ERP

Partner Contact (res.partner)

1:many
Fully supported

AI Works contacts attached to an Account merge into Odoo res.partner records with parent_id set to the company partner. If AI Works stores contact role or department, we preserve these in custom fields on the contact partner. phone and email map to phone and email fields; a dedicated function field maps to the partner's formatted address block.

AI Works

Tax / Fiscal Configuration

maps to

Odoo ERP

Tax (account.tax)

lossy
Fully supported

AI Works tax rates map to Odoo account.tax records with the correct tax_scope (sale, purchase, none), amount_type (fixed, percent, group), and children taxes for compound tax structures. We configure fiscal positions (account.fiscal.position) to handle tax mapping differences for vendors and customers in different jurisdictions before any Invoice or PO import begins.

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.

AI Works logo

AI Works gotchas

High

Vendor is not positioned as a conventional packaged ERP

High

No publicly documented API or schema

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

  • Custom fields require Odoo module registration to persist

    AI Works custom fields added directly to record models do not have a direct import equivalent in Odoo. Odoo stores all persistent fields in the database via module-defined ORM field definitions; adding fields through the UI (Settings > Technical > Fields) creates temporary fields that are overwritten on upgrade or module reinstall. We create a custom Python module per entity with proper field definitions and XML view inheritance so that migrated custom fields survive Odoo version upgrades. The customer must review and approve the custom field-to-Odoo-type mapping before module creation because field type changes (e.g., Char to Selection) require data transformation.

  • Odoo's chart-of-accounts structure is mandatory for invoice import

    AI Works invoices with line items referencing account codes require a pre-existing Odoo chart of accounts (account.account records with unique code, name, and account_type) before any account.move or purchase.order import. Accounts Receivable and Accounts Payable must exist as reconcilable bank-type accounts. If AI Works uses a flat account structure without Odoo's account-type classification (receivable, payable, bank, expense, revenue), we configure the chart of accounts during the scoping phase and the customer must validate it with their accountant before data migration begins.

  • Multi-currency invoice amounts require exchange rate locks

    If AI Works stores invoices in multiple currencies, Odoo requires active currency records (res.currency), configured exchange rates, and locked rate dates for each imported document. Odoo recalculates currency amounts on any rate change, which can alter the reported amount_total after migration if rates are not pinned. We set the rate on the currency record to the AI Works transaction date's rate and flag the document as requiring accountant review if the original currency differs from the company's base currency.

  • Odoo automations and server actions do not migrate from AI Works

    AI Works workflow rules, approval chains, and scheduled automations are not exported in a format compatible with Odoo's automated actions or server actions. We audit and document every active AI Works automation (trigger, conditions, actions, schedule) as a written handoff for the customer's Odoo admin to rebuild in Odoo Studio. The migration does not include Odoo Studio or Python-based server action creation as a standard deliverable; this is scope for a separate engagement or internal admin work.

  • Duplicate and orphaned records must be cleaned before import

    Migrations from systems with fewer data-integrity controls (such as mid-market AI-built ERPs) frequently surface duplicate vendor listings, Account records without contact details, and products missing SKUs or pricing. Odoo will import any valid CSV data including duplicates. We flag duplicate records during the pre-migration data audit and deliver a deduplication report with a recommended resolution (merge, archive, or drop) before import. Running the import without this step results in duplicate partners and products that create reconciliation work at month-end and require retroactive cleanup.

Migration approach

Six steps for a successful AI Works to Odoo ERP data migration

  1. Source data audit and Odoo edition selection

    We extract a full export from AI Works covering Users, Accounts, Invoices, Purchase Orders, Products, Inventory balances, and any Custom Fields. We profile data quality: duplicate accounts, missing contact details, unmapped tax codes, inconsistent currency amounts, and orphaned records. In parallel, we confirm which Odoo apps the customer will activate (Accounting, Inventory, Purchase, HR) and which edition (Community or Enterprise) because Community requires manual module installation while Enterprise provides in-app app installation. The output is a written data audit report and an Odoo edition recommendation.

  2. Odoo schema design and chart of accounts configuration

    We configure the destination Odoo instance: chart of accounts with account codes and types, tax codes with fiscal positions, warehouse and location structure for inventory, product categories, and units of measure. We create any required custom Odoo module files (Python model definitions and XML view patches) for AI Works custom fields, with each field mapped to a specific Odoo field type. This schema design is deployed into a staging Odoo environment before any production data moves.

  3. Staging migration and reconciliation

    We run a full migration into a staging Odoo instance using representative data volume. The customer's finance lead reconciles 25-50 randomly sampled records (invoices, POs, account balances) against the AI Works source. Inventory quant totals are reconciled at the warehouse level. Any field mapping corrections, tax configuration gaps, or account code mismatches are resolved here before production migration begins.

  4. Owner and user provisioning

    We extract every distinct AI Works User and map them by email to Odoo res.users. Users without a matching Odoo account go to a provisioning queue for the customer's admin. We confirm access group assignments and the list of Odoo apps each user will access. This step gates the record import because OwnerId references on invoices and POs must point to valid Odoo users.

  5. Production migration in dependency order

    We migrate in record-dependency order: Users first (validated), then Partners (Accounts and Contacts), then Product Templates and Products, then Inventory Quants, then Purchase Orders, then Account Moves (Invoices and Bills), then Custom Fields via the custom module. Each phase emits a row-count reconciliation report. Multi-currency documents are imported with exchange rate locks applied. Tax lines are created via Odoo's tax computation engine rather than hard-coded amounts to ensure tax report accuracy.

  6. Cutover, validation, and automation handoff

    We freeze AI Works writes during the cutover window, run a final delta migration of any records modified since the initial export, and enable Odoo as the system of record. We validate account.move totals against AI Works invoice totals at the portfolio level. We deliver the automation inventory document to the customer's Odoo admin for rebuild in Odoo Studio or as server actions. We provide a one-week hypercare window for reconciliation issues. Odoo Studio rebuild, workflow rebuild, and admin training are outside standard migration scope and are separate engagements.

Platform deep dives

Context on both ends of the pair

AI Works logo

AI Works

Source

Strengths

  • Flexible custom-build engagement model suits organizations needing bespoke AI overlays.
  • Direct, small-team vendor relationship.
  • AI talent resourcing can complement internal teams.
  • No prescriptive product lock-in for those starting from a custom data model.

Weaknesses

  • No public ERP product documentation, schema, or pricing.
  • Absent from major reviewer aggregators (G2, Capterra, Software Advice).
  • Migration scoping requires the vendor's direct cooperation; self-service is not viable.
  • Roadmap and product versioning are not publicly visible.
  • Small-vendor delivery risk for finance-critical systems.
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. 1 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 AI Works and Odoo ERP.

  • Object compatibility

    B

    1 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

    AI Works: Not publicly documented — typical SaaS limits assumed and confirmed during scoping.

  • Data volume sensitivity

    B

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

Estimator

Estimate your AI Works 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 AI Works to Odoo ERP data migrations

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

Can't find your answer?

Walk through your AI Works to Odoo ERP migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most AI Works to Odoo migrations land between four and six weeks for accounts with under 10,000 Account records, 5,000 Invoices, and 2,000 Products with no complex multi-currency or multi-warehouse inventory structure. Migrations with large historical transaction volumes (over 50,000 invoices or POs), complex inventory valuation methods (FIFO with lot tracking), multiple currency configurations, or significant custom field counts requiring dedicated Odoo module development move to ten to sixteen weeks because of schema design, custom module development, and inventory reconciliation scope.

Adjacent paths

Related migrations to explore

Ready when you are

Move from AI Works.
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