ERP migration
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
Source
Odoo ERP
Destination
Compatibility
7 of 10
objects map 1:1 between AI Works and Odoo ERP.
Complexity
BStandard
Timeline
4-6 weeks
Overview
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.
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 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
Odoo ERP
User
1:1AI 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
Odoo ERP
Partner (res.partner)
1:1AI 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
Odoo ERP
Account Move (account.move)
1:1AI 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
Odoo ERP
Purchase Order (purchase.order)
1:1AI 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
Odoo ERP
Product (product.product)
1:1AI 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
Odoo ERP
Quant (stock.quant)
1:1AI 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
Odoo ERP
Custom Field (via custom module)
lossyAI 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
Odoo ERP
Written Inventory (no code migration)
1:1AI 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
Odoo ERP
Partner Contact (res.partner)
1:manyAI 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
Odoo ERP
Tax (account.tax)
lossyAI 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.
| AI Works | Odoo ERP | Compatibility | |
|---|---|---|---|
| User | User1:1 | Fully supported | |
| Account | Partner (res.partner)1:1 | Fully supported | |
| Invoice | Account Move (account.move)1:1 | Fully supported | |
| Purchase Order | Purchase Order (purchase.order)1:1 | Fully supported | |
| Product | Product (product.product)1:1 | Fully supported | |
| Inventory / Stock | Quant (stock.quant)1:1 | Fully supported | |
| Custom Field | Custom Field (via custom module)lossy | Fully supported | |
| Approval / Workflow Chain | Written Inventory (no code migration)1:1 | Fully supported | |
| Contact / Address | Partner Contact (res.partner)1:many | Fully supported | |
| Tax / Fiscal Configuration | Tax (account.tax)lossy | 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.
AI Works gotchas
Vendor is not positioned as a conventional packaged ERP
No publicly documented API or schema
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
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.
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.
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.
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.
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.
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
AI Works
Source
Strengths
Weaknesses
Odoo ERP
Destination
Strengths
Weaknesses
Complexity grading
Standard ERP migration. 1 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 AI Works and Odoo ERP.
Object compatibility
1 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
AI Works: Not publicly documented — typical SaaS limits assumed and confirmed during scoping.
Data volume sensitivity
AI Works 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 AI Works to Odoo ERP migration scoping. Not seeing yours? Book a call.
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 consultationAdjacent paths
Other ways to leave AI Works
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.