Migrate from Dynamics 365 Field Service to Odoo CRM

D365 Account maps to Odoo res.partner where is_company=True. Primary address, phone, website, and industry fields map directly using Odoo's standard address fields. Parent-account hierarchies in D365 map to res.partner.parent_id in Odoo. If the account is a billing entity only, it migrates as a company-type partner; Odoo does not distinguish between 'billing' and 'service' accounts natively.

D365 Contact maps to Odoo res.partner where is_company=False. Name, email, phone, mobile, job title, and address fields migrate directly. D365's multiple-contact-per-account model is natively supported by Odoo's res.partner structure — no junction table required. Owner (user_id) resolves via email match against Odoo users.

D365 Bookable Resource has no direct Odoo equivalent. FlitStack creates a res.partner record with a custom 'Technician' partner category for each resource, preserving resource name, email, and organizational unit. If your D365 setup uses resource characteristics (skills, certifications), those migrate as crm.lead.tag entries applied to work-order-linked opportunities — Odoo's project.resource model is used only if Odoo Project is deployed alongside CRM.

D365 Work Order is the central service record and cannot map to a single Odoo object. The customer-facing context (account, contact, address, service type) maps to crm.lead as an opportunity with the work order name as the opportunity name. The internal work-tracking context (assigned technician, scheduled date, incident summary) maps to project.task if Odoo Project is in scope; otherwise it stores as custom fields on the crm.lead. The split is determined by whether your Odoo deployment includes the Project app.

D365 Work Order Incidents record problems or symptoms per work order. Multiple incidents per work order are merged into a set of crm.lead.tag entries on the corresponding Odoo opportunity (e.g., 'Incident: Electrical Fault', 'Incident: Motor Failure'). If incident codes carry pricing or billing weight, those values migrate as custom decimal fields on the opportunity rather than as tags. Symptom codes and incident types without a meaningful Odoo tag equivalent are preserved in an 'Incident_History__c' custom field as a text block.

D365 Work Order Products (parts and materials applied to a work order) map to Odoo sale.order.line records on the linked quotation or sale order. Product name, quantity, unit cost, and unit price migrate directly. If the work order has no linked quote, FlitStack creates a draft sale.order attached to the opportunity's partner. The product.product record must exist in Odoo before the line can map — FlitStack validates product SKU existence and flags missing products before migration.

D365 Work Order Services (labor line items) map to sale.order.line with the service flag set to True. Duration and hourly rate from D365 migrate as quantity and unit price on the Odoo line. If D365 tracks service task type (diagnostic, repair, maintenance), that value becomes a crm.lead.tag on the parent opportunity. Tax codes on service lines map to Odoo's account.tax based on the D365 tax code value — value-by-value mapping is required per jurisdiction.

D365 Cases (service incidents not tied to a work order) map to crm.lead records with a dedicated 'Case' stage in the Odoo pipeline. Subject, description, priority, and status migrate as crm.lead name, description, priority, and stage. If cases have a parent-account or parent-contact, those link via the standard partner_id lookup in Odoo. Case resolution notes and internal comments migrate as mail.message records attached to the lead.

D365 Agreements (recurring service contracts) map to Odoo sale.subscription records. Contract name, start/end dates, billing frequency, and recurring amount migrate directly. If the agreement contains a line-item schedule (services covered), those lines migrate as sale.subscription.line records. One-time setup fees on the agreement map as a non-recurring line on the subscription. Billing term (advance/arear) maps to Odoo's invoicing policy on the subscription product.

D365 Customer Asset links equipment to a customer account with serial number, product, and installed date. Odoo has no native customer asset entity — FlitStack creates stock.production.lot records for each asset serial number and attaches a custom 'Customer_Account__c' field linking the lot to the customer partner. Asset lifecycle status (Active, Inactive, Under Repair) migrates as a custom selection field on the lot. If your Odoo deployment includes the Maintenance app, assets can alternatively map to maintenance.equipment with the customer as the partner_id.

D365 Resource Bookings assign technicians to work orders with start/end times. Each booking maps to a project.task record with the assigned technician as the user_id and the booking window as task planned date range. If the booking has a meeting context (customer on-site visit), a calendar.event is also created in Odoo with the customer partner linked. Odoo's standard calendar uses mail.activity.type records for activity types — FlitStack maps D365 booking type codes to the closest Odoo activity type by name match.

D365 Field Service products (parts) and service items map to Odoo product.product records. Product name, SKU, list price, standard cost, and product type (inventory vs. consumable vs. service) migrate directly. Product categories from D365 map to product.category in Odoo. If D365 uses product variants (size, color), those migrate as Odoo product variants on the same template.