The Definitive Guide to Migrating to Microsoft Dynamics 365 Sales

Microsoft Dynamics 365 Sales is the sales application inside Microsoft's broader Dynamics 365 business-applications suite, sitting alongside Customer Service, Field Service, Customer Insights and Finance & Operations. All of them store their data in Dataverse — the Microsoft-managed relational layer formerly called the Common Data Service — and run on top of the Power Platform ¹¹¹.

The typical Sales customer is a mid-market or enterprise revenue team that already lives inside Microsoft 365: Outlook for email, Teams for collaboration, SharePoint for documents, Azure AD for identity. Compared with Salesforce Sales Cloud, Dynamics 365 Sales positions on Microsoft-native integration and Copilot reach into Office; compared with HubSpot or Pipedrive, it positions on enterprise-grade extensibility through plug-ins and Power Automate flows ⁵.

The shapes of migration that actually land on Dynamics 365 Sales tend to fall into four patterns. First, Salesforce exits, driven by total cost of ownership at the Enterprise tier and by teams that want their CRM closer to Microsoft 365 and Power BI. Second, on-premises Dynamics CRM cloud moves, where customers running Dynamics CRM 2015/2016 or Customer Engagement on-premises shift to the online Dataverse-backed product.

Third, consolidation projects: a business standardising on the Microsoft stack and replacing Pipedrive, HubSpot, Zoho or homegrown systems with Sales plus Customer Service plus Customer Insights on a single Dataverse. Fourth, M&A integration, where an acquirer pulls the acquired company off a different CRM onto its existing Dynamics environment. A Salesforce exit has rich automation that does not move as code; an on-prem Dynamics move has clean schema but old plug-ins that need rewriting against the current platform.

What makes migrating *to* Dynamics 365 Sales harder than the category average is the platform's extensibility surface. There are five places business logic can live — Business Process Flows, classic Workflows, server-side Plug-ins, Power Automate cloud flows, and client-side JavaScript — and a migration has to decide which layer rebuilds each piece of legacy logic.

Add Dataverse security roles, Business Units and Teams on top, and the schema is only half the project. The native Data Import Wizard caps individual files at 8 MB (32 MB for .zip) and Microsoft itself recommends limiting import jobs to 20,000 rows — anything bigger is supposed to go through SSIS, not the wizard ¹³¹⁴.

What makes it easier is template-based imports straight from the system, mature duplicate-detection rules across Accounts, Contacts and Leads, and a Dataverse model that already speaks the standard CRM vocabulary — Lead, Account, Contact, Opportunity, Quote, Order, Invoice⁹⁶. Teams that scope the five automation layers and the security model up front finish on time; teams that treat it as a CSV-shaped project do not.

Schema is half the project. Security roles, plug-ins, flows and Business Process Flows are the other half.

Dynamics 365 Sales does not have its own data layer. Every record lives in a Dataverse table (formerly called an entity), and Sales ships a curated set of standard tables that the application's forms, views and Business Process Flows are bound to ¹¹¹.

Before you can map a single column you need to know which Dataverse table the row belongs on, what columns are required, and which value will serve as the alternate key for upsert. The table below summarises the tables you will touch in a Sales migration.

Every Dataverse record has a system-generated GUID (accountid, contactid, opportunityid) which is the canonical primary key. For migrations, the practical upsert key is an alternate key — a column you mark as unique on the table definition, then use as the entity reference when upserting.

Set up alternate keys on Account (often the legacy crm_source_id or website domain), Contact (legacy ID or email), and any custom table before the first row goes in — adding an alternate key after data exists requires Microsoft to build a unique index across what may now be a millions-of-rows table. The column catalogue below covers what you can model and the limits you need to plan around.

Relationships in Dataverse come in three shapes. One-to-Many (parent-child, e.g. Account → Contact) supports configurable cascading behaviour: on delete, you can choose Cascade All, Cascade Active, Cascade User-Owned, Remove Link or Restrict ⁴⁵. Many-to-One is the inverse, exposed as a lookup column on the child. Many-to-Many is supported natively but stores the relationship in a hidden intersect table that is read-only to external loads — for editable many-to-many you create a manual junction table with two lookups ⁴³.

Custom tables participate in relationships the same way standard tables do, including the same cascade options and lookup mechanics. Microsoft Dataverse storage is consumed in three pools — Database (relational rows), File (attachments) and Log (audit) — and the tenant allowance scales with licensed users; teams importing legacy attachments need to size File storage explicitly because it is the pool that fills first.

The single best predictor of a clean Sales migration is how much work you do on the source side before the first import job is queued. Microsoft's own Dataverse guidance is explicit: skipped or rushed testing is one of the most common reasons migrations fail, and the fix is almost always pre-processing rather than post-cleanup.

Treat the source export as raw material that needs to be shaped to Dataverse's expectations — option-set integer values, alternate keys, owner-resolved-to-Azure-AD users, dates in ISO-8601, currencies aligned to the exchange rate.

Source-side prep

• Audit and dedup the source database before export. Dynamics 365 publishes default duplicate-detection rules for Accounts, Contacts and Leads, but practitioner guidance is to dedup *before* import so the rules act as a safety net, not the first line of defence.
• Resolve option-set values to integers, not labels. Every Choice column stores an integer; the label is for display. The wizard will accept some labels via auto-match but programmatic loads expect the integer and fail silently when the label is wrong-cased.
• Stamp a stable external ID on every record in the source export — the source platform's primary key or a UUID — so you can wire an alternate key on the Dataverse table and re-runs are deterministic.
• Normalise currencies and exchange rates. Dataverse stores an Exchange Rate per Transaction Currency record; if your source had multi-currency data without a rate column, decide whether you import in base currency or pre-create Transaction Currency rows with historical rates.
• Decide what is in scope for historical activities. Phone Calls, Emails, Appointments, Tasks and Letters can be imported with a backdated *Actual End* timestamp, but each one carries the same write cost as a record create ⁶⁶.

Destination-side prep

• Design the environment strategy — Default, Production, Sandbox, Developer — and pick which one is the data-migration environment. Microsoft explicitly recommends a dedicated data-migration environment because it is a disruptive task that cannot coexist with other testing activities ³⁴.
• Provision users in Azure AD / Entra ID first, assign Dynamics 365 Sales licences, then map them into Dataverse security roles before importing. Owner assignment during import fails silently if the referenced user is not yet a Dataverse user.
• Build security roles, Business Units and Teams before importing. Owner-based row security is enforced at retrieve, not at write — get this wrong and reps see records they should not, or miss records they should.
• Pre-create every custom table and column with the correct data type, including alternate keys, calculated/rollup formulas, and Choice option sets with stable integer values.
• Build the Solution. Wrap your customisations in an unmanaged Solution in the development environment, then export as managed and deploy to the migration and production environments — this is the ALM pattern Microsoft documents for Power Platform ¹¹.

People prep

Cutover only works if humans cooperate. Lock down a source-system freeze window — typically 48 to 96 hours for mid-market — and communicate it to every department that touches the CRM. Train sales reps on the Sales Hub model-driven app, Business Process Flows and Outlook + Teams integration before go-live. Microsoft's own guidance pegs small-to-mid migrations at 8 to 12 weeks of elapsed time, with enterprise programmes running 6 to 12 months end-to-end.

Dynamics 365 Sales exposes several load paths and the right one depends on row count, table mix, and whether the load needs to be re-runnable. The Data Import Wizard covers small-to-medium one-shot migrations under 20,000 rows per job. SSIS with KingswaySoft (or equivalent) and the Data Migration Framework sit on top and add transformation, staging and resume-on-failure semantics.

Data Import Wizard

The native import lives in the model-driven app under Settings → Data Management → Imports, or via Advanced Find → Import Data on supported entity grids ¹³. Supported file formats: CSV (.csv), Text (.txt), Compressed (.zip), Excel Spreadsheet 2003 (.xml) and Excel Workbook (.xlsx). The maximum file size is 8 MB for individual files and 32 MB for .zip bundles ¹³¹⁴. A .zip can include multiple CSV/XML/TXT files and an optional Attachments folder, all imported as a single job.

The wizard supports a Map Automatically mode that matches columns to table fields by header name, and an explicit Data Map mode that lets you save and reuse mappings across imports. Templates exported from Settings → Templates for Data Import give pre-built XML spreadsheets with the right columns for Accounts, Contacts, Leads and other standard tables. The right call: wizard for one-shot loads under 20,000 rows on standard tables.

SSIS, KingswaySoft, and the Data Migration Framework

For enterprise-scale loads, the most common stack is SQL Server Integration Services (SSIS) plus the KingswaySoft Dynamics 365 connector. SSIS handles transformation, staging tables and resume-on-failure; the connector wraps the Dataverse write path with batch-size tuning, error-row routing and built-in lookups ¹⁵⁰. The Data Migration Framework (DMF) inside Power Platform admin is the Microsoft-native ETL equivalent and handles configuration data and reference-data loads through entity maps that include concatenation, split and replace transformations ¹⁴.

Workato, Fivetran, Azure Data Factory and Power Automate are also commonly used in two ways: reverse-ETL where the source platform is staged into Azure SQL or Synapse, transformed in T-SQL, then synced into Dataverse; and ongoing-sync where the tool takes over once the one-time migration is complete.

Mapping is where every migration earns its scars. The schema decisions you make in your mapping spreadsheet determine whether reports work on day two, whether Business Process Flows fire correctly on day five, and whether your sales team trusts the data on day thirty.

Work table by table, top to bottom of the import order: Transaction Currencies first, then Users and Teams, then Accounts (so Contacts and Opportunities can point at them), then Contacts, then Leads, then Opportunities, then Activities, then Annotations and attachments, then custom tables, then Quote/Order/Invoice if in scope ¹⁵⁰.

Accounts

Contacts and Leads

Sales treats Lead and Contact as distinct tables, not a single dual-status record. A Lead represents an unqualified inquiry; on qualify, the Lead can be converted into an Account, Contact and Opportunity together ¹⁰⁶¹⁴⁶. Decide before mapping whether your source's lead-stage records become Dataverse Leads or Contacts — most migrations split on a *Stage = Qualified* flag.

Opportunities and the Business Process Flow

Opportunities in Sales are not just a record — they are a record bound to a Business Process Flow (BPF) with stages such as Qualify, Develop, Propose and Close ¹⁰⁶¹⁴⁹. The BPF is the visible pipeline-stage indicator on every Opportunity form. When you import an Opportunity you set its statecode (Open / Won / Lost) and statuscode (sub-status), and separately set its position on the BPF via the processid and stageid columns.

If you skip the BPF columns the Opportunity loads but appears at stage 1 of whatever the default Lead-to-Opportunity Sales Process is. For multi-pipeline source systems (Pipedrive, Salesforce, HubSpot), recreate each pipeline as its own custom BPF in Dataverse first, then map source-stage → BPF-stage as part of the Opportunity load.

Custom-field mapping strategy

Resist the urge to map every source custom field one-to-one. Migrate only the columns used by an active process or report in the last 12 months. Dataverse caps tables at roughly 1,000 columns combined system + custom; once a table is past 600–700 columns the form load times degrade noticeably, and reports built on Dataverse views start hitting the 50-column projection limit.

For Choice columns whose source values do not match, either extend the destination option set with the missing integer values, collapse adjacent values during transform, or introduce a parallel custom column that holds the legacy value verbatim. Calculated and Rollup fields do not import data — Dataverse recomputes them on retrieve or on schedule. Source formulas rebuild as Dataverse calculated fields, and rollup values worth preserving go into a *Legacy Rollup* number column at import time ⁵⁹.

Historical activities — Phone Calls, Emails, Appointments, Tasks

All five Activity types accept backdated timestamps via the actualend (completed activities) or scheduledend (planned) columns. The visible Timeline date on a Contact or Opportunity reads from modifiedon, not actualend, which catches most teams — the import stamps modifiedon to today and the historical activity appears at the top of the timeline rather than at its true date ⁸⁴.

The fix is to explicitly set modifiedon during import (it is overridable with a privileged service principal) and set overriddencreatedon to the original create date — Dataverse documents this column specifically for backdated migrations ⁶⁶. Activity rows also need an activitypartylist payload to attach the From/To/Cc parties; that party list references either a contact, lead, account or systemuser, and missing references silently drop the activity reference from the timeline.

Files and attachments — Annotations and SharePoint

Attachments in Sales live in the Annotation (note) table — each Note has an optional documentbody (base64 binary), filename, mimetype and filesize. Annotations are associated to a parent record via the objectid + objecttypecode columns. The Data Import Wizard accepts Notes inside a .zip with an /Attachments subfolder; the wizard reads the binary and creates the Annotation row in one pass.

For estates above a few gigabytes the supported pattern is SharePoint integration: enable SharePoint document management in Settings → Document Management, point it at a SharePoint Online site, and store attachments as SharePoint files linked to the Dataverse record rather than as Annotation documentbody blobs. This pushes the storage cost off the Dataverse File pool and onto Microsoft 365 file storage. Tools like Inogic Attach2Dynamics handle bulk-migration of historical Annotations to SharePoint or Azure Blob in one pass.

Audit trail, ownership and original timestamps

Dataverse stamps createdon, createdby, modifiedon and modifiedby on every row. These are overridable on import under specific conditions: the calling identity must have the prvOverrideCreatedOnCreatedBy privilege, and you set the overriddencreatedon column rather than createdon directly ⁸³. Standard non-privileged imports get today's timestamp and the importing user as createdby, which silently breaks reports filtered by Created Date.

Owner assignment during import works only if the referenced user or team exists in Dataverse at the moment of write. Rows whose owner cannot be resolved are imported with the importing user as owner, which silently leaks records to anyone whose security role includes that owner's Business Unit ⁸⁵.

Account-level audit logging is enabled per-table under Settings → Auditing; once on, the audit table records every Create, Update and Delete with previous and new values⁸⁸. Audit data counts against the Log storage pool, which is separate from Database and File storage but still tier-bound — heavy backfill of historical audit rows is not recommended; capture the source-system audit trail into custom *Legacy Audit* columns instead.

CRM-specific: duplicate detection, sequences, server-side sync

Dynamics 365 ships default duplicate-detection rules for Account (name), Contact (email) and Lead (name + email domain) and lets you author custom rules under Settings → Data Management → Duplicate Detection Rules ⁹⁶¹⁰⁰. Microsoft's recommendation during import is to disable duplicate detection on the load and re-enable after, because each duplicate check is a synchronous query that throttles bulk-load throughput badly ¹³.

Sequences (the cadence tool inside Sales Insights) do not have an import mechanism — recreate the structure manually and apply to active leads/opportunities post-cutover. Lead-scoring models likewise do not import; rebuild as predictive lead scoring inside Sales Insights or as a custom Dataverse score column ¹¹¹.

Server-side synchronisation with Exchange Online for email and calendar is configured per user under Settings → Email Configuration → Mailboxes, and should be enabled *after* the historical activity import, not during — otherwise the connector backfills against the same Activities you just loaded and creates duplicates ¹⁴⁴.

Validation is the bridge between the import finishing and users being allowed in. Microsoft's FastTrack guidance recommends three stages: a 10 percent test load into a sandbox with stakeholder spot-checks, the full load into the migration environment with real-time monitoring of record counts and relationship integrity, and a 30-day post-migration data-quality audit driven by the audit table¹⁴². Have department reps verify their own records — they know what right looks like.

Build a reconciliation queries spreadsheet that compares source and destination on each of these counts. Anything outside a 0.5 percent variance gets investigated before users get login access.

• Total Accounts imported vs source — minus deliberately excluded rows (test accounts, soft-deleted records, opt-outs).
• Total Contacts imported vs source, with a count of Contacts where parentcustomerid is null — those are unassociated and should match an explicit list.
• Total Opportunities per pipeline + BPF stage, plus sum of estimatedvalue per pipeline — a non-trivial currency variance signals a stage-mapping error or a missing Transaction Currency Exchange Rate.
• Total Activities per type (Phone Call, Email, Appointment, Task, Letter) imported vs source — and a date-bucketed comparison against overriddencreatedon to confirm backdating round-tripped.
• Relationship counts — Contact→Account, Opportunity→Account, Activity→Regarding by object-type-code — checked against source-derived expected counts.
• Owner distribution — GROUP BY ownerid and confirm no record landed under the migration service principal that should not have.
• Alternate-key integrity — count distinct values on each custom alternate-key column; any duplicates indicate the dedup transform missed cases.

On top of reconciliation, run a manual spot-check protocol: pick 30 random records across tables and verify each field against the source UI. Pick five high-value Opportunities and trace the full graph — Account, Contacts, Quote, Activities, Annotations. If a non-trivial discrepancy shows up in three or more of the 30, halt the load, fix the root cause, and re-import the affected rows by their alternate-key column.

Dynamics 365 supports a partial rollback on imports: under Settings → Data Management → Imports, each import job appears as a row with a Delete option that lets you delete only the records created by that import, leaving everything else intact ¹¹⁴. This is the closest thing to native bulk-undo, but it is import-job-scoped — deletes only the records that job created, and only if they have not been modified since.

The real rollback strategy remains: export everything to Azure Blob or SharePoint before the import starts, stamp every imported row with an *Import Batch ID* custom column, and if catastrophe strikes, bulk-delete by that batch ID via Advanced Find or a Power Automate flow and re-import from the cleaned source.

Cutover sequencing: (1) source goes read-only and the team is notified; (2) final delta export captures everything that changed during the dry-run window; (3) delta is imported via the Data Import Wizard or SSIS; (4) reconciliation runs; (5) users get login access and a 48-hour hyper-care window with the migration lead on call; (6) source decommission is scheduled for 30 to 90 days out, never the same day.

The Microsoft Solutions Partner programme tiers partners by capability and customer count, with a specialisation badge for Business Applications that signals Dynamics 365 depth ¹²³. For Sales migrations specifically, partners with explicit Salesforce-to-Dynamics, on-prem-to-online, or HubSpot-to-Dynamics practices tend to ship cleaner than generalist implementation shops.

Cobalt, Rand Group, Arctic IT, Encore Business Solutions, ProServeIT, SingleStone and Veelead are commonly named in the migration corner of the market and each offers fixed-scope migration packages alongside ongoing managed services. Microsoft also runs its in-house FastTrack for Dynamics 365 service which provides architecture guidance and remediation support at no cost for qualifying customers — useful for tenant-to-tenant moves and large enterprise programmes ¹²³.

On the ETL and iPaaS side, KingswaySoft's SSIS Dynamics 365 connector is the de facto standard for enterprise migrations ¹⁵⁰. Fivetran, Workato, Azure Data Factory, Power Automate and Microsoft's own Data Migration Framework all have Dataverse connectors that handle staging, transformation and ongoing sync. Their role is rarely the migration itself — it is the staging layer that lands source data into Azure SQL or Synapse, and the ongoing-sync layer once the one-time load is done.

Managed-migration cost ranges vary widely with scope. A small-business Sales Professional implementation with 10 users, minimal customisation and a one-time CSV import of Accounts and Contacts lands around $4,000–$8,000 in published practitioner estimates ¹³¹. Mid-market and enterprise Dynamics 365 CRM implementations — Sales plus historical data, Power Platform automation and Office 365 integration — run $25,000 to over $250,000, driven by record count, custom-table complexity and integration rebuild surface.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Dynamics 365 Sales migrations and handles the Dataverse schema modelling, alternate-key design, option-set integer conversion, BPF stage mapping, server-side privilege configuration for overriddencreatedon, and the reconciliation work described in Sections 5 and 7. Pricing is fixed-fee, scoped by record count and source platform, with separate line items for custom tables, historical Activity depth and SharePoint attachment volume so scope is transparent.

This is one of several legitimate paths — the right choice for any given team depends on whether they want a Solutions Partner with industry depth, a Microsoft FastTrack engagement, an SSIS-led iPaaS approach, or a specialist migration vendor. Explore FlitStack →