Migrate from Agility ERP to Odoo ERP

Agility ERP Customer records map to Odoo res.partner with the customer_rank set to a positive value (or customer boolean flag enabled) to classify as a customer-type partner. Address records in Agility ERP map to Odoo partner address fields (street, city, state, zip, country) using the partner_address model. Payment terms from Agility ERP map to Odoo property_payment_term_id on the partner. We validate email format and flag duplicate customer names across the import set to prevent double-creation in Odoo.

Agility ERP Vendor records map to Odoo res.partner with the supplier_rank set to a positive value to classify as a vendor-type partner. Remit-to addresses in Agility ERP that are stored as separate address records map to additional partner contact records of type invoice or default. Tax ID fields migrate to Odoo's l10n_base_vat field or a custom field if the country's VAT handling requires it. Payment terms map to property_supplier_payment_term_id. We check for duplicate vendor names across the import set to prevent double-creation in the target ERP.

Open sales orders from Agility ERP transfer as Odoo sale.order records with sale.order.line children carrying quantity, unit price, and product references. Agility ERP uses proprietary order status labels (Open, Released, Backordered, etc.) that do not map directly to Odoo's standard sale_order states (draft, sent, sale_order, done, cancelled). We build a customer-specific status lookup table during the discovery phase before migration so every order lands with the correct Odoo state. The original Agility ERP order number migrates as the Odoo sale_order name or client_order_ref. Odoo requires the partner_id (customer) to exist before the sale order is imported, so partner migration must complete first.

Open purchase orders map to Odoo purchase.order using the same status-mapping logic applied for sales orders. Line-level purchase order data transfers with product reference, quantity, and price on purchase.order.line. The Agility ERP supplier reference field migrates as client_order_ref on the purchase order line. Odoo requires the partner_id (vendor) to exist before the purchase order is imported, so vendor partner migration must complete before purchase order import begins.

Agility ERP inventory items map to Odoo product.product (or product.template depending on whether variant management is required). The item type in Agility ERP determines the Odoo product type: storable items map to product.type equal to product, consumables to consumable, and services to service. Cost layer data from Agility ERP including average cost, FIFO cost, or lot cost requires explicit mapping to Odoo's standard_price field or move-based valuation depending on the costing method selected during discovery. On-hand quantities and reorder points migrate but may require re-evaluation against the destination warehouse configuration in Odoo.

Agility ERP account codes, descriptions, and account type classification (asset, liability, expense, revenue) map to Odoo account.account records scoped by company_id. Odoo imposes a 64-character limit on account.code. We audit every Agility ERP account code against this limit during scoping. Codes exceeding 64 characters are flagged, renumbered with a systematic prefix-and-truncation approach, and tracked in a mapping table delivered alongside the migrated chart of accounts. The mapping table allows the customer's accountant to reconcile any downstream reporting that references the original Agility ERP account code.

Fixed asset records including depreciation schedules are not accessible via the Agility ERP standard export or API layer. Customers with a non-zero fixed asset balance require a custom database extraction coordinated directly with Agility ERP support, which adds lead time and may require a separate professional services engagement. We flag any customer with a non-zero fixed asset balance during scoping, coordinate the custom extract before the migration window opens, and import the resulting data into Odoo's account.asset management module once the chart of accounts and journal entries are validated.

Custom fields added by the customer in Agility ERP are stored in a non-standard extension table that sits outside the main export layer. Each custom field requires field-by-field review and explicit mapping to an Odoo ir.model.fields definition (or a custom field with __custom suffix) before the parent record migration begins. We build the full custom field schema in Odoo during the configuration phase, configure field visibility and required status per Odoo's security model, and import custom field values alongside their parent records. Fields with complex data types such as multi-select or cross-record references may require a transformation script.

Historical journal entries from Agility ERP migrate to Odoo account.move records with debit and credit line data mapped to Odoo's line_ids table. The original Agility ERP journal entry number migrates as the Odoo move name or a reference field. We flag entries that contain embedded account codes from the legacy chart of accounts and remap them to the new Odoo account codes using the chart of accounts mapping table before loading. Entries with inconsistent debit-credit totals are flagged for manual review rather than imported with a balancing error.

Agility ERP sales order and purchase order numbers use internal sequences that may not align with Odoo's auto-generated sequence format. We map the original Agility ERP order numbers to Odoo's sale.order sequence (or purchase.order sequence) by setting the sequence next number to a value that continues after the highest Agility ERP order number. The original Agility ERP order reference is preserved in the client_order_ref field for audit trail continuity.

Agility ERP product category or item group classifications map to Odoo product.category records. Category names and hierarchies from Agility ERP transfer directly, with parent_id resolved by traversing the category name hierarchy. Product category assignment in Odoo determines default accounting valuation and costing method for items assigned to that category.

Units of measure used in Agility ERP item and order records map to Odoo uom.uom entries. Odoo maintains separate UoM lists for sale, purchase, and inventory contexts with automatic conversion factors between related units. We audit the Agility ERP UoM set against Odoo's standard uom.uom library and create any missing units during the schema configuration phase before inventory items are imported.