CRM migration
Field-level mapping, validation, and rollback between Sellsy and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Sellsy
Source
Odoo CRM
Destination
Compatibility
9 of 13
objects map 1:1 between Sellsy and Odoo CRM.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from Sellsy to Odoo CRM is a consolidation migration as much as a CRM migration. Sellsy combines CRM, invoicing, and pre-accounting under one roof; Odoo CRM is one module within a full ERP suite that can replace all of those simultaneously or run as a standalone CRM module. The primary technical challenge is that Sellsy conflates Individuals and Companies into a single Contact export without a clean discriminator field — we split by type before importing into Odoo's separate Contact (res.partner, style=contact) and Company (res.partner, style=company) model. Financial documents (Invoices, Orders, Credit Notes) require the Odoo Accounting module to be active and configured; we sequence them after the partner and product catalogs to preserve account balances. SmartTags on Sellsy transactional documents map to Odoo Tags, and where Odoo has no tagging field on that object, we create a custom Char field to hold the tag values. We do not migrate Sellsy automations, document templates, or staff privilege models as code; we deliver a written inventory of each for the customer's Odoo administrator to rebuild.
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 Sellsy 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.
Sellsy
Contact (Individuals)
Odoo CRM
res.partner (style=contact)
1:manySellsy bundles Individuals and Companies in a single Contact export with a type discriminator (personne morale / personne physique). We split the export by the type attribute before import. Each Individual maps to a res.partner record with style=contact. Name, email, phone, address, and custom field values migrate directly. Owner (sellsy staff) maps to Odoo User on the created_by_uid and write_uid fields. The customer chooses whether to create a parent company partner for each Individual or leave them standalone in Odoo.
Sellsy
Corporation / Company
Odoo CRM
res.partner (style=company)
1:1Sellsy Corporation records map to res.partner with style=company. Corporate name, SIRENE or company registry data, address, revenue range, and industry classification migrate as partner fields. The linked staff owner maps to Odoo User. If the customer uses Sellsy's SIRENE enrichment, we preserve the official company identifiers (SIREN, SIRET) in a custom Char field on the Odoo partner record.
Sellsy
Opportunity
Odoo CRM
crm.lead
1:1Sellsy Opportunities map directly to Odoo crm.lead records. Pipeline stages from Sellsy map to Odoo Stage names within the customer's Odoo CRM pipeline. The opportunity amount (montant) migrates to the expected_revenue or planned_revenue field; probability migrates as probability. Owner assignment uses email matching against Odoo Users. Closed Won and Closed Lost outcomes map to Odoo's won and lost stage values.
Sellsy
Pipeline Stage
Odoo CRM
crm.stage
lossyEach Sellsy pipeline becomes an Odoo CRM Stage within the customer's pipeline configuration. Stage order and probability percentages migrate from Sellsy. Odoo CRM's Kanban drag-and-drop stage management requires that we configure the stage sequence before opportunity records are imported so that the default stage is set correctly on insert.
Sellsy
Invoice
Odoo CRM
account.move (type=out_invoice)
1:1Sellsy Invoices require the Odoo Accounting module to be installed and configured before import. Invoice header data (partner, date, number, due date) maps to account.move. Line items map to account.move.line with account_id resolved from the Odoo chart of accounts. Tax amounts, discounts, and SmartTags migrate to Tags on the move record. Invoice status (draft, sent, paid) maps to Odoo's move_state workflow. We flag that the Odoo Accounting app must be activated and a fiscal position / chart of accounts configured before this object imports.
Sellsy
Order
Odoo CRM
sale.order
1:1Sellsy Orders map to Odoo Sale Order records. Product lines migrate as sale.order.line with product_id resolved via the Odoo product catalog. Order total, discount, and SmartTags transfer to the sale.order record. If Odoo Inventory is active, the stock.picking workflow is triggered after sale.order confirmation; we do not trigger confirmation during migration to allow the customer's team to review before fulfilment activation.
Sellsy
Credit Note
Odoo CRM
account.move (type=out_refund)
1:1Sellsy Credit Notes (API support added in v2.86.0) map to Odoo account.move with type=out_refund. The linked original invoice reference migrates to the Odoo reconcile field if the original account.move record has already been imported; otherwise the reference is stored in a custom field for manual reconciliation after import. SmartTags transfer to Odoo Tags on the refund move.
Sellsy
Product
Odoo CRM
product.product / product.template
1:1Sellsy Products map to Odoo product.template (for product type and pricing) and product.product (for stock-tracked variants). Product code from Sellsy maps to the default_code field. Pricing rules migrate to Odoo pricelist items. The product catalog must be imported before Invoice and Order records to satisfy product_id foreign key constraints.
Sellsy
Staff
Odoo CRM
res.users
1:1Sellsy Staff records map to Odoo res.users. We resolve by email match. Staff role and privilege information in Sellsy does not map directly to Odoo's access-control groups — the Odoo administrator assigns access rights based on the staff member's intended role in Odoo. We flag that Sellsy's Staff privilege model is not a direct equivalent of Odoo's user groups and document the mapping decision for the administrator.
Sellsy
Task
Odoo CRM
project.task
1:1Sellsy Tasks map to Odoo project.task records. Assignee, due date, status, and description migrate. If the customer does not have the Odoo Project app active, tasks migrate as a standalone CRM activity log against the related partner or opportunity record instead. The customer confirms the target app during scoping.
Sellsy
Activity (calls, emails, meetings)
Odoo CRM
mail.message / project.task
1:1Sellsy Activities (appointments, calls, logged interactions) map to Odoo mail.message records linked to the parent crm.lead or res.partner. Call logs and meeting entries preserve timestamps and body content. Activity type (call, meeting, email) is stored as a custom field on the mail.message to maintain the original categorisation. We note that Odoo does not expose a native activity timeline per Contact the same way Sellsy does; the CRM Activity view in Odoo shows a subset of logged activities.
Sellsy
SmartTag
Odoo CRM
mail.activity.mixin / Tags
lossySellsy SmartTags are a tagging layer applied to Invoices, Orders, and Credit Notes. In Odoo, Tags are available on crm.lead, account.move, and sale.order records via the mail.activity.mixin or ir_attachment tag system. We map SmartTags to Odoo Tags on the corresponding model. Where the destination Odoo model has no native Tags field, we create a custom Char field to hold the tag values, flagged during scoping for the customer's administrator to confirm.
Sellsy
Custom Field
Odoo CRM
ir.model.fields
lossySellsy custom fields on Invoices, Contacts, and Corporations are read via GET /custom-fields and mapped to Odoo custom fields created in Odoo Studio or via the ORM before migration. Field type mapping follows: Sellsy text maps to Odoo Char, Sellsy number to Float or Monetary, Sellsy date to Date, Sellsy checkbox to Boolean. Custom fields that reference other Sellsy objects (e.g., a lookup from an Invoice to a Contact) are resolved to the corresponding Odoo record ID at migration time.
| Sellsy | Odoo CRM | Compatibility | |
|---|---|---|---|
| Contact (Individuals) | res.partner (style=contact)1:many | Fully supported | |
| Corporation / Company | res.partner (style=company)1:1 | Fully supported | |
| Opportunity | crm.lead1:1 | Fully supported | |
| Pipeline Stage | crm.stagelossy | Fully supported | |
| Invoice | account.move (type=out_invoice)1:1 | Fully supported | |
| Order | sale.order1:1 | Fully supported | |
| Credit Note | account.move (type=out_refund)1:1 | Fully supported | |
| Product | product.product / product.template1:1 | Fully supported | |
| Staff | res.users1:1 | Mapping required | |
| Task | project.task1:1 | Fully supported | |
| Activity (calls, emails, meetings) | mail.message / project.task1:1 | Fully supported | |
| SmartTag | mail.activity.mixin / Tagslossy | Fully supported | |
| Custom Field | ir.model.fieldslossy | Fully supported |
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.
Sellsy gotchas
Owner name uniqueness required in CSV exports
Pricing numbers scattered across modular and bundled models
SmartTags are a tagging layer, not a structured object
Public API rate limits not documented
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
Scoping and module activation check
We audit the source Sellsy account across all active modules, record counts for Contacts/Individuals/Corporations, Opportunities, Invoices, Orders, Credit Notes, Products, Staff, Tasks, and Activities. We confirm the customer's Odoo version, edition (Community or Enterprise), and which Odoo apps are already active (CRM, Accounting, Inventory, Project). If the customer intends to migrate financial documents, we confirm that the Odoo Accounting app is installed and a chart of accounts is configured before the migration window. The scoping output is a written migration scope document and a checklist of Odoo prerequisites.
Contact split and partner schema design
We inspect the Sellsy Contact CSV export schema and confirm the type discriminator column for Individuals vs Companies. We design the Odoo res.partner import plan: Corporations become style=company partners, Individuals become style=contact partners, and the customer decides whether to link Individual partners to their parent Company partner. We pre-create any custom fields on res.partner needed to hold SIRENE identifiers, original Sellsy IDs for reconciliation, and SmartTags where applicable. If Odoo Contacts requires address records in a separate res.partner.address model (certain Odoo versions), we split the flat address fields into the correct child record structure.
Product catalog and financial document schema
We extract the Sellsy product catalog and import it into Odoo product.template and product.product before any transactional records are loaded. This establishes the product_id foreign key required for sale.order and account.move.line records. We then create the Odoo chart of accounts structure to support account.move imports, map Sellsy tax codes to Odoo tax groups, and configure the sale_journal and purchase_journal references that Odoo Accounting requires on invoice and order records.
Sandbox migration and reconciliation
We run a full migration into a staging Odoo database (a copy of the production database or a fresh Odoo.sh environment) with production-like record volumes. The customer's team reconciles record counts, spot-checks 25-50 randomly sampled records against the Sellsy source for field accuracy, and verifies that the contact split produced the correct partner counts. Schema corrections, custom field additions, and mapping adjustments happen here before production cutover.
Owner and user provisioning
We extract every distinct Sellsy Staff member referenced as an owner on Contacts, Opportunities, Invoices, Orders, and Tasks. We match by email against the Odoo res.users table. Any Sellsy owner without a matching Odoo user goes to a reconciliation queue for the customer's administrator to provision before production migration resumes. Owner assignment cannot be completed in Odoo without an active User record for each owner.
Production migration in dependency order
We run production migration in record-dependency order: Product catalog first (no dependencies), then res.partner records (Individuals and Companies), then crm.lead (Opportunities with owner and partner lookups resolved), then sale.order, then account.move (Invoices and Credit Notes), then project.task, then mail.message activity history. Each phase emits a row-count reconciliation report before the next phase begins. SmartTags are mapped to Odoo Tags on each pass. Custom field values from Sellsy are written to the pre-created Odoo custom fields during the same pass.
Cutover, validation, and automation inventory handoff
We freeze Sellsy writes during cutover and run a final delta migration of any records modified during the migration window. We validate that record counts match across all objects, that partner-contact linking is intact, that financial document totals reconcile against Sellsy dashboard totals, and that the owner assignment rate exceeds 95 percent. We deliver the automation and document template inventory document to the customer's Odoo administrator for rebuild in Odoo Studio or via the Actions menu. We provide a one-week hypercare window for reconciliation issues raised by the team and do not include post-migration admin support, training, or workflow rebuild in the standard scope.
Platform deep dives
Sellsy
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Sellsy and Odoo CRM.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
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
Sellsy: Not publicly documented.
Data volume sensitivity
Sellsy exposes a bulk API — large-volume migrations stream efficiently.
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 Sellsy to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Sellsy 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 Sellsy
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.