Is Dynamics 365 Overkill for a 30 Person Company?

Headcount is the wrong unit, and everyone uses it anyway

Thirty people tells you almost nothing about which CRM fits. A thirty person agency where four people sell and the rest deliver has a very different requirement from a thirty person distributor where twenty five people touch customer orders every day. The number that predicts the decision is how many people write to the same customer record, and from how many different jobs. One team writing means a pipeline tool. Three teams writing means a shared record, and a shared record is a platform decision.

Count the systems, not the seats

A better question than how many people you have is how many places the same customer already exists. If the customer is in the CRM, in a delivery tracker, in the accounting system, and in a shared mailbox, then whichever CRM you buy is going to be asked to reconcile those. A light CRM answers that with exports and connectors. A platform answers it by putting the records in one database and reporting across them. That is the actual fork in the road, and it does not move when you hire ten more people.

Ask what happens on the day after the sale

If the answer is an invoice and nothing else, a pipeline tool is enough. If the answer is a project, an onboarding, an installation, a support entitlement, or a renewal that somebody has to track against what was actually sold, then the sale is the start of the record rather than the end of it. Systems that end at closed won make the team keep the rest somewhere else, and somewhere else is a spreadsheet.

Growth curve matters more than current size

Thirty people who will be thirty five next year should buy for today and change their minds later, because a light CRM is not a life sentence and the migration is survivable. Thirty people who are about to open a second entity, take on a channel, or add a service business have a different calculation, because the thing that is cheap to decide now is expensive to retrofit after two years of history. Neither of those is decided by the headcount itself.

The honest version of the seat count argument

Small teams are told that enterprise platforms need scale to pay off. That is partly true and mostly for the wrong reason. It is not that the software needs a large number of users, it is that a platform needs someone to own it. The threshold worth watching is not thirty seats, it is whether there is one person, internal or hired, who is accountable for how the system is configured. Below that line, buy the simplest thing that works.

Reporting: the number leadership asks for lives in three systems

What it looks like: Somebody wants revenue by service line against delivery cost, or pipeline next to consultant utilization, or renewals weighted by support tickets raised. Every month it takes a person a day of exports and a spreadsheet that only they understand, and the answer is stale by the time it is circulated.

Why it happens: A light CRM reports beautifully on the data inside itself. It is not built to join that data to a project tracker, a time sheet, or a ledger, so the joining happens outside the product, in an export, a connector, or a warehouse somebody has to maintain. Dynamics 365 Customer Engagement stores records in Dataverse, so Power BI reads them directly alongside anything else in the same tenant, and a Dataverse table can be created for the thing your business actually tracks rather than forcing it into a deal record.

What it costs to live with: The visible cost is the day a month. The real cost is that decisions get made on the numbers that are easy to produce rather than the numbers that matter, and nobody notices, because the report that would have shown the problem was too expensive to build.

Automation: the rule is guidance and a seller in a hurry can walk around it

What it looks like: A discount goes out that should have needed approval. A deal moves to closed won with no signed document attached. A record is created by an import or an integration and skips every check the form applies. The fix is a reminder in a team meeting, and it works for a fortnight.

Why it happens: Workflow engines in light CRMs react after the fact. They run when a record changes and they can update it, notify someone, or enrol it in a sequence, which is genuinely useful. What they structurally cannot do is refuse the save. On Dataverse, a plug in runs inside the transaction, so a rule can block a record that violates it, whichever direction the record arrived from. Business process flows with stages and branching, business rules on the form, and server side logic are three different levels of firmness, and the difference only matters once a rule protects a margin, a compliance step, or an approval.

What it costs to live with: Everything is fine until the first time it is not, and the incident that exposes it is usually a discount, a missed renewal, or an audit question. If your process merely suggests good behaviour and the business needs it enforced, you are one motivated person away from the exception.

Integration: the system you need to connect has its own authentication

What it looks like: The CRM has to talk to the ERP or the accounting system, an internal database behind the firewall, an industry application with no public API, or a partner system that expects certificates and a scheduled file. There is no ready made connector, or there is one and it does about sixty percent of the job.

Why it happens: Marketplace connectors are excellent for the popular targets and thin everywhere else, and the moment you need retry logic, idempotency, field level mapping, and an error queue somebody watches, you are building an integration whichever CRM you own. The difference is where it runs. With a light CRM, that logic lives in a separate integration tool or a service somebody has to host and monitor. On the Power Platform it is Power Automate, custom connectors over an OpenAPI specification, and Azure Functions or plug ins where the volume or the transaction boundary demands it, sitting on the same platform, in the same tenant, under the same governance as the CRM itself.

What it costs to live with: A separate integration layer is a second system with its own failures, its own credentials, and usually one person who understands it. When that person leaves, the integration becomes a black box that nobody dares change, and that is the point at which companies call us.

The fourth one nobody lists: quotes, pricing, and discounts

What it looks like: The price depends on a customer specific agreement with validity dates, on volume tiers that compound, on a bundle, or on a margin floor that has to hold. Sellers do the arithmetic in a spreadsheet and paste the result into the CRM, so the CRM no longer knows what was actually sold.

Why it happens: Products, quotes, and a light approval step exist in most CRMs and are fine for a standard price list. Dynamics 365 Sales ships price lists, price list items, discount lists, and unit groups, and anything the price list cannot express runs as server side logic, so it applies to a record created by a form, a bulk import, or an integration alike.

What it costs to live with: Once pricing lives outside the CRM, so does the truth about margin, and the forecast becomes a report about what people typed rather than what they sold.

The fifth: the screen your process needs does not exist

What it looks like: The team wants a board, a planner, a matrix, an inspection form, or a comparison view, and the CRM offers a list. So the work happens in a spreadsheet next to the CRM and gets typed back in, badly.

Why it happens: A light CRM gives you a good API and an app marketplace, and a genuinely custom screen means building an application beside the CRM and asking people to leave it to do their job. On the Microsoft side, PCF controls written in TypeScript and React run natively on the form, canvas apps and Power Pages cover the internal and external cases, and all of it ships as managed solutions with source code you own. We publish our own controls, so this is the part of the comparison we know best.

What it costs to live with: Adoption. People do not abandon a CRM because it lacks a feature, they abandon it because the screen makes their job slower than the spreadsheet did.

The sixth: the people who need one step should not need a full seat

What it looks like: An approver, a delivery lead, a technician, or a customer needs to do exactly one thing in the system. Buying them a full CRM seat is absurd, so instead they get emailed and somebody else types it in.

Why it happens: Per seat pricing across a whole company is the wrong shape for occasional participation. The Power Platform lets that one step live in a Power Apps or Power Pages surface sized for the person doing it, on the same Dataverse records, with proper security rather than a shared login.

What it costs to live with: Every step that leaves the system is a step whose timing, owner, and outcome are invisible in reporting, which quietly undermines the reporting problem you bought the CRM to solve.

Decide what the customer record actually is

Before any migration, agree what an account, a contact, and a deal mean in your business, and what the things that are none of those should become. Half of what makes a platform feel heavy is a data model that was inherited rather than designed, and this is the cheapest hour you will ever spend on the project.

Clean the data before it moves, not after

Duplicates, dead records, half filled fields, and companies that exist three times under three spellings will all migrate perfectly if you let them. Deciding what history is genuinely worth carrying is a business decision, not a technical one, and it is the item most often skipped in a rushed plan.

Rebuild the logic rather than porting it

The rules living in vendor workflows have to be written again, and that is an opportunity rather than a chore, because half of them exist to work around a limitation you are leaving behind. We rebuild them as Power Automate flows, business rules, or server side logic depending on how firmly each one needs to hold.

Run environments properly from day one

Separate development, test, and production environments, changes made in unmanaged solutions and promoted as managed ones, so a change can be reviewed and rolled back instead of edited live. It is also the only way ongoing support means anything, because you cannot support what you cannot version.

Give it an owner and a first ninety days

Name the person accountable for the system, agree what the first release actually includes, and cut everything else into a second one. Teams that go live with a narrow, finished scope keep the momentum. Teams that go live with everything half configured spend a year explaining why the new system is worse than the old one.