Migrate from Pilot ERP to Odoo ERP

Pilot ERP Customers map to Odoo res.partner records with address data restructured. Odoo separates address records into contact-type sub-records attached to the company-level Partner, while Pilot ERP stores address fields inline on the Customer record. We extract Pilot ERP address fields (street, city, state, postal code, country) and create a primary contact child record under the Partner during import. Any secondary addresses stored in Pilot ERP become additional Odoo contact records linked to the same Partner.

Pilot ERP Vendors map to Odoo res.partner records with partner_type=supplier. The same address restructuring applies: inline Vendor addresses become Odoo contact sub-records. Payment terms (Net 30, Net 60) from Pilot ERP map to Odoo's account.payment.term table and are linked via payment_term_id on the Partner record.

Pilot ERP Items map to Odoo product.product (stockable variant) or product.template records. Part numbers map to Odoo's default_code field. We map Pilot ERP costing method to the corresponding Odoo product costing_type (FIFO maps to 'fifo', Average maps to 'average', Standard maps to 'standard'). Units of measure from Pilot ERP map to Odoo's uom.uom table, with conversion ratios preserved. Multi-attribute product variants in Odoo require the product.template structure; single-variant Items map directly to product.product.

Pilot ERP Work Orders track manufacturing jobs linked to Items (finished goods) and optionally to Purchase Orders (raw materials). These map to Odoo mrp.production (Manufacturing Order), which depends on a Bill of Materials (mrp.bom) defining components and operations. We inventory all Pilot ERP Work Orders during discovery and flag any that reference non-existent Items. BoMs must be loaded or created before or alongside Work Order migration so that component links resolve at import time. Odoo Manufacturing Orders carry a state machine (draft, confirmed, in progress, done, cancel) that may differ from Pilot ERP's Work Order status values; we map each status explicitly during the transform phase.

Pilot ERP Purchase Orders map to Odoo purchase.order records. Vendor reference and Item lines transfer directly, with Product quantities and prices mapping to Odoo purchase.order.line. Odoo additionally tracks incoming moves (stock.picking) linked to each Purchase Order; this is a structural addition Pilot ERP does not have. We flag any Pilot ERP Purchase Orders still referencing voided, cancelled, or closed Work Orders during the audit phase because these create orphaned material-reservation links in Odoo. The customer resolves these before go-live to prevent receiving discrepancies.

Pilot ERP Invoices map to Odoo account.move records with move_type=out_invoice for open and historical AR. Payment status and remaining balance from Pilot ERP transfer to Odoo's amount_residual and payment_state fields. Historical paid invoices migrate with full line-item detail for audit trail continuity. Odoo uses a sequence-based invoice numbering scheme (INV/YYYY/XXXX) that may conflict with existing Pilot ERP invoice numbers; we check the Odoo sequence for conflicts before import and flag numbering adjustments to the customer's admin.

Pilot ERP Bills map to Odoo account.move records with move_type=in_invoice for vendor bills. Outstanding balance and payment terms transfer directly. Partial-payment history is preserved as individual payment records linked to the Bill. The same numbering conflict check applies as with Invoices. Bills in Pilot ERP that reference Vendors not yet imported are held in a pre-load reconciliation queue.

Pilot ERP Job Costing tracks material, labor, and overhead components per job or Work Order. Odoo represents these through analytic.account entries linked to Manufacturing Orders and through cost structure analysis inside the Manufacturing app. We create an analytic.account per Pilot ERP Job Costing job during migration and map material, labor, and overhead line amounts to analytic.line records. Any cost categories that cannot map cleanly to Odoo's analytic account structure are flagged for manual configuration review before the financial data load begins.

Pilot ERP's chart of accounts maps to Odoo's account.account table. Each account's type (asset, liability, equity, revenue, expense) maps to Odoo's account.account type field. Accounts with transaction histories that do not fit cleanly into Odoo's account type taxonomy are flagged during the audit phase because mismapped account types cause incorrect trial balance classifications and balance sheet errors in Odoo's standard financial reports.

Pilot ERP's barcode-labelled inventory records reference Items by part number. We verify every barcode-labelled record resolves to a valid Item in the Item master before migration. Any barcode-labelled inventory record pointing to a non-existent, discontinued, or duplicate Item is flagged in the pre-load audit report and resolved by the customer before the inventory data phase begins. Odoo's stock.quant records are created from the verified inventory snapshot.

Pilot ERP supports custom fields on standard objects but does not expose a schema export endpoint or documented field definitions. We inventory custom field definitions during the discovery call by reviewing Pilot ERP's field configuration screens alongside the customer. We then recreate these as custom fields in Odoo using Studio or ORM before the data load phase. Each custom field is mapped to its corresponding record during import, and any custom fields on Objects with no Odoo equivalent are documented in the migration inventory for the customer's admin to handle as custom properties or notes fields.

Pilot ERP stores binary file attachments linked to Work Orders, Customers, Items, and other records but exposes no documented API endpoint for exporting these files. We document every attachment reference discovered during the audit phase and deliver a written inventory of files that require manual export or database-level extraction. Records with missing attachment files are flagged explicitly in the migration deliverable so the customer can address the gap outside the automated migration scope.