Migrate from The Service Program to Microsoft Dynamics 365 Sales

TSP Customer records carry both company and billing-person data. We split this into a Dynamics 365 Account (company name, address, industry) and a Contact (primary billing or service contact) linked via AccountId. If the Customer has no company name, the Contact becomes the Account holder and Account.Name receives the Contact's full name.

TSP stores phone and email directly on the Customer record. These migrate as Contact.Phone and Contact.Email. Multiple phone numbers are consolidated into the primary Phone field and a secondary Telephone field on the Contact record. Any unstructured phone notes or non-standard contact information is preserved in a custom TSP_PhoneNotes__c field to ensure no contact data is lost during migration.

TSP locations are stored per Customer with address, site name, and access notes. When a Customer has one site, the address becomes Account.ShippingAddress. When a Customer has multiple sites (pool route, multiple properties), we create a custom Site__c table with a lookup to Account and store the site-specific address, access codes, and service frequency as custom fields.

TSP work orders carry job type, scheduled date, assigned technician, line items, and status. We map these to a custom Service_Ticket__c table (Dataverse) because Dynamics Sales does not have an out-of-box field-service ticket entity. Each ticket links to the Account and Contact, stores technician assignment as a Contact lookup, and carries original create date and status history in custom audit fields.

Line items on a TSP work order (labor, parts, flat-fee services) migrate as records in a custom line-item table linked to Service_Ticket__c. Each line stores description, quantity, unit price, and total. If the destination is Dynamics 365 Sales Enterprise + Field Service, line items can alternatively map to Agreement Booking Dates with service tasks.

TSP equipment records track make, model, serial number, installation date, warranty expiration, and customer site link. We create a custom Equipment__c table in Dataverse with all standard fields plus the TSP_Equipment_ID__c reference. If the customer licenses Dynamics 365 Field Service, equipment migrates to the msdyn_customerAsset table with the same field coverage.

TSP technicians have name, phone, certifications, and hourly rate. We resolve each technician by email against Dynamics 365 users — matched technicians become SystemUser records with their role set to Field Service Resource. Unmatched technicians (no D365 license) become Contact records with a custom Technician__c flag and a TSP_Certifications__c field for rebuild reference.

TSP time entries record technician hours per work order or per day. We create a custom Time_Entry__c table linked to the Service_Ticket__c and the technician Contact record, storing date, hours worked, time type (travel, labor, admin), and billable flag. Original entry timestamps are preserved in a custom Created_At_Original__c field.

TSP invoices live in QuickBooks. We store the QB invoice number and total on a custom QB_Invoice_Ref__c field on the related Service_Ticket__c or Opportunity. The invoice document itself is not migrated; FlitStack records the QB link so the invoice stays in QuickBooks and the D365 record carries the reference for audit trail continuity.

TSP file attachments on work orders or equipment records (photos, contracts, spec sheets) are downloaded and re-uploaded to the SharePoint document library associated with the D365 Account or custom Service_Ticket__c table. File size limits of SharePoint (default 10 GB per document library) apply. Inline images in notes are extracted and re-hosted as SharePoint file attachments.

TSP stores arbitrary custom properties per Customer, Work Order, or Equipment record without a published schema. We enumerate these during the audit phase, map each to a typed custom field in D365 (text, number, picklist, date, or boolean), and create the field in the appropriate Dataverse solution before migration. Any property with no D365 equivalent becomes a JSON blob in a TSP_Custom_Data__c text field for reference.

TSP scheduling data (assigned technician, date/time window, route stop order) has no direct D365 equivalent. We create a custom Schedule_Block__c table with technician lookup, Account/Site lookup, scheduled start/end datetime, and TSP_Route_Stop__c order number. This preserves the dispatch board layout as reference data for rebuilding in Power Apps or Dynamics 365 Field Service.