Migrate from SprintHub to Microsoft Dynamics 365 Sales

SprintHub Lead records map directly to Dynamics 365 Lead. We extract all standard fields including name, contact info, status, and owner assignment. SprintHub's lifecycle stage and lead score properties map to custom fields on the Dynamics Lead so that historical qualification data is preserved. The Dynamics LeadStatus field is populated from SprintHub's lead_status property with a mapping table created during scoping.

SprintHub Contact records map to Dynamics 365 Contact. The Contact's custom properties and tag associations extract from SprintHub's nested API response and map to typed Dynamics fields or multi-select picklists. Each Contact gets a pre-resolved AccountId by matching the SprintHub company association to the destination Account name during import so that no Contact lands orphaned.

SprintHub Company records map to Dynamics 365 Account. The company name becomes the Account Name, industry maps to IndustryCode, and size fields map to NumberOfEmployees or a custom field depending on the source data. Account is imported before Contact so that the parent lookup is satisfied at the moment of Contact insert.

SprintHub pipeline definitions (which vary per instance) map to Dynamics 365 Record Types on Opportunity, each paired with a Sales Process that whitelists the relevant stage values. We extract the pipeline names and stage order as explicit configuration rather than assuming standard names, since SprintHub pipelines are fully custom per account.

Stage names, order, and win/loss probability percentages from SprintHub map to Dynamics StageName and StageProbability fields. We extract stage configurations as key-value pairs during discovery, create each stage in the target Sales Process, and set probability percentages rounded to the nearest integer allowed by Dynamics.

SprintHub Deals map to Dynamics 365 Opportunity. Deal stage maps to the target Opportunity StageName via the stage mapping defined during pipeline configuration. Closed-Lost and Closed-Won reasons from SprintHub custom properties become Dynamics LossReason and custom Win_Reason fields. The parent AccountId is resolved at migration time via the Company-to-Account mapping.

SprintHub's global tag list (with color metadata) and tag-to-record associations cannot map to a native Dynamics equivalent because Dynamics has no tagging feature. We evaluate per-migration whether to use multi-select picklist fields on Contact and Account or a custom tag entity with a many-to-many relationship. The customer selects the strategy during scoping, and we apply it consistently across all record types that carry SprintHub tags.

SprintHub's multiple WhatsApp account configurations and account-to-team routing rules have no native Microsoft Dynamics 365 Sales equivalent. We preserve the routing logic as a written inventory (account IDs, assigned teams, conversation threads) and flag that the destination implementation requires either Dynamics 365 Customer Service channel configuration or a third-party WhatsApp Business API connector. This is a high-severity planning item that must be resolved before cutover.

SprintHub automation rules including trigger conditions, filter logic, and multi-step action sequences are stored in a proprietary format. We export the full rule definitions as structured JSON including trigger types, condition branches, delays, and action steps. Rebuilding equivalent automations in Microsoft Dynamics 365 Sales requires Power Automate or a Dynamics sales app consultant; we deliver the rule inventory and a written recommendation for each rule's Power Automate or Dynamics workflow equivalent.

Custom field names, types, and picklist options vary per SprintHub instance. We extract the full custom field schema alongside record values and map each to a typed Dynamics field. Type conversions (SprintHub's string-based custom fields to Dynamics picklists, option sets, or numeric fields) are documented and presented to the customer for approval before migration. Any picklist values that do not map cleanly to Dynamics option sets are flagged with a recommendation.

SprintHub Owner records map to Dynamics 365 User by email match. We extract every distinct owner referenced on Leads, Contacts, Accounts, Deals, and engagement records and cross-reference against the destination org's User table. Any Owner without a matching User goes to a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references are required on most standard objects, so this resolution must complete before the main import phases begin.