CRM migration
Field-level mapping, validation, and rollback between Getfly CRM and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Getfly CRM
Source
Odoo CRM
Destination
Compatibility
9 of 13
objects map 1:1 between Getfly CRM and Odoo CRM.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from Getfly CRM to Odoo CRM restructures your data model around a different philosophy. Getfly organizes contacts under customer Accounts with an integrated calling stack and marketing automation scoped to Vietnamese SME workflows. Odoo separates People (Contacts) from Organizations (Companies), imports Leads before converting them to Opportunities, and provides a modular ERP stack where CRM is one of many installable apps. We resolve the Account-to-Contact-Company split during scoping, map Getfly pipeline stages to Odoo stages, and preserve call log recording URLs by downloading and re-hosting them in Odoo's attachment storage. Workflow automations built within Getfly do not export; we document the full automation topology during discovery so your admin can rebuild equivalent rules in Odoo Studio. Integrated PABX calling is a Getfly-specific feature that maps partially to Odoo's VoIP module, and KPI dashboards require rebuild as Odoo reports.
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 Getfly CRM 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.
Getfly CRM
Account (Customer)
Odoo CRM
Company (res.partner is_company=True) + Contact (res.partner is_company=False)
1:manyGetfly Accounts with a single primary contact map to an Odoo Company (res.partner with is_company=True) plus a Contact record (is_company=False) linked via parent_id. Getfly Accounts with multiple linked Contacts generate one Company record and multiple Contact records, each with parent_id pointing to the Company. The Account name becomes the Company name; the primary contact's name, email, and phone populate the Contact record. We flag accounts with no contact records during extraction for admin review before insert.
Getfly CRM
Contact (within Account)
Odoo CRM
Contact (res.partner is_company=False)
1:1Getfly's secondary contact fields map to Odoo Contact records with parent_id pointing to the Company res.partner. Email, phone, mobile, and address fields map directly. Role or title fields map to res.partner.function. Any contact-level custom fields migrate to custom res.partner fields created in Odoo Technical Settings before import.
Getfly CRM
Pipeline Stages
Odoo CRM
CRM Stage (crm.stage)
lossyGetfly's configurable pipeline stages map to Odoo CRM Stage records scoped by team_id. Stage order, name, and probability percentage migrate to stage_id.sequence, stage_id.name, and stage_id.onchange_stage_probability. Odoo requires at least one Stage per CRM Team; we create the Stage records before any Opportunity import so the foreign key is satisfied.
Getfly CRM
Deal
Odoo CRM
Opportunity (crm.lead)
1:1Getfly Deals map to Odoo CRM Lead (crm.lead) in opportunity state. Deal name becomes crm.lead.name, deal amount becomes crm.lead.planned_revenue, and dealstage maps to stage_id via the stage name match. Contact_id and company_id (res.partner) are resolved via email and name lookup before the Opportunity insert. Lost or won state migrates as stage_id on the corresponding closed stage.
Getfly CRM
Product
Odoo CRM
Product Template (product.template) + Product Variant (product.product)
1:1Getfly Products map to Odoo product.template records. SKU, name, list_price, and standard_price migrate directly. Getfly custom_fields stored as nested objects on Products flatten into custom product.template fields that we create in Odoo Technical Settings before import. Variant management follows Odoo's standard: if Getfly has no variants, we create a single product.template with product_variant_ids containing one product.product.
Getfly CRM
Activity: Task
Odoo CRM
Task (project.task)
1:1Getfly Activity records of type Task map to Odoo project.task. Subject, description, date, assigned user, and linked account are preserved. activity_type = task maps to project.task with kanban_state = open. Completed tasks map with kanban_state = done and write_date reflecting the completion timestamp.
Getfly CRM
Activity: Call
Odoo CRM
Task (project.task with subtype note)
1:1Getfly PABX call records map to Odoo project.task records with a note subtype to preserve call direction, duration, and disposition in custom fields. The original Getfly recording URL is downloaded during the extract phase and re-uploaded as an ir.attachment linked to the task. If the destination Odoo instance does not have the VoIP module, call recordings are stored as generic attachments with a naming convention reflecting the call date and duration.
Getfly CRM
Activity: Meeting
Odoo CRM
Calendar Event (calendar.event)
1:1Getfly Activity records of type Meeting map to Odoo calendar.event. Start datetime, end datetime, subject, description, and attendee list (linked contacts) migrate to calendar.event and calendar.attendee records respectively. Meeting location maps to calendar.event.location.
Getfly CRM
Workflow Automations
Odoo CRM
Server Actions (base.automation) / Automated Actions
lossyGetfly workflow rules are not exportable via API and do not migrate. We document every active Getfly automation during discovery using a workflow audit questionnaire completed by the customer before migration kickoff. The output is a written inventory with trigger type, conditions, actions, and recommended Odoo base.automation or Studio action equivalent. The customer's Odoo admin or an Odoo partner rebuilds the automations post-migration.
Getfly CRM
Custom Fields (Account/Product level)
Odoo CRM
Custom Fields (res.partner / product.template)
lossyGetfly custom fields vary per customer and are discovered by sampling Account and Product records since Getfly has no schema registry endpoint. We instruct the customer to run a full field audit from Getfly's admin panel before migration kickoff. Each discovered custom field maps to an Odoo custom field (created in Settings > Technical > Fields) with a compatible type (char, text, float, integer, selection, many2one, date) before the data import phase begins.
Getfly CRM
User / Owner
Odoo CRM
User (res.users)
1:1Getfly Users map to Odoo res.users. We resolve by email match. Any Getfly Owner without a matching Odoo res.users is held in a reconciliation queue; the customer's Odoo admin provisions missing users before the Opportunity and Activity import phases run because OwnerId (user_id) is required on crm.lead and project.task.
Getfly CRM
Campaign
Odoo CRM
CRM Team + Tag (ir.model.data)
1:1Getfly marketing Campaigns (name, start/end dates, linked accounts) map to Odoo CRM Tags applied to the relevant Contact and Opportunity records. Campaign membership is preserved as tag names matching the Getfly campaign. If the customer uses Odoo's full CRM module with Team, each Campaign maps to a CRM Team with its own Stage pipeline.
Getfly CRM
Attachment
Odoo CRM
Attachment (ir.attachment)
1:1Attachments associated with Getfly Accounts or Products are referenced by URL in the API. We download each file to local storage during export, preserving the original filename and MIME type, then re-upload to Odoo as ir.attachment records linked to the corresponding res.partner or product.template via res_model and res_id. This prevents broken attachment links post-migration.
| Getfly CRM | Odoo CRM | Compatibility | |
|---|---|---|---|
| Account (Customer) | Company (res.partner is_company=True) + Contact (res.partner is_company=False)1:many | Fully supported | |
| Contact (within Account) | Contact (res.partner is_company=False)1:1 | Fully supported | |
| Pipeline Stages | CRM Stage (crm.stage)lossy | Mapping required | |
| Deal | Opportunity (crm.lead)1:1 | Fully supported | |
| Product | Product Template (product.template) + Product Variant (product.product)1:1 | Fully supported | |
| Activity: Task | Task (project.task)1:1 | Fully supported | |
| Activity: Call | Task (project.task with subtype note)1:1 | Fully supported | |
| Activity: Meeting | Calendar Event (calendar.event)1:1 | Fully supported | |
| Workflow Automations | Server Actions (base.automation) / Automated Actionslossy | Not supported | |
| Custom Fields (Account/Product level) | Custom Fields (res.partner / product.template)lossy | Fully supported | |
| User / Owner | User (res.users)1:1 | Fully supported | |
| Campaign | CRM Team + Tag (ir.model.data)1:1 | Fully supported | |
| Attachment | Attachment (ir.attachment)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.
Getfly CRM gotchas
Workflow automations are not exportable via API
API requires X-API-KEY with subdomain-scoped access
Custom field schemas vary per customer with no registry endpoint
PABX call recordings are URL-referenced only
No public pricing page requires direct sales inquiry
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 API key provisioning
We audit the Getfly account via the X-API-KEY scoped to the customer's subdomain. We extract a full record census: Account count, Contact count, Product count, Deal count by stage, Activity count by type, Campaign count, User roster, and a sample of 50 Account records to identify active custom field names and types. We also distribute the workflow audit questionnaire at this stage so the customer has time to complete it before migration begins. The discovery output is a written scope document with record counts, field mapping draft, and automation inventory template.
Odoo schema design and field provisioning
We design the destination Odoo schema before any data moves. This includes creating custom fields on res.partner (for Contacts and Companies) and product.template using Odoo Technical Settings, configuring CRM Teams and Stages (one Stage per team with probability percentages matching Getfly stage probabilities), and designing the Account-to-Company-Contact split rule based on the customer's Getfly Account structure. Schema changes deploy into an Odoo staging or sandbox database first for validation. Odoo Community self-host migrations require us to coordinate schema deployment with the customer's hosting infrastructure team.
Sandbox migration and record reconciliation
We run a full migration into an Odoo staging database using a representative subset of production data. The customer's RevOps lead reconciles record counts in Odoo against the source census (Accounts vs Companies+Contacts, Deals vs Opportunities, Activities vs Tasks+Events), spot-checks 25-50 records for field-level accuracy, and validates that custom fields populated correctly. Any mapping corrections, missing field creation, or stage configuration adjustments happen at this stage. The customer signs off on the staging result before production migration begins.
Owner reconciliation and user provisioning
We extract every distinct Getfly Owner referenced on Accounts, Deals, and Activities and match by email against the destination Odoo res.users table. Owners without a matching Odoo user go to a reconciliation queue. The customer's Odoo admin provisions any missing Odoo users and sets their access rights. Migration cannot proceed to the Activity import phase without this step because project.task.user_id and crm.lead.user_id are required fields that must resolve to a valid res.users record.
Production migration in dependency order
We run production migration in record-dependency order: res.users provisioning validation, Companies (res.partner is_company=True from Getfly Accounts), Contacts (res.partner is_company=False from Getfly Account contacts), product.template records (with custom field population), crm.stage records per team, crm.lead records as Opportunities (with stage_id, company_id, and user_id resolved), project.task for Tasks and Calls (with call recording ir.attachment download-and-re-upload in the same batch), calendar.event for Meetings, ir.attachment for generic file attachments, and CRM Tags for Campaign membership. Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, delta sync, and automation handoff
We freeze Getfly writes during the cutover window, run a final delta migration of any records created or modified during the migration window, then set Odoo as the system of record. We deliver the workflow automation inventory document to the customer's admin team with Odoo base.automation recommendations per rule. We support a one-week hypercare window where we resolve any data quality issues raised by the customer's team. We do not rebuild Getfly automations as Odoo base.automation inside the migration scope; that is a separate engagement scoped with an Odoo certified partner or the customer's internal admin.
Platform deep dives
Getfly CRM
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 Getfly CRM 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
Getfly CRM: Not publicly documented — direct inquiry to Getfly engineering required.
Data volume sensitivity
Getfly CRM 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 Getfly CRM to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Getfly CRM 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 Getfly CRM
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.