Migrate from Odoo Field Service to Microsoft Dynamics 365 Sales

Odoo field-service tasks have no standard equivalent in Dynamics 365 Sales

Odoo Field Service tasks are work-order records anchored to Kanban stages, planned hours, and employee assignments. Dynamics 365 Sales has no native 'task' entity that mirrors this structure — its primary records are Leads, Opportunities, and Accounts. Teams that need field-service data in Dynamics must either add the Field Service module (which introduces its own Work Order entity) or create a custom Work Order table in Dataverse. We determine which path during the schema-design step: a custom table preserves the full task schema without requiring an additional module licence, while the Field Service module adds scheduling and service-territory features. Either choice must be made before field mapping begins, because picklist Option Sets and custom columns are scoped to the target table.

Odoo XML-RPC batch limit requires chunked extraction that extends migration timelines

Odoo's external XML-RPC API allows a maximum of 1,000 records per batch call when using the orm.execute method. For Odoo Field Service setups with 30,000 or more task records, this means a minimum of 30 sequential batch calls — each subject to Odoo's per-user request-rate limits and server-response timeouts under heavy load. We implement a chunked-read strategy with exponential back-off on 429 responses and checkpoint logging so that a timeout on record batch 18 does not restart the entire extraction. The migration plan documents the chunking threshold upfront so that teams with large task volumes can plan for extended extraction windows. This is specific to Odoo as a source; Dynamics 365 Dataverse uses a different batch API with its own limits that do not apply during the source-read phase.

Odoo stage names must be pre-seeded as Dynamics Option Set values before migration

Odoo Kanban stages store names as free-form text strings in the fsm.stage model. Dynamics 365 Option Set fields (the equivalent of a pick-list) require values to be created in the solution before records can be saved with those values. If your Odoo pipeline has 12 distinct stage names, we must create 12 Option Set labels in your Dynamics solution before the migration runs — otherwise records would insert with a null stage and require a post-migration update pass. We extract every unique stage name during the audit phase, generate the Option Set value list, and deliver it as a solution-component XML file that your Dynamics admin imports before the migration date. This step is a blocker if skipped; it cannot be retrofitted after data lands.

Multi-technician task assignments collapse to a single Dynamics OwnerId

Odoo allows an unlimited number of employees to be assigned to a single field-service task via its task.employee.ids many2many relation. Dynamics 365 record ownership is single-owner — every record has exactly one OwnerId pointing to a SystemUser or Team. We resolve the primary assignee (first employee in Odoo's assignment sequence) to the Dynamics OwnerId. All secondary assignees are written to a custom semicolon-delimited text field (fs_secondary_assignees__c) so that the information is preserved and your admin can decide whether to create separate records, add team memberships, or handle assignments via a custom sub-grid on the Work Order form.

Chatter history loses rich-text formatting when migrated as Dataverse Annotations

Odoo chatter stores messages in HTML format, supporting bold, links, inline images, and quoted reply blocks. Dataverse Annotations accept plain-text NoteText by default; embedded images are stored as separate noteannotationfiles and require separate attachment handling. We strip HTML tags during the chatter-to-annotation conversion, preserving the text content and timestamps. If your organisation relies on visual formatting in task chatter (for example, structured tables or coloured priority labels embedded in notes), those visual elements will be lost. We surface this in the pre-migration report so that your team can decide whether to keep a read-only Odoo archive for chatter reference.