Migrate from Service Suite FSM to Microsoft Dynamics 365 Sales

Service Suite FSM work orders have no direct equivalent in D365 Sales. FlitStack AI creates a custom table in Dataverse named FSM Work Order with custom fields for wo_number, status, priority, service_type, technician_id, scheduled_date, and completion notes. This table links to the Account record representing the customer.

Service requests in FSM capture the underlying reason a customer initiated service and are mapped to a custom Dataverse table linked to the FSM Work Order via a lookup relationship. Fields such as request_type, description, customer_priority, and resolution_summary migrate as custom fields on this table, preserving the full service request context from the source system for reference and audit purposes.

The FSM customer object is the closest analogue to a D365 Sales Account. Company name maps to Account.Name, address maps to the address composite, phone maps to Telephone1, and the industry and employee-count fields map directly to their D365 equivalents.

FSM contacts (office staff) map to D365 Sales Contacts with firstname, lastname, email, phone, and jobtitle mapping directly. FSM technician records map to Contacts as well — the email address is used for owner resolution if the technician is also a D365 Sales user; otherwise the record is a Contact only.

FSM customer assets (equipment under service contract) migrate as a custom Dataverse table linked to the Account. Fields include asset_id, product_name, serial_number, installation_date, warranty_expiry, and location. The primary asset description is also surfaced as a custom field on the Account record for quick visibility.

Work order line items in FSM capture the individual parts used, services performed, labor hours, and quantities associated with each work order. These items migrate as a custom Dataverse table linked to the parent FSM Work Order. Fields including parts_replaced, labor_hours, and service_quantity have no D365 Sales standard equivalent and are stored as custom fields on this table to preserve detailed service delivery records.

FSM technicians and resources map to Contacts with a custom Dataverse table for FSM-specific resource data: resource_pool, skill_set, certification_level, and territory. If the technician is also a D365 Sales user, they are invited as a user and their Contact record is linked via the OwnerId field.

Historical service records in FSM that document completed visits, parts replaced, service outcomes, and resolution details migrate to a custom Dataverse table linked to both the FSM Asset and the Account. Timestamps recording when each service event occurred and the technician_id responsible are preserved to maintain full audit continuity and service history traceability post-migration.

FSM scheduling data including dispatch_date, service_window, territory, and scheduling_mode has no native D365 Sales equivalent and requires a custom Dataverse table to capture these details. This custom table is linked to the FSM Work Order and Resource records to preserve the complete scheduling context from the source system for historical reference and capacity planning analysis.

FSM email threads, call logs, and notes attached to work orders or contacts migrate as D365 Sales Email, Task, and Note records respectively. Original timestamps recording when each communication occurred, technician ownership of the record, and parent-record links connecting to the Work Order or Contact are all preserved during migration to maintain complete communication history.

FSM payment records are preserved as a custom Dataverse table linked to the Work Order and Account. Since D365 Sales has no native payment processing, invoice_number, amount_paid, payment_method, and payment_date are preserved as reference data for the accounting team to reconcile manually or via a payment integration.

Any custom FSM objects defined by the customer — such as equipment types, contract tiers, or site-specific classifications — migrate as Dataverse custom tables. The migration preserves field names, data types, and relationship models exactly as they exist in FSM. N:N relationships in FSM that use junction objects require equivalent junction tables in Dataverse; FlitStack AI identifies these relationships in the migration plan and creates the appropriate junction table structure.