Migrate from Dynamics 365 Field Service to Microsoft Dynamics 365 Sales

Direct 1:1 map via Dataverse API. Both platforms expose the Account entity with the same logical schema — name, address, industry, primary contact, and parent account hierarchy all map field-for-field without transformation. Owner resolved by email match to the destination user, with unmatched owners flagged for manual assignment before migration.

Direct 1:1 map. Both use the Contact entity with full name fields, email, phone, job title, address, and account lookup. Dynamics 365 Sales Contact.AccountId links to the migrated Account record. N:1 contact-to-account relationships from Field Service preserved via the same lookup.

Dynamics 365 Sales has no native work order entity. We create a WorkOrder__c custom table in Dataverse and map work order fields — work order number, service account, system status, sub-status, priority, description, actual arrival time, actual departure time, and total travel time — as custom fields on the WorkOrder__c record.

Work order incidents (problems linked to work orders) map to a custom multi-select text field or a related WorkOrderIncident__c table, depending on the complexity of incident data. Each incident's msdyn_name (problem description) and msdyn_estimate (labor estimate) migrate as fields on the incident record linked back to WorkOrder__c, preserving the relationship for reporting and audit purposes.

Booking records (resource assignments, start/end times, booking status) have no native equivalent in Dynamics 365 Sales. We serialize the relevant booking fields — resource name, scheduled start, scheduled end, travel duration, and booking status — as JSON or delimited text in a custom BookingData__c field on the WorkOrder__c record.

CustomerAsset entity with operational status, install date, serial number, product, customer account, and asset parent has no Dynamics 365 Sales equivalent. We create a CustomerAsset__c custom table, map all standard fields, and link to the migrated Account record via AccountId lookup.

Service agreements with recurring billing lines, service tasks, and booking setup have no Dynamics 365 Sales equivalent. We export agreement data to a custom ServiceAgreement__c table for reference and generate a PDF summary of each active agreement for manual re-creation in Sales using Opportunities and Contracts.

Product catalog — name, product number, default unit, price list items, and product type — maps directly. Field Service products used in work order products and work order services align with the Sales product entity. Unit group and pricing mechanics are shared across both platforms.

Field Service price list items (products × price lists × units) map to Dynamics 365 Sales price list item structure. Both use the same pricing engine and support quantity-based pricing, discount lists, and tiered pricing. Price list linkage to accounts and opportunities preserved.

Products consumed on work orders (parts used, quantity, unit price, line status) serialize into a custom field on WorkOrder__c since Sales has no work-order-product entity. The data remains queryable for reference even though it does not become a native opportunity product line.

Services delivered on work orders (service task, duration, billing type) serialize into a custom field on WorkOrder__c. The service description and estimated duration are preserved; actual duration comes from BookableResourceBooking.

Field Service technicians and dispatchers exist as BookableResource records linked to SystemUser. We match SystemUser by email to destination users in Dynamics 365 Sales. Active field technicians who will not use Dynamics 365 Sales are flagged as 'to be assigned to a fallback user' before migration, ensuring no orphaned booking assignments exist in the destination environment.

Service territories in Field Service map to Sales territories by territory name and region. Both use the Territory entity with the same hierarchical structure. Territory-based record assignment rules translate directly.

Notes attached to work orders, customer assets, or accounts map directly to the Annotation entity in Dynamics 365 Sales. Both platforms use the same Dataverse annotation model, ensuring consistency in how notes are stored and retrieved. File attachments migrate as annotation attachments with the original file blob preserved, maintaining complete audit trails and documentation for each record.

If the Field Service instance contains opportunities (Enterprise instances can link opportunities to work orders), those map directly to Dynamics 365 Sales Opportunity. Pipeline stage, close date, probability, estimated revenue, and opportunity contacts migrate field-for-field, preserving the complete sales cycle data from the source environment.

Quotes, sales orders, and invoices present in the Field Service instance (typically from Project Service or Sales integration) migrate directly to their Dynamics 365 Sales equivalents. Product line items, pricing, discount amounts, and status fields align between the two platforms' transactional entities, ensuring accurate financial records and order history in the destination.

Any custom Field Service extensions (custom fields on work order, custom lookup relationships, or plugin-generated attributes) map to corresponding custom columns in Dynamics 365 Sales. Custom entities that have no semantic equivalent in Sales are exported as custom Dataverse tables and linked to the migrated records via lookup fields, preserving data relationships and operational context.

IoT alerts from Connected Field Service have no Dynamics 365 Sales equivalent. We export alert history as a custom IOTAlert__c reference table linked to the affected CustomerAsset__c record. Active alert routing logic must be rebuilt in Power Automate or an IoT middleware.