Migrate from Vtiger All-In-One CRM to Odoo CRM

Vtiger Organizations map directly to Odoo res.partner records with company_type set to 'company'. The Organization name becomes the partner's name field, and the website domain is used as the dedupe key during import to prevent duplicate partner creation. Any Organization custom fields migrate as additional char, selection, or boolean fields on res.partner. If Vtiger's Organization has no name, we fall back to the primary domain in the website field.

Vtiger Contacts map to Odoo res.partner records with company_type set to 'person', linked to a parent res.partner (the imported Organization) via the parent_id field. We resolve the Organization-to-partner lookup at migration time so that every Contact has a valid parent_id. Vtiger's support for multiple phone numbers (phone, mobile, other phone) maps to Odoo's phone and mobile fields; any additional phone values are flagged for custom field creation. Email, mailing address, title, and department migrate directly.

Vtiger Leads map to Odoo crm.lead records with type='lead'. The lead_status and lead_source from Vtiger are preserved as custom fields on the Odoo crm.lead (x_vtiger_lead_status and x_vtiger_lead_source) for audit and reporting continuity. We merge both Vtiger Leads and Vtiger Potentials into Odoo's single crm.lead model during migration: Leads enter as type='lead', Potentials (see mapping 4) enter as type='opportunity'. Odoo teams and pipeline stages must be configured before migration to accept the incoming record types.

Vtiger Potentials (the deal/opportunity object) map to Odoo crm.lead with type='opportunity'. The Potential amount becomes the crm.lead expected_revenue; the sales_stage maps to the Odoo CRM stage on the target team's pipeline; close_date maps to date_deadline; and the linked Organization and Contact resolve to their imported res.partner IDs. If Vtiger's pipeline and stage combination does not exist in Odoo, we create it before migration. The original Vtiger sales_stage and pipeline name are preserved as custom fields on the Odoo record.

Vtiger Help Desk Tickets map to Odoo helpdesk.ticket if the Helpdesk app is installed in the destination Odoo instance. Helpdesk.app is available on Odoo Enterprise; Odoo Community can use a mail.message-based fallback with a ticket-like tag structure, though this sacrifices SLA and round-robin features. We confirm the Odoo edition and installed apps during discovery. Ticket status (Open, Wait for Response, Closed) maps to Odoo stage names; priority maps directly. The assigned agent resolves to an Odoo User by email match. Related Contact and Organization resolve to imported res.partner IDs.

Vtiger Products map to Odoo product.product records with type='product' or 'service' depending on the Vtiger product type. The product code, list price (listprice), and standard cost (cost_price) migrate directly. Vendor associations on Vtiger Products become Odoo supplier info records on the product. If the Vtiger Inventory module is disabled, Products may still exist but Stock Quantities will not; we flag this during discovery. Products must be imported before any Quote or Sales Order line items that reference them.

Vtiger Quotes map to Odoo sale.order records in draft state, which requires the Odoo Sale app to be installed in the destination. If Sale app is absent, we flag this as a blocking dependency and advise the customer to enable it before migration. Quote line items (Products linked to Quotes) map to sale.order.line with quantity, price_unit, and discount preserved. The Quote's linked Organization and Contact resolve to the imported res.partner records. Product existence in Odoo is confirmed before Quote migration begins to satisfy the sale.order.line product_id foreign key. The original Vtiger Quote number is stored as name to preserve reference continuity.

Vtiger Sales Orders map to Odoo sale.order records in confirmed (sale) state with the same dependency chain as Quotes: Sale app must be installed, Products must exist first, and the res.partner link must resolve to an imported partner. Sales Order totals and line items migrate as sale.order.line records. If Vtiger's Inventory module is disabled, Sales Order records may be absent from the export; we check for this during discovery and flag the gap.

Vtiger Projects map to Odoo project.project. Task dependencies (Finish-to-Start, Start-to-Start, Finish-to-Finish) are preserved as Odoo project.task dependency records where the destination Odoo version supports them. Milestones map to Odoo project.milestone if available on the destination Odoo edition. Projects must be imported before their child Tasks to satisfy the project_id foreign key. If the Odoo Project app is not installed, we flag this as a scope limitation and recommend installing it before migration.

Vtiger Tasks are split based on context: Tasks under a Project map to Odoo project.task with project_id set; standalone Tasks map to Odoo project.task with no project_id or to calendar.event (for calendar-bound tasks). Subtask hierarchy is preserved as parent_id on project.task where Odoo supports it. Assignee resolves to an Odoo User by email; due_date migrates as date_deadline; priority and status map directly. All parent Projects must be created before Task import to satisfy project_id references.

Vtiger activity history (calls, emails, meetings, notes attached to Contacts, Organizations, or Potentials) maps to Odoo mail.message records linked via model and res_id to the appropriate crm.lead or res.partner. Call engagements become mail.message with subtype='mt_comment' and a custom call duration field; email body migrates as mail.message HTML content; meetings create mail.event with start and stop datetime preserved; notes migrate as mail.message with note-style subtype. Each message is associated with the correct parent record using the resolved res.partner or crm.lead ID from the migration.

Vtiger exports attachments individually per record with no bulk download. For migrations with fewer than 500 files, we download and import directly to Odoo ir.attachment linked via res_model and res_id. For sets exceeding 500 files, we stage the file set in object storage, then re-associate each file with its parent record (Contact, Organization, Potential, Project) after the primary data import completes. This two-phase approach prevents download timeouts and requires the customer to provision adequate Odoo attachment storage before cutover.

Vtiger custom fields on any object (Contacts, Organizations, Potentials, Products, Tickets) are recreated in Odoo as custom fields on the corresponding model. We generate a field-type comparison: Vtiger picklist becomes Odoo selection; multi-checkbox becomes many2many; date becomes date; currency becomes float with decimal precision; phone becomes char. Picklist option values migrate as selection options on the Odoo field. Custom field definitions and all existing data values move together so that the Odoo field is populated from day one.

Vtiger workflow automation rules (triggers, conditions, actions) are configuration metadata that do not exist as transferable records in Vtiger's data model. We extract the workflow definitions as JSON alongside the data export and deliver a re-implementation guide that maps each Vtiger trigger, condition, and action to its Odoo automated action or server action equivalent. The customer's Odoo admin rebuilds critical automations manually after migration. We do not import Workflows as data.