CRM migration
Field-level mapping, validation, and rollback between MetroLeads and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
MetroLeads
Source
Odoo CRM
Destination
Compatibility
8 of 12
objects map 1:1 between MetroLeads and Odoo CRM.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from MetroLeads to Odoo CRM is a schema redesign, not a record copy. MetroLeads organizes its entire data model around a Lead-centric object where each record carries state, source_tags, lead_fields, and embedded phones and emails. Odoo CRM uses a dual-object model with Leads that convert to Opportunities, a Partner object that replaces MetroLeads Companies, and a separate Pipeline Stages system that replaces MetroLeads tenant-configured state values. We resolve the lead-to-opportunity conversion during scoping, map MetroLeads custom property IDs to Odoo custom field names through the schema catalog first, and preserve MetroLeads call metadata as Odoo activities. Advanced Data Modules and Intellisearch records do not map one-to-one to Odoo objects; we export the raw configuration and deliver a written remapping plan for Odoo Custom Fields and Tags. Workflow automations and reporting configurations do not migrate; we inventory them for the customer admin to rebuild in Odoo's Action Rules or Studio.
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 MetroLeads 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.
MetroLeads
Lead
Odoo CRM
Lead + Opportunity (split required)
1:manyMetroLeads Lead records map to Odoo crm.lead. Leads with terminal MetroLeads state values (e.g., won, customer) map directly to crm.lead with type=opportunity. Leads in intermediate states map to crm.lead with type=lead, and the customer decides whether to run Odoo's lead-to-opportunity wizard manually post-migration or batch-convert at migration time. We preserve MetroLeads state values in a custom Char field x_metro_state on crm.lead so the customer admin can map them to Odoo stage names during pipeline configuration.
MetroLeads
Company
Odoo CRM
res.partner
1:1MetroLeads Company records map to Odoo res.partner with is_company=True. The MetroLeads company UUID is stored in x_metro_company_id as a Char field for audit. Each MetroLeads Lead linked to that Company gets the res.partner record as its partner_id on the Odoo crm.lead. Companies with no associated Leads still migrate as standalone Partners to preserve the organizational structure.
MetroLeads
Phones (embedded array)
Odoo CRM
res.partner.phone
1:1MetroLeads phones are an embedded array on each Lead with type metadata (Work, Mobile, etc.). We extract the phone array, resolve the type, and map Work phones to res.partner.phone and Mobile phones to res.partner.mobile. Multiple phones of the same type are appended with a separator for the Odoo Char field. The original type metadata is preserved in x_metro_phone_type on the partner record.
MetroLeads
Emails (embedded array)
Odoo CRM
res.partner.email
1:1MetroLeads emails are an embedded array with type metadata. We extract and map Work email to res.partner.email and Personal email to x_metro_email_personal for the custom field we create during schema setup. The original type metadata is stored in x_metro_email_type.
MetroLeads
Events
Odoo CRM
mail.activity
1:1MetroLeads Events (call logs, meeting records, email tracking) map to Odoo mail.activity records. event_type maps to activity_type_id (Call, Meeting, Email, etc.) via the Odoo activity type configuration. event_timestamp maps to date_deadline and create_date preserves the original event creation time. The related crm.lead is set as res_id with model=crm.lead so activities appear in the Odoo lead chatter.
MetroLeads
User
Odoo CRM
res.users
1:1MetroLeads Users (sales reps, admins) map to Odoo res.users by email match. assigned_to on MetroLeads Leads becomes user_id on Odoo crm.lead. Any MetroLeads User without a matching Odoo User goes to a reconciliation queue for the customer's Odoo admin to provision before record import resumes.
MetroLeads
Lead State
Odoo CRM
crm.stage
lossyMetroLeads state is a tenant-configured string field with arbitrary values. We extract all unique state values during the export scan, present them to the customer for lifecycle-stage mapping, and configure corresponding crm.stage records in Odoo before migration. Each stage is assigned to the relevant sales team via team_id. Unmapped state values are flagged and default to the first stage in the pipeline.
MetroLeads
Source Tags
Odoo CRM
crm.tag
1:1MetroLeads source_tags are string arrays on Lead records. We create crm.tag records in Odoo for each unique tag value before migration, then link tags to crm.lead records via crm.lead.tag_rel. Tags used for lead disposition (disposition_answered, etc.) are preserved as tags for filtering in Odoo's CRM pipeline view.
MetroLeads
Custom lead_fields
Odoo CRM
Custom Fields on crm.lead
lossyMetroLeads custom property values are keyed by internal property IDs (customer_id_070). We fetch the MetroLeads property schema first, build an ID-to-name mapping, create the corresponding custom fields in Odoo via Studio or metadata (x_fieldname__c naming convention), and populate them during import. Property types (text, number, date, dropdown) map to appropriate Odoo field types (char, float, date, selection).
MetroLeads
Intellisearch
Odoo CRM
crm.tag + Custom Field
1:1MetroLeads Intellisearch is a scoring and saved-search layer that does not map 1:1 to Odoo. We export the raw Intellisearch configuration (saved search criteria, score weights) as a JSON file delivered alongside the migration. If the customer uses lead scoring, we map the score value to a custom integer field x_metro_intelliscore on crm.lead and recommend Odoo's Smart Search or a third-party scoring module for ongoing scoring.
MetroLeads
Advanced Data Modules
Odoo CRM
Custom Models (ir.model)
lossyMetroLeads Advanced Data Modules are tenant-specific data structures with per-organization field definitions. We export the module schema alongside records, create the corresponding custom models in Odoo (ir.model and ir.model.fields via XML-RPC), and map records to the new model. This step requires Odoo Developer mode or Studio access and is scoped as a separate configuration phase in the migration plan.
MetroLeads
Lead Group
Odoo CRM
crm.team or Tag
1:1MetroLeads lead_group is a UUID reference grouping related leads across the platform. We export the UUID and map grouped leads to an Odoo crm.team (for sales team groupings) or a tag applied across all members of the group. The customer chooses the strategy during scoping based on whether lead_group represented a sales territory, campaign, or internal grouping.
| MetroLeads | Odoo CRM | Compatibility | |
|---|---|---|---|
| Lead | Lead + Opportunity (split required)1:many | Fully supported | |
| Company | res.partner1:1 | Fully supported | |
| Phones (embedded array) | res.partner.phone1:1 | Fully supported | |
| Emails (embedded array) | res.partner.email1:1 | Fully supported | |
| Events | mail.activity1:1 | Mapping required | |
| User | res.users1:1 | Fully supported | |
| Lead State | crm.stagelossy | Mapping required | |
| Source Tags | crm.tag1:1 | Fully supported | |
| Custom lead_fields | Custom Fields on crm.leadlossy | Fully supported | |
| Intellisearch | crm.tag + Custom Field1:1 | Mapping required | |
| Advanced Data Modules | Custom Models (ir.model)lossy | Mapping required | |
| Lead Group | crm.team or Tag1:1 | Mapping required |
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.
MetroLeads gotchas
Merge API field priority can silently overwrite data
Custom lead_fields use property IDs not property names
Tenant-specific state values require pre-migration catalog
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 deployment assessment
We audit the source MetroLeads tenant across Lead volume, Company count, Events per lead, custom property catalog (fetched via the property schema endpoint), Advanced Data Module definitions, active User count, and source_tags vocabulary. We pair this with an Odoo deployment assessment: Odoo Online ($50/user/mo) for cloud-managed; Odoo.sh for cloud-hosted with git deployment; or self-hosted for on-premise. The discovery output is a written migration scope document covering record counts, property ID mapping plan, state-to-stage mapping table, and Odoo edition recommendation.
Property schema catalog and custom field creation
We fetch the MetroLeads property schema catalog and build the ID-to-name mapping. We then create the corresponding custom fields in Odoo via Studio (for Odoo Online/Enterprise) or ir.model.fields XML (for self-hosted). Field types are matched: text properties to Char, numeric to Float or Integer, dates to Date, dropdowns to Selection. This step must complete before any Lead records are imported so that Odoo can accept the incoming custom field values.
State-to-stage mapping and pipeline configuration
We extract all unique MetroLeads state values, present the mapping table to the customer for confirmation, and configure the corresponding crm.stage records in Odoo before migration. We assign each stage to the relevant crm.team. The mapping is committed to writing before record migration begins.
Sandbox migration and reconciliation
We run a full migration into an Odoo test database or Sandbox using production-like data volume. The customer's Odoo admin reconciles record counts (Leads in, Partners in, Activities in), spot-checks 25-50 random records against the MetroLeads source, and validates custom field population. Any mapping corrections and custom field additions happen here. The customer signs off on the sandbox migration before production migration begins.
User provisioning and owner reconciliation
We extract every distinct MetroLeads User referenced on Leads and Events and match by email against the Odoo destination res.users table. Users without a matching Odoo User go to a reconciliation queue. The customer's Odoo admin provisions any missing users and sets active/inactive status matching the MetroLeads user status. Migration cannot proceed past record imports because user_id on crm.lead is required for Odoo's assignment logic.
Production migration in dependency order
We run production migration in record-dependency order: res.users (manual provisioning, validated), res.partner (Companies from MetroLeads, with is_company=True), crm.lead (Leads with state-to-stage mapping applied and custom field values populated via x_metro_* fields), mail.activity (Events linked to crm.lead via res_id and model), crm.tag (created before lead import, linked via crm.lead.tag_rel), and Advanced Data Modules (last, after standard Odoo models are populated). Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, validation, and workflow inventory handoff
We freeze MetroLeads 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 the Workflow and Reporting Inventory document listing every MetroLeads automation and custom report with a recommended Odoo Action Rule or Studio equivalent. We support a one-week hypercare window where we resolve reconciliation issues raised by the customer's sales team. We do not rebuild MetroLeads automations as Odoo Action Rules inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
MetroLeads
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between MetroLeads and Odoo CRM.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across MetroLeads and Odoo CRM.
Object compatibility
All 8 core objects map 1:1 between MetroLeads 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
MetroLeads: Not publicly documented in the available research data.
Data volume sensitivity
MetroLeads 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 MetroLeads to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your MetroLeads 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 MetroLeads
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.