Migrate from Dynamics 365 Sales to SuiteCRM

Migrate from Dynamics 365 Sales to SuiteCRM: what the work involves

Most teams start this move because a renewal is coming up, a licensing change raises the cost per user, a data residency rule requires customer records on their own servers, or the Dataverse platform has become hard to leave. The answer in short: the move is a staged extraction of Dataverse data, a mapping of accounts, contacts, opportunities and activities onto SuiteCRM modules, and a rebuild of the business process flows and approvals that sales relies on, run by a small team over several test cycles rather than one weekend cutover. The usual team is a CRM administrator who knows the Dynamics customizations, an IT or platform engineer who builds the SuiteCRM environment and identity integration, and a sales operations lead who signs off on field mappings and pipeline stages. An implementation partner is useful when the Dynamics org has heavy plug-ins, custom entities or Power Automate flows that nobody has documented. Ask any partner for a fixed-scope written plan that lists the tables in scope, the workflows to rebuild and the test exit criteria before work starts. Effort depends mainly on the number of custom entities, the volume of activity history you keep and how many integrations write into Dataverse today. Confirm these counts in your own org before you ask for a quote.

The main risks are lost activity history, duplicate or orphaned records, and users who lose Outlook sync or sign-in on cutover day. Plan a staging instance, take full backups of the SuiteCRM database and files before each load, and reconcile record counts for every table after each test run. SuiteCRM 8 supports LDAP and SAML sign-in, so decide early whether users will authenticate through your identity provider. Test the SAML logout behavior too: in SuiteCRM 8.7.0 and later, signing out at the identity provider does not end the SuiteCRM session, so users need to be told this before go-live. Confirm the exact Outlook and Microsoft 365 connector behavior for your SuiteCRM version with the SuiteCRM documentation and a pilot group, since this is the integration users notice first. Keep Dynamics read-only for a defined period after cutover so that anyone who needs historical data can still reach it.

Which Dynamics 365 Sales capabilities map to SuiteCRM, and which need rework

This table maps the main Dynamics 365 Sales capabilities to their closest SuiteCRM equivalents and marks each as clean, needs rework or gap. Use it to scope the migration: clean rows move with standard import, rework rows need design time, and gap rows need a decision on whether to rebuild, replace or drop them.

Capability	SuiteCRM equivalent	Status and what to confirm
Accounts and contacts	Accounts and Contacts modules with relationships	Clean for standard fields. Confirm custom Dataverse columns and parent-child account hierarchies map to SuiteCRM fields or relationships.
Leads	Leads module with conversion to accounts, contacts and opportunities	Needs rework. Confirm how your lead qualification and conversion rules were built in Dynamics and recreate them in SuiteCRM workflows.
Opportunities	Opportunities module with sales stages and amounts	Clean for core fields. Stage names, probability values and currency handling need a mapping sheet agreed before import.
Quotes and products	Quotes and product catalog in the SuiteCRM 8 sales modules as configured	Needs rework. Confirm which quote templates, price lists and approval steps are in use, since these need explicit configuration.
Activities (emails, calls, tasks, appointments)	Activities and history linked to records	Needs rework. Confirm which activity types and timeline views your users rely on, and whether historical email content is in scope for migration.
Cases	Cases module, or a dedicated support tool if case management is in scope	Gap for queues and knowledge articles. Confirm whether Dynamics Customer Service cases are migrating and which tool will hold them.
Business process flows	Workflow and process definitions in SuiteCRM	Gap in direct form. Stages and branching must be redesigned as SuiteCRM workflows and reviewed with sales operations.
Outlook sync and Power Platform automations	No native Outlook add-in equivalent for the Dataverse sync model; automations rebuilt as SuiteCRM workflows or external integrations	Gap. Confirm which Outlook features users need, and treat Power Automate flows and custom Dataverse plug-ins as logic to be rewritten and tested.
Copilot and custom Dataverse logic	No direct SuiteCRM counterpart for Copilot features; custom business logic must be rebuilt	Gap. Inventory custom plug-ins, calculated fields and Copilot usage in your environment before committing to a timeline.
Reporting and SSO	Reports and dashboards in SuiteCRM; SSO through LDAP or SAML using AUTH_TYPE settings	Needs rework. SAML logout does not end the SuiteCRM session when initiated at the identity provider, so confirm this behavior with your identity team.

Which exports and integrations move out of Dataverse

Getting data out of Dataverse is the first technical step, and the export path you choose decides how much of the data model you keep. The cards below cover the two documented export routes, the records to move, and the sign-in and Microsoft 365 integrations that users will notice on cutover day.

Excel exports from views

Excel exports run from a saved view in the Dynamics 365 Sales interface, so they carry only the columns and rows that view returns. They suit a sample check of accounts or opportunities, but they are not a complete copy. Before you rely on one, confirm the export row limit for your version with Microsoft and compare the row counts against the source table. Use these exports to validate the SuiteCRM import, not as the system of record.

Azure Synapse Link for full copies

Azure Synapse Link for Dataverse writes full table copies to a data lake in CSV, which is the path to use for a complete extract. Confirm with Microsoft which tables need change tracking enabled, because tables without it cannot be copied this way, and check that the environment has the required permissions before the subscription changes. Plan the extract as a dated snapshot, then run a delta pass just before cutover so late edits are captured.

Core records and their relationships

Accounts, contacts, opportunities, activities and attachments carry most of the sales history, and each one links to the others through lookup fields. Map the Dataverse GUIDs to SuiteCRM record IDs so that contacts stay attached to the right account and activities stay attached to the right opportunity. Check attachment file sizes and counts early, since they often drive the transfer time more than row counts do.

Outlook and Microsoft 365 sync

Users who depend on Outlook add-in sync or email tracking will lose that behavior when Dynamics 365 Sales is switched off, and SuiteCRM does not inherit it. Inventory which users sync mailboxes and calendars, and decide whether they will use a replacement connector or log activities manually for a transition period. Confirm any connector's support for your Microsoft 365 tenant before you commit to it.

Entra ID SAML sign-in

SuiteCRM 8 can sign users in through SAML using the nbgrp onelogin-saml-bundle, enabled with AUTH_TYPE=saml. Create a SAML application for SuiteCRM in Microsoft Entra ID, map the user attributes SuiteCRM expects, and test with a pilot group first. Note that SuiteCRM 8.7.0 and later do not support IdP-initiated logout, so signing out of Entra ID will not end the SuiteCRM session.

Power Automate flows to rebuild

Power Automate flows that create records, send notifications or sync data with Dataverse do not move with the data. List each flow, its trigger, its connectors and its owner, then decide whether it becomes a SuiteCRM workflow, a scheduled job or an integration on your own automation platform. Do not assume a prebuilt connector exists for any flow until you have confirmed it in writing with the vendor or in your own test environment.

Migration sequence from inventory to decommission

This sequence moves Dynamics 365 Sales data, customizations and users into a self-hosted SuiteCRM 8 environment in controlled stages. Each stage closes with a written output, so the cutover decision rests on evidence and the Dynamics environment is retired only after a retained archive exists.

Inventory tables, customizations and users
The Dynamics administrator and a sales operations lead list every entity in scope, including standard tables, custom entities, relationships, business process flows, workflows, plug-ins, reports, dashboards and security roles. They also export the active user list with role assignments and team memberships, and record which fields have no business owner. The output is a signed inventory workbook that marks each item as migrate, rebuild or retire, and it is done when the sales lead has approved every row marked retire.
Build a staging pilot on SuiteCRM 8
The platform team installs a current SuiteCRM 8 release on a staging server, confirming the version and the PHP, web server and database combination against the SuiteCRM 8 compatibility matrix before installation. They load a representative sample of accounts, contacts, opportunities and activities from the first extract and rebuild two or three critical processes by hand. The output is a documented staging build with its version recorded, and it is done when a sales user can complete a full opportunity cycle without support from the migration team.
Map fields and test imports
Analysts map each Dataverse column to a SuiteCRM module field, record lookup and relationship, and decide how choice values, currency, time zones and owner fields translate. The team runs repeated test imports against staging, logging every rejected row and every truncated value, then fixes the mapping and reloads until the error log stops changing. The output is an approved mapping specification and a clean import report, and it is done when reruns reproduce the same record counts.
Run a parallel period with reconciliation
Users keep Dynamics as the system of record while a scheduled delta extract refreshes the SuiteCRM copy, and a reconciliation script compares record counts, totals of open pipeline value and key identifiers between the two systems. Discrepancies go to named owners and are resolved in the mapping or the source data. The output is a reconciliation report signed by the sales lead and finance, and it is done when the open differences are zero or each one has an accepted explanation.
Cut over users and identity
The team freezes Dynamics edits, runs the final delta extract and import, and reruns the reconciliation on the frozen data. Identity is configured in SuiteCRM 8 through LDAP or SAML, with the identity provider and the Outlook connection repointed for each user group, and sign-out behavior is documented because SAML logout at the identity provider does not end the SuiteCRM session. The output is a go-live checklist with each user group confirmed, and it is done when pilot users sign in and read their own accounts and activities.
Export and archive the Dynamics data
Before any licence or environment is removed, the administrator takes full extracts of the in-scope tables, the customization exports, audit logs and attachments, and stores them in an encrypted archive that the organization controls. The archive is indexed against the inventory, and a restore test confirms that the extracts can be opened and counted. The output is an archive manifest with checksums and an owner, and it is done when the restore test passes and the retention period is recorded by the compliance lead.
Decommission the Dynamics environment
After the read-only period set by the business and the archive is verified, the team removes user access, disables integrations and workflows, and revokes application registrations and service accounts in Microsoft Entra ID. The admin confirms with the Microsoft administrator and the procurement team how the subscription and any Dataverse storage are closed, and retains the contract and deletion evidence. The output is a decommission record, and it is done when no active user, integration or service principal still points at the old environment.

How the migration differs by team size and starting point

A small sales team that uses standard accounts, contacts, opportunities and a few views usually has the smallest migration. The data model is close to SuiteCRM's core modules, so most of the work is export, clean-up and a short user cutover. This is an illustrative scenario, and the actual effort depends on how much history and how many custom fields the team carries.

Export scope: Pull accounts, contacts, opportunities and activities through Excel exports from the standard views, then check record counts against Dataverse before you delete anything.
Duplicate cleanup: Merge duplicate accounts and contacts in the source before import, because small teams often skip this and carry the same clutter into a new system.
Sequencing: Stand up a SuiteCRM 8 test instance, load a sample, and have two or three users test the pipeline before the full load.
User cutover: Repoint Outlook and sign-in for a handful of accounts in one step, with a short read-only period on Dynamics.
Retirement: Keep an archived export of the full history for the period your records policy requires.

Before you start, confirm with your team which fields the sales process actually uses, since that list usually shrinks the scope more than any other step.

Why SSO and Outlook need their own cutover plan

Sign-in and Outlook behavior change on cutover day even when the data migrates cleanly, so they need their own plan. SuiteCRM 8 can authenticate users through SAML or LDAP, selected with the AUTH_TYPE setting (saml or ldap). Decide which path fits your directory before the data load, because the choice determines how accounts are matched, how passwords are handled and who can still log in if the identity provider is unavailable. Current users will be mapped from Microsoft Entra ID or your on-premises directory, so confirm how each existing Dynamics 365 user maps to a SuiteCRM user record and which roles they receive.

Plan for logout behavior explicitly. The SuiteCRM 8.7.0 and later SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so signing out at the identity provider does not end the SuiteCRM session. Users who leave a shared workstation may stay signed in to CRM after they believe they have logged out. Test this in staging, document it for your security team, and decide whether it is acceptable or needs a compensating control such as session timeouts. Confirm the current SAML configuration reference for your exact version before you rely on it.

Test sign-in and the Outlook path in a staging instance that mirrors your identity configuration, then tell users what changes for them. Confirm which Outlook integration path SuiteCRM supports for your version, since Dynamics 365 uses its own Outlook add-in and the replacement will not behave the same way. Communicate the new login URL, the logout limitation, any change in how calendar and email are linked to records, and who to contact during the first week. Run a pilot group before the full cutover, and keep the Dynamics 365 read-only access available until users confirm their Outlook sync works.

What usually goes wrong and how to prevent it

Most failed CRM cutovers fail quietly: relationships break, history goes missing, duplicates pile up, and people keep using the old system. Each card below names one failure, why it hurts this migration, and the check that prevents it before users go live.

Broken account and contact links

Dataverse stores contacts and accounts as separate related tables, and a flat export can lose the parent link that ties a person to a company. Once the link is gone, opportunities and cases attached to an account show the wrong contacts or none at all. Map the relationship fields explicitly in SuiteCRM and load accounts before contacts. Then sample at least a few enterprise accounts with multiple contacts and confirm each contact opens under the right company.

Activity history gaps

Emails, tasks, phone calls and appointments are stored as activity records, and Excel views often omit them or cap how many rows come out. Sales leaders then find deals with no history behind them, which undermines forecasts and handovers. Decide which activity types must migrate, extract them as their own tables, and reconcile row counts against Dynamics before sign-off. Record any activity types you deliberately leave behind so the decision is documented.

Duplicates from repeated imports

Test loads, partial reruns and a final load often create two copies of the same account or contact in SuiteCRM. Duplicates split activity history and skew reports on pipeline and customer counts. Give every migrated record its Dynamics GUID in a dedicated external ID field, and use that field as the match key for every rerun so imports update instead of insert. Run a duplicate check on accounts and contacts after each load and keep the load logs.

Customizations left on the Dynamics side

Custom entities, business process flows, calculated fields and workflow logic often exist only in Dynamics, and the export captures data but not the rules behind it. Teams then discover mid-cutover that stage gates or required fields no longer run. Inventory every custom entity, flow and automation before extraction, and mark each one as rebuilt, retired or deliberately dropped. Assign an owner to each rebuilt item and test it in a staging SuiteCRM instance.

Lost files under public/legacy in SuiteCRM 7

If your source or target runs SuiteCRM 7, the migration docs warn that the process may remove non-core files under the public/legacy folder. Custom templates, logos or scripts placed there disappear without an obvious error. Before any move, take full file and database backups, list every file under public/legacy that differs from the stock install, and test the migration on a staging copy first. Re-apply custom files only after review, not by blind restore.

Users who keep working in Dynamics

After cutover, some sales reps keep updating records in Dynamics, especially through Outlook, mobile apps or saved bookmarks. Changes then land in a system that no longer feeds reporting, and the two copies drift apart within days. Set a dated freeze on Dynamics edits, remove or redirect Outlook and bookmarked access, and confirm SSO sends users only to the SuiteCRM login. Check the Dynamics audit trail for edits after the freeze date.

What drives cost and duration in this migration

This table lists the factors that most change the effort and cost of moving Dynamics 365 Sales into SuiteCRM, with what each one means for your project. Use it to scope a written quote and to decide which drivers you can reduce before work starts. The main takeaway is that data volume, customization and integrations usually matter more than the license decision.

Driver	Why it changes cost or effort	How to keep it down
Record volume and attachments	Large account, activity and note tables take longer to extract, transform, load and reconcile, and attachment storage grows the hosting footprint.	Archive closed records older than your retention rule, migrate attachments in a separate, verified batch, and agree on what is in scope.
Custom entities and fields	Each custom Dataverse table and column needs a mapping to a SuiteCRM module or field, and some may need new modules or dropdown lists.	Inventory customizations first, retire unused fields, and map to standard SuiteCRM modules where the business meaning matches.
Business process flows and Power Automate flows	Stage-based business process flows and cloud flows do not transfer automatically, so each one is rebuilt as SuiteCRM workflows or as separate automation.	List every flow with its trigger, owner and use, then rebuild only those still used, starting with the sales stages that drive reporting.
Integrations and connected apps	Outlook sync, marketing tools, ERP links and reporting connections each need a replacement connector, credentials and testing.	Count active integrations from the admin side, classify them as required or retire, and ask the vendor which connectors are in scope.
Data quality	Duplicate accounts, missing owners, inconsistent country codes and stale opportunities add cleansing rounds before and after load.	Run deduplication and owner checks in Dynamics before export, and agree on acceptance criteria for a sample load.
User count, roles and training	Each role needs its own permissions, and users need time to learn SuiteCRM screens, search and reporting.	Reduce the number of security roles, pilot with one sales team, and deliver short role-based guides instead of a general course.
Identity and SSO	Repointing sign-in from Microsoft Entra ID to SuiteCRM requires SAML or LDAP configuration, and the SAML implementation in 8.7.0+ does not support IdP-initiated logout, which affects user expectations.	Confirm the authentication method early, test with a pilot group, and tell users that logging out at the identity provider does not end the SuiteCRM session.
Hosting and support choices	Self-hosting adds infrastructure, patching, backup and monitoring work that recurs, while SuiteCRM Ltd offers paid support, hosting and migration services as separate options.	Decide between in-house operations, a managed host or a support package, and request the recurring cost of each in writing.
Written quote scope	Vague scopes produce change requests, so the quote should state exactly what is included and excluded.	Ask for the export method, mapping workbook, number of test cycles, cutover support, handover documents and the price of each optional item.

Questions buyers ask before moving Dynamics 365 Sales to SuiteCRM

How much does a move from Dynamics 365 Sales to SuiteCRM cost?

The software itself is free under the AGPLv3 license, so the cost sits in the work and the infrastructure around it. Expect one-time costs for data extraction, mapping, rebuilding business process flows, testing and cutover, and recurring costs for servers, database, backups, patching and support. Costs rise with the number of custom entities, the volume of history you keep, the number of integrations and the SSO and Outlook work. SuiteCRM Ltd sells support packages, hosting, implementation and migration services, and a quote from any provider should break these out separately. Ask for the scope, the deliverables, the environments included and what is recurring after go-live.

How long does a Dynamics 365 Sales to SuiteCRM migration take?

Duration depends on how much data and customization you move, not on the CRM alone. The main drivers are the number of tables and custom fields to map, how many business process flows need rebuilding, how clean the source data is, how many users need Outlook and single sign-on changes, and how many approval cycles your testing and cutover require. Teams with a small set of standard accounts, contacts and opportunities usually finish faster than teams with heavy customization and years of activity history. No duration is fixed in advance; ask any provider for a timeline tied to a written scope with named milestones.

What does the migration require from our own team?

Your team needs to make decisions and provide access that only your organization can supply. This includes a named business owner who signs off on field mapping, people who know which Dynamics customizations and reports are still used, an administrator who can grant Dataverse export rights and manage the target servers, and an identity contact who can configure the SAML or LDAP connection. Expect user acceptance testing time from sales managers and a few users who check opportunities and activities after the trial load. Confirm these commitments in the statement of work so that delays are visible early.

Can our internal team run the migration without an outside partner?

A capable internal team can run a migration, provided it has the skills and time for the work. The skills include Dataverse table structure, data transformation, PHP and Symfony administration for SuiteCRM 8, web server and database operations, SAML or LDAP configuration, and test planning. Teams that lack one of these skills usually bring in help for that part only. Consider the cost of backfilling people who are already busy and the risk of an unrehearsed cutover. A fixed-scope engagement with a written deliverables list is one option; a retainer for ongoing operations is another.

Can SuiteCRM run in our own cloud account or data center?

Yes. SuiteCRM is free to download and self-host, so you can run it in your own cloud account, a private data center or an isolated network. SuiteCRM 8.10 supports PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4 on Linux, Unix or macOS, according to the SuiteCRM compatibility matrix. Confirm that your operating system, database versions and load balancer choices match that matrix before you size the environment. DeployOpen implements and hosts open-source platforms inside the client's own infrastructure, including air-gapped networks.

What happens to our Dynamics customizations when we move to SuiteCRM?

Dynamics customizations do not transfer automatically. Custom entities, fields, forms, views, business rules, Power Automate flows and plug-ins each need a decision: rebuild in SuiteCRM, replace with a standard feature, or retire. Business process flows usually become SuiteCRM workflows or custom logic, and any Power Platform integration needs a new route. Inventory every customization before scoping, because some will be unused. Where you need SuiteCRM 8 customizations, check how they are built and maintained, since SuiteCRM 7 to 8 is documented as a migration, not an upgrade.

How do we run Dynamics 365 Sales and SuiteCRM in parallel?

Parallel running works best with a defined system of record for each data type and a clear cutover date. Many teams keep Dynamics as the master during a trial period, run scheduled extracts into a staging SuiteCRM instance, and compare record counts and key fields. Others freeze new entries in Dynamics for a short window before the final load. Decide who can edit which records during overlap, and how activities logged in Outlook will be captured. Keep Dynamics read-only after cutover until your retention and audit requirements are met, and confirm the archive plan with your compliance owner.

What should we test on a SuiteCRM staging instance before cutover?

Test on a staging instance first, with a full backup of files and database before any change. The SuiteCRM migration documentation advises testing this way and reviewing customizations, because the migration may remove non-core files under the public/legacy folder. Check record counts and totals for accounts, contacts, opportunities and activities, verify reference links and owner assignments, and confirm that LDAP or SAML sign-in works for test users. Note that SuiteCRM 8.7.0 and later SAML does not support IdP-initiated logout, so sessions can remain open after logging out at the identity provider. Plan for that behavior in your access policy.

Where to confirm the export and SuiteCRM details

Start with the SuiteCRM migration guidance before you commit to a date. The migration documentation advises testing on a staging instance, backing up both files and database, and reviewing customizations, because the migration may remove non-core files under the public/legacy folder. Read the SuiteCRM home page for the current edition and services, then check the SuiteCRM LTS and release lifecycle page to confirm which 8.x release line your team will standardize on and when patch releases are expected. Confirm the SuiteCRM 8 compatibility matrix against your planned PHP, Apache, MariaDB or MySQL versions and your Linux host before you order servers. Ask your implementation partner to show the matrix results in writing for your target release.

Next, confirm the sign-in design. The LDAP configuration reference covers the AUTH_TYPE=ldap setting and the Symfony Security LDAP authenticators, and the SAML configuration reference covers AUTH_TYPE=saml and the nbgrp onelogin-saml-bundle. Read the SAML reference closely: for the 8.7.0 and later SAML implementation, IdP-initiated logout and POST binding to the logout service are not supported, so a user who signs out at Microsoft Entra ID will still have an open SuiteCRM session. Decide with your security team how session timeouts and sign-out expectations will be handled for users who move from Outlook and Dynamics to SuiteCRM.

Finally, confirm Dataverse export options with Microsoft documentation for your own tenant. Export capabilities, licensing for bulk extraction, Azure Synapse Link configuration and change tracking requirements depend on your Dynamics 365 edition, your Azure subscriptions and your administrator permissions, so do not rely on a general description. Ask your Microsoft administrator to confirm which tables are available to extract in full and to record the export method and date in the migration plan. Keep those records with your migration evidence so that field mappings and row counts can be checked against the source system after cutover.

Migrate from Dynamics 365 Sales to SuiteCRM