Migrate from Novo Work Order to Odoo CRM

Novo stores customers as contact records with name, email, phone, and address fields. These map directly to res.partner in Odoo. The partner's is_company flag is set to False for individual contacts; company-type contacts (if Novo distinguishes them) set is_company to True and become parent partner records. Novo's customer_id is preserved as Source_System_ID__c for delta-run de-duplication.

Novo work orders map to maintenance.request in Odoo when the Maintenance module is installed. This is the most structurally faithful mapping — maintenance.request includes user_id (assigned technician), equipment_id (linked asset), schedule_date, completion date, and description. Novo's priority field maps to maintenance.priority (0–5 scale). If the Maintenance module is not available in the target Odoo instance, work orders map to crm.lead as a Project-type opportunity with custom fields for operational data.

When the Maintenance module is not activated or when work orders represent sales-driven service engagements rather than asset maintenance, Novo work orders map to crm.lead. The work order name becomes the opportunity name, description maps to crm.lead description, and operational fields (labor hours, parts cost) become custom fields on the lead. The crm.lead type is set to 'opportunity' to distinguish from standard sales leads.

Novo assets (equipment records with name, serial number, category, and location) map directly to maintenance.equipment in Odoo. The equipment_id on maintenance.request links work orders to the relevant asset. If the target Odoo instance does not have the Maintenance module, assets map to product.product (with type='product') for inventory tracking purposes.

Novo's multi-department structure has no native Odoo equivalent. FlitStack maps each Novo department to a crm.team record in Odoo, with team members (technicians) assigned as crm.team member res.users records. Odoo's Record Rules are then configured to scope visibility by team, approximating Novo's department-level data isolation. This requires Odoo admin configuration post-migration.

Novo status values (Open, In Progress, On Hold, Completed, Cancelled) are mapped one-to-one to Odoo maintenance.stage or crm.stage records depending on the destination object. Each stage is created in Odoo with the appropriate sequence number and fold flag before work order imports run. Stage-entered timestamps from Novo are preserved as custom datetime fields on the target record.

Novo stores locations as address records attached to work orders. These migrate as res.partner records with is_company=False and a dedicated address type. In Odoo, the address is stored on the partner record using the address fields (street, city, state_id, zip, country_id). If a location serves as both a customer and a service site, it is duplicated as a separate partner record with category='Service Location'.

Novo users (technicians, department heads, admins) map to res.users in Odoo. Resolution is performed by email address match — each Novo user.email is matched against res.users.login. Unmatched users are flagged before migration; the team either pre-creates Odoo user accounts or assigns records to a fallback user. Novo department assignments map to crm.team membership.

Novo file attachments on work orders (photos, PDFs, inspection reports) are exported from Novo's storage and re-uploaded to Odoo as ir.attachment records linked to the target maintenance.request or crm.lead record via res_model and res_id. Odoo's ir_attachment model stores files in its filestore directory. Large file handling respects Odoo's attachment size limits (configurable in system parameters).

Novo's internal activity history on work orders (status changes, notes, internal comments) migrates as mail.message records on the target Odoo record. Each message is created with message_type='comment', author_id matching the Novo user who performed the action, and body containing the activity description. Original timestamps are preserved. This provides a complete audit trail on the Odoo record without requiring Odoo's full activity tracking module.

Novo custom fields on work orders (e.g., inspection_type, permit_number, weather_conditions) require Odoo custom field definitions on the target model (maintenance.request or crm.lead). FlitStack creates the Odoo field definition (x_ prefix for Community Edition) with the matching type (Char, Selection, Date, Float, etc.) before data import. Pick-list-style custom fields in Novo are created as Selection fields in Odoo with the same option values.

Novo custom fields on customer contacts (e.g., preferred_service_area, customer_tier, billing_code) migrate as custom fields on res.partner in Odoo. The same x_ prefix convention applies for Community Edition. After migration, Odoo Studio can be used to expose these fields on the partner form view without code changes.