Migrate from Visibility ERP to Odoo ERP

Visibility multi-level BOMs map to Odoo BoM records attached to a master Product (the manufactured item). Each BoM line is a component (sub-assembly or raw material). Phantom BOMs in Visibility map to BoM type kit or sub-assembly in Odoo. We walk the full parent-component tree from Visibility and insert each level as a separate BoM in Odoo, linking sub-assembly BoMs as components of the parent. Phantom BOMs get BoM type=subassembly so they auto-resolve during Manufacturing Order explosion.

Visibility Work Orders map to Odoo Manufacturing Orders. The Work Order header (number, status, scheduled dates, work center assignment) maps to MO fields. Component lines map to BoM-exploded stock moves. Routing steps map to Odoo workorders. We preserve the original Work Order number in a custom reference field and set MO state to draft or confirmed based on Visibility status. BOM revision-locked Work Orders map to the corresponding BoM revision in Odoo via the revision-mapping table built during scoping.

Visibility Production Orders map to Odoo Manufacturing Orders at the header level. The linked BOM revision and routing operation sequence migrate as MO source BoM and work order operations. Scheduled start and end dates become MO scheduled date and deadline. Material and labor requirements from Visibility carry forward as stock move lines and work order timesheet estimates.

Visibility Routings define the sequence of operations, work centers, and standard times. In Odoo, routing data lives on the Work Order Operations tab of the BoM or MO. We map each Routing step as a workorder record with sequence, work center, duration, and operation name. Custom operation-level user fields migrate as custom fields on the workorder model.

Visibility Sales Orders map to Odoo Sale Order with line-level mapping for configured lines, pricing, discounts, and shipment schedules. The Visibility configured line (from the Product Configurator) maps to an Odoo product variant with the configured combination applied. Scheduled shipment dates migrate as delivery dates on order lines. Original SO number is preserved as the Odoo name field for reference.

Open Purchase Orders with line items, vendor assignments, scheduled receipts, and unit costs migrate directly. We map PO header fields (vendor, date, payment terms) and flatten line-level detail (product, quantity, unit cost, scheduled date) into Odoo POL. Vendor is resolved via the vendor reference on the Odoo Contact. Open POs (not yet received) are migrated in draft state for the customer's team to confirm in Odoo.

Visibility lot numbers, serial numbers, expiration dates, and bin locations map to Odoo lot/serial records and quant records. Lot-controlled items require mapping lot assignment at the inventory transaction level, not just the item master. We extract all lots and associated quant quantities from Visibility and insert them into Odoo with location_id resolved against the destination warehouse structure configured during schema design.

Visibility QC inspection results, non-conformance records, and corrective actions link to Work Orders and inventory transactions. We migrate QC records as Odoo Quality Checks linked to the corresponding Manufacturing Order or stock move, and Quality Alerts for non-conformance records with their corrective action description preserved. The mapping type is 1:N because a single Work Order may have multiple QC checkpoints.

Visibility uses a hierarchical GL code structure that varies by deployment (segmented vs. flat). We extract the full account tree, map account types (asset, liability, equity, revenue, expense), and validate that the destination Odoo chart of accounts segment structure matches. We recommend installing Odoo with a standard manufacturing-friendly chart of accounts first, then mapping Visibility accounts to Odoo accounts by account code, with any unmapped accounts flagged for the customer's accountant to review before GL data loads.

Open invoices, credit memos, and payment records carry vendor/customer references, due dates, and aging buckets. We map open AP as Odoo Vendor Bills in open state and open AR as Odoo Customer Invoices. Original invoice numbers are preserved as Odoo reference fields. Aging buckets are not Odoo-native but we carry the original due date and payment term so aging reports regenerate correctly post-migration.

Visibility User accounts and role profiles map to Odoo Users. Role names map to the closest Odoo access rights group (Employee, Manager, Administrator). We resolve users by email match against the Odoo destination User table. Any Visibility User without a matching Odoo User goes to a reconciliation queue for the customer's admin to provision before the user data phase begins.

Visibility allows user-defined fields across most objects but exposes no public schema for them. We request a custom field export during scoping (typically via a database-level query or a Visibility-supported report), build a bespoke field map before any import begins, and pre-create each Odoo custom field with the correct field type before data migration starts. Custom fields without a known Odoo equivalent are flagged for the customer to decide whether to drop or map to a note field.