CRM migration
Field-level mapping, validation, and rollback between Q Dispatch and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Q Dispatch
Source
Odoo CRM
Destination
Compatibility
8 of 10
objects map 1:1 between Q Dispatch and Odoo CRM.
Complexity
BStandard
Timeline
48–96 hours
Overview
Q Dispatch organizes field service data around work orders, technicians, and job scheduling. Odoo CRM models the same information using crm.lead for opportunities, res.partner for contacts and companies, and res.users for team members. We extract Q Dispatch data via its export API, transform work orders into Odoo crm.lead records, convert customers into res.partner entries with address and contact data intact, and map technicians to Odoo users by email match. Custom fields on Q Dispatch work orders become Odoo custom Char, Integer, or Selection fields on crm.lead. The migration carries original create dates as stored custom fields since Odoo's create_date is set at migration time. We sequence the load so res.partner records exist before crm.lead records that reference them. Delta-pickup captures any jobs modified during cutover. Workflows and automation rules built in Q Dispatch do not migrate — those must be rebuilt in Odoo's Automate menu or via Odoo's studio-based workflow designer.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Q Dispatch object lands in Odoo CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Q Dispatch
Work Order
Odoo CRM
crm.lead
1:1Q Dispatch work orders map to Odoo crm.lead records as opportunities. The work order name becomes the crm.lead name field. Job description, address, and scheduled date map to crm.lead description, street/city fields, and planned_date_end respectively. Status is remapped from Q Dispatch statuses to Odoo pipeline stages.
Q Dispatch
Customer
Odoo CRM
res.partner
1:1Q Dispatch customer records map to Odoo res.partner. Company-type customers use contact_type='contact' and store the company name in name; individual customers use contact_type='person' with firstname and lastname split. Email, phone, mobile, and address fields map directly to Odoo partner fields.
Q Dispatch
Technician / Staff Member
Odoo CRM
res.users
1:1Q Dispatch technicians map to Odoo res.users by email match. Active technicians become Odoo internal users with appropriate access rights. Inactive or archived technicians are optionally migrated as res.partner contacts. Skill tags from Q Dispatch require custom fields on res.users since Odoo has no native skill-tag model.
Q Dispatch
Work Order Line Item / Service Line
Odoo CRM
sale.order.line (via Sale app)
many:1Q Dispatch service line items on work orders merge into Odoo sale.order.line records. If the destination Odoo instance includes the Sale app, service lines create sale.order.line entries linked to the crm.lead opportunity. Line descriptions, quantities, and unit prices transfer directly.
Q Dispatch
Schedule / Dispatch Event
Odoo CRM
calendar.event
1:1Q Dispatch scheduling data migrates to Odoo calendar.event records linked to the res.users technician. Start and end times preserve from the work order schedule. The dispatch board routing logic itself does not transfer — that workflow must be rebuilt using Odoo Project tasks or a field service module post-migration.
Q Dispatch
Customer Site / Location
Odoo CRM
res.partner (address fields) + custom field
many:1Q Dispatch sites (multiple service locations per customer) become address records under the parent res.partner. Site-specific notes and access instructions map to custom Char fields on the partner record since Odoo has no native multi-site-per-customer model in the base CRM.
Q Dispatch
Work Order Attachments / Photos
Odoo CRM
ir.attachment
1:1File attachments from Q Dispatch work orders download and re-upload to Odoo as ir.attachment records linked to the corresponding crm.lead. Odoo's attachment storage uses the database filestore by default; large file migrations require sufficient disk allocation in the Odoo instance.
Q Dispatch
Work Order Notes / Internal Comments
Odoo CRM
mail.message
1:1Q Dispatch work order notes and internal comments migrate as Odoo mail.message records attached to the crm.lead. Original timestamps and author information (resolved by email match to res.users) are preserved. Public-facing customer communications become mail.message with subtypes, while internal notes use the 'note' subtype to distinguish visibility within Odoo. Attachments on notes also migrate as ir.attachment records linked to the corresponding mail.message.
Q Dispatch
Custom Work Order Fields
Odoo CRM
ir.model.fields (custom)
1:1Q Dispatch custom fields on work orders require Odoo custom field creation via Settings > Technical > Models before data loads. We generate the field creation XML for each custom field, matching the source field type (Char, Integer, Selection, Date, etc.) and populate values during the migration run.
Q Dispatch
Invoice / Billing Record
Odoo CRM
account.move
1:1Q Dispatch billing and invoice records do not migrate as native Odoo accounting entries. If Odoo Accounting is in use, we export invoice data as CSV for manual import into account.move. Completed invoice metadata (amount, date, status) is preserved as custom fields on the linked crm.lead for historical reference.
| Q Dispatch | Odoo CRM | Compatibility | |
|---|---|---|---|
| Work Order | crm.lead1:1 | Fully supported | |
| Customer | res.partner1:1 | Fully supported | |
| Technician / Staff Member | res.users1:1 | Fully supported | |
| Work Order Line Item / Service Line | sale.order.line (via Sale app)many:1 | Fully supported | |
| Schedule / Dispatch Event | calendar.event1:1 | Fully supported | |
| Customer Site / Location | res.partner (address fields) + custom fieldmany:1 | Fully supported | |
| Work Order Attachments / Photos | ir.attachment1:1 | Fully supported | |
| Work Order Notes / Internal Comments | mail.message1:1 | Fully supported | |
| Custom Work Order Fields | ir.model.fields (custom)1:1 | Fully supported | |
| Invoice / Billing Record | account.move1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Q Dispatch gotchas
Export mechanism is not API-first
Custom field schemas do not transfer
Invoice and payment data may require reconciliation
No free tier or trial documented
Odoo CRM gotchas
Odoo.sh version gating blocks assisted migrations from trial
Enterprise modules fail to install on Community after database restore
Custom module view inheritance breaks between Odoo major versions
Custom fields risk losing their application context on Community
API access for Community is gated behind the Custom Plan
Pair-specific challenges
Migration approach
Audit Q Dispatch schema and Odoo target configuration
FlitStack extracts the Q Dispatch data model — work order fields, customer fields, technician records, and custom field definitions — via API export. We compare the Q Dispatch schema against your target Odoo instance's crm.lead model, res.partner fields, and res.users fields. Custom field gaps are identified and a field-creation plan is generated. Your Odoo admin creates the required custom fields via Settings > Technical > Models before migration data loads.
Map and deduplicate Q Dispatch customers to res.partner
Q Dispatch customer records export first. We match by email domain to identify duplicate customers, resolve them to a single res.partner record, and link multiple Q Dispatch site records to a parent res.partner company record where applicable. The customer load sequence runs before work orders so partner_id foreign keys resolve on the crm.lead migration step. We also validate address consistency across duplicate records and consolidate contact information to ensure data integrity in the target system.
Resolve Q Dispatch technicians to Odoo res.users
Q Dispatch technician records match against Odoo res.users by email. Active technicians with valid Odoo user accounts get mapped directly. Technicians without Odoo accounts are flagged — your admin either creates Odoo user accounts or we map them to res.partner contacts instead. Skill tags and availability data are exported as custom fields on the res.users record since Odoo has no native skill-tag model.
Run a sample migration with field-level verification
A representative slice of Q Dispatch work orders — typically 100–500 records spanning multiple statuses, technicians, and customers — migrates first. We generate a field-level diff showing source values versus destination Odoo crm.lead fields. You verify stage mapping, technician assignment, customer linking, and custom field population. Approval of the sample unlocks the full migration run. This validation step catches mapping errors early and allows for adjustments before committing to the complete dataset transfer.
Execute full migration with delta-pickup window
Full Q Dispatch work orders migrate to Odoo crm.lead records. A 24–48 hour delta-pickup window captures any work orders created or modified in Q Dispatch during the cutover period. All attachments download from Q Dispatch and re-upload to Odoo's ir.attachment model linked to the corresponding crm.lead. Audit log records every operation. One-click rollback reverts the Odoo instance to pre-migration state if reconciliation identifies critical data mismatches.
Deliver migration report and rebuild reference export
FlitStack delivers a migration summary report: record counts by object, custom field coverage, unmatched technician list, and any fields that could not migrate. A Q Dispatch workflow definition export is provided as a CSV reference so your Odoo admin can rebuild dispatch routing rules in Odoo Studio. Post-migration support is available for 5 business days following go-live to address any data issues discovered during user acceptance testing.
Platform deep dives
Q Dispatch
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a manual workaround.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Q Dispatch and Odoo CRM.
Object compatibility
1 of 8 objects need a manual workaround.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Q Dispatch: Not publicly documented.
Data volume sensitivity
Q Dispatch doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Q Dispatch to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Q Dispatch to Odoo CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Q Dispatch
Other ways to arrive at Odoo CRM
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.