Migrate from Trade Service Pro to Microsoft Dynamics 365 Sales

Trade Service Pro Customers map 1:1 to Dynamics 365 Sales Accounts. Address, phone, and website fields carry over directly. Multiple TSP locations under one customer become separate Account records linked via ParentAccountId in Dynamics 365. The original TSP customer ID is stored in a custom Legacy_ID__c field on each Account to preserve referential integrity with historical records and downstream integrations.

TSP Contacts map to Dynamics 365 Contacts. Each Contact requires an AccountId (parent Account must exist first in migration sequence). Primary contact flag on a TSP Customer carries over as a custom Is_Primary_Contact__c boolean field since Dynamics has no native equivalent.

TSP Locations represent service addresses distinct from the customer record. In Dynamics 365, service locations can become child Accounts (using ParentAccountId hierarchy) or a custom ServiceLocation table. We recommend the custom table approach for high-volume field service shops to avoid inflating the Account namespace.

TSP WorkOrders serve two purposes: dispatch-and-service records and quasi-sales records when a work order originates from a quote. We map service-only WorkOrders to a custom WorkOrder table in Dynamics 365. WorkOrders tied to sold estimates map to Opportunities linked to the originating Quote, preserving the sales pipeline view.

WorkOrder is the most structurally complex mapping. TSP stores technician assignment, labor hours, line items, and status history. Dynamics 365 Sales has no native WorkOrder entity — we create a custom WorkOrder table with a 1:1 field mapping, including WorkOrder_Number__c as the external reference, Status__c as a custom picklist, and Technician__c as a lookup to the User/Contact who performed the service.

TSP Estimates map to Dynamics 365 Quotes. Line items become Quote Details (quotedetail). Estimate totals, tax, and discount fields map directly. TSP Estimate status (Draft, Sent, Accepted, Declined) becomes a custom Quote_Status__c picklist since Dynamics uses Active, Revised, Dead, and Won statuses natively.

TSP Invoices map to Dynamics 365 Invoices. Invoice lines become Invoice Details. Payment status and payment method are not native Dynamics fields — we preserve these as custom text fields (Payment_Status__c, Payment_Method__c) and retain any processor reference (e.g., Stripe charge ID) in a notes attachment URL.

TSP Payments record individual transactions against an Invoice. Dynamics 365 Invoice does not store a sub-payment ledger. We create a custom Payment_Record__c table with a lookup to the related Invoice, capturing amount, date, processor, and transaction ID. This preserves full payment history without distorting the Invoice's closed status.

TSP Technicians represent field employees who can also be assigned as WorkOrder technicians. In Dynamics 365, field resources map to Bookable Resources (msdyn_resource) on Field Service plans, or to SystemUsers on Sales-only plans. We match TSP technicians by email to existing Dynamics 365 users and flag unmatched technicians for your admin to create or reassign.

TSP Intake records represent incoming lead information — ad source, referral, call log. These map to Dynamics 365 Leads, with TSP's ad_source field mapping to LeadSource, intake notes mapping to Description, and original creation date preserved as a custom Created_In_Source__c datetime field.

TSP attachments on WorkOrders, Estimates, and Invoices are re-uploaded to a linked SharePoint document library. Dynamics 365 Notes on each record store the SharePoint URL, preserving the original file name and upload timestamp as custom fields on the Note record.

Custom properties on TSP Customers, WorkOrders, Estimates, and Invoices require custom fields in Dynamics 365. We prefix each with new_ following Dataverse naming conventions. Field data type mapping: text→String, number→Integer or Decimal, date→DateTime, checkbox→Boolean, dropdown→Picklist. We audit the actual custom field inventory during discovery and create corresponding fields in your Dynamics 365 solution layer during the pre-migration phase.