Here is a pattern I have seen more times than I would like. A Dynamics 365 programme captures its requirements, the requirements turn into a backlog, the backlog turns into a build — and somewhere in that chain the question “is this actually a fit for the platform, or are we about to custom-build our way around it?” never gets asked properly. The bill for skipping that question always arrives. It just arrives late, as a customisation backlog nobody can maintain.

Fit-gap analysis is the step that asks the question on purpose. It is a systematic way of comparing what the business needs against what the platform actually does out of the box — and deciding, deliberately, how to close each gap.

The decision triangle

Every fit-gap call sits inside a triangle of scope, cost and schedule. Move one and the others move. A requirement that needs custom development is not “bad” — but it costs more to build, more to support, and more to schedule around, and that has to be a conscious choice rather than an accident. Fit-gap analysis is what makes the choice conscious.

Categorising the gap

For each requirement, you decide how it will actually be delivered. The categories I use in the book run roughly like this:

• Fit — the platform already does this, with little or no configuration.
• Configured — achievable by configuring standard components: tables, forms, flows. No code.
• Developed — beyond standard configuration; needs a custom component such as a plugin, PCF control or custom script.
• Dynamics — this is really a first-party Dynamics 365 capability. Once enough requirements point this way, that is your signal that Dynamics 365 should be the base, not something you rebuild on bare Power Platform.
• AppSource — better solved by a proven third-party app than by custom build, given complexity or support overhead.
• Azure — better implemented with an Azure service, sometimes for capability, sometimes purely on cost.
• Microsoft 365 — already covered by SharePoint, Teams, Forms or similar, and just needs integrating.

Alongside the category, each requirement gets an effort size, a priority, a feasibility assessment, a best-fit component and a notes field. The notes are more valuable than they look — they are how a future reader reconstructs why a decision was made.

Feasibility is where the project gets saved

The part of fit-gap analysis that earns its keep is feasibility. Four questions do most of the work. Will this feature actually be used in production, or is it built on a process that is about to change? Is it technically possible at all within the platform and the constraints? Is there a business process hiding here that nobody captured? And is there a regulatory or compliance issue that quietly rules an approach out? Catch any of those early and you have saved the programme real money. Catch them in user acceptance testing and you have not.

When the answer genuinely isn't knowable from experience, that is what a proof of concept is for — a small, contained spike to retire the risk before it becomes a commitment.

What you end up with

The output is a gap register: every requirement, how it will be met, what it will take, and — crucially — every feasibility concern flagged before it becomes a surprise. It is not a glamorous document. But it is the difference between a programme that knows what it has signed up for and one that finds out the hard way. Done well, fit-gap analysis also tends to reduce scope, because seeing the true cost of a low-priority, high-effort requirement next to its value is often all it takes to descope it sensibly.

This post is adapted from the fit-gap analysis chapter of my book, the Microsoft Power Platform Solutions Architect's Handbook (Packt, 2nd edition). If a Dynamics 365 programme of yours is heading from requirements straight into build without this step, it is worth a conversation.