When Dynamics 365 Isn't the Answer, and What We Recommend Instead
Dynamics 365 is not the answer when the business would use only a small slice of what it provides, when the people who need the system are mostly occasional or external users, when the core process does not resemble sales, service or field service, or when the organization must own its hosting, data residency and source code outright. In those cases we usually recommend one of two alternatives. A model-driven or canvas app built on Power Platform and Dataverse keeps the Microsoft ecosystem without the full Dynamics 365 application layer. A custom-built CRM on React, Node.js or .NET and PostgreSQL gives full control without Microsoft licensing. The right choice depends on fit, not preference.
This is guidance from 8+ years of delivering Dynamics 365 Customer Engagement, Power Platform and custom CRM projects. We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.
What are the signs that Dynamics 365 is the wrong fit?
The warning signs tend to show up during discovery, long before go-live, if anyone is looking for them:
- The requirements map to a handful of tables and forms, and nobody can name a Dynamics 365 Sales, Customer Service or Field Service feature the business actually needs. Opportunity pipelines, case routing, entitlements, SLAs and work order scheduling are the reason to buy the applications. If none of them matter, you are paying for structure you will hide.
- The design starts by deactivating out of the box tables, renaming Account to something else and repurposing Opportunity as an unrelated process. Each workaround is cheap on day one and expensive at every release wave after it.
- Most of the people who need access are external: members, applicants, suppliers, citizens. That points at Power Pages or a dedicated portal, not internal CRM seats.
- The organization has a hard requirement for on-premises hosting, a specific sovereign cloud, or ownership of the source code, and those requirements are not negotiable.
None of these mean Dynamics 365 is a poor product. They mean the problem is a different shape from the one the product was designed to solve.
When is Power Platform without Dynamics 365 the better option?
When the business needs a structured, secure business application inside the Microsoft ecosystem, but not the opinionated sales or service processes. A model-driven Power App on Dataverse gives you the same security model, business units, auditing, Power Automate flows, Copilot Studio agents and Microsoft 365 integration that Dynamics 365 is built on, with a data model you design from scratch rather than adapt.
Typical examples are grant and application management, asset and inspection registers, partner onboarding, internal case handling that has nothing to do with customer service entitlements, and approval-heavy processes that live next to SharePoint and Teams. Where the user interface needs something the standard controls cannot do, such as a timeline with custom grouping or a matrix editor, a PCF control fills the gap without abandoning the platform.
The trade-off is that you build what Dynamics 365 would have given you. If the requirements start drifting towards lead qualification, queues with SLAs or resource scheduling, the build cost of recreating those features is usually a signal to move back to the first-party application. Our Power Platform consulting work starts with exactly that check.
When does a custom-built CRM make more sense?
When Microsoft licensing does not fit the organization at all. That covers businesses with large numbers of light users, organizations that need to host on their own infrastructure or in a specific jurisdiction, product companies that want the CRM embedded in their own platform, and teams that want to own every line of code and every release decision.
A custom CRM built on React for the interface, Node.js or .NET for the API layer and PostgreSQL for the data gives you a schema shaped exactly around your process, row level security in the database, no per-user licensing model to plan around, and deployment wherever you choose. Integration with an accounting system, an ERP such as Business Central, a data warehouse or a telephony platform is a normal API project rather than a connector decision.
What you give up is the platform. Auditing, role-based security, document generation, email sync, reporting and mobile access are all things you build, test and maintain yourself or through a partner. A custom CRM is the right answer when that ownership is a benefit, not when it is a way of avoiding a decision. We cover the full trade-off on our custom CRM development page.
How do we decide between the three options?
We run the same structured assessment every time, before anyone talks about technology:
- Process fit. Map the core processes against what Dynamics 365 Sales, Customer Service, Field Service and Customer Insights provide out of the box. A strong match favours Dynamics 365.
- User profile. Count full users, occasional users and external users separately. Mostly external or light users push towards Power Pages or a custom build.
- Ecosystem dependency. If Outlook, Teams, SharePoint, Power BI and Entra ID sit at the centre of daily work, staying on Dataverse has real value.
- Control requirements. Hosting location, code ownership and release cadence requirements can rule options out on their own.
- Change model. Who will maintain the system in three years, and with what skills? A Power Platform solution and a React and PostgreSQL codebase need very different teams.
The output is a written recommendation with the reasons, the risks and what would have to change for a different option to win.
What does this look like in practice?
Two patterns come up repeatedly. The first is an organization that customised Dynamics 365 Sales into something unrecognisable, with Opportunity used for project tracking and every upgrade breaking a plugin. The fix is rarely a rebuild. More often it is a model-driven app with a clean data model, keeping Dynamics 365 for the teams that genuinely sell.
The second is a business that ran a requirements workshop, saw that most users were external and that hosting had to stay in-country, and chose a custom CRM from the start. Both are good outcomes because the decision was made on evidence. You can see how we approach mixed Dynamics 365 and Power Platform estates in our consulting firm case study, and how sector requirements shape the choice on our professional services industry page.
What should you do if you are already on the wrong platform?
Do not migrate in a hurry. Start with a short technical review of what is actually used: which tables hold live data, which processes run, which customisations break on update. That review tells you whether to simplify in place, move to a leaner Power Platform design, or plan a staged migration to a custom CRM with the data model mapped table by table. Every one of those paths is viable. The expensive one is staying put while the workarounds pile up. Our services overview explains how we run these reviews across Dynamics 365, Power Platform and custom builds.
Dynamics 365 is the wrong answer when most of its modules go unused, when many users only need narrow access, when the data model fights the business, or when the organization needs full control over hosting and code. In those cases we recommend a Power Apps solution on Dataverse, or a custom-built CRM on React, Node.js or .NET and PostgreSQL, chosen on fit rather than habit.
What do readers ask?
How do I know if Dynamics 365 is the wrong CRM for my business?
Look for requirements that use few of the Sales, Customer Service or Field Service features, a design that starts by repurposing standard tables, mostly external or occasional users, and hard requirements for self-hosting or code ownership. Any of these suggests the problem is a different shape from the one Dynamics 365 was built to solve.
Can we use Power Platform without buying Dynamics 365?
Yes. A model-driven or canvas Power App on Dataverse gives you the same security model, auditing, Power Automate and Microsoft 365 integration that Dynamics 365 is built on, with a data model you design yourself. It suits structured business applications that do not need the first-party sales or service processes.
When is a custom-built CRM better than Dynamics 365 or Power Platform?
When Microsoft licensing does not fit: many light or external users, a requirement to host on your own infrastructure or in a specific jurisdiction, a CRM embedded in your own product, or a need to own all the source code. A custom CRM on React, Node.js or .NET and PostgreSQL gives that control, in exchange for owning the platform features.
What do you give up by choosing a custom CRM instead of Dataverse?
The platform features that Dataverse provides out of the box: role-based security, auditing, email and Outlook sync, document generation, mobile apps and low-code extensibility. In a custom CRM these are built, tested and maintained as part of the codebase. That is a benefit when you want full control, and a cost when you do not.
Does Solzet always recommend Dynamics 365?
No. We recommend the right solution, whether that is Dynamics 365, Power Platform or a custom-built CRM, based on a structured assessment of process fit, user profile, ecosystem dependency, control requirements and the team that will maintain it. The written recommendation states the reasons and what would make a different option win.
We are already on Dynamics 365 and it does not fit. Should we migrate?
Not in a hurry. Start with a technical review of what is actually used and what breaks on update. The answer may be simplifying in place, moving to a leaner Power Platform design on Dataverse, or a staged migration to a custom CRM. Each is viable; the costly option is letting workarounds keep accumulating.
Can a custom CRM integrate with Business Central or another ERP?
Yes. A custom CRM integrates with ERP and accounting systems such as Business Central through their APIs, exchanging customers, orders and invoices. Solzet builds the CRM side and the integration; we do not implement or configure the ERP itself.