CRM migration
Field-level mapping, validation, and rollback between Ascora and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Ascora
Source
Odoo CRM
Destination
Compatibility
11 of 12
objects map 1:1 between Ascora and Odoo CRM.
Complexity
BStandard
Timeline
3–5 business days
Overview
Ascora is a field-service management platform built around jobs, quotes, scheduling, and GPS — its data model centres on customer sites, equipment records, and work-order status rather than lead-to-close pipeline stages. Odoo CRM splits early-stage prospects into crm.lead and converts them to crm.lead2opportunity records once qualified, with stage pipelines driven by pick-list values and forecast categories. The migration carries Ascora contacts and companies into Odoo res.partner, jobs into crm.lead (reclassified as opportunities via crm.lead2opportunity), and Ascora quotes into Odoo sale.order objects with their line items and custom terms preserved. Workflows, scheduling rules, and GPS tracking cannot migrate and must be rebuilt using Odoo automation rules and project-task templates. FlitStack sequences the load so res.partner records exist before opportunity records that reference them, resolves owner emails against Odoo res.users, and captures a delta window of 24–48 hours to catch any in-flight changes during cutover. The migration reads Ascora via scoped API access and writes to Odoo via XML-RPC — no disruption to Ascora operations during the run.
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 Ascora 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.
Ascora
Contact
Odoo CRM
crm.lead / res.partner
1:1Ascora contact maps to res.partner (for customers) and crm.lead (for unqualified prospects). Active jobs linked to a contact route that contact to res.partner; contacts with no jobs and no quotes become crm.lead records. The contact's email and phone are stored on res.partner as email and phone; the contact's name splits into firstname and lastname on res.partner.
Ascora
Company
Odoo CRM
res.partner (company_type = 'company')
1:1Ascora companies with a ABN/ACN or business name map to res.partner with company_type set to 'company'. Child contacts (site contacts, billing contacts) become child contact_address records under the parent res.partner. Multi-site companies in Ascora with separate contacts per site generate multiple contact_address records under one parent.
Ascora
Site
Odoo CRM
res.partner (contact_address)
1:1Each Ascora site with a service address becomes a res.partner contact_address child record of the primary customer res.partner. Site name maps to contact_name on the address record. Site-specific notes and instructions map to comment on the address record. Sites without an address are flagged for manual review before the migration commits.
Ascora
Job
Odoo CRM
crm.lead (reclassified via crm.lead2opportunity) + project.task
1:1Ascora jobs migrate to crm.lead as the base record — job name becomes the opportunity name, job description becomes the opportunity description, and job status maps to the crm.lead stage pick-list. If the job has a linked project or multi-phase scope, Odoo project.project and project.task records are created and linked via the project_id field on crm.lead. Task names derive from the job's line items or work phases.
Ascora
Job status
Odoo CRM
crm.lead stage + project.task stage
1:1Ascora job status values (Scheduled, In Progress, On Hold, Completed, Invoiced) map to Odoo crm.lead stage values using a value-by-value lookup table. Completed jobs map to the Won stage; Invoiced jobs map to Won with an invoice_id flag set. Jobs without a closeable status become crm.lead in the New or Qualification stage.
Ascora
Quote
Odoo CRM
sale.order + sale.order.line
1:1Ascora quotes become Odoo sale.order records with their original quote number preserved in the Odoo name field. Quote line items map to sale.order.line records linked by order_id. Custom terms and notes from the Ascora quote description field map to sale.order.note (displayed on Odoo quotation reports). Quote expiry date maps to validity_date on the sale.order; acceptance status maps to state transitions.
Ascora
Quote acceptance status
Odoo CRM
sale.order state
1:1Ascora quote status values (Draft, Sent, Accepted, Declined, Expired) map to Odoo sale.order state values: Draft to draft, Sent to sent, Accepted to sale or done depending on whether confirmation has run, Declined to cancel, Expired to cancel with an expiry flag. A custom field x_quote_original_status preserves the Ascora value for audit purposes.
Ascora
Custom fields on contacts
Odoo CRM
ir.model.fields (x_ prefixed custom fields)
1:1Ascora custom properties on contacts (trade licence number, insurance policy reference, preferred contact method) require Odoo custom field creation via Settings > Technical > Database Structure > Fields before migration runs. Each custom field is created as a Char, Selection, or Boolean type on res.partner depending on the Ascora data type. The migration plan flags any custom fields that reference pick-list value sets for value-mapping setup.
Ascora
Custom fields on jobs
Odoo CRM
ir.model.fields on crm.lead + project.task
1:1Ascora custom properties scoped to jobs (work type classification, site access instructions, crew assignment notes) map to custom fields on crm.lead and project.task. Trade-type classifications that drive scheduling rules in Ascora are stored as custom Selection fields on crm.lead for reporting segmentation, since Odoo scheduling logic is handled in the project module and must be rebuilt manually.
Ascora
Equipment
Odoo CRM
product.product / product.template (or asset)
1:manyAscora equipment records split into two Odoo objects: if the equipment is a billable product or part, it maps to product.product with the equipment name as product name and the service history stored as a text note. If Odoo Maintenance app is active, equipment maps to maintenance.equipment for asset tracking. Equipment linked to sites generates a note on the corresponding contact_address record referencing the asset.
Ascora
Attachments on jobs
Odoo CRM
ir.attachment linked to crm.lead
1:1Ascora file attachments on jobs (photos, signed forms, compliance certificates) re-upload to Odoo as ir.attachment records linked to the corresponding crm.lead via res_model = 'crm.lead' and res_id = the lead ID. Original filenames are preserved in the name field. Attachments without a parent job (orphaned files) are attached to the contact res.partner record instead.
Ascora
Owner / assigned user
Odoo CRM
res.users (via email match)
1:1Ascora job owners and contact owners resolve by email match against res.users in Odoo. Unmatched owners are flagged in the migration report — your team either invites them as Odoo users first or assigns their records to a fallback user. This prevents orphaned records where crm.lead.create_uid or user_id cannot resolve.
| Ascora | Odoo CRM | Compatibility | |
|---|---|---|---|
| Contact | crm.lead / res.partner1:1 | Fully supported | |
| Company | res.partner (company_type = 'company')1:1 | Fully supported | |
| Site | res.partner (contact_address)1:1 | Fully supported | |
| Job | crm.lead (reclassified via crm.lead2opportunity) + project.task1:1 | Fully supported | |
| Job status | crm.lead stage + project.task stage1:1 | Fully supported | |
| Quote | sale.order + sale.order.line1:1 | Fully supported | |
| Quote acceptance status | sale.order state1:1 | Fully supported | |
| Custom fields on contacts | ir.model.fields (x_ prefixed custom fields)1:1 | Fully supported | |
| Custom fields on jobs | ir.model.fields on crm.lead + project.task1:1 | Fully supported | |
| Equipment | product.product / product.template (or asset)1:many | Mapping required | |
| Attachments on jobs | ir.attachment linked to crm.lead1:1 | Fully supported | |
| Owner / assigned user | res.users (via email match)1: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.
Ascora gotchas
No documented public REST API with published rate limits
Custom Forms use Word template field codes with no structured schema export
Xero two-way sync creates reconciliation risk during migration
Excel export is the primary bulk data extraction mechanism
No pricing transparency — plan tiers are not publicly 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 Ascora data and configure Odoo schema
FlitStack AI exports the full Ascora dataset via scoped read access — contacts, companies, sites, jobs, quotes, line items, attachments, and custom properties. We simultaneously audit record counts, pick-list values on job status and quote status, and any multi-site relationships. In parallel, your Odoo admin (or our team) creates the crm.lead stage pipelines, sale.order price lists, and custom fields (x_abn, x_ascora_id, x_original_create_date, x_expired) via Settings > Technical > Database Structure so Odoo is schema-ready before validation runs.
Resolve owners and cross-reference product catalog
Ascora user and contact owner emails match against res.users in Odoo by email. Unmatched owners are flagged with a resolution report — your team either creates Odoo user accounts for them first or assigns their records to a fallback owner before migration. Separately, every Ascora quote line item is checked against the Odoo product.product catalog. Any line items without a matching product ID are flagged so placeholder products can be created in Odoo before the sale.order import step.
Import contacts and companies first, then jobs and quotes
Odoo requires res.partner to exist before crm.lead (which references partner_id) and sale.order (which references partner_id). We sequence the migration in dependency order: res.partner records → res.partner contact_address records for sites → crm.lead for jobs → sale.order for quotes with sale.order.line line items in the same transaction. Custom field values are written alongside standard fields in the same API call. Each import batch generates a validation report showing record counts, error rows, and owner resolution status.
Run sample migration with field-level diff
A representative sample — typically 100–300 records across contacts, companies, jobs, and quotes — migrates first against the live Odoo instance. We generate a field-level diff comparing source values against destination field values, so you can verify stage mapping for job status, validity_date for quote expiry, and owner resolution before the full run commits. You approve the sample before we proceed to the full migration.
Full migration with delta-pickup and post-migration handover
All remaining records migrate against the live Odoo database. A delta-pickup window of 24–48 hours captures any records created or modified in Ascora during the cutover so Odoo reflects the final state at go-live. We generate a migration audit log listing every record created, updated, or skipped with error reasons. A post-migration checklist covers the items that require manual rebuild: scheduling configuration, GPS integration setup, Odoo automation rules (ir.actions.server) replacing Ascora workflows, and accounting integration reconnection. One-click rollback is available if reconciliation uncovers critical mismatches.
Platform deep dives
Ascora
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between Ascora and Odoo CRM.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Ascora and Odoo CRM.
Object compatibility
All 8 core objects map 1:1 between Ascora and Odoo CRM.
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
Ascora: Not publicly documented.
Data volume sensitivity
Ascora 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 Ascora to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Ascora 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 Ascora
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.