Migrate from PipelineManager to Microsoft Dynamics 365 Sales

Discovery and edition selection

We audit the source PipelineManager account across tier (Develop/Grow/Enterprise), Pipeline count, active Deal volume, People and Company record counts, activity log volume, active Workflows, custom field inventory, and user count. We pair this with a Microsoft Dynamics 365 Sales edition review: Sales Professional ($65/user) covers single-pipeline, standard-object migrations; Sales Enterprise ($105/user) is required for advanced forecasting, multi-pipeline Record Type management, or AI features; Sales Premium ($150+/user) adds Viva Sales and advanced relationship insights. The discovery output is a written migration scope with record counts, custom field mapping, and a Dynamics 365 edition recommendation.

Schema design and Record Type/Sales Process configuration

We design the destination Dynamics 365 schema before any data moves. This includes creating custom fields on Contact, Account, and Opportunity (with Dataverse types matched to PipelineManager field types), configuring one Record Type per PipelineManager Pipeline, creating a Sales Process per Record Type with stage values ordered to match PipelineManager stage positions, and setting stage probabilities from PipelineManager stage weights. Schema deploys to a Dynamics 365 Sandbox environment first for validation against the customer's admin sign-off.

Sandbox migration and reconciliation

We run a full migration into the Dynamics 365 Sandbox using production-like data volume. The customer's RevOps lead reconciles record counts (Opportunities in, Contacts in, Accounts in, Activities in), spot-checks 25-50 random records against PipelineManager source, and confirms the Record Type and stage mapping are correct. Any schema corrections, field type mismatches, or mapping adjustments happen here before production migration begins. Sandbox reconciliation is the last opportunity to correct mapping logic without affecting live data.

Owner reconciliation and User provisioning

We extract every distinct PipelineManager Owner referenced on Deal, People, and Activity records and match by email against the Dynamics 365 destination User table. Owners without a matching User go to a reconciliation queue for the customer's admin to provision. Dynamics 365 requires a valid OwnerId (systemuserid) on Opportunity and Contact at insert time, so User provisioning must complete before the production import phases begin. We verify each User's security role grants the migration user the necessary Dataverse privileges before proceeding.

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from PipelineManager Companies), Contacts (with AccountId resolved), Users (manual, validated), Opportunities (with RecordTypeId, SalesProcessId, AccountId, and OwnerId resolved), Activities (Tasks and Events via Dataverse Bulk API with parent-record lookup), Attachments (as Notes or SharePoint links), Custom Fields data (per entity). Each phase emits a row-count reconciliation report before the next phase begins. For activity migrations over 50,000 records, we chunk using Bulk API batch limits and exponential backoff on throttling responses.

Cutover, validation, and Workflow rebuild handoff

We freeze PipelineManager writes during cutover, run a final delta migration of any records created or modified during the migration window, then enable Microsoft Dynamics 365 Sales as the system of record. We deliver a Workflow inventory document listing every PipelineManager Workflow with its trigger, conditions, and actions and a recommended Microsoft Dynamics 365 Sales Process Builder or Power Automate equivalent. We support a one-week hypercare window for reconciliation issues raised by the sales team. We do not rebuild PipelineManager Workflows as Dynamics 365 workflows inside the migration scope; that is a separate engagement.