CRM migration

Migrate from Customer Database App to Odoo CRM

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

Customer Database App logo

Customer Database App

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

58%

7 of 12

objects map 1:1 between Customer Database App and Odoo CRM.

Complexity

BStandard

Timeline

2-3 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Customer Database App holds data as a single flat contact record with an entirely user-defined field schema. Odoo CRM uses a relational model built around res.partner (Contacts), crm.lead (Leads), and crm.lead (Opportunities), with a structured pipeline stage system and tag management via res.partner.category. There is no public API on Customer Database App, so we extract through CSV or VCF exports, infer the active field list from column headers, and map each custom field to an Odoo custom field of equivalent type. MySQL sync users hold a second copy of their data; we extract from MySQL where it is reachable as it typically contains records not yet synced back to the local app. Vouchers, phone call history, and caller-ID logs have no Odoo equivalent and do not migrate. We deliver a written Odoo pipeline and stage configuration before data moves, and a supplemental voucher export CSV for manual re-entry.

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

Customer Database App logo

Customer Database App

What's pushing teams away

  • The absence of a programmatic API makes automated exports and integrations with downstream tools impossible without manual file handling.
  • No collaborative features such as user roles, activity logs, or shared dashboards create friction when a second team member needs access to a customer record.
  • The free tier carries no service-level guarantee; users have reported no recourse when data loss occurs on the hosted version.
  • Scalability is limited — performance degrades noticeably as the customer list grows beyond a few hundred records on mobile hardware.
  • Marketing and automation capabilities are absent, which pushes teams to migrate once they need email campaigns, lead scoring, or workflow triggers.

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 Customer Database App objects map to Odoo CRM

Each row shows how a Customer Database App 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.

Customer Database App

Contact

maps to

Odoo CRM

res.partner

1:1
Fully supported

Customer Database App Contacts map directly to Odoo res.partner records. We infer the complete field list from the CSV column headers, then create Odoo custom fields of matching type (char, text, date, integer, float, selection) in the Odoo Settings before import. Free-text fields with embedded commas are sanitized during the transform. The res.partner is created as customer=True to mark it as an external contact rather than an internal user.

Customer Database App

Pipeline Stage

maps to

Odoo CRM

crm.stage

lossy
Fully supported

Customer Database App Kanban stages export as a label column on each contact record. We map each distinct stage name to a corresponding crm.stage sequence in Odoo, preserving the original ordering. Probability percentages can be set per stage if the customer provides the weighting; otherwise stages default to Odoo's standard probability ladder. The stage sequence is configured before contact import so that Opportunities can reference the correct stage_id on insert.

Customer Database App

Contact (with stage label)

maps to

Odoo CRM

crm.lead (Opportunity)

lossy
Fully supported

Contacts that have a non-empty pipeline stage label in Customer Database App are candidates for crm.lead creation. We create a crm.lead per contact where a stage label exists, linking it to the corresponding res.partner via partner_id. This requires the partner to be inserted first so the foreign key resolves. The lead_name on crm.lead defaults to the contact's display name, and type='opportunity' is set to distinguish from pure Leads.

Customer Database App

Group / Tag

maps to

Odoo CRM

res.partner.category

1:many
Fully supported

Customer Database App exports tags as comma-separated label strings on each contact row. We split these into individual tag names, create each res.partner.category record if it does not already exist, and link it to the corresponding res.partner via res.partner.category_id (many2many). Tags with special characters are normalized to lowercase alphanumeric for Odoo category name compatibility.

Customer Database App

Birthday

maps to

Odoo CRM

res.partner (date field or custom)

1:1
Fully supported

Birthday exports from Customer Database App as a date field on the contact record. We map it to an Odoo res.partner.date field if the customer's Odoo instance has the Birthdate field enabled via Contacts configuration, or to a custom date field birthdate_date__c on res.partner if the standard field is not active. The date format is normalized to YYYY-MM-DD during the transform.

Customer Database App

Contact Image / PDF Export

maps to

Odoo CRM

ir.attachment linked to res.partner

1:1
Fully supported

Customer Database App can export individual contact records as PDFs or store contact photos. We bundle these into a ZIP archive indexed by contact identifier, then attach each file to the corresponding res.partner record via ir.attachment with res_model='res.partner' and res_id pointing to the partner ID. PDF exports land as application/pdf; images land as image/png or image/jpeg.

Customer Database App

Voucher

maps to

Odoo CRM

Not migrated

1:1
Fully supported

Vouchers are a standalone object in Customer Database App with no equivalent in Odoo CRM. Voucher balances are not exported via CSV and have no standard CRM representation. We do not migrate voucher records. We generate a supplemental voucher CSV with all available voucher fields for manual re-entry by the customer in Odoo or in a dedicated vouchers application they choose to install.

Customer Database App

Phone Call History

maps to

Odoo CRM

Not migrated

1:1
Not supported

Caller-ID logs and call history are transient device-level records that are not included in CSV or VCF exports from Customer Database App. These do not migrate. We recommend documenting call-handling procedures and any reference phone numbers separately for the customer's admin to re-enter manually if needed.

Customer Database App

MySQL Sync (if enabled)

maps to

Odoo CRM

Primary extraction source

1:1
Fully supported

Customers with MySQL sync enabled hold two copies of their data. We extract from the MySQL database where it is reachable because it typically contains records not yet synced back to the local app and more complete field data. We reconcile the MySQL copy against any latest CSV export to detect records added or modified after the last sync cycle, then use the MySQL version as authoritative.

Customer Database App

Custom Property (arbitrary user-defined)

maps to

Odoo CRM

ir.model.fields (custom) on res.partner

lossy
Fully supported

Customer Database App supports unlimited user-defined fields with no enforced type or naming convention. We infer the type of each custom field from the exported data values (numeric strings become integer or float, ISO dates become date, everything else becomes char or text). We pre-create each custom field as an ir.model.fields entry in the customer's Odoo database before the contact import phase, so the import can populate them without schema errors.

Customer Database App

Owner / User

maps to

Odoo CRM

res.users

1:1
Fully supported

Customer Database App does not have a multi-user model, but contact records may contain an owner or assigned-to field. We map owner references to res.users by email address where the email domain matches an active Odoo user. Unmatched owners are flagged in the reconciliation report for the customer's admin to provision before the contact import phase runs.

Customer Database App

GDPR / Data Export

maps to

Odoo CRM

res.partner archive

lossy
Fully supported

Customer Database App includes EU-GDPR tools for data export and deletion requests. If the customer's Odoo instance includes the gdpr module or a GDPR app from the Odoo Apps store, we preserve the gdpr_expiration_date and any consent records as custom fields on res.partner. Deletion requests are noted in the migration scope but are not automatically recreated as Odoo does not have a native gdpr.deletion.request model in standard CRM.

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.

Customer Database App logo

Customer Database App gotchas

High

No API means migration runs through CSV exports only

Medium

User-defined schema creates field mapping ambiguity

Medium

MySQL sync creates a parallel data source that must be reconciled

Low

Voucher and birthday objects have no standard CRM equivalent

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

  • No API forces CSV extraction with no delta-sync after cutover

    Customer Database App has no public REST or GraphQL API. We extract data exclusively through CSV or VCF exports generated from within the app, or from the paired MySQL backend where sync is enabled. Any records added or modified in Customer Database App after the migration export date require a manual re-export and a delta import step. We coordinate the final cutover export as close to go-live as possible to minimize the delta window, but automated real-time sync is not achievable without an API that does not exist.

  • User-defined schema means field mapping is installation-specific

    Every Customer Database App installation has a different field set with no canonical schema definition. We infer the active field list from the first export file's column headers and flag any discrepancy between the export and the customer's stated field list before loading data into Odoo. Custom fields with free-text values containing commas may cause CSV parsing issues; we sanitize these during transform. If a customer has renamed or removed fields after their last export, we re-request a fresh export before migration begins.

  • MySQL sync creates a parallel data source requiring reconciliation

    Users who have enabled MySQL sync hold two copies of their data. The MySQL copy may contain records not yet synced back to the local app, or records modified after the last sync cycle. We extract from the MySQL source where it is reachable as it typically holds the most complete dataset. We reconcile the MySQL copy against any latest CSV export to detect deltas, and use MySQL as authoritative. If the MySQL database is not accessible at migration time, we fall back to the CSV export with the limitation that unsynced records may be absent.

  • Odoo requires custom fields to exist before import can populate them

    Odoo CRM enforces a schema-first model: custom fields must be created as ir.model.fields entries before data can be inserted into them. Unlike Customer Database App where any field name can be added on the fly, Odoo requires a formal field creation step with type specification for each custom property. We create all required custom fields in the customer's Odoo database during the schema configuration phase before any data load begins. This adds a pre-import step that must complete before the contact migration phase.

  • Vouchers and call history have no Odoo equivalent and do not migrate

    Voucher balances are not exported from Customer Database App via CSV and have no standard Odoo CRM object. Call history and caller-ID logs are device-level records not included in any export format. We do not migrate these objects. We generate a supplemental CSV of all available voucher fields for the customer's admin to re-enter manually in Odoo or a dedicated vouchers application they choose to install.

Migration approach

Six steps for a successful Customer Database App to Odoo CRM data migration

  1. Export and schema inference

    We request a full CSV export from Customer Database App, or connect to the paired MySQL database if sync is enabled and reachable. We parse the column headers to build the complete active field list and infer each field's data type from the exported values. We present the inferred schema to the customer for confirmation and flag any fields that appear to contain multiple values, embedded delimiters, or non-standard date formats. Any discrepancies between the export and the customer's field list trigger a re-export before we proceed.

  2. Odoo custom field creation and pipeline stage configuration

    We log into the customer's Odoo instance (Community or Online) and create all required custom fields on res.partner as ir.model.fields entries, specifying the correct field type (char, text, date, datetime, integer, float, boolean, selection) for each. We configure the crm.stage pipeline to match the stage names and ordering from Customer Database App, setting probability percentages per stage where the customer provides them. If the customer plans to use crm.lead as Opportunities, we configure the crm.team and assign a salesperson responsible for pipeline ownership.

  3. Owner reconciliation and user provisioning

    We extract every distinct owner or assigned-to reference from the Customer Database App export and match by email against the Odoo res.users table. Any owner without a matching Odoo user is flagged in a reconciliation report. The customer's Odoo admin provisions the missing users (or deactivates the reference if the original owner is no longer active) before we proceed to contact import. OwnerId resolution must complete before Opportunity import because crm.lead requires a valid user_id on insert.

  4. Sandbox migration and reconciliation

    We run a full migration into the customer's Odoo Sandbox or a staging database using production-equivalent data volume. The customer reconciles record counts (Contacts in, Opportunities in, Tags created), spot-checks 25-50 records against the source export, and verifies that custom fields populated correctly, tags assigned to the right contacts, and pipeline stages reflect the original Customer Database App order. The customer signs off the sandbox result before production migration begins.

  5. Production migration in dependency order

    We run production migration in record-dependency order: res.partner (Contacts) first with all custom fields populated, then crm.lead (Opportunities) with partner_id resolved to the contact, res.partner.category (Tags) created individually and linked via many2many, ir.attachment records for contact images and PDFs via ZIP index, and birthday or anniversary dates on res.partner. Each phase emits a row-count reconciliation report before the next phase begins. The MySQL source is used as authoritative where it is accessible.

  6. Cutover, validation, and supplemental export delivery

    We freeze Customer Database App as the system of record once production migration is validated. We deliver the supplemental voucher CSV for manual re-entry and the written pipeline-stage configuration summary for the customer's admin to verify in Odoo. We do not migrate call history, caller-ID logs, or vouchers as these have no Odoo CRM equivalent. We support a three-day post-migration window to resolve any data discrepancies surfaced by the sales team during their first week in Odoo. Workflow and automation rebuilds are outside standard migration scope and are documented as a separate admin task.

Platform deep dives

Context on both ends of the pair

Customer Database App logo

Customer Database App

Source

Strengths

  • Zero cost with no contact count limit removes budget objections entirely for early-stage teams.
  • Mobile app and web browser access means the same database works on desktop and in the field.
  • User-defined schema accommodates non-standard business models without forcing a predefined data model.
  • MySQL sync option enables self-hosting for users who want data portability and ownership.
  • Built-in EU-GDPR tools such as data export and deletion requests simplify compliance for European users.

Weaknesses

  • No public API forces reliance on manual CSV or VCF exports, which breaks down at scale.
  • Absence of user roles and permissions makes the app unsuitable for teams with access-control requirements.
  • No email sequencing, marketing automation, or built-in communications channels limits long-term utility as a sales tool.
  • No SLA or data-residency guarantees on the hosted version introduce reliability risk for business-critical data.
  • Limited reporting and analytics mean users quickly outgrow the insight capabilities once the customer base matures.
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 Customer Database App and Odoo CRM.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Customer Database App and Odoo CRM.

  • Object compatibility

    A

    All 8 core objects map 1:1 between Customer Database App 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

    Customer Database App: Not applicable — no API exists.

  • Data volume sensitivity

    B

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

Estimator

Estimate your Customer Database App 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 Customer Database App to Odoo CRM data migrations

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

Can't find your answer?

Walk through your Customer Database App 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 two and three weeks for accounts under 2,000 Contacts and under 20 custom fields with no MySQL sync complication. Migrations above 5,000 Contacts, with complex multi-value custom fields, a live MySQL sync requiring reconciliation, or attachments bundled as ZIP archives, extend to four to eight weeks. The schema-inference and Odoo custom-field-creation steps are the primary drivers of the pre-import timeline, adding one to two weeks that would not appear in a standard API-to-API migration.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Customer Database App.
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