CRM migration

Migrate from Corteza CRM to Odoo CRM

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

Corteza CRM logo

Corteza CRM

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

64%

9 of 14

objects map 1:1 between Corteza CRM and Odoo CRM.

Complexity

BStandard

Timeline

3-5 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Corteza CRM to Odoo CRM is a schema translation from a module-based open-source platform to a record-type-based ERP suite. Corteza organizes CRM data into configurable modules (Lead, Account, Contact, Opportunity, Campaign, Case, Contract, Task, Event) with JSON API and namespace export/import paths; Odoo CRM uses res.partner in two modes (company vs individual), crm.lead in two types (lead vs opportunity), and a calendar.event model for meetings and calls. We audit the Corteza namespace for orphaned page references that block export, capture workflow definitions during discovery for the rebuild handoff, map every standard module to its Odoo equivalent, and resolve the res.partner split between company and individual contacts using the company_name field. Workflows, automations, and namespace configurations do not migrate as code; we deliver a written inventory for Odoo Studio rebuild.

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

Corteza CRM logo

Corteza CRM

What's pushing teams away

  • Enterprise support is unclear — despite Enterprise tier branding, there is no documented SLA or dedicated support channel, leaving self-hosted teams without recourse when issues arise.
  • Workflow stability after upgrades is inconsistent — lead conversion automation buttons have been documented as disabled after restore operations, requiring manual re-import of workflow definitions to fix.
  • The platform feels bare for production use — federation is marked experimental and disabled by default, and multiple standard CRM functions still require manual scripts or DB workarounds.
  • Self-hosting carries hidden operational cost — teams need DevOps capacity for deployment, backups, updates, and troubleshooting that SaaS CRMs absorb entirely.

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 Corteza CRM objects map to Odoo CRM

Each row shows how a Corteza 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.

Corteza CRM

Lead

maps to

Odoo CRM

crm.lead (type = lead)

1:1
Fully supported

Corteza Lead records with conversion status of unconverted map to Odoo crm.lead with type = lead. Standard fields (first_name, last_name, email, phone, rating, source) translate to Odoo name, email_from, phone, and medium_id. We set type to lead at migration time and leave the opportunity conversion to occur natively in Odoo after go-live. Any Corteza lead_score or custom scoring fields map to crm.lead priority or a custom float field.

Corteza CRM

Account

maps to

Odoo CRM

res.partner (is_company = True)

1:1
Fully supported

Corteza Account records map to Odoo res.partner with is_company = True. The company_name, industry, website, street, city, country, phone, and social media URL fields translate to Odoo partner fields (name, industry_id, website, street, city, country_id, phone, social_twitter/facebook/linkedin). We set parent_id = NULL for company partners and use the company_name field as the primary name field.

Corteza CRM

Contact

maps to

Odoo CRM

res.partner (is_company = False, parent_id to Account)

1:many
Fully supported

Corteza Contact records map to Odoo res.partner with is_company = False and parent_id pointing to the migrated Account partner. First name and last name concatenate into Odoo name. Email, phone, job_title, department, and the account relationship (AccountContactRole) translate to email, phone, function, department_id, and contact_type. If a Corteza Contact has no parent Account, we create an orphan partner record and flag it for the customer admin to resolve.

Corteza CRM

Opportunity

maps to

Odoo CRM

crm.lead (type = opportunity)

1:1
Fully supported

Corteza Opportunity records map to Odoo crm.lead with type = opportunity. Stage, amount, probability, expected_close_date, and description map to stage_id, expected_revenue, probability, date_deadline, and description. We resolve the Account lookup by matching Corteza account_id to the migrated res.partner company record and set partner_id on the Odoo opportunity. OpportunityContactRole records create crm.lead.partner_involved_id entries linking the Opportunity to related Contact partners.

Corteza CRM

Campaign

maps to

Odoo CRM

crm.tag or utm.campaign

lossy
Fully supported

Corteza Campaign records translate to Odoo utm.campaign for campaign tracking attribution (UTM tags on leads and opportunities). CampaignMember records linking Contacts and Leads to a Campaign migrate as crm.lead records tagged with the utm.campaign reference. Odoo does not have a native CampaignMember object; the campaign association is stored on the lead via campaign_id. If the customer requires campaign member tracking as a separate list, we recommend using Odoo Mass Mailing Lists (mailing.list) as the replacement.

Corteza CRM

Case

maps to

Odoo CRM

helpdesk.ticket

lossy
Fully supported

Corteza Case records map to Odoo helpdesk.ticket if the customer licenses the Odoo Helpdesk app. Case status, priority, origin, and description translate to ticket stage_id, priority, origin, and description. Case-contact and case-account relationships map to ticket partner_id and the ticket's project_id if linked. If Helpdesk is not licensed, Cases map to crm.lead with a custom case_type tag and lose the service-level tracking features.

Corteza CRM

Contract

maps to

Odoo CRM

account.move or sale.subscription

lossy
Fully supported

Corteza Contract records with line items (ContractLineItem) translate to Odoo account.move (invoicing) or sale.subscription (subscription management) depending on whether the contracts represent recurring billing or one-time agreements. Contract terms, dates, and related Account and Contact roles map to the corresponding fields. ContractLineItem pricing and quantities map to invoice lines or subscription line items. This mapping requires the customer to decide on the Odoo contract representation during scoping.

Corteza CRM

Task

maps to

Odoo CRM

project.task or calendar.event

1:1
Fully supported

Corteza standalone Tasks with no parent CRM record map to Odoo project.task. Tasks related to CRM records (Lead, Account, Contact, Opportunity) map to Odoo calendar.event if they represent meetings or calls, or project.task if they represent action items. Status, due date, assignee, and description translate to stage_id, date_deadline, user_id, and description. Task assignment resolves Corteza user IDs to Odoo res.users by email match.

Corteza CRM

Event

maps to

Odoo CRM

calendar.event

1:1
Fully supported

Corteza Event records (meetings, calls) map to Odoo calendar.event with start_datetime, stop_datetime, duration, location, and description preserved. Organizer and attendee references from Corteza resolve by email to Odoo res.users (organizer) and res.partner (attendees). EventRelation records in Odoo link attendees via calendar.event.res_partner_rel. We set the event's crm_lead_id if the Odoo event is linked to a migrated opportunity.

Corteza CRM

Quote

maps to

Odoo CRM

sale.order

1:1
Fully supported

Corteza Quote records with line items (QuoteLineItem) map to Odoo sale.order. Quote status (draft, sent, accepted, lost) maps to Odoo state (draft, sent, sale_order, canceled). Related Opportunity maps via the order's opport_id to the migrated crm.lead opportunity. QuoteLineItem quantity, unit price, and discount map to sale.order.line quantity, price_unit, and discount. Product references resolve to Odoo product.product records via SKU match.

Corteza CRM

Product

maps to

Odoo CRM

product.product / product.template

1:1
Fully supported

Corteza Product records map to Odoo product.template with product_variant_ids. Product name, SKU (hs_sku), list price, and cost map to name, default_code, list_price, and standard_price. If Corteza products have variants (size, color), we create Odoo product template with variant attributes. Pricebook and PricebookEntry records translate to Odoo product.pricelist and product.pricelist.item entries attached to the product.

Corteza CRM

Custom Module

maps to

Odoo CRM

ir.model / ir.model.fields

lossy
Fully supported

Corteza's low-code module builder creates entirely custom module objects. We translate these to Odoo custom modules by pre-creating ir.model (x_custom_object) and ir.model.fields definitions in the destination Odoo database before data migration. Custom field types in Corteza (select, number, date, record reference) map to Odoo field types (selection, float, datetime, many2one). Custom validation rules, required field constraints, and default values translate to Odoo ir.model.constraint and ir.model.fields.default entries. The customer reviews the custom module mapping during staging.

Corteza CRM

Files and Attachments

maps to

Odoo CRM

ir.attachment

1:1
Mapping required

Corteza file fields and standalone attachments migrate as Odoo ir.attachment records. We extract file binary content, name, and mime type from the Corteza export and create ir.attachment records linked via res_model and res_id to the migrated parent record (crm.lead, res.partner, etc.). Folder structure from Corteza's export is not preserved; all files land in a flat attachment list on each record. Bulk attachment export with full folder hierarchy may require supplemental file system handling beyond the API migration path.

Corteza CRM

Workflow and Automations

maps to

Odoo CRM

Inventory only (not migrated)

1:1
Fully supported

Corteza Workflow definitions are captured during discovery as JSON exports and documented in the workflow rebuild handoff. We do not translate Corteza workflows to Odoo automated actions because the trigger models and action types differ structurally. The inventory document lists each Corteza workflow with its trigger (record create, update, stage change), conditions, sequence, and actions with Odoo Automated Action or Studio action equivalents recommended for rebuild in Odoo Studio. Lead conversion automation is flagged as requiring specific Odoo CRM action rules.

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.

Corteza CRM logo

Corteza CRM gotchas

High

Namespace export fails on orphaned page references

High

Workflow automation breaks after restore or upgrade

Medium

Field-level security does not cover all access scenarios

Medium

Federation is experimental and not production-ready

Low

No publicly documented API rate limits

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

  • Namespace export fails on orphaned page references

    Corteza's namespace export path explicitly halts when any page in the namespace references a deleted module. This prevents the 'export everything and move it' migration path from completing without prior remediation. We audit the namespace tree for orphaned page-module links before attempting export, clean up the broken references, and then proceed with the namespace package. If the customer has been using Corteza for an extended period without pruning deleted modules, this audit can add one to three days to the discovery phase.

  • Workflow automation definitions do not migrate between platforms

    Corteza Workflows, including lead conversion buttons and CRM action automations, have been documented as breaking after restore or upgrade events even within the same Corteza instance. Moving from Corteza to Odoo means all workflow definitions require rebuild in Odoo Studio Automated Actions, server actions, or base_automation rules. We capture a complete workflow inventory during discovery with trigger, condition, action, and sequence details, but the rebuild work is a separate admin task post-migration. The lead conversion button specifically requires rebuilding as an Odoo CRM action rule on stage change.

  • res.partner split between company and individual requires up-front design

    Odoo uses a single res.partner model for both companies and individuals, differentiated by the is_company flag. A Corteza migration that treats this as a simple 1:1 object map will produce duplicate partner records. We split during migration: Corteza Account records become is_company = True res.partner records; Corteza Contact records become is_company = False records with parent_id pointing to the migrated Account partner. This split requires validating that every Corteza Contact has a valid Account relationship; Contacts without parent Accounts require a decision (create orphan company, link to existing, or exclude) before migration proceeds.

  • No documented API rate limits for Corteza bulk export

    Corteza does not publish API rate limit quotas in its public documentation. For bulk migration operations against a specific Corteza instance, we cannot pre-configure rate-limit-aware throttling without performing discovery requests to measure the instance's actual behavior. We start with conservative request pacing and monitor for HTTP 429 responses to dynamically adjust throughput. Large Corteza instances (over 100,000 records) may require extended export windows if the instance enforces implicit throttling not documented in public API docs.

  • Odoo CRM requires the Helpdesk app for Case service-level features

    Corteza Cases include service-level tracking (priority, origin, status, milestones, entitlements) that has no equivalent in the base Odoo CRM module. If the customer relies on case management with SLA tracking, the Odoo Helpdesk app must be licensed and configured before case migration. Without Helpdesk, Cases migrate as crm.lead records tagged with a case_type marker, losing priority escalation, entitlement management, and milestone tracking features. We confirm the Helpdesk licensing decision during scoping.

Migration approach

Six steps for a successful Corteza CRM to Odoo CRM data migration

  1. Discovery and namespace audit

    We audit the source Corteza instance across all modules in use, custom module definitions, workflow list, user roster, and attachment volume. We specifically run the namespace export audit to identify orphaned page references that would block export. We extract the complete workflow definition list in JSON format for the rebuild inventory. We pair this with a review of the target Odoo version (Odoo Online, Odoo.sh, or on-premise), the Odoo Apps already licensed (CRM, Project, Helpdesk, Sale, Invoice), and any custom module requirements. The discovery output is a written migration scope, namespace cleanup checklist, and workflow inventory draft.

  2. Namespace cleanup and schema preparation

    We clean up orphaned page references in the Corteza namespace (pages that reference deleted modules) so that namespace export can complete. We simultaneously begin Odoo schema preparation: configuring the Odoo CRM pipeline stages to match Corteza opportunity stages, creating res.partner address titles and industries, provisioning custom fields on crm.lead and res.partner for Corteza properties that do not map to standard Odoo fields, and configuring the crm.lead record types. If custom Corteza modules exist, we create Odoo custom module definitions (ir.model, ir.model.fields) in a staging database. If the Helpdesk app is licensed, we configure ticket stages to match Case statuses.

  3. Staging migration and reconciliation

    We run a full migration into a staging Odoo database (copy of production or a fresh Odoo Online database) using representative data volume. We validate record counts for each object (Accounts -> res.partner, Contacts -> res.partner, Leads -> crm.lead, Opportunities -> crm.lead, Cases -> helpdesk.ticket, Tasks -> project.task, Events -> calendar.event), spot-check 25-50 random records against the Corteza source for field accuracy, and confirm the parent_id relationships on res.partner records. Any mapping corrections and schema adjustments happen in staging before production migration begins.

  4. User and Owner reconciliation

    We extract every distinct user referenced on Corteza records (Leads, Opportunities, Cases, Tasks, Events) and match by email against the Odoo destination's res.users table. Users without a matching Odoo account go to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Corteza users require a decision (provision as inactive Odoo users, reassign records to active users, or exclude) during scoping.

  5. Production migration in dependency order

    We run production migration in record-dependency order: res.partner company records first (from Corteza Accounts), res.partner individual records second (from Corteza Contacts with parent_id resolved), crm.lead lead records (type = lead), crm.lead opportunity records (type = opportunity with partner_id and user_id resolved), helpdesk.ticket records, project.task records, calendar.event records, sale.order quotes, product.product records, and ir.attachment records last. Each phase emits a row-count reconciliation report before the next phase begins. Custom module data migrates after standard objects because custom module records may have many2one lookups to res.partner or crm.lead.

  6. Cutover, validation, and workflow handoff

    We freeze Corteza writes during cutover, run a final delta migration of any records modified during the migration window, then enable Odoo as the system of record. We deliver the workflow inventory document to the customer's admin team with Odoo Automated Action and Studio equivalents for each Corteza workflow. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's team. We do not rebuild Corteza workflows as Odoo automated actions inside the migration scope; that work is handled by the customer's admin or an Odoo implementation partner using the delivered inventory.

Platform deep dives

Context on both ends of the pair

Corteza CRM logo

Corteza CRM

Source

Strengths

  • 100% open-source with no per-user, per-contact, or tier-gated feature restrictions on the self-hosted version.
  • Self-hosted deployment gives complete data ownership and sovereignty over where customer data resides.
  • Low-code module builder lets non-developers create custom CRM objects and fields without writing code.
  • API-first design documented via OpenAPI with OIDC authentication for secure integrations.
  • Fine-grained RBAC with field-level read and update permissions for complex internal security policies.

Weaknesses

  • No documented SLA or dedicated enterprise support tier despite Enterprise tier branding — self-hosted teams rely on community forums.
  • Upgrade and restore events can break standard CRM workflow behavior, including lead conversion automation buttons.
  • Federation feature is marked experimental and disabled by default, limiting multi-instance identity management.
  • Self-hosted deployment requires DevOps resources for installation, configuration, backups, and ongoing maintenance.
  • Community-driven support has inconsistent response times compared to vendor-backed SaaS alternatives.
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 Corteza CRM and Odoo CRM.

B

Overall complexity

Standard migration

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

  • Object compatibility

    A

    All 8 core objects map 1:1 between Corteza CRM 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

    Corteza CRM: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

Estimate your Corteza CRM 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 Corteza CRM to Odoo CRM data migrations

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

Can't find your answer?

Walk through your Corteza CRM 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 records with standard CRM modules and a clean namespace export. Migrations with custom Corteza modules, orphaned page references requiring cleanup, large activity histories (over 200,000 calendar events or tasks), or multi-company Odoo setups requiring complex res.partner parent_id resolution move to eight to twelve weeks because of module translation complexity, namespace remediation, and Odoo configuration time. The discovery phase alone takes one to two weeks because of the namespace audit requirement.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Corteza CRM.
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