CRM migration
Field-level mapping, validation, and rollback between Accelo and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Accelo
Source
Odoo CRM
Destination
Compatibility
11 of 15
objects map 1:1 between Accelo and Odoo CRM.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from Accelo to Odoo CRM restructures how professional services data maps to an ERP-native CRM model. Accelo's Jobs are project-centric containers combining task delivery, time tracking, and retainer billing in one object; Odoo splits these across CRM Opportunities (for pipeline), Project tasks (for delivery), and Timesheets (for billing). We resolve that structural split during scoping so Jobs with retainer associations map to a different destination path than billable project Jobs. Accelo's API has no bulk export endpoint — pagination through /api/v0 adds migration time for large time entry and task histories. Custom fields on Jobs, Tasks, and Tickets are not accessible via Accelo's public API; we identify these gaps during discovery and either extract via CSV where available or flag for Odoo custom field creation post-migration. Workflows, Retainer billing rules, and ticket SLA triggers do not migrate; we deliver a written inventory for Odoo Business App configuration post-cutover.
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 Accelo 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.
Accelo
Company
Odoo CRM
res.partner
1:1Accelo Companies map to Odoo res.partner records with partner_type set to 'company' to activate the contacts-within-company hierarchy. The company name becomes partner_name, address fields map to street, city, state, country, and zip, and industry maps to an Odoo custom industry selection field we create during schema setup.
Accelo
Contact
Odoo CRM
res.partner
1:1Accelo Contacts map to Odoo res.partner with partner_type set to 'person'. Contact-to-company linkage via the parent_id field maintains the company-contact hierarchy. Email, phone, mobile, title, and custom fields migrate directly. We preserve the contact's Accelo owner assignment in a custom field accelo_owner_id for staff assignment reconciliation.
Accelo
Deal
Odoo CRM
crm.lead
1:1Accelo Deals (Sales Pipeline) map to Odoo CRM crm.lead records classified as Opportunities. Deal name becomes the lead name, deal value maps to expected_revenue, and the pipeline stage maps to Odoo's stage_id with a customer-approved stage matrix created during scoping. Owner assignment resolves via the staff mapping.
Accelo
Job
Odoo CRM
project.project + project.task
1:manyAccelo Jobs are the core structural challenge of this migration. Each Job becomes an Odoo project.project record with phases mapped to task sections or sub-projects depending on the Job's phase depth. The Job's contract value maps to the project's allowed sale orders or contract module reference. We flag Jobs that have an active Retainer association as these require a separate Odoo Subscription or contract record alongside the Project.
Accelo
Task
Odoo CRM
project.task
1:1Accelo Tasks map to Odoo project.task records linked to the parent project.project from the Job mapping. Task assignees map to Odoo project.user_ids. Due dates, checklists, and custom fields migrate; checklist items become child tasks in Odoo. Note that Accelo custom fields on Tasks are not exposed via the public API — we flag these for Odoo custom field creation post-migration.
Accelo
Time Entry
Odoo CRM
account.analytic.line
1:1Accelo time entries map to Odoo account.analytic.line (analytic accounting lines) linked to the Project from the Job mapping. Billable flag maps to the line's unit_amount and product mapping. Billable rate from Accelo's staff billing rate metadata migrates as a custom field or maps to the timesheet product unit price in Odoo's Timesheet app. Large time entry sets require pagination through Accelo's API because no bulk export exists.
Accelo
Staff
Odoo CRM
hr.employee
1:1Accelo Staff records map to Odoo hr.employee. We map staff email to employee work email, staff name to employee name, and department assignment to hr.department in Odoo. Staff role (Manager, Team Member, etc.) becomes an Odoo job_id reference. Owner-to-Staff mapping resolves at migration time for record assignment consistency.
Accelo
Lead
Odoo CRM
crm.lead
1:1Accelo Leads export via the Sales API and map directly to Odoo crm.lead records. Lead status maps to Odoo's stage_id, and source information migrates to the lead's source_id. Custom fields on Leads are preserved via Odoo's custom field system. We differentiate Leads from Deals during scoping based on the customer's Accelo pipeline configuration.
Accelo
Ticket
Odoo CRM
helpdesk.ticket
1:1Accelo Tickets map to Odoo Helpdesk ticket records if the customer activates the Odoo Helpdesk app. Ticket subject maps to name, description to description, priority to priority, and status to stage_id. Ticket assignee maps to user_id in Odoo Helpdesk. If Odoo Helpdesk is not activated, tickets map to crm.lead with a custom ticket-type tag.
Accelo
Retainer
Odoo CRM
sale.subscription
1:manyAccelo Retainers are compound objects that split into Odoo Subscription records (contract terms, prepaid balance, start/end dates) and associated Invoice records (billing activity). The Retainer prepaid balance migrates to the subscription's recurring_total. We document the Retainer-to-subscription mapping and flag any financial references to retired chart-of-accounts entries for the customer's accounting team to reconcile.
Accelo
Invoice
Odoo CRM
account.move
1:1Accelo Invoice records map to Odoo account.move records of type 'out_invoice'. Line items migrate as invoice_line_ids with product, quantity, and price unit preserved. Invoice status (draft, sent, paid) maps to Odoo's state field. Historical invoice records may reference retired financial data — we flag these for the customer's accounting team and do not alter the source data.
Accelo
Attachment
Odoo CRM
ir.attachment
1:1Accelo file attachments on Jobs, Tasks, and Tickets export via /attachments endpoints and migrate as Odoo ir.attachment records linked via res_model and res_id to the target object (project.project, project.task, or helpdesk.ticket). We download files individually and re-upload to Odoo's document storage with the original filename preserved. Large attachment sets increase migration time proportionally.
Accelo
Comment
Odoo CRM
mail.message
1:1Accelo ticket comment threads (conversations) map to Odoo mail.message records on the helpdesk.ticket. Each message preserves body text, author (mapped to res.partner), and create_date for thread ordering. Comments on Jobs and Tasks use a different Accelo endpoint — these migrate as project.task messages or note records depending on the customer's Odoo configuration.
Accelo
Custom Field (Companies and Contacts)
Odoo CRM
ir.model.fields
lossyAccelo custom fields on Companies and Contacts migrate to Odoo custom ir.model.fields created via Odoo Studio before data migration. We create text, selection, date, and integer field types matching the Accelo field type. Choice-based fields become Odoo selection fields with matching option values. Field-level security in Odoo is set to editable for the relevant user groups during migration.
Accelo
Category
Odoo CRM
crm.tag
lossyAccelo Categories on Companies, Contacts, and Deals map to Odoo CRM tags via crm.tag records. Each unique Accelo category value becomes a tag name. We create the tag records before migration and link them to migrated records via the tag_ids many2many field on crm.lead.
| Accelo | Odoo CRM | Compatibility | |
|---|---|---|---|
| Company | res.partner1:1 | Fully supported | |
| Contact | res.partner1:1 | Fully supported | |
| Deal | crm.lead1:1 | Fully supported | |
| Job | project.project + project.task1:many | Fully supported | |
| Task | project.task1:1 | Fully supported | |
| Time Entry | account.analytic.line1:1 | Fully supported | |
| Staff | hr.employee1:1 | Fully supported | |
| Lead | crm.lead1:1 | Fully supported | |
| Ticket | helpdesk.ticket1:1 | Fully supported | |
| Retainer | sale.subscription1:many | Fully supported | |
| Invoice | account.move1:1 | Fully supported | |
| Attachment | ir.attachment1:1 | Fully supported | |
| Comment | mail.message1:1 | Fully supported | |
| Custom Field (Companies and Contacts) | ir.model.fieldslossy | Fully supported | |
| Category | crm.taglossy | 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.
Accelo gotchas
Accelo REST API lacks a bulk export endpoint for large datasets
Custom field support is limited to Companies and Contacts
Accelo Payments fee structure is not migrated to destination billing
Accelo does not expose a Wikipedia article
Glitchy UI can corrupt display state during migration scoping
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
Discovery and Accelo API audit
We audit the source Accelo account across subscription tier (Plus, Premium, Advanced, Enterprise), API endpoint availability, custom field inventory per object (Companies, Contacts, Jobs, Tasks, Tickets), retainer record count, time entry volume, active workflow count, and staff user count. We also identify any CSV exportable subsets for custom-field-bearing objects. The discovery output is a written migration scope document with record counts per object, a custom field gap analysis, a Retainer split plan, and a Staff-to-Employee mapping table template for the customer to populate with Odoo employee IDs before production migration.
Odoo schema design and custom field creation
We design the destination Odoo schema before any data moves. This includes creating custom fields on res.partner (for contact/company custom fields), crm.lead, project.project, project.task, helpdesk.ticket, and hr.employee via Odoo Studio or XML-RPC field creation API calls. We configure CRM pipeline stages to match the Accelo deal stage matrix, create project stages for Job migration, and configure helpdesk ticket stages if the Helpdesk app is active. The schema is validated in an Odoo staging environment before production deployment. We also configure the Odoo user permissions and employee records matching the Staff mapping table.
Sandbox migration and mapping reconciliation
We run a full migration into an Odoo test database using representative data volume. The customer's RevOps or implementation lead reconciles record counts (Companies in, Contacts in, Deals in, Jobs in, Time Entries in), spot-checks 25-50 records per object against the Accelo source, and validates the Retainer split against expected Odoo Subscription records. Mapping corrections and custom field additions happen in staging before any production migration attempt. This step also validates the Staff-to-Employee mapping and identifies any Accelo owners without a corresponding Odoo employee record.
Owner reconciliation and Odoo user provisioning
We extract every distinct Accelo Staff member referenced on Contact, Company, Deal, Job, and Ticket records and cross-reference against the Odoo destination's hr.employee table using email as the dedupe key. Staff members without a matching Odoo employee go to a reconciliation queue for the customer's admin to provision. Migration of records assigned to unprovisioned staff is deferred until the queue is resolved because Odoo's user_id and user_ids fields are required for proper record ownership and notification routing.
Production migration in dependency order
We run production migration in dependency order: res.partner company records first (parent_id null), then contact records (with parent_id resolved to company), then crm.lead for Deals and Leads, then project.project for Jobs, then project.task for Tasks, then account.analytic.line for time entries via paginated API calls, then helpdesk.ticket for Tickets, then sale.subscription for Retainers (with associated invoice and time entry linkage), then ir.attachment for file attachments, then mail.message for ticket conversations. Each phase emits a row-count reconciliation report before the next phase begins. Time entry pagination is scheduled during off-peak hours to minimize API throttling risk.
Cutover, delta sync, and workflow inventory handoff
We freeze Accelo writes during cutover, run a final delta migration of any records modified during the migration window, then enable Odoo CRM as the system of record. We deliver a written inventory of every active Accelo workflow, automation trigger, and retainer billing rule that does not migrate, with a recommended Odoo configuration equivalent for the customer's admin or Odoo partner to rebuild. We support a one-week hypercare window where we resolve reconciliation issues raised by the customer's team. We do not rebuild Accelo workflows as Odoo automated actions or business apps inside the migration scope; that is a separate engagement.
Platform deep dives
Accelo
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Accelo and Odoo CRM.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
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
Accelo: Not publicly documented.
Data volume sensitivity
Accelo 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 Accelo to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Accelo 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 Accelo
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.