Migrate from Sales Journey to Microsoft Dynamics 365 Sales

Discovery and data export coordination

We audit the Sales Journey application via a live walkthrough with the customer's admin, identifying all objects (Contacts, Companies, Deals, Leads, Activities), custom fields, pipeline configurations, and user accounts in use. Because Sales Journey lacks a public API, we coordinate with the customer to request data exports directly from the platform's UI or through vendor support. We cross-reference export counts against the customer's internal record estimates and escalate any gaps immediately. The discovery output is a written migration scope with record counts, custom field inventory, and pipeline stage list.

Destination schema design in Dynamics 365 Sandbox

We design the Microsoft Dynamics 365 Sales destination schema in a Sandbox environment before production migration begins. This includes creating all required custom fields (with correct Dataverse field types), configuring Sales Processes per source pipeline, setting up Record Types for multi-line-of-business scenarios, and provisioning any custom tables that map to Sales Journey custom objects. We deploy the schema via the Dataverse API or Power Apps solution and validate that field-level security, required field rules, and validation rules are documented for the data migration phase.

Owner reconciliation and user provisioning

We extract every distinct owner referenced on Sales Journey records and build an email-based cross-reference table against the Dynamics 365 User table in the destination org. Any owner without a matching Dynamics 365 User goes to a reconciliation queue for the customer's admin to provision before migration. We cannot write records with unresolved OwnerId references, so this step gates all subsequent phases.

Sandbox migration and reconciliation

We run a full migration into the Dynamics 365 Sandbox using production-like record volumes. The customer's RevOps or IT lead reconciles record counts across all objects, spot-checks 20-30 records against the Sales Journey source data, and validates that pipeline stage mapping, owner assignment, and relationship lookups are correct. Any mapping corrections are documented and applied before production migration begins. This step prevents discovery of mapping errors in production.

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from Sales Journey Companies), Contacts (with AccountId resolved), Leads (if applicable), Opportunities (with AccountId, OwnerId, and Sales Process resolved), then Activity history (Tasks, Events, EmailMessages via Dataverse Bulk API with batch chunking and exponential backoff on rate limit responses). Each phase emits a row-count reconciliation report before the next phase begins. Custom fields are loaded after their corresponding standard fields to ensure the schema is in place first.

Cutover, validation, and automation rebuild handoff

We freeze writes to Sales Journey during cutover, run a final delta migration of any records modified during the migration window, then enable Microsoft Dynamics 365 Sales as the system of record. We deliver a written inventory of all active automations, pipeline workflows, and engagement scoring logic from Sales Journey with a recommended Dynamics 365 Power Automate or workflow equivalent for the customer's admin to rebuild post-migration. We do not rebuild workflows or automations as part of the migration scope. We support a brief hypercare window to resolve any record reconciliation issues reported in the first week after cutover.