Migrate from Odoo Help Desk to Salesforce Service Cloud

Odoo Tickets map to Salesforce Case. We export subject, description, stage, priority, assignee (res.users), partner (res.partner), team (helpdesk.team), tags, creation date, and write date. The res.partner customer reference is the critical dependency: we export all referenced res.partner records first and resolve them to Salesforce Account or Contact IDs before inserting Cases so that the WhoId and AccountId foreign keys are satisfied at insert time. Custom fields on helpdesk.ticket (detected as x_studio_ or x_ fields in ir.model.fields) are exported as explicit column mappings and created as custom fields on Case before the migration run.

Odoo res.partner records that are companies (is_company=True) map to Salesforce Account; individual contacts (is_company=False) map to Salesforce Contact attached to the corresponding Account. The Odoo partner record may be referenced across multiple helpdesk.ticket rows, so we deduplicate by partner ID during export and use the Salesforce upsert semantics to avoid duplicate Account or Contact creation. Email, phone, street, city, country, and website migrate to the standard Account or Contact fields. Any partner without an email is flagged for manual review because Salesforce Cases without a Contact or Account require a Known Contact configuration to route correctly.

Odoo Helpdesk Teams define pipeline settings, member assignments, and alias emails. We export team definitions and map them to Salesforce Queue records, which control case assignment routing. Teams that use Odoo's email alias routing map to Salesforce Email-to-Case routing rules. If the customer uses Odoo's multi-company feature, team-to-company linkage is preserved as a custom text field on the Queue because Salesforce Queues are org-wide rather than company-scoped. The team configuration is documented separately so the admin rebuilds routing rules in Service Cloud Omni-Channel.

Team membership is a many2many link between res.users and helpdesk.team. We resolve the user records (login, name, active status) and map them to Salesforce User records by email match. Inactive Odoo users are included in the export so that historical assignment records remain intact on closed tickets; they are mapped to inactive Salesforce Users. Name collisions (two Odoo users with the same email as two Salesforce Users) are flagged in the reconciliation queue for the admin to disambiguate before migration resumes.

Odoo helpdesk stages are team-scoped records with name, sequence, is_close flag, and fold status. We export all stage definitions, sort them by sequence order, and map them to Salesforce Case Status values within a Case Record Type. The is_close flag maps to a Case Status value where IsClosed=True on the Salesforce Status field. If Odoo stages use fold (collapsed view in the kanban), we document that behavior as a Salesforce List View configuration note rather than a direct field migration.

Ticket conversations live in mail.message and mail.tracking_value linked to helpdesk.ticket by res_id. We export message body (HTML), author (res.partner ID mapped to Contact), creation date, and message type (email, comment, notification). Messages are inserted as Salesforce EmailMessage records linked to the parent Case. Large message threads on high-volume tickets are batch-fetched separately per ticket to isolate the blast radius of an Odoo database timeout. We set the EmailMessage.parentId to the migrated Case ID and Incoming=true or false based on the Odoo author type. Internal notes in Odoo (message_type=notification) map to Case Comments with IsPublished=false.

Attachments on tickets are stored in ir.attachment linked by res_model='helpdesk.ticket' and res_id=ticket_id. We export file binaries via Odoo's /web/binary/base64 endpoint, create ContentVersion records in Salesforce, and link them to the parent Case via ContentDocumentLink. Large attachment blobs (>10 MB per file) are flagged for separate handling because Salesforce ContentDocument limits and Odoo's memory threshold both require chunked transfer. We preserve original filename, file extension, and mime type as ContentVersion metadata fields.

Odoo helpdesk tags are ir.records in a shared tag pool linked to helpdesk.ticket via many2many. They are plain string labels. We export tag names and link them back to migrated tickets. The destination strategy is chosen during scoping: either Salesforce native Case Tags (Text field with tags comma-separated) or a custom multi-select picklist if the customer wants tag-based reporting in Salesforce. We do not assume all tags are support-specific; some may have been repurposed for internal categorization and we surface them for the admin to confirm the mapping intent.

Odoo SLA policies define response and resolution deadlines tied to ticket priority or team. We export SLA definitions (name, stage_target, time_days, time_hours, priority) as a documented configuration record rather than a direct API object import, because Salesforce SLA enforcement uses Entitlement Processes and Business Hours which require the admin to configure the Entitlement record first. We map the Odoo SLA priority levels to Salesforce Case Priority and note which Entitlement Process each ticket team should be assigned to. The admin activates business hours in Service Cloud before the Entitlement Process is usable.

Odoo Help Desk ratings are linked to ticket resolution with a rating/subrating value (1-5 stars) and a rater reference to res.partner. Salesforce Service Cloud standard objects do not have a native CSAT field on Case. We map the rating value to a custom numeric field rating_score__c on Case and the rater partner to the Case Contact. If the customer used Odoo's rating with comments, the comment text migrates to a custom long-text field rating_comment__c. We note that Salesforce Survey (former Surveyforce) or a connected product like Qualtrics is the native path for ongoing CSAT collection after migration.

Custom fields on helpdesk.ticket registered in ir.model.fields with state='manual' are detected during schema discovery and exported as explicit column mappings. Both x_studio_ and x_ prefixed fields are surfaced with their human-readable string labels so the customer confirms which ones to migrate. We create equivalent custom fields on the Case object in Salesforce (with __c suffix, matching the original field type where possible) before the migration run. Fields that use Odoo selection fields map to Salesforce picklists, which requires the admin to replicate the picklist value set in Salesforce before migration proceeds.

Agent assignment on helpdesk.ticket (user_ids many2many) maps to the Salesforce User assigned as Case Owner. We export user login, name, email, and active status. Inactive Odoo users are exported so that historical assignment records on closed tickets remain intact and point to the correct User ID. The mapping is resolved by email match against the destination Salesforce org's User table. Any Odoo user with no matching Salesforce User is placed in a reconciliation queue; the admin provisions the User in Salesforce before migration resumes.