Migrate from Atomic CRM to Odoo CRM

Atomic CRM Contacts map to Odoo res.partner records. Contacts with a company link become partners of type company; contacts without a company link become individual partners. The primary key UUID in Supabase is not reused in Odoo; we generate new integer IDs and record the source UUID in a custom field src_uuid__c for audit traceability. Email, phone, and address fields map directly to Odoo's standard partner fields. Company sector in Atomic becomes a partner category or industry_id tag in Odoo.

Atomic CRM Companies map to Odoo res.partner records with partner_type set to company. The one-to-many relationship between Companies and Contacts in Atomic maps to Odoo's native parent_id on res.partner, where the Contact record carries parent_id pointing to the Company partner. We create Company partners first during migration to satisfy the foreign key before importing Contact records. Company sector, size, website, revenue, and tax_identifier map to equivalent partner fields or custom fields created in Odoo Studio during schema setup.

Atomic CRM Deals map to Odoo crm.lead records with type=opportunity. The deal name maps to name, the monetary value maps to planned_revenue, and the deal stage maps to stage_id which we resolve against Odoo's pre-configured pipeline stages. We pre-create Odoo pipeline stages matching Atomic's deal categories before migration. Any Atomic deal linked to a Contact maps with partner_id set to the corresponding res.partner ID, and partner_name is pulled from the Contact's name field.

Atomic CRM Notes map to Odoo mail.message records. The note body becomes the message body, the source Contact or Deal reference becomes res_id and res_model pointing to the migrated res.partner or crm.lead record. Author attribution is resolved via the Contact email matching an Odoo res.users record. Odoo's Chatter thread on crm.lead displays these as the activity conversation history. Note timestamps are preserved in message_date for chronological ordering.

Atomic CRM Tasks map to Odoo crm.activity records linked to crm.lead via activity_type_id and res_id. Atomic task types (Call, Email, Meeting) defined as TypeScript props in App.tsx must be provided by the customer during scoping; we create corresponding activity types in Odoo CRM Settings before migration. Task status, assignee (hubspot_owner_id), due date, and description map to activity state, user_id, date_deadline, and note respectively. Owner resolution uses email matching against Odoo res.users.

Atomic CRM custom fields are Postgres columns added via Supabase Studio without documentation. We run a pre-migration schema diff against a reference Atomic CRM export to discover every column on every table, then pre-create equivalent fields in Odoo using Odoo Studio (or XML data file in developer mode). Field types are mapped from Postgres column types to Odoo field types (varchar to char, integer to integer, boolean to boolean, jsonb to many2many or char depending on content). Custom field mapping is the most time-sensitive part of the schema audit and must complete before any data import.

Atomic CRM user management relies on Supabase Auth with auth UUIDs as owner references on Deals and Tasks. We extract every distinct owner reference and match by email address against the destination Odoo res.users table. Any Atomic owner without a matching Odoo user is placed in a reconciliation queue; the customer provisions the missing Odoo users before record migration resumes. Owner resolution is required for Deals and Tasks and must complete before those object imports begin.

Atomic CRM attachment metadata lives in Supabase but the actual files may live in Supabase Storage or an external S3 bucket. We check for the storage backend during scoping. If files are in Supabase Storage, we export the bucket contents and re-attach them in Odoo as ir.attachment records using Odoo's file storage (local or database attachment mode). Files stored outside Supabase (custom S3, external URLs) require separate coordination. Binary blob storage migration is scoped and priced separately from the base migration.

Atomic CRM stores tags as a many-to-many relationship table (likely contact_tag and deal_tag). Tags migrate to Odoo crm.tag records linked to crm.lead via the tag_ids many2many field. The customer chooses during scoping between Odoo crm.tag for loose labeling or a dedicated many2many field on res.partner for contact-level categorization. Tag names are deduplicated during import and new tag records are created in Odoo before the crm.lead import phase.

Atomic CRM deal categories and pipeline stages are defined as TypeScript props passed to the CRM root component, not stored in the Postgres database. The customer provides App.tsx (or equivalent) during scoping. We parse the deal category enum values, create corresponding crm.stage records in Odoo CRM with sequence and probability values, and map stage_id references during the Deal migration phase. Omitting this step results in Deals importing with no stage assignment.

Atomic CRM task types (Call, Email, Meeting) are TypeScript enum props in App.tsx, not stored in the database. We request the customer share App.tsx during scoping and extract the task type enumeration. We create corresponding crm.activity.type records in Odoo CRM Settings with the same name and icon before the Task migration phase begins. Without this step, imported Tasks have no activity type assignment in Odoo.

If the Atomic CRM instance includes historical email forwarding logs stored in Supabase (mail forwarding feature introduced March 2026), these migrate as mail.message records with message_type=email linked to the relevant crm.lead or res.partner via res_id and res_model. Email subject, body, sender, and recipient map to subject, body, email_from, and email_to fields. We only migrate email metadata stored in Postgres tables; actual email transport remains external (the customer's mail server or Odoo's incoming mail gateway).

Call logs stored in Supabase as part of the Tasks table with a Call classification migrate as crm.activity records with activity_type_id set to the Call activity type resolved from Odoo. Call duration, disposition, and any notes in the task body map to Odoo's custom activity fields. Activity date is preserved from the original Supabase record timestamp.

Atomic CRM owner references on Deals and Tasks use Supabase Auth UUIDs. We match these to Odoo res.users by email address during the owner reconciliation phase. The resulting user_id is written to the crm.lead responsible_id field. Any unresolved owners are flagged in the reconciliation report and held until the customer provisions the corresponding Odoo user account. Owner resolution must complete before the Deal and Task import phases run.

Atomic CRM deal pipelines are single Kanban views with configurable stage names. Odoo CRM supports multiple crm.team (sales teams) each with their own crm.stage sequence. We configure one crm.team per pipeline and assign stage_id values within each team. Stage probabilities are set on the stage records and honored in Odoo's revenue forecasting. This configuration is deployed in Odoo Studio or via XML data file before any crm.lead records are imported.

Atomic CRM's foreign-key relationship between Contacts and Companies (one Company to many Contacts) maps to Odoo's parent_id on res.partner. The Company Contact in Odoo is a res.partner with partner_type=company and the individual Contact is a res.partner with parent_id pointing to it. We preserve the relationship direction during import by creating Company partners first, then resolving parent_id on each Contact record from the stored company_id in the Atomic CRM Contact row.