Migrate from Kylas Sales CRM to Microsoft Dynamics 365 Sales

Discovery and data audit

We audit the Kylas organization across all active objects: record counts for Leads, Contacts, Companies, Deals, Activities, and Documents; custom field schemas on each object; pipeline names and stage counts; active user list and ownership distribution; Smart List criteria; and workflow automation rules. We run a data-quality profile to flag duplicates, missing required fields, and invalid formats. We pair this with a Microsoft Dynamics 365 Sales edition check (Sales Professional at $65/user or Sales Enterprise at $95/user) and confirm the target environment (Sandbox or Production) is accessible and licensed.

Schema design and option set mapping

We design the Dynamics 365 destination schema: custom fields created via the maker portal or solution file, option set values seeded from the Kylas picklist export, Sales Processes and Record Types mapped from Kylas pipeline names, and Page Layouts scoped per Record Type. We configure a staging Dynamics environment (Sandbox or dev org) for the first migration pass. WhatsApp metadata, field-sales check-in content, and Smart List criteria are documented as non-migratable items at this stage so the customer can plan for manual rebuild.

Sandbox migration and reconciliation

We run a full migration into the staging Dynamics environment using the Dataverse Web API, ingesting records in dependency order: Users validated, Accounts created from Companies, Contacts with parentaccountid resolved, Leads with owner resolved, Opportunities with AccountId and RecordTypeId resolved, Activities via chunked API writes. The customer's RevOps lead reviews 25-50 spot-checked records against the Kylas source, validates picklist values, and signs off the schema and mapping before production migration proceeds.

User provisioning and owner reconciliation

We extract every distinct Kylas owner referenced on Leads, Contacts, Accounts, Opportunities, and Activities and match by email against the Dynamics destination org's User table. Any Kylas owner without a matching Dynamics User is held in a reconciliation queue. The customer's admin provisions missing Users (active status matching the original Kylas user's active/inactive state) before production migration begins. This step gates all subsequent record imports because OwnerId references are required on standard objects.

Production migration in dependency order

We run production migration with records sequenced: Accounts first, then Contacts with AccountId resolved, then Leads, then Opportunities with AccountId, OwnerId, and RecordTypeId resolved, then Activity history (Tasks, Notes, Emails) via the Dataverse API with batch chunking and exponential backoff on throttling responses. Custom fields and Documents follow. Each phase emits a row-count reconciliation report before the next phase begins. Smart List criteria, workflow automation rules, and WhatsApp integration requirements are delivered as written documentation for manual rebuild.

Cutover, validation, and handoff

We freeze Kylas writes during the cutover window, run a final delta migration of any records modified during the migration window, then set Microsoft Dynamics 365 Sales as the system of record. We validate record counts against the Kylas source, run duplicate detection reports, and confirm option set values rendered correctly. We deliver the automation and Smart List inventory document to the customer's admin team. We provide a one-week hypercare window for reconciliation issues raised by the sales team. Workflow rebuild and WhatsApp connector setup are outside standard migration scope.