Migrate from StreetSmart to Microsoft Dynamics 365 Sales

StreetSmart Customer records map directly to Dynamics 365 Accounts. Customer name, phone, and billing address migrate as Account.Name, Account.Telephone, and Account.BillingAddress fields respectively. If the Customer has multiple service locations, each Location record is evaluated separately and linked back to the parent Account record through the AccountId lookup or a dedicated Location__c table when the custom table approach is selected.

Primary contact records attached to a StreetSmart Customer map to Dynamics 365 Contacts linked to the corresponding Account via AccountId. Additional contacts beyond the primary require Contact roles or Account Contact Relationships in Dynamics — these are created as separate Contact records with the appropriate relationship type to preserve the original contact hierarchy from StreetSmart.

StreetSmart Location records store service-site addresses with GPS coordinates and territory tags. If Dynamics 365 Sales Professional is the target (15-table limit), Locations map to Account service-address fields. If Enterprise, a custom Location__c table with a lookup to Account is created to preserve the N:1 hierarchy.

StreetSmart Jobs are the core record — they carry job status, service type, scheduling window, and technician assignment. In Dynamics, Jobs can map to Opportunities (if the service is revenue-linked) or to a custom Service_Job__c table for job-centric organizations that do not follow a traditional opportunity-to-close sales process.

StreetSmart job status values such as Scheduled, In Progress, Completed, and Cancelled require value-by-value mapping to the destination pick-list. Stage transition timestamps in StreetSmart are preserved as custom datetime fields in Dynamics for historical reporting continuity and audit trail verification.

StreetSmart service-type codes map to a custom pick-list in Dynamics 365. If the destination uses the Opportunity object, a Service_Type__c custom field is created. Pick-list values are mapped one-by-one; unmapped values are flagged and defaulted to a catch-all value pending admin review.

StreetSmart technician assignments are resolved by email against Dynamics 365 Users. Unmatched technicians are flagged before migration — either invited to Dynamics as Users or assigned to a fallback owner. A custom Technician__c field stores the original StreetSmart technician identifier for traceability.

StreetSmart scheduling windows (start/end datetime, time zone) have no direct Dynamics equivalent. They migrate as Scheduled_Start__c and Scheduled_End__c custom datetime fields. Scheduling conflicts visible in StreetSmart require a post-migration review of Dynamics Calendar or a Power Automate flow to recreate.

StreetSmart job notes and file attachments migrate as Dynamics Notes and Attachments on the corresponding Opportunity or Service_Job__c record. Original timestamps and note authors are preserved in Dynamics. File size limits of the destination storage apply — files exceeding Dynamics storage quotas are flagged for manual retrieval from the source export.

StreetSmart territory tags used for dispatch routing have no native equivalent in Dynamics 365 Sales. They migrate as a custom Territory__c pick-list field. If the organization uses Dynamics Territory Management, territory assignment is reconfigured post-migration using the migrated Territory__c values as reference data.

StreetSmart custom fields on Customer records (e.g. contract tier, SLA flag, billing code) require custom field creation in Dynamics on the Account or Contact object depending on scope. Each custom field is documented in the migration plan with its type, pick-list values, and default handling.

StreetSmart job status-change history and audit events are not represented natively in Dynamics. They migrate as a series of Note records attached to the Service_Job__c record with timestamps and event descriptions, or as custom audit datetime fields tracking key status transitions.

StreetSmart integrations with ERP systems, payment processors, or third-party route-optimization tools have no direct equivalent in Dynamics 365 Sales and cannot be migrated automatically. Third-party connections must be rebuilt post-migration using Dynamics connectors, Power Automate, or Azure Logic Apps depending on the integration complexity and required real-time capabilities.

StreetSmart automated dispatch rules and route-optimization triggers are a platform-native feature with no migration path to Dynamics 365. These must be designed from scratch in Power Automate or as Dataverse plug-ins. FlitStack exports the rule definitions as a reference document for the Dynamics implementation team.