Migrate from Leadtrekker Lead Management to Microsoft Dynamics 365 Sales

Discovery and API probe

We audit the Leadtrekker account to enumerate all record types, custom fields, user groups, activity log volume, and any existing integration connections. Because Leadtrekker does not publish API documentation, we conduct a discovery probe against the live API to determine available endpoints, pagination behavior, authentication method, and safe request pacing. We produce a written scoping document that identifies every Leadtrekker field, its data type, and its mapping to a Microsoft Dynamics 365 Sales field or custom field. We also review the Microsoft Dynamics 365 Sales edition (Professional or Enterprise) in use and confirm any required custom field creation in the destination org before migration begins.

Schema design and sandbox preparation

We design the destination Microsoft Dynamics 365 Sales schema based on the discovery output. This includes pre-creating any custom Lead fields discovered in Leadtrekker, extending picklists for Lead Source values, and mapping Leadtrekker assignment-group structures to Dynamics Teams and Security Roles. The schema is deployed into a Dynamics Sandbox environment first for validation. We configure the Lead-to-Account-Contact convert mapping so that any Leads qualifying to Opportunities during or after migration map correctly to the right business process flow.

Sandbox migration and reconciliation

We run a full migration into the Dynamics Sandbox using production-like data volume. The customer's sales operations lead reconciles record counts (Leads in, Activities in, Users mapped), spot-checks 20-30 random records against the Leadtrekker source, and signs off the schema and mapping before production migration begins. This step catches unmapped fields, incorrect date formatting, and owner resolution failures before they affect live data.

Owner reconciliation and User provisioning

We extract every distinct Leadtrekker Owner referenced on Lead records and activity logs and match by email against the Dynamics 365 destination org's User table. Any Leadtrekker Owner without a matching Dynamics User goes to a reconciliation queue. The customer's Dynamics admin provisions missing Users and assigns the appropriate Security Role before the production migration phase begins. Migration cannot proceed past this step because OwnerId references are required on all standard Lead and Activity records.

Production migration in dependency order

We run production migration in record-dependency order: Users (manual provisioning validated), Leads (with custom fields pre-created and owner IDs resolved), Activities (Tasks, Events, EmailMessages attached to the Lead via WhatId lookup), and User Group mappings (documented as a role-mapping table). Each phase emits a row-count reconciliation report before the next phase begins. We use the Dynamics 365 Web API for real-time record inserts and the Bulk API for activity history volumes exceeding 10,000 records, with exponential backoff on rate-limit responses.

Cutover, validation, and notification handoff

We freeze Leadtrekker writes during the cutover window, run a final delta migration of any records modified during the window, then mark Microsoft Dynamics 365 Sales as the system of record. We deliver the notification and assignment-rule inventory document to the customer's Dynamics admin for manual rebuild using Dynamics workflow rules or Power Automate. We provide a one-week hypercare window to resolve any data quality issues raised during the first business week in the new system.