How to export your data from Dynamics 365 Sales

How to export data from Dynamics 365 Sales without losing records or relationships

If your renewal, licensing change, residency rule or lock-in concern is pushing you to leave Dynamics 365 Sales, the first practical question is how much of your data you can actually take out. Dynamics 365 Sales gives you two routes: Excel exports from views, which suit small, ad hoc pulls, and Azure Synapse Link, which copies full tables to a data lake. A complete exit needs both the table-level copy and a verification step that proves the copy is complete. Treat the export as a data copy, not a migration: it moves rows out, but it does not rebuild the business logic that depends on them.

Before you plan any volumes, confirm the current export limits for views and the table-level requirements for Azure Synapse Link in Microsoft's own documentation, since these change between releases. Ask your Microsoft partner or administrator which Dataverse tables your organization actually uses, including custom entities, and which of them need change tracking enabled for the link to capture them. Record the row count of each table in Dataverse and compare it with the row count in your extract. That comparison is the simplest check that nothing was dropped by a filter, a view limit or a failed sync.

Relationships, attachments, email and customizations need separate handling because a flat extract does not carry them intact. Lookup fields appear as identifiers, so you must export the parent and child tables together and keep the GUIDs, otherwise accounts, contacts and opportunities lose their links. Activity attachments and notes are stored apart from the records they belong to, and email content is not part of a simple table copy. Business process flows, workflows, plug-ins and custom business rules have no export format at all, so list them now as requirements to rebuild in the target system. Ask your administrator to produce a written inventory of these items before the subscription is reduced.

Which Dynamics 365 Sales data you can export and by which path

This table maps each main CRM data type to the two export paths named for Dynamics 365 Sales: view exports to Excel and Azure Synapse Link to a data lake. Use it to decide which path covers each table, then confirm the limits and table lists with Microsoft before you plan the extract. The main takeaway is that a complete, repeatable copy of every table depends on Synapse Link and its Azure costs.

Data type	Export method	Format	Limits to confirm
Accounts	View export to Excel; Synapse Link full table copy	Excel file; CSV in data lake	Confirm view row cap and that the accounts table is in the Synapse Link table list
Contacts	View export to Excel; Synapse Link full table copy	Excel file; CSV in data lake	Confirm row cap and how parent account lookups are written in CSV
Opportunities	View export to Excel; Synapse Link full table copy	Excel file; CSV in data lake	Confirm row cap and how stage, owner and close date fields export
Quotes	View export to Excel; confirm Synapse Link coverage	Excel file; CSV if table is supported	Confirm whether the quote tables and line items are in the Synapse Link table list
Cases	View export to Excel; confirm Synapse Link coverage	Excel file; CSV if table is supported	Confirm row cap and whether case resolution history is included
Activities	View export to Excel; confirm Synapse Link coverage	Excel file; CSV if table is supported	Confirm whether emails, tasks, appointments and calls each export as separate tables
Notes and attachments	Confirm with Microsoft; Synapse Link may hold metadata only	Confirm with Microsoft	Confirm whether note text and file content are copied, or only references
Custom entities	Synapse Link full table copy for entities you select	CSV in data lake	Confirm which custom tables can be selected and how option sets export

What does not come out cleanly and how to handle each gap

Excel exports and Synapse Link move table rows, but much of what makes a Dynamics 365 Sales org work lives outside those tables. The cards below cover the common gaps, the workaround for each, and the point where the client should confirm with Microsoft what is documented as exportable.

Business process flows and workflow logic

Business process flows, workflows and business rules define how a deal moves through stages and which fields are required at each step. They are stored as metadata in the Dataverse solution, not as record data, so a table export returns the opportunities but not the stage logic that produced them. Rebuild these from a written specification in the target CRM, using the exported stage history as the test set. Ask your Microsoft partner or admin which solution components can be exported as managed or unmanaged solution files for reference.

Power Automate flows and plug-in code

Power Automate cloud flows, custom plug-ins and web resources hold automation that runs against your data, often without anyone noticing it. Export these as solution components where Microsoft supports it, and keep the source files in version control. Where a flow has no reusable equivalent in the new platform, document its trigger, inputs, actions and owner, then rebuild it. Confirm with Microsoft which flow definitions and plug-in assemblies you can retrieve for your tenant before the subscription ends.

Reports, dashboards and charts

Reports built in Report Wizard or Power BI, system dashboards and personal charts are definitions, not data. Exporting a view gives you the rows behind a chart but not the chart, its filters or its calculated measures. Record the measures, filters and audience for each report in a specification, then recreate them in the new CRM or in a self-hosted BI tool. Check which report definitions Microsoft lets you export as RDL or solution files, since this varies by report type.

Security roles and team hierarchies

Security roles, business units, teams and hierarchy security decide who sees which account or opportunity. A flat export of owner fields loses the business unit tree and the privilege levels attached to each role. Export the role and team membership lists as a reference, then map them to the new platform's groups and record permissions by hand. Plan this as an access review, not a copy, and confirm with Microsoft which security configuration data is available through the admin tools.

Email and calendar content in Exchange

Email tracked against Dynamics records is usually stored in Exchange or Outlook, and the CRM keeps only the activity link. Exporting the activity table gives subjects and timestamps, but not message bodies, attachments or calendar detail held in the Microsoft 365 tenant. Pull the mailboxes you need through Exchange tools or eDiscovery, scoped to the retention rules your legal team set. Confirm what your tenant plan permits before you start.

Documents linked through SharePoint

Documents attached to accounts and opportunities often sit in SharePoint document libraries, with the CRM holding only a link or folder reference. The link breaks once the subscription ends, so the files must be downloaded before cutover. Export the library contents with their metadata and folder paths, then re-link them in the new system or store them in an object store you control. Confirm the permissions and versioning rules for each library with your Microsoft 365 administrator.

Choosing between view exports and full table copies

A team with a few thousand records, a handful of views and no formal audit obligations usually needs one careful export and a clean spreadsheet. The Excel export from a view is the fitting path because it respects the columns and filters the team already uses, and it needs no extra Azure resources. For example (illustrative): a sales operations lead exports the active accounts view and the open opportunities view, then compares the row counts with the grid before closing the subscription.

Who runs it: any user whose security role allows export on each table in scope. A user who can see a record may still lack export rights, so confirm the role coverage with the Dynamics administrator.
Admin time: limited and mostly manual. Expect one session per view plus a reconciliation pass against the live app.
Limits: view exports are bounded by the limits Microsoft applies to the grid. Confirm the current limit in your tenant before assuming one export covers everything.
Lookups: exported views show display names for lookup fields rather than full identifiers, so note which relationships you will need to rebuild in the target.
Repeatability: the output is a one-time snapshot, so plan a final re-run close to cutover.

Check every export's row count against a live count in the app, and confirm that each view includes the fields your target system needs.

The export sequence for a complete Dynamics 365 Sales extract

This sequence produces a dated, verified copy of your Dynamics 365 Sales data that you can check against the live system before the subscription changes. Each step has a named check, so the final archive can be shown to finance, compliance and the migration team as complete.

Inventory entities and record counts
The CRM administrator lists every table in scope, including accounts, contacts, leads, opportunities, quotes, orders, invoices, cases, activities, notes, users, teams, business units and any custom tables your organization added. For each table, record the row count from the live environment and the date it was taken, then store the list in your migration workbook. The step is done when every custom table has an owner and a recorded count, and the business owner has signed off that nothing material is missing.
Confirm change tracking on required tables
The Dynamics administrator checks which tables have change tracking enabled, because Azure Synapse Link depends on it to capture changes for each table it copies. Enable it on any in-scope table that lacks it, and note the tables where you cannot enable it so you can plan a separate extract for them. Confirm the setting in the maker portal for each table before you move on. The step is done when the table list shows a status for every in-scope table.
Set up the data lake and Synapse link
The cloud or data platform administrator creates an Azure storage account with hierarchical namespace for the data lake, then links it to the Dataverse environment through Azure Synapse Link. The administrator selects the in-scope tables in the link profile and confirms that the lake folder for each table is created. Access to the storage account is limited to named service accounts and the migration team. The step is done when each selected table shows a folder in the lake and a status that indicates the initial copy is progressing.
Run initial full copies
Once the link reports the initial copy as complete for each table, the data platform engineer records the completion time and the file set in the lake for that run. Keep the output in CSV form, because that is the format your receiving system will import, and do not overwrite earlier runs. Confirm that no table reports an error state before you proceed. The step is done when every table has one complete copy with a recorded run identifier and timestamp.
Export views for business user checks
Sales operations and account owners export the saved views they use every day to Excel, the same way they would for a routine report. The aim is not a full copy but a human check that records they know, such as open opportunities by owner or accounts with active cases, appear in the lake extract with matching values. Note any view that has more rows than the Excel export allows, because those tables need the lake copy as the only complete source. The step is done when each named business owner has signed off on at least one view from their area.
Reconcile counts and keys against the live system
The data engineer compares the row count of each CSV file with the count recorded in the inventory step, and checks that primary keys are unique and that foreign keys such as account and owner identifiers resolve within the same extract. Investigate any difference, because changes made after the initial copy may explain small gaps, and rerun the link for that table if needed. The step is done when every table either matches its count or has a documented, explained variance that the business owner has accepted.
Store a dated archive with a hash manifest
The archive owner packages the reconciled CSV files into a dated folder in storage that you control, and generates a manifest that lists each file with its size and a cryptographic hash. Store the manifest separately from the files, and set retention and access rules that your records policy requires. Confirm the hashes by recomputing them from the stored copies on a second machine. The step is done when a second person has verified the manifest and the archive is locked against edits.
Log every run in the migration record
The project manager keeps a run log that records each export, the operator, the environment, the tables included, the row counts, the hash manifest reference, and any exceptions or re-runs. Keep the log with the migration plan so that auditors, legal reviewers or the implementation partner can trace how the archive was produced. Review the log at each stage gate before the subscription is changed. The step is done when the log covers every run and each exception has a recorded resolution.

How to prove the export is complete before you cancel anything

Verify completeness against a frozen source before anyone touches the subscription. Pick a single source timestamp, then compare record counts for each table you exported (accounts, contacts, opportunities, quotes, cases, activities and any custom tables) against the same query run in Dynamics 365 Sales at that moment. Record the timestamp in your evidence file, and agree with the business owner whether records changed after it will be captured in a delta export or handled manually. Counts alone do not prove much, so also check that primary keys are unique and complete in the target, and that lookup fields such as an opportunity's account or a case's contact still resolve to a valid parent record. Orphaned lookups are the most common silent failure when relational data is flattened into CSV files, so treat any orphan as an open defect, not a rounding issue.

Test the parts that counts cannot see. Sample attachments and notes by hand: pick a set of records across each owner and each year, open the linked files, and confirm the file names, sizes and text match the source. Confirm that activity and note relationships still point to the correct parent. Then run the full export a second time from a clean session and compare the two output sets file by file. If the second run does not match the first, find out why (time-based fields, changed records or a filter that was not applied) before you accept either set. Keep the export logs, the source timestamp, the tool and version used, and a checksum manifest that lists every file with its hash and row count. Store these alongside the data, under access control, for as long as your retention policy requires.

Write the verification plan down and agree it with the people who will sign off. A short document that lists the tables in scope, the counts and key checks, the sample sizes, the acceptance threshold for each check and who approves the result will reduce disputes at cutover. Confirm with your legal and records teams which evidence they need to keep and for how long, and confirm with the vendor and your implementation partner which fields and tables the export tool does not return by default. Do not cancel or reduce the Dynamics 365 Sales licenses until the signed plan shows every check passed or every exception has a documented decision.

What to plan before the Dynamics 365 Sales contract ends

Most of the export work depends on dates and rights that sit in your Microsoft agreement, not in the CRM itself. The cards below cover the contract items and the operational decisions that determine how much time, access and storage you need before the subscription stops.

Notice and renewal dates

Find the notice period, the renewal date and any auto-renewal clause in your Microsoft agreement or order form. Work backward from the last day you can give notice, because that date, not the subscription end date, usually sets when your export project must be finished. Confirm with your Microsoft account team whether any notice must be in writing and to which address.

Time to run and verify full extracts

Plan a window for the first full extract and at least one repeat run. Excel exports from views are limited in size, so large tables such as accounts, contacts and activities will likely need a bulk method. Schedule time to compare row counts and sample records against the source before you rely on the copy, and keep the source active until that check passes.

Azure subscription and data lake costs

Azure Synapse Link copies Dataverse tables into a data lake in your Azure subscription, so storage and compute for that lake are billed to you, separately from the Dynamics 365 license. Ask your Microsoft team and your Azure administrator to confirm which subscription will pay, what storage tier you will use and how long the lake will be kept. Estimate these costs from the Azure pricing for your region, not from the CRM license.

Admin roles needed to run exports

Exporting full tables, enabling change tracking and configuring Synapse Link each need specific administrative permissions in the Power Platform and Azure. Identify who holds those roles now, and whether they are in the same tenant as the production environment. Plan for a named owner who can grant access during the export window, since an export that waits on a role request can consume the time you planned for verification.

Retention and deletion obligations for the archive

Decide how long the exported archive must be kept and who may read it. Your retention schedule, data protection terms and any sector rules set the minimum period, and the archive will contain personal data from contacts and accounts. Document where the archive is stored, who has access, and when it will be deleted, so the copy you keep is not less controlled than the Dataverse data it replaces.

Contract terms on data return

Check whether the agreement says what Microsoft provides on termination, how long your data remains available after the subscription ends, and whether any deletion timeline applies. Confirm these terms in writing with your Microsoft account team instead of relying on general product documentation. Use the answers to set the hard deadline for your final extract and to decide whether you need a second full copy taken just before access ends.

What to extract first so the new CRM can go live

Extract the records that the sales team touches every day before anything else. Start with accounts and contacts with their identifiers, meaning the Dataverse GUIDs, external IDs and any legacy codes your ERP or support tools use to match a customer. Without those identifiers, opportunities, cases and activities cannot be reattached to the right customer after the move. Next, export open opportunities with their stages, owners, close dates and amounts, and the products and price lists they reference. Confirm with your Dynamics administrator which price list is active for each region, because a product export alone does not show which price applies to which customer.

Then pull quotes and orders that are still in use, meaning open quotes, orders awaiting fulfillment and any renewal terms that run past the cutover date. These are the records most likely to be disputed later, so reconcile their totals against Dynamics before you sign off the export. Open cases come next if your service team uses the CRM for tickets, since a case can carry a customer commitment that the new system must show from day one. Keep the last year of activities (calls, emails, tasks and meetings) as the working history. Older history can be archived read-only in a file store if the destination does not need it, and the field mapping for each entity to SuiteCRM, EspoCRM or Odoo is covered in the migration pages.

Before you start the extraction, record the row counts for each entity in Dynamics and check them against the export files, so that gaps show up while the source system is still live. Ask your Dynamics administrator which of these tables need change tracking enabled for an incremental copy, and confirm this in your own environment rather than assuming it. Plan a final delta extraction close to cutover so that records changed after the first full copy are not lost. Note the date of each extraction in your migration log, since the people running the cutover will rely on it.

Questions buyers ask about exporting Dynamics 365 Sales data

Can our team export all Dynamics 365 Sales data without outside help?

Partly, and the hardest parts are the ones that matter most. Users with the right security roles can export views to Excel, but that route covers one view at a time and is subject to size limits you need to confirm in your own environment. A complete copy of every table, including custom entities, usually goes through Azure Synapse Link to a data lake. That requires an Azure subscription, a Dataverse administrator to enable it and a decision on change tracking for each table in scope. Your team can usually handle the Excel exports and the table inventory. Many organizations bring in help for the Synapse Link setup, the schema mapping and the row-count checks, because errors in those steps are easy to miss.

What makes a Dynamics 365 data export take more effort?

Effort depends more on the shape of your Dataverse environment than on the number of users. The main drivers are:

The number of custom entities and the relationships between them, since each table needs its own extract and a key map.
Attachment volume, including notes, email attachments and documents, which need a separate copy routine.
Synapse Link setup and access, meaning Azure permissions, storage design and which tables have change tracking turned on.
Plugins, business process flows and reports that hold logic you need to document before the subscription ends.

Each of these adds analysis and testing time, so ask a partner to inventory them before agreeing on a scope.

How long does a full extract from Dynamics 365 Sales take?

It depends on data volume, and the only reliable answer comes from measuring it in a test environment. Run a representative extract of your largest tables, time it, count rows against the source and record any failures. Then extrapolate to the full data set, allowing for attachments and retries. Plan the production run for a window when users are not editing records, because changes made during the extract can cause mismatches between tables. Ask the partner to show measured timings from a test copy in the written plan, and keep those results with the migration record so the production run can be compared against them.

Who on our side needs to be involved in the export?

Three roles are needed, and one person often covers more than one. A Dynamics 365 administrator enables the export paths, manages security roles and confirms which tables and columns are in scope. A data owner from sales operations decides which records are retained, archived or deleted, and signs off on the final row counts. An Azure or Microsoft contact, usually from your cloud or licensing team, handles the storage account, subscription permissions and any tenant-level approvals. Legal or privacy staff should also review which personal data is copied to new storage. Confirm named people for each role before work starts.

Does an export from Dynamics 365 count as a backup for compliance?

No, not on its own. An export is a copy of data at one point in time. It becomes part of a backup strategy only when it is protected, versioned, tested for restoration and covered by a retention rule. Your compliance program will expect controls over who can read the copy, where it is stored, how long it is kept and how deletion is recorded. An export may also omit items a true backup would capture, such as some metadata and configuration. Treat the extract as a migration artifact with its own access controls, encryption and retention schedule, and document how it fits your backup and records policies. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any assessment outcome.

Can we run the Dynamics 365 export ourselves to save money?

Yes, for a limited set of data. Excel exports from views are within reach of an experienced administrator, provided you accept that each export covers one view and that you confirm the current size limits in your environment. A full relational copy is harder. Synapse Link requires Azure setup, change tracking decisions and reconciliation that most CRM teams have not done before. A sensible split is to do the table inventory and the Excel exports in-house, then decide whether the Synapse Link work and verification are worth outsourcing based on your team's Azure experience and the time it would take them to learn it.

What should we ask a partner to include in a written export quote?

Ask for a written scope that lists each deliverable, not just a single total. Request:

A table inventory listing each entity, its export method and the row counts measured from your environment.
The Synapse Link configuration steps, including the Azure resources, permissions and change tracking settings your team must approve.
How attachments are handled, the output format, and the row-count or checksum reconciliation used to verify each extract.
A test extract with a timing report, plus the production run plan and cutover window.
Secure storage, retention and deletion rules for the extract, and the handover documentation.
Stated assumptions, your responsibilities, and how changes are handled if your environment differs from the inventory.

DeployOpen engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How DeployOpen scopes and delivers a Dynamics 365 Sales data exit

DeployOpen plans and implements the data exit as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. The work covers extraction from Dataverse, validation of completeness and the handover of documented, self-hosted target systems inside your own infrastructure.

How we scope

Inventory which Dynamics 365 Sales tables, views, attachments and customizations must leave, and who owns each one.
Confirm which export routes you already have, such as Excel exports, Azure Synapse Link or a licensed extraction tool, and their limits.
Record the written scope, deliverables and timeline, and identify the data your team must confirm before the subscription ends.

How we build

Set up the extraction pipeline in your own cloud account or data center, so exported CSV files never leave your controlled environment.
Check row counts, key relationships between accounts, contacts, opportunities and activities, and attachment links against the source.
Test every export on a staging copy of the target platform before any production load, and record each validation result.

How we hand over

Deliver a runbook covering each extraction job, its schedule, its output format and the checks that confirm it succeeded.
Document the field mapping, data retention locations and access controls, so your auditors and security team can review them.
Provide a final export set and a dated record of what was extracted, which your team keeps for the exit file.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the handover, if your timeline needs it.
Re-run extraction and validation for any late changes to the source data before the Dynamics 365 Sales subscription ends.
Prepare the systems, controls and evidence your compliance assessors need, while independent auditors issue any formal report.