Skip to content

Salesforce or Dynamics 365: which one to choose?

Two subscription CRM suites: the choice rests on the ecosystem you already run, not on a feature comparison.

Salesforce and Dynamics 365 are two subscription suites where a company records customers, deals and sales activity, with Dynamics 365 inside a wider family that reaches the ERP, and the choice between them comes down to a few criteria, almost never to a feature comparison. Both are assigned per individual user: every person who signs in needs their own license, and what they can do depends on the level assigned. Cost grows with headcount first, and with data volume only later. Both have an official marketplace of third-party applications and a network of implementation partners, and that is where much of what the base product does not do ends up. What is left are three real criteria, and they are what the decision turns on: the ecosystem the company already runs, how much to customize and who will do it, what actually binds you after signing.

See also: CRM (Customer Relationship Management) · The software that tracks contacts, deals and customer interactions in one place shared across the whole company.

The ecosystem the company already runs

This is the criterion that weighs most and almost nobody puts it first. Dynamics 365 stores its data in Dataverse, the same data layer used by Power Platform applications, and its accounts are Microsoft Entra ID accounts: the same credentials as corporate mail, if the company runs Microsoft 365, and there identities and permissions are not one more system to govern. Salesforce is a platform in its own right: it federates with corporate identity, but leaves a second directory of users and permissions to keep aligned, and in a mixed application landscape that independence removes a constraint. The question is not which one is better, but how many user directories to administer three years from now.

How much to customize, and who will do it

On both, customization starts declarative and reaches code only if needed. On Salesforce the configuration of an organization, meaning the data schema, processes, permissions and presentation, is described by platform metadata, and from there it goes down to the platform's server language and its web components. On Dynamics 365 it starts from the low-code tools of Power Platform and goes down to server-side code when a rule cannot be expressed declaratively, and Microsoft's documentation advises staying declarative for as long as possible. The real risk variable is not the technical level, it is the implementation partner, and who leads the project: IT or sales.

What actually binds you after signing

The data is nobody's hostage: both vendors officially document how to take customer data back out, Salesforce through periodic CSV exports and programmatic interfaces, Microsoft through a Dataverse export toward a data lake or an analytical store. The configuration does not come out: processes, automations and customizations sit in the platform's proprietary format, and that is my own reasoning, not a vendor statement. Rebuilding them elsewhere is not a data migration, it is a new project: the concrete CRM case of vendor lock-in. Connecting the ERP through an iPaaS, reading the data where it lives instead of duplicating it, likewise stays a project. Total cost is read by category: per-user licenses, implementation, migration, training.

An enterprise example

A manufacturer of two hundred people decides to adopt a CRM. It already runs entirely on Microsoft 365 and has an ERP nobody intends to replace: choosing Dynamics 365 does not come from functional superiority, it comes from the fact that people already have a corporate identity. The same company, with mail and ERP at different suppliers, would reasonably pick Salesforce, which inherits no ecosystem. In neither case will the cost line that surprises be the license.

Why it matters for decision makers

I neither implement nor resell either of them, so the honest answer can perfectly well be neither, or the one you already have. A CRM replaced without changing the way people work is spending that moves the problem: if salespeople do not record deals today, they will not on a new platform, and the project that is needed is change management before it is software. And the question for anyone proposing either is always the same: who pays for the work if this choice has to be undone four years from now.

Frequently asked questions

Per-user licenses are only one of four cost categories, and rarely the one that decides the bill. The other three are implementation, meaning the partner's work configuring processes and permissions, moving data over from existing systems along with cleaning it, and training the people who will use it every day. Comparing two offers on the license line alone compares the most predictable and least decisive part of the bill.

It starts with a real advantage, because accounts and permissions are already the corporate ones and there is no second directory of users and permissions to keep aligned. It is not an automatic answer though: if sales processes need deep customization, or if a trusted partner with skills on the other platform is already in place, that advantage can be outweighed. The right question is how many user directories the company wants to administer three years from now.

A CRM governs the commercial relationship, so contacts, deals, quotes and sales and service activity. An ERP governs internal execution, so orders, inventory, production, purchasing and administration. They are two distinct systems that coexist and talk to each other in almost every company: the useful question is not which of the two to choose, but where each piece of data is created and who reads it from the other side without duplicating it.
  • CRM (Customer Relationship Management) · The software that tracks contacts, deals and customer interactions in one place shared across the whole company.
  • Build vs buy · Deciding whether to build software in-house, buy it ready-made, or blend the two into a targeted approach.
  • Data migration · Moving data from one system or platform to another without breaking what depends on it: the real risk is organizational, not technical.
  • iPaaS · A managed platform connecting applications and data through ready-made connectors, instead of one integration per pair of systems.
  • Software exit strategy · The document stating how you leave a software vendor: data, formats, timing, support and the cost of exit.

See it in the universe

If it is a technical decision you keep postponing, that is the decision I help you make.

SEE CUSTOM TOOLS AND GOVERNANCE

Or write to me.