CRM migration
Field-level mapping, validation, and rollback between AgentLocator and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
AgentLocator
Source
Odoo CRM
Destination
Compatibility
12 of 12
objects map 1:1 between AgentLocator and Odoo CRM.
Complexity
BStandard
Timeline
48–72 hours
Overview
AgentLocator stores leads, contacts, companies, and pipeline stages in a flat real-estate-optimized schema focused on lead generation and follow-up. Odoo CRM uses the crm.lead model (which can be a Lead or Opportunity depending on stage), res.partner for contacts and companies combined, and crm.team for sales groups. We map AgentLocator's leads to Odoo crm.lead records, contact properties to res.partner fields, pipeline stages to crm.stage values per team, and tasks to mail.message and crm.activity records. Custom fields from AgentLocator become ir.model.fields in Odoo with type-aware conversion. Odoo's External API (XML-RPC) handles the migration for Custom-plan instances; Community editions use direct PostgreSQL writes. Workflows, drip campaigns, and ad-management rules from AgentLocator do not migrate — we export their definitions as a rebuild reference for Odoo's Automated Actions and Email Marketing modules. Attachments are re-uploaded to Odoo attachments via the /web/binary/attachment API. Owner resolution matches AgentLocator owner emails to Odoo res.users login emails before records are written.
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 AgentLocator 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.
AgentLocator
Lead
Odoo CRM
crm.lead
1:1AgentLocator leads map directly to Odoo crm.lead records. The crm.lead model handles both raw leads and opportunities — Odoo determines type by stage (unqualified = Lead; qualified with probability > 0 = Opportunity). We preserve the original create date as create_date and write the AgentLocator source system ID into a custom x_source_id char field for traceability.
AgentLocator
Contact
Odoo CRM
res.partner
1:1AgentLocator contacts map to Odoo res.partner with partner_type='contact'. Odoo combines contacts and companies in one model; we set the contact as an individual (is_company=False) and attach it to a parent company partner record when AgentLocator provides a company association. During migration, we also transfer phone numbers, email addresses, job titles, and any custom fields defined on the contact object to corresponding res.partner fields.
AgentLocator
Company
Odoo CRM
res.partner
1:1AgentLocator company records map to res.partner with is_company=True. Odoo stores company-level fields (industry, website, employee count) on the partner record directly rather than a separate object. We map company name to partner_id.name, domain to website, and industry to industry_id lookup.
AgentLocator
Pipeline Stage
Odoo CRM
crm.stage
1:1Each AgentLocator pipeline stage value maps to a corresponding crm.stage name within the target crm.team. Odoo stages are scoped per team and have a sequence order, probability, and is_won/is_lost flags. We map stage names value-by-value and set probability and stage-type flags from Odoo's default conventions unless your team specifies otherwise.
AgentLocator
Deal / Opportunity
Odoo CRM
crm.lead (opportunity mode)
1:1AgentLocator deals with a closedate and amount map to Odoo crm.lead records in opportunity mode. We set the lead_id to the migrated opportunity, write the deal name as crm.lead name, amount as planned_revenue, and closedate as date_deadline. Stage maps via the pipeline-stage value_mapping described above.
AgentLocator
Task / Activity
Odoo CRM
mail.message / crm.activity
1:1AgentLocator logged tasks (calls, emails, follow-ups) map to Odoo crm.activity records linked to the crm.lead. The activity type (call, email, meeting) maps to crm.activity.activity_type_id (phonecall, email, meeting). Original timestamps and owner email are preserved for audit continuity. We also transfer any task descriptions or notes attached to the activity record into the crm.activity note field.
AgentLocator
Note
Odoo CRM
mail.message
1:1AgentLocator notes on leads or contacts map to Odoo mail.message records with message_type='comment'. The note body populates the body field. Odoo renders mail.message records inline in the crm.lead and res.partner chatter views so notes appear alongside other activities. This ensures that historical note content remains accessible within the migrated records and maintains the full context of prior communications.
AgentLocator
Custom Field
Odoo CRM
ir.model.fields
1:1AgentLocator custom fields on leads and contacts require Odoo custom fields created via Settings > Technical > Models > Fields before migration. We create ir.model.fields with matching field types (char, selection, text, float, date, datetime) and then populate the data during migration. The field__c naming convention applies in Odoo Community; Odoo Studio uses a GUI label.
AgentLocator
Attachment / File
Odoo CRM
ir.attachment
1:1AgentLocator file attachments on leads or contacts re-upload to Odoo ir.attachment records. We download the file from AgentLocator's export, then POST it to Odoo's /web/binary/attachment API with the res_model and res_id linking to the migrated crm.lead or res.partner record. The original filename, MIME type, and file size are preserved in Odoo's ir.attachment fields to maintain document integrity and facilitate later retrieval.
AgentLocator
User / Owner
Odoo CRM
res.users
1:1AgentLocator owner assignments resolve by email match to Odoo res.users records. We query res.users for matching login email; unmatched owners are flagged pre-migration and either invited to Odoo first or assigned to a fallback Odoo user (admin by default). No record lands without a valid Odoo user owner_id.
AgentLocator
Tag
Odoo CRM
crm.tag
1:1AgentLocator tags on leads map to Odoo crm.tag records. Tags are stored as a many2many relation on crm.lead (tag_ids). We map tag names verbatim and create any missing tags in Odoo during migration. Each tag record includes the tag name and an optional color index for visual distinction in Odoo's kanban view.
AgentLocator
Saved Filter
Odoo CRM
ir.filters
1:1AgentLocator saved filters for lead segmentation do not have a direct Odoo equivalent. Odoo's ir.filters model stores saved filter definitions, but AgentLocator's filter logic (e.g., by lead source, tag, pipeline stage combinations) must be manually recreated as Odoo filters or domain expressions after migration.
| AgentLocator | Odoo CRM | Compatibility | |
|---|---|---|---|
| Lead | crm.lead1:1 | Fully supported | |
| Contact | res.partner1:1 | Fully supported | |
| Company | res.partner1:1 | Fully supported | |
| Pipeline Stage | crm.stage1:1 | Fully supported | |
| Deal / Opportunity | crm.lead (opportunity mode)1:1 | Fully supported | |
| Task / Activity | mail.message / crm.activity1:1 | Fully supported | |
| Note | mail.message1:1 | Fully supported | |
| Custom Field | ir.model.fields1:1 | Fully supported | |
| Attachment / File | ir.attachment1:1 | Fully supported | |
| User / Owner | res.users1:1 | Fully supported | |
| Tag | crm.tag1:1 | Fully supported | |
| Saved Filter | ir.filters1: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.
AgentLocator gotchas
Annual billing with no refund clause
No public API — migration requires CSV export
Drip campaign automation cannot be exported
Website and IDX/MLS feeds require separate migration
Saved searches are not portable
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 AgentLocator data export and plan Odoo schema setup
FlitStack AI begins every migration with a data audit of your AgentLocator instance. We identify all record types (leads, contacts, companies, deals, tasks, notes), count total records per type, and catalog every custom field and tag. Simultaneously, we review your target Odoo database: which edition (Community or Custom), which CRM modules are installed, and whether custom fields need to be pre-created in Odoo's Settings > Technical > Models before data can land. We deliver a schema setup checklist specifying the Odoo custom fields to create, crm.team names to set up, and crm.stage values to configure per team. Odoo administrators can complete this checklist before the migration run, or FlitStack's technical team creates the fields via the ORM or direct PostgreSQL write depending on Odoo edition.
Resolve owner and user mappings by email
AgentLocator assigns leads and deals to owner users by email. We match each unique owner email against Odoo's res.users.login field. For matched users, we write the res.users.id as the Odoo user_id on migrated records. For unmatched owners (agents who have left, or emails not yet registered in Odoo), we flag these records before migration commits. Your team either invites the unmatched users to Odoo before the cutover, or assigns those records to a designated fallback Odoo user (typically the admin). This step ensures zero records land in Odoo with a null or invalid user_id, which would cause ownership gaps in reporting and pipeline views.
Migrate company and contact partners before leads and deals
Odoo's res.partner model requires parent company records to exist before contact records can reference them via parent_id. FlitStack AI sequences the migration in dependency order: first res.partner records where is_company=True (AgentLocator companies), then res.partner records where is_company=False (AgentLocator contacts) with parent_id set to the migrated company, then crm.lead records with partner_id lookup set to the migrated contact. This order respects PostgreSQL foreign-key constraints and ensures that when a deal or lead is created in Odoo, its contact link resolves correctly. Tasks and notes (mail.message records) are written after their parent records exist, preserving the full activity thread in Odoo's chatter view.
Run a sample migration with field-level diff and validate in Odoo UI
Before committing the full migration, FlitStack AI runs a sample pass against a representative slice of data — typically 200–500 records spanning leads, contacts, companies, deals, and activity records. The sample migrates to a staging Odoo database (or a test company within the production database). We generate a field-level diff comparing source AgentLocator field values against the corresponding Odoo crm.lead, res.partner, and mail.message field values. You review the diff in the Odoo UI to verify stage mapping, contact name formatting, owner resolution, and custom field population. Any mapping corrections are made to the migration configuration before the full run proceeds.
Execute full migration with delta-pickup window and post-migration audit
The full migration runs against the production Odoo database. During the migration, your team continues working in AgentLocator — FlitStack AI uses scoped read access only. A delta-pickup window of 24–48 hours captures any records created or modified in AgentLocator during the migration run. After the delta window closes, we perform a post-migration audit: record counts per object compared against source totals, spot-check of field values in Odoo UI, verification that attachments appear on correct records, and confirmation that owner resolution covered all assigned records. If reconciliation reveals discrepancies, FlitStack AI corrects and re-runs affected records. One-click rollback to the pre-migration state is available if the audit fails for critical data.
Platform deep dives
AgentLocator
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 AgentLocator 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
AgentLocator: Not publicly documented.
Data volume sensitivity
AgentLocator 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 AgentLocator to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your AgentLocator 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 AgentLocator
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.