CRM migration

Migrate from MetroLeads to Odoo CRM

Field-level mapping, validation, and rollback between MetroLeads and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.

MetroLeads logo

MetroLeads

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

67%

8 of 12

objects map 1:1 between MetroLeads and Odoo CRM.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

MetroLeads logo

MetroLeads

What's pushing teams away

  • Reporting and analytics features lack customization depth, with limited dashboard options for drag-and-drop insight building and graphical trend visualization.
  • Integration ecosystem is narrower than enterprise CRMs, making it difficult to connect specialized tools as the business scales beyond the built-in connectors.
  • Small review sample size on public platforms makes independent quality assessment difficult before committing to a contract.

Choosing

Odoo CRM logo

Odoo CRM

What's pulling them in

  • Teams choose Odoo CRM for its modular architecture — one base install with one-click app additions means they can adopt CRM alone and add accounting, inventory, or sales later as the business grows.
  • Small businesses pick Odoo because the Community edition is free and open-source, with no per-user or contact limits, allowing full evaluation before committing to a paid Enterprise tier.
  • The drag-and-drop Kanban pipeline and AI lead scoring are highlighted across G2 reviews as concrete features that make lead management faster and more visual than spreadsheet-based workflows.
  • Odoo's native integration with email, live chat, SMS, VoIP, and WhatsApp means inbound leads from multiple channels feed into a single pipeline without third-party middleware.
  • Companies in retail, supply chain, and construction value that Odoo's CRM module shares the same PostgreSQL database and UI as its ERP modules, eliminating data silos between sales and operations.

Object mapping

How MetroLeads objects map to Odoo CRM

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

maps to

Odoo CRM

Lead + Opportunity (split required)

1:many
Fully supported

MetroLeads 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

maps to

Odoo CRM

res.partner

1:1
Fully supported

MetroLeads 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)

maps to

Odoo CRM

res.partner.phone

1:1
Fully supported

MetroLeads 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)

maps to

Odoo CRM

res.partner.email

1:1
Fully supported

MetroLeads 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

maps to

Odoo CRM

mail.activity

1:1
Mapping required

MetroLeads 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

maps to

Odoo CRM

res.users

1:1
Fully supported

MetroLeads 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

maps to

Odoo CRM

crm.stage

lossy
Mapping required

MetroLeads 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

maps to

Odoo CRM

crm.tag

1:1
Fully supported

MetroLeads 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

maps to

Odoo CRM

Custom Fields on crm.lead

lossy
Fully supported

MetroLeads 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

maps to

Odoo CRM

crm.tag + Custom Field

1:1
Mapping required

MetroLeads 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

maps to

Odoo CRM

Custom Models (ir.model)

lossy
Mapping required

MetroLeads 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

maps to

Odoo CRM

crm.team or Tag

1:1
Mapping required

MetroLeads 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.

Gotchas + challenges

What specifically takes care here

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 logo

MetroLeads gotchas

High

Merge API field priority can silently overwrite data

Medium

Custom lead_fields use property IDs not property names

Medium

Tenant-specific state values require pre-migration catalog

Odoo CRM logo

Odoo CRM gotchas

High

Odoo.sh version gating blocks assisted migrations from trial

High

Enterprise modules fail to install on Community after database restore

Medium

Custom module view inheritance breaks between Odoo major versions

Medium

Custom fields risk losing their application context on Community

Low

API access for Community is gated behind the Custom Plan

Pair-specific challenges

  • MetroLeads property IDs require schema catalog extraction before field mapping

    Custom property values in MetroLeads lead_fields are keyed by internal property IDs (customer_id_070) rather than human-readable names. The property name catalog is a separate API call, and the naming convention varies by tenant. We fetch the full property schema first, build an ID-to-name mapping, create the corresponding custom fields in Odoo, and apply that mapping during field mapping so destination fields are named correctly. Skipping this step results in Odoo custom fields with cryptic internal names and no way to validate whether the correct values landed in the correct fields.

  • MetroLeads native VOIP call metadata has no direct Odoo equivalent

    MetroLeads embeds call recording URLs, disposition codes, and duration directly in the Lead record alongside the call event. Odoo CRM does not have a native VOIP module as part of the core CRM app. Call metadata migrates to mail.activity records with activity_type=Call and custom fields for duration and disposition, but call recordings require a separate storage plan (Odoo Attachments on the activity record, or an external storage bucket with the URL preserved in a Char field). We document the recording storage strategy during scoping and implement the agreed approach during migration.

  • Tenant-specific MetroLeads state values require pre-migration lifecycle mapping

    The MetroLeads Lead state field accepts tenant-configured string values, meaning contacted in one MetroLeads instance may not exist in another. Odoo CRM uses Pipeline Stages defined per sales team. We extract all unique state values during the export scan, present them to the customer for lifecycle-stage mapping, and flag any unmapped values so no records are orphaned with an unresolvable stage during import. The mapping table is committed before any lead records are written to Odoo.

  • Odoo self-hosted instances require XML-RPC migration versus JSON-RPC for Online

    Odoo Online and Odoo.sh use JSON-RPC with Odoo's standard API endpoints. Self-hosted (on-premise) Odoo instances may run older versions with XML-RPC as the primary data migration interface, which has different batching behavior and authentication mechanisms. We determine the Odoo deployment type during scoping and configure the migration pipeline accordingly. Self-hosted migrations on Odoo 12-14 may also require additional schema migration steps if the crm.lead model has custom field definitions that differ from the current Odoo version.

  • Odoo merge API and dedupe rules operate differently from MetroLeads deduplication

    MetroLeads performs automatic lead deduplication on import, and its merge API prioritizes primary lead fields when two leads conflict. Odoo CRM uses a manual duplicate merging process via the crm.merge.opportunity wizard or third-party dedupe modules, and does not auto-merge on import. We flag potential duplicate Leads during the export scan (matching on email and phone) and present them to the customer for manual resolution or dedupe-module activation before the final import phase.

Migration approach

Six steps for a successful MetroLeads to Odoo CRM data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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

Context on both ends of the pair

MetroLeads logo

MetroLeads

Source

Strengths

  • Unified CRM, telephony, and lead capture in a single platform reduces vendor fragmentation.
  • Automatic lead deduplication prevents duplicate records on import.
  • Native cloud VOIP with call logging integrated directly into the Lead record.
  • Workflow automation for reminders and follow-up sequences is built in.
  • Omni-channel engagement tracking across voice, email, and web.

Weaknesses

  • Limited review corpus on public platforms makes independent quality assessment challenging.
  • Analytics and reporting lack advanced visualization and customization options.
  • Smaller integration ecosystem compared to enterprise-grade CRMs.
  • No publicly documented pricing tiers on the main website.
  • Limited evidence of advanced customization options for enterprise-scale deployments.
Odoo CRM logo

Odoo CRM

Destination

Strengths

  • Modular open-source architecture lets teams start with CRM and add ERP apps as needs grow, all sharing one PostgreSQL database.
  • Free Community edition with no contact limits and full source code access means zero licensing cost for evaluation and small deployments.
  • Drag-and-drop Kanban pipeline with AI lead scoring gives a visual, prioritized view of the sales funnel without requiring custom configuration.
  • Native integrations with email, live chat, SMS, VoIP, WhatsApp, and social media feed all inbound leads into a single unified inbox.
  • Active Odoo Community Association (OCA) maintains dozens of community-maintained modules on GitHub for extended functionality.

Weaknesses

  • Gmail and email integration reliability is a recurring complaint — threads drop and conversations scatter across inboxes, disrupting sales team workflows.
  • Enterprise edition pricing stacks quickly: multiple apps at per-user rates ($25–$50/user/month) plus Odoo.sh hosting costs more than many SMBs anticipate.
  • Setup and configuration complexity increases significantly once custom fields, automation rules, and multiple installed modules are in play.
  • Odoo.sh trial databases run on a version (e.g., 18.3) that is not directly migratable to Odoo.sh, blocking the assisted migration path Odoo advertises.
  • Version upgrades between major Odoo releases (e.g., 17→18) frequently break custom module view definitions and XPath expressions, requiring manual remediation.

Complexity grading

How hard is this migration?

Standard CRM migration. All 8 core objects map 1:1 between MetroLeads and Odoo CRM.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across MetroLeads and Odoo CRM.

  • Object compatibility

    A

    All 8 core objects map 1:1 between MetroLeads and Odoo CRM.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    MetroLeads: Not publicly documented in the available research data.

  • Data volume sensitivity

    B

    MetroLeads doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your MetroLeads to Odoo CRM migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about MetroLeads to Odoo CRM data migrations

Answers to the questions buyers ask most during MetroLeads to Odoo CRM migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between three and five weeks for accounts under 15,000 Leads and 3,000 Companies with no Advanced Data Modules and a straightforward state-to-stage mapping. Migrations with multiple Advanced Data Modules, large engagement histories (over 200,000 event records), complex custom property schemas, or Odoo self-hosted destinations move to six to ten weeks because of property ID catalog extraction, custom model creation in Odoo, and the XML-RPC batch chunking required for large activity imports.

Adjacent paths

Related migrations to explore

Ready when you are

Move from MetroLeads.
Land in Odoo CRM, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day