Migrate from Field service software to Microsoft Dynamics 365 Sales

Customer accounts in the field‑service platform map one‑to‑one to Dynamics 365 Account records. The service address populates Address1_Line1, Address1_City, Address1_StateOrProvince, and Address1_PostalCode. When an account has multiple service locations, each location can be a child Account linked via ParentAccountId, preserving the hierarchy. Custom attributes such as region codes or service‑tier flags are transferred to new_ custom fields, and the original create date is stored in a custom datetime field.

Primary contact records map to Dynamics 365 Contact entities. Email populates EMailAddress1, phone numbers fill Telephone1 and MobilePhone, and each contact links to its parent Account via AccountId. Multiple contacts per account are linked through Contact.ParentCustomerId. Source roles such as billing, technical, or emergency are transferred to custom fields (new_billingcontact, new_technicalcontact) or to AccountContactRole junction records, preserving the original create date in a custom datetime field.

Work orders with billable service outcomes map to Dynamics 365 Opportunity if they represent a revenue contract. Reactive service requests (trouble calls) map to Case records. The mapping depends on whether the source work order generated an invoice or is pre-contract. Service-type work orders default to Case.

Each line item on a work order (labor, parts, travel) translates to an Opportunity Product record if the parent is an Opportunity. For Case-based work orders, service tasks become Notes or custom sub-entities. Labor hours and parts costs preserve the price-list structure from the source.

Technician records in the FSM migrate to a Dynamics 365 User for CRM login and to a Bookable Resource for scheduling. The technician’s email becomes the User’s principal name and links to the Bookable Resource. Skills from the source become BookableResourceCharacteristic records of type “Skill”, and certifications are added as additional characteristics. Service territories map to Territory records, with the technician’s assignment recorded via BookableResourceTerritory links.

Equipment assets map to the msdyn_customerasset entity. Fields such as msdyn_Name, msdyn_SerialNumber, msdyn_WarrantyExpiration, and msdyn_InstalledDate capture the asset name, serial number, warranty end date, and installation date. The asset is linked to its Account via msdyn_Account and can reference the related Product or Contact for service history. Parent‑child hierarchies are stored using msdyn_ParentAssetId, and any source‑specific attributes like manufacturer or model codes are transferred to new_ custom fields.

Recurring service contracts in FSM become Opportunity records linked to the Account with a custom field flagging them as contract-based. If the contract has defined pricing, a Quote record stores the line items and can be converted to an Order when service is performed.

Parts catalog items map to Dynamics 365 Product records with the product type set to 'Product' or 'Service' depending on whether the item is a physical part or labor service. Unit of measure and price lists carry over to the Product's pricing fields.

Technician time entries linked to work orders require a custom data model in Dynamics 365 Sales unless the Field Service license is active. We create a custom time-entry entity or use Notes with a timestamp and duration for historical reference. Billable time entries map to Opportunity Product line items.

Custom objects such as permits, inspections, or insurance claims migrate to new Dataverse custom tables using the new_ prefix. Each table’s columns are defined with matching Dataverse data types, and source pick‑list values are translated to corresponding Dynamics 365 options. Original relationships (1:N, N:1, N:N) are recreated with Dataverse relationship definitions, preserving referential integrity. The migration plan includes the entity‑relationship diagram and field‑by‑field mapping for admin review before data loads.

Attachments such as work‑order PDFs, service‑visit photos, and customer signatures are extracted from the source blob storage and loaded into Dynamics 365. Small files are stored as Note records, with the binary content in the Body field and the original file name in FileName. The Note is linked to the parent Case or Opportunity via RegardingId. Larger files are uploaded to SharePoint document libraries attached to the Account or Opportunity folder.

Scheduling rules, route optimization settings, and territory definitions in FSM have no direct Dynamics 365 Sales equivalent without the Field Service license. We export these as configuration reference documents for the admin to rebuild using the Resource Scheduling Optimization add-in.