Migrating a pipeline from Salesforce or spreadsheets

What it does

Moving an existing sales pipeline into Dynamics 365 Sales means deciding how much history comes with it, and by what mechanism. The built-in import wizard handles files. Dataflows, the SDK and third-party tools handle everything the wizard cannot. The decision that actually matters is not tooling — it is how far back you go, and clients almost always want to go back too far.

Key facts

The import wizard accepts .xlsx, .csv and .xml (XML Spreadsheet 2003). File size limit is 8 MB, or 32 MB for a .zip.
One file per run. Multiple files means running the wizard repeatedly.
Columns map automatically when headings match display names; anything else is mapped by hand, and the mapping can be saved under a name and reused.
Lookup columns are mapped with the Lookup Reference button, choosing which columns are searched to resolve the relationship.
Choice column values are combined with existing values during import. Values you do not map are dropped — silently, from the import's point of view.
Results come back as Success, Failures or Partial Failures, and failed rows can be pulled out with Export Error Rows, corrected, and re-imported.
Import status runs Submitted, Parsing, Transforming, Importing, Completed.
Virtual tables and elastic tables are not supported by the wizard.
Imports update primary table fields only — related table fields in the file are ignored.
Files under 1 MB are processed in parallel; larger files are processed sequentially, so one big file is slower than several small ones.
Duplicate handling is a choice at import time: allow duplicates, or let duplicate detection rules apply.
Premium forecasting needs closed opportunities carrying Actual Value, Actual Close Date, Estimated Value and Estimated Close Date, and every opportunity must be owned by a system user. That shapes what your migration has to carry.

When to use / skip

Use the import wizard for reference data, small one-off loads and error correction cycles — price lists, territories, a few thousand contacts, the leftovers a proper migration missed. It is genuinely good at that, and the Export Error Rows loop is a decent working pattern. Do not build a Salesforce migration on it. Two megabyte files and one-at-a-time runs are not a migration tool, and the ordering dependencies across accounts, contacts, opportunities and activities will defeat you.

For anything real, use dataflows or an integration tool that can stage, transform and load in a defined order with proper key management. That is where the effort goes: an external ID column on every migrated record so you can re-run loads idempotently, and a resolution strategy for owners, currencies and choice values before a single row moves.

On scope, hold the line at open pipeline plus enough closed history to be useful, not everything. Open opportunities and their accounts and contacts must come. Closed-won and closed-lost from the last twelve to twenty-four months should come, because that history is what makes forecasting predictions and scoring possible later. Activity history — every email and call from six years of Salesforce — should generally not come. It bloats storage, it is nearly never read, and it is the part of the migration that consumes the most effort for the least return. If the client insists, offer read-only archive access to the old system for a defined period instead. That has worked for me more often than it has failed.

Spreadsheet migrations are a different animal. The data is smaller but far dirtier, there is no system of record to reconcile against, and the pipeline usually exists in three inconsistent versions belonging to three managers. Budget the cleansing, do it in the spreadsheet before it reaches Dataverse, and get the sales director to sign off the final list of open deals as accurate — because after go-live, every missing deal becomes your fault.

Configuration decisions

How much closed history comes across, expressed as a date cutoff rather than a vague "recent".
Whether activity history migrates at all, and if not, what the archive arrangement for the old system is.
The external ID strategy — which column on which tables carries the source key so loads can be re-run without duplicating.
Owner mapping: which source users map to which system users, and what happens to records owned by leavers, since forecasting and scoring need system user owners.
Currency and exchange rate handling for multi-currency pipelines, decided before load rather than corrected after.
Whether duplicate detection rules are active during migration or switched off for speed and enforced afterwards.

Gotchas

Unmapped choice values are dropped without a visible failure. The import reports success and the field is empty. Reconcile counts per field, not just row totals.
Related-table fields in an import file are ignored. People put account fields on a contact sheet, see a successful import, and assume the account updated.
Loading opportunities before their accounts and contacts produces orphan lookups that resolve to nothing. Order is not optional.
Migrated opportunities with no owner, or owned by a team, quietly break premium forecasting and predictive scoring later. Fix ownership during migration, not afterwards.
Closed opportunities imported without actual values and actual close dates look complete but are useless as forecasting training data.
One 6 MB file is slower than six 1 MB files, because only sub-1 MB files are processed in parallel. Splitting the file is a real win, not a superstition.

Consultant notes

Get the closed-history cutoff agreed in writing at kickoff. It is the single biggest lever on migration effort and the one clients most want to reopen in week ten.
Demo the Export Error Rows loop to whoever will own data quality. It converts migration from a black box into something the client can run themselves.
Push back on migrating six years of activities. Offer the read-only archive alternative and give the storage and effort numbers.
Run at least two full rehearsal loads into a sandbox with real volumes and time them. The first tells you what breaks, the second tells you how long cutover actually takes.
Before go-live, have the sales director sign off the open pipeline list — count, total value, and owner per deal. That signature is the thing that ends the arguments in week one.

Worth another look if the import wizard's file limits change, or after the next release wave touches dataflows.