Migrate from UPilot to Odoo CRM

UPilot Contact records map to Odoo res.partner with partner_type = 'contact'. Standard fields (name, email, phone, website) migrate directly. The UPilot 360-degree view task context (tasks embedded in contact records) migrates as mail.activity records linked to the res.partner. Company association maps to a parent res.partner record where the contact's company exists. Note that Odoo res.partner is a unified model serving both individuals and organizations; industry-specific classification via partner_weight or industry_id maps from UPilot's industry property.

UPilot Company records map to Odoo res.partner with partner_type = 'company' and is_company = True. Domain and address fields map to website, street, city, state_id, country_id, and zip on the partner record. Company record is created before Contact import so that the parent_id relationship on res.partner is satisfied at the moment of contact insert. Multi-company setups in UPilot map to multiple res.partner records or, if Enterprise-tier Odoo multi-company is in scope, to separate company records in the Odoo multi-company registry.

UPilot Deals map to Odoo crm.lead with type = 'opportunity'. Deal name becomes crm.lead name; deal value maps to planned_revenue; expected close date maps to date_deadline. The pipeline stage maps to stage_id on crm.lead via the stage sequence ordering. Note: UPilot supports multiple pipelines with independent stage sets; Odoo CRM Community supports only one pipeline. We resolve this by mapping each UPilot pipeline to a crm.team segment and encoding pipeline identity in a custom stage_id prefix or tag so that stage sequences remain distinct per business line.

Odoo CRM Community supports one pipeline Kanban view. We address this by creating crm.team records (one per UPilot pipeline) and mapping UPilot pipeline identity into a tag or custom field on crm.lead. Stage names and probabilities migrate from UPilot pipeline stages to crm.stage definitions ordered by sequence. If the customer needs pipeline-level filtering in the Kanban view, we configure domain filters on crm.team in Odoo Studio rather than multiple pipeline views.

UPilot Tasks linked to Contacts and Deals map to Odoo mail.activity records attached to the corresponding res.partner (for Contact-linked tasks) or crm.lead (for Deal-linked tasks). Task title becomes mail.activity activity_type_id and summary; due date maps to date_deadline; status maps to active/done state. Task assignments migrate by resolving the UPilot owner email to the Odoo res.users record via user lookup. Tasks not yet due retain their original date_deadline so that the activity calendar reflects the original schedule.

UPilot's forecast projections tied to pipeline stage probabilities map to probability field on crm.lead. Stage-level probability percentages in UPilot become stage_id probability values on each crm.stage definition. Note that Odoo's forecast reporting uses the sum of planned_revenue weighted by probability, which differs from UPilot's dedicated forecast view; we document the delta for the customer's admin to configure Odoo's reporting correctly.

UPilot Support Tickets with conversation threads map to Odoo helpdesk.ticket if the Odoo Helpdesk module is installed in the destination environment. Ticket subject becomes helpdesk.ticket name; ticket status maps to stage_id; conversation threads migrate as mail.message records attached to the ticket. If Helpdesk is not in scope, ticket records map as crm.lead notes or are flagged for manual handoff to a ticketing system. Conversation threading semantics differ between platforms and require case-by-case validation during scoping.

UPilot custom fields on Contact, Company, and Deal records map to Odoo ir.model.fields definitions created via Odoo Studio or Python model inheritance. We extract field types from UPilot during discovery and create equivalent Odoo field definitions (char, text, selection, many2one, etc.) before record import. Required-field flags and default values migrate as field_default values on ir.model.fields. Fields referencing lookups (e.g., industry, source) require the lookup table to be populated before the main record import runs.

UPilot lead source tracking (Marketing module records, campaign associations) maps to Odoo UTM (Utm) module tracking records. utm.source carries the original channel, utm.campaign carries the campaign identity, and utm.medium carries the interaction type. If the customer does not have the UTM module installed in Odoo, we map lead sources to a selection field or tag on crm.lead during migration.

UPilot Owners map to Odoo res.users records by email match. Owner_id on Deals and Tasks resolves to user_id on crm.lead and res.partner. Any UPilot Owner without a matching res.users in the destination Odoo instance goes to a reconciliation queue for the customer's admin to provision users before record import resumes. Inactive UPilot owners map to inactive Odoo users flagged for activation review.

UPilot report configurations and dashboard snapshots are documented as written inventory records during migration. Odoo's reporting engine uses a different model (actions, ir.filters, and custom SQL views for advanced reporting). We extract UPilot report field selections and filter criteria and deliver them as a report mapping document that the customer's admin uses to configure equivalent Odoo reports in Studio or via the reporting module. Scheduled report delivery settings require manual recreation in Odoo.

UPilot meeting scheduler integrations and availability rules do not migrate as active scheduling links. We extract any existing meeting records (past scheduled meetings) as calendar.event records in Odoo with start_datetime, stop_datetime, partner_ids (linked attendees), and location preserved. Active scheduling links and availability rules are flagged for manual reconfiguration in Odoo's calendar module or via the calendar.external.provider integration.