Migration Checklist: Moving to Dynamics 365 Sales

Phase 0

Decide & Plan

Lock scope, ownership, compliance, and the cutover window before any work starts.

• Define which Dataverse tables are in scope. List every standard Sales table (Account, Contact, Lead, Opportunity, Quote, Order, Invoice, Product, Price List, Competitor) and every custom table that must move. Mark any source object that maps to none of these as out of scope.

  Risk if skipped: Undeclared tables surface mid-cutover and force unplanned schema work in the production environment.

• Define historical-data scope by table. Decide how many years of closed Opportunities, completed Activities, fulfilled Orders, and posted Invoices to migrate. Note whether emails, phone calls, appointments, tasks, and Annotations are in or out.

  Risk if skipped: An 'everything' scope inflates storage costs against Dataverse capacity entitlement and stretches the cutover window past the planned freeze.

• Confirm tenant and environment strategy. Decide whether the destination is a brand-new Microsoft 365 tenant or an existing one. Plan separate Dev, Sandbox, and Production environments in the Power Platform admin center.

  Risk if skipped: Tenant-to-tenant moves of Dynamics 365 Sales cannot be self-served and require a FastTrack engagement that adds weeks of lead time.

• Confirm Sales SKU per user. Decide the mix of Sales Professional, Sales Enterprise, Sales Premium, and Team Member licenses needed at go-live. Some forecasting and Sales Insights features require the Enterprise or Premium tier.
• Document data-residency and compliance constraints. Record the Dataverse geography the production environment must sit in, plus any GDPR, HIPAA, SOC2, or industry-regulatory obligations that gate the cutover.

  Risk if skipped: Provisioning the environment in the wrong geography requires a full environment rebuild — there is no in-place region change.

• Assign one accountable migration owner. Name a single DRI with authority to make trade-off calls. List business sponsors, the system administrator, the integration owner, and the security-role owner alongside.
• Write the success criteria. State the falsifiable conditions that declare the migration done — record-count parity per table, pipeline-value parity, no critical defects open, sign-off from the named sponsor.

  Risk if skipped: Without written criteria, 'done' becomes a moving target and the project never formally closes.

• Set the freeze date and cutover window. Pick the source-system freeze timestamp and the cutover weekend. Reserve a roll-back window inside it. Communicate both to sales leadership.
• List explicit out-of-scope items. Write down what is not moving — legacy custom objects, archived attachments older than N years, abandoned automations. Get the sponsor to initial it.

  Risk if skipped: Items not declared out of scope become implicit in-scope items that surface as defects during validation.

Phase 1

Pre-Migration Prep

Cleanse the source, build the Dataverse schema, and prepare users before any export.

Phase 2

Source Export

Get every byte you will need out of the source, in a form you can transform.

• Export Accounts with every standard and custom column. Include owner, parent account, primary contact, and the source primary key — that primary key becomes the sourcesystemid for the Dataverse Alternate Key.
• Export Contacts with every standard and custom column. Include parent account reference, owner, and source primary key.
• Export Leads with status, source, qualification timestamps, and disqualification reason. Capture the lead-to-opportunity conversion link if the source records it; you will rebuild that relationship on the Lead row in Dataverse.
• Export Opportunities with stage, close date, revenue, owner, parent account, and primary contact. Capture estimatedclosedate, actualclosedate, statecode, statuscode, and the full custom-field set.

  Risk if skipped: Closed Opportunities re-imported without statecode set return as Open in Dataverse and skew pipeline reports.

• Export Opportunity Products (line items). Each Opportunity Product references both the Opportunity and a Product or write-in product. Export the link table separately from the Opportunity header.
• Export Quotes, Orders, and Invoices with their line items. Export header and line rows in separate files. Preserve the parent-child key so the relationship can be rebuilt at load time.
• Export Product catalog, Price Lists, and Price List Items. Without these in place at load time, Opportunity Product imports fall back to write-in product and lose the catalog link.

  Risk if skipped: Loading Opportunity Products before the Product and Price List records exist orphans every line item.

• Export Activities — emails, phone calls, appointments, tasks — as separate files. Each activity type has its own schema. Include the regarding (parent) record reference, the activity party list, and the createdon timestamp.

  Risk if skipped: Activities loaded without their regarding reference detach from the parent Account, Contact, or Opportunity and become orphaned in Timeline.

• Export Notes (Annotations) separately from activities. Capture subject, notetext, objectid (the regarding record), objecttypecode, and any attached file binaries.
• Export file attachments and their metadata. For each file, capture the filename, MIME type, the parent record id, and the binary itself. Decide whether the destination is SharePoint or Annotation.documentbody per Phase 1b.
• Export the user list with roles, manager, and Business Unit assignment. Map every source owner to a destination Entra ID user before loading any record they own.
• Export Competitor, Sales Literature, and Goal records if in scope.
• Export every active source pipeline stage definition. Capture stage name, order, probability, and any stage-required fields. These map to Business Process Flow stages in Phase 3d.
• Screenshot or export every source dashboard and report. Dashboards do not migrate — they will be rebuilt in Phase 7. Capture filter logic, chart type, and source-of-truth fields.
• Stamp every export file with the exact export timestamp in UTC. This timestamp is the delta watermark for the Phase 5 final-pull export.

  Risk if skipped: Without a watermark, the delta-pull duplicates records and a manual diff costs hours of cutover-window time.

Phase 3

Transform & Map

Reshape source exports into Dataverse-shaped files, table by table, column by column.

Phase 4

Sandbox Test Migration

Prove every transform, every load order, and every throughput assumption in the Sandbox environment.

• Pick a representative 1–5% sample per in-scope table. Bias the sample toward records that exercise edge cases — Opportunities with line items, Contacts with attachments, Accounts with parent-child hierarchy.
• Choose the import method per table. Use the Import Data Wizard only for tables under 20,000 rows total. Document the chosen method per table for everything larger.

  Risk if skipped: Microsoft's documented recommendation is to limit Import Data Wizard imports to 20,000 rows; pushing more into the wizard exhausts memory and the job hangs.

• Load the sample in the Sandbox via the chosen method. Start small — work through the first few batches deliberately, then scale up once errors are clean.
• Use update-only semantics on every batch update to prevent accidental insert. Force update-only behavior on writes so missing-record errors surface instead of silently creating a row with the bogus GUID.

  Risk if skipped: Without update-only semantics, source GUIDs that have no Alternate Key match get created as new Dataverse rows with the source GUID, polluting the table.

• Spot-check 10 random Sandbox records per table against the source. Walk every column, every linked record, every Note, every attachment. Have a sales-ops domain expert do the spot-check.
• Test long strings, special characters, and unicode. Load deliberately ugly rows — Cyrillic names, emoji, em-dashes, embedded newlines in Notes. Confirm Dataverse stores and renders them.
• Test the historical-timestamp override. Pick a row, set overriddencreatedon, load it, then open it in Sales Hub Timeline. Confirm the original created date displays — not the import date.

  Risk if skipped: Test failures here are easy to fix; production failures here are expensive to fix because every row must be re-stamped.

• Test parent-child relationships end-to-end. Walk Account → Contacts → Opportunities → Opportunity Products → Quotes. Confirm every link resolves in both directions.
• Test N:N junction loads after both sides exist. Send Associate requests for a small sample. Verify the junction shows in both parents' related-records grid.
• Test attachment upload at the chosen storage tier. If SharePoint, confirm the document library auto-creates and the file opens from the record. If Annotation, confirm documentbody decodes without corruption.
• Run a full-volume rehearsal. Load the full dataset into Sandbox. Measure wall-clock time for each table. Multiply by any safety factor and confirm the cutover window fits.

  Risk if skipped: A first-time full-volume run in Production is the single most common reason cutover windows blow past their planned end time.

• Validate Business Process Flow assignment on a sample Opportunity batch. Confirm each imported Opportunity carries an active BPF instance at the intended stage and that progressing the stage in Sales Hub does not throw.
• Get written Sandbox sign-off from the migration sponsor and a sales-ops lead. Email is fine; signature is the gate to Phase 5. List defects deferred to post-cutover.

  Risk if skipped: Proceeding to Production without sign-off leaves the team with no shared definition of 'tested' when a defect surfaces later.

Phase 5

Production Cutover

Execute the load against Production in tight sequence, idempotent at every step.

• Confirm source freeze and verify zero writes in the last hour. Run a source-side query for any updatedat newer than the freeze timestamp. If hits, escalate and reset the freeze.

  Risk if skipped: Writes during cutover create a delta that is impossible to fully reconcile after Phase 6.

• Take the final delta export of every in-scope table. Pull rows changed since the Phase 2 watermark. Stamp this export with a new watermark — it is the source of truth for cutover.
• Verify Power Automate flows and classic Workflows remain disabled in Production. Spot-check the flow list. Any flow accidentally re-enabled between Phase 4 and now must go back to draft before the first record loads.
• Verify SharePoint integration is configured and the migration user has site access. If attachments target SharePoint, the document libraries must exist or auto-create privileges must be granted before the load.
• Load Users, Business Units, and Teams first. Every owned record needs a valid owner GUID. Users must exist before any record they own loads.
• Load Product catalog, Unit Groups, and Price Lists. Catalog records are referenced by Opportunity Products, Quote Products, and Order Products. Load them next.
• Load Accounts with Alternate Key upsert. Capture the request ID, row count, and error log per batch.

  Risk if skipped: A failed batch without a captured request ID cannot be diagnosed against the trace log.

• Load Contacts with Alternate Key upsert and stamp parentaccountid via @odata.bind.
• Load Leads, Opportunities, Quotes, Orders, Invoices, and their line items in order. Header tables first, then line tables. Use @odata.bind to set parent references explicitly.
• Load Activities — emails, phone calls, appointments, tasks — with regardingobjectid set per record. Each activity needs a regarding lookup to its parent. Set statecode on completed activities so they land in the right Timeline bucket.
• Load Annotations (Notes) and re-upload attachment binaries. If SharePoint is the target, push files to the document library and let the integration create the metadata; if Annotation, base64-encode and POST documentbody.
• Load N:N junction associations in a final dedicated pass. Send Associate requests in batches. Confirm both sides of the relationship are loaded before each request.
• Cross-check destination row counts against source row counts at every step. If any table is off by more than the documented tolerance, stop and diagnose — do not push through with partial data.

  Risk if skipped: Pushing past a row-count miss compounds the defect and makes root-cause analysis multiple orders of magnitude harder.

• Re-enable Power Automate flows, Workflows, and Plug-ins only after all loads complete. Toggle in the documented order — internal-routing flows first, customer-facing flows last. Watch the run history for the first 30 minutes.
• Stamp a 'cutover complete' marker record. Create one row in a Cutover Log custom table with the timestamp, the migration user, and the final row counts. This anchors Phase 6 reconciliation.

Phase 6

Validate

Prove the migration was correct before letting users in.

Phase 7

Post-Migration Cleanup

Land users on the new system and decommission the old one.

• Announce go-live to all end users. Include the Sales Hub URL, the Microsoft Entra sign-in instructions, and the first-responder Teams channel.
• Run role-specific training sessions. Sellers — Timeline, Sales Process, Copilot. Managers — forecasts, pipeline analytics. Sales ops — Solutions, security roles, duplicate detection.
• Set the source system to read-only. Lock the source on the announced date. Pin a notice in the source CRM directing users to Sales Hub.
• Rebuild dashboards in Dynamics 365 Sales. Use the Phase 2 dashboard screenshots as the spec. Build interactive dashboards in the Sales Hub or model-driven Power Apps as appropriate.
• Activate Power Automate flows in their final intended state. Walk the flow list; promote each from draft to active per the Phase 1a inventory. Watch run history for the first 24 hours.
• Re-establish integrations to email, calendar, Teams, and BI tools. Enable server-side sync for Exchange Online. Configure Teams chat for Dynamics 365. Repoint Power BI datasets to the new environment.
• Publish duplicate-detection rules. Toggle the rules built in Phase 1b from unpublished to published. Run a one-time duplicate-detection job to surface any cross-record duplicates created during load.
• Enable Copilot and predictive scoring on a delay. Wait 30 days for data-entry patterns to stabilize before enabling Copilot summaries and predictive lead/opportunity scoring; both train on destination behavior.
• Export the unmanaged Solution as a managed Solution and source-control it. The managed export is the deployable artifact for future environment promotions. Tag the version with the cutover date.
• Schedule a 30-day post-migration retrospective. Capture what worked, what bit the team, and what the next migration cohort should change.
• Archive every export, mapping spreadsheet, and run log to long-term storage. Keep them at least as long as the compliance retention window from Phase 0 requires.

  Risk if skipped: Without archived run logs, any future forensic question about a specific record's lineage is unanswerable.

• Set the source-system decommission date. Typically 90 days after cutover, after the final data-retention window closes. Communicate the date to finance, legal, and IT.
• Close the migration project formally. Final status report, lessons-learned doc, sponsor sign-off on closure. Free the team to move on.