Migrate from Ostendo to Odoo ERP

Ostendo Customer records map to Odoo res.partner with partner_type set to 'contact' for billing contacts and 'delivery' for shipping addresses. The Ostendo CUSTOMERMASTER holds customer code, name, billing address, delivery address, contact details, and payment terms — all of which translate to standard Odoo partner fields. We preserve the Ostendo customer code as the partner's ref field for cross-system audit trails. Multi-address delivery points from Ostendo become child partner records linked via parent_id.

Ostendo ITEMMASTER records map to Odoo product.product (the stock-keeping unit variant) and product.template (the product definition). Item code maps to Odoo's default_code; item description to name; unit cost to standard_price; and Primary Supplier linkage to the product's seller_ids. Ostendo's stock levels per location map to Odoo's quant records against the corresponding warehouse location. We extract all ITEMMASTER fields including the supplier association that becomes the vendor price list entry.

Ostendo Purchase Orders map to Odoo purchase.order (header) and purchase.order.line (lines). Supplier linkage resolves to res.partner (vendor) via the contact name match. PO number, order date, expected delivery date, and line-level quantity, unit price, and taxes migrate as-is. Header-level freight and handling charges migrate to Odoo's order-level amount_total reconciliation. Line-level status (pending, confirmed, received) maps to Odoo's state field (draft, sent, purchase, done).

Ostendo Sales Orders (covering Order Styles for various sales activities including POS) map to Odoo sale.order and sale.order.line. The customer reference resolves to res.partner. Order date, requested delivery date, and pricing migrate. Line-level product, quantity, and unit price transfer; Odoo's sol_service_policy and invoice_policy fields are set to defaults during configuration. POS orders from Ostendo migrate with the POS flag cleared and the order type set to standard sale order.

Ostendo Work Orders map to Odoo mrp.production (the manufacturing order header) and mrp.workorder (per-operation routing steps). The work order job costing fields (labour hours, material consumption) migrate to the MO's move_raw_ids and workorder duration tracking. Multi-level BOMs from Ostendo require flattening before loading into Odoo's single-level BoM structure — we decompose nested BOMs into parent BoM records with child BoM line items referencing the sub-assembly products, creating a flat BoM structure that Odoo's MRP module consumes. Work order status (scheduled, in-progress, completed) maps to Odoo's state field (planned, progress, done).

Ostendo timesheets linked to Work Orders and Jobs map to Odoo account.analytic.line. We extract the Ostendo time entry records (employee, date, hours, job reference, activity type) and resolve the Odoo employee user via email match. The work order reference becomes the analytic line's so_line or production_id linking. GPS data and material-issued flags from Freeway Mobile entries are stored in custom analytic line fields for audit. Timesheets with incomplete job linkages are flagged for reconciliation before loading.

Ostendo stock levels (quantity per location, serial numbers, bin references) map to Odoo stock.quant records linked to stock.location entries. Serial number tracking migrates to Odoo's stock.production.lot with lot_name and product_id. Multi-site Ostendo records (different physical locations) create corresponding Odoo warehouse records and child location hierarchy. Quant records are loaded after product templates and locations are established to satisfy foreign-key constraints.

Ostendo Stock Locations and Service Zones map to Odoo stock.warehouse (physical site) and stock.location (logical hierarchy within each warehouse: area, aisle, bin). Freeform Ostendo location names become Odoo location complete_name strings. Service Zones used for field service dispatch map to Odoo stock.location records tagged with a custom location_type field, linked to the field service scheduling module if Odoo Field Service is in scope.

Ostendo Asset records (linked to Service Zones with meter readings and equipment checks) map to Odoo account.asset. Asset name, acquisition date, original value, and depreciation method migrate as standard asset fields. Maintenance history from Ostendo migrates to Odoo maintenance records if Odoo Maintenance app is licensed; otherwise it is preserved in custom asset description fields for manual recreation.

Ostendo User records (managed through User Security and Options) migrate to Odoo res.users. The key transformation is the concurrent-to-named-user conversion: Ostendo concurrent-user count (typically 25-40% of total staff) becomes the Odoo named-user count. We flag any gap where the Ostendo concurrent license count is lower than the named-user count required, which may reveal the customer under-licensed their Ostendo environment. Inactive Ostendo users are created as Odoo portal users or inactive records for historical record ownership continuity.

Ostendo's Freeway Mobile user-defined templates create custom fields per object without a standard export format. During discovery we enumerate all custom template fields per Ostendo screen and map each to an equivalent Odoo custom field created via Odoo Studio or in the migration schema. We alert the customer to any destination fields that cannot hold equivalent data (e.g., mobile-specific GPS, photo, signature capture) without manual configuration or third-party module installation in Odoo.

Ostendo's SQL-based Report Writer produces saved reports, inquiries, and pivot tables that reference Ostendo-specific table structures and SQL queries. These have no direct equivalent in Odoo's reporting layer. We do not migrate reports or saved queries. We deliver a written inventory of all Ostendo reports with their table dependencies, query logic, and recommended Odoo equivalent (in-app report, Odoo Studio custom report, or BI tool query) for the customer's admin to rebuild post-migration.