Migrate from Salesforce Field Service to Microsoft Dynamics 365 Sales

WorkOrder maps directly to Dynamics 365 Case when the field service record represents a reactive service call, maintenance ticket, or support incident. We map WorkOrder.Subject to Case.Title, WorkOrder.Status to Case.StatusCode, and WorkOrder.Priority to Case.Priority. For contract-based or project-type work orders, we map to Opportunity instead.

WorkOrder records where IsClosed = false and WorkType indicates billable project or contract work split to Dynamics 365 Opportunity. The Opportunity.Name derives from WorkOrder.WorkOrderNumber + Account.Name. Amount and line items map to Opportunity.Amount and OpportunityProduct records. This split requires a WorkType-based value-mapping rule defined before migration.

ServiceAppointments translate to Dynamics 365 Activities — completed visits become Tasks with Subject, Description, and actual duration; scheduled future appointments become Appointments with Start/End times preserved from the source Schedulesapointment.ScheduledStart and ScheduledEnd fields. Parent link maps to the migrated Case or Opportunity record ID.

Salesforce ServiceResources (technicians, dispatchers, crews) map to Dynamics 365 SystemUser records. We match by email to resolve existing Dynamics 365 users. ServiceResource.IsActive determines SystemUser.IsDisabled. Skill certifications and territory assignments from related SkillRequirement and ServiceTerritory records surface as custom fields on the SystemUser or related custom entities in Dataverse.

SkillRequirement stores skill-to-resource mappings with skill level and certification status. Dynamics 365 lacks a native SkillRequirement equivalent in core Sales — we create a custom SkillAssignment table in Dataverse linked to SystemUser. Each skill migrates as a skill name text value with a related proficiency level field. Organizations using Field Service module can use its native skill entities instead.

Salesforce Assets linked to Accounts migrate to the Dynamics 365 Field Service Asset entity when the Field Service add-in is licensed. For core Sales migrations without Field Service, Assets migrate as a custom Asset table or as structured custom fields on the Account record (serial number, installation date, warranty expiration). Parent-child asset hierarchies map to Asset.ParentAssetId where the destination supports it.

WorkOrderLineItem maps to OpportunityProduct when the parent WorkOrder split to Opportunity. Each line item's Product2 reference migrates to Product in Dynamics 365. Quantity, unit price, and line cost translate to Quantity, UnitPrice, and manual discount or tax fields. Non-billable parts on service cases map as Case (Incident) line notes or custom fields.

ServiceTerritory defines geographic zones for dispatch and scheduling. In Dynamics 365, Territory management exists in Sales Enterprise. We map each ServiceTerritory.Name to a Territory record and link ServiceResources with their assigned territories via a custom junction object. If Dynamics 365 Field Service is active, scheduling territories map natively to the scheduling assistant.

Salesforce Entitlement records define service level agreements, active periods, and covered assets. We map Entitlement.Name to Contract.Title, Entitlement.StartDate to Contract.StartDate, and map covered Assets to Contract line items or custom fields. SLA milestones migrate as custom fields on the Contract record since Dynamics 365 SLA tracking is part of the Customer Service hub module.

Salesforce User records who own WorkOrders, ServiceAppointments, and Assets resolve to Dynamics 365 SystemUser by email match. Unmatched owners receive a fallback assignment to a designated migration admin user and are flagged in the reconciliation report for manual reassignment in Dynamics 365.

Salesforce Account maps 1:1 to Dynamics 365 Account. Account.Name, Account.Phone, Account.BillingAddress, and Account.Industry transfer directly. Multi-address configurations (Shipping vs Billing) collapse to the primary address with secondary stored as a custom field since Dynamics 365 core Sales uses a single address block unless the Field Service add-in is active.