Fit-gap analysis for Dynamics 365

A fit-gap analysis compares business requirements to standard Dynamics 365 capabilities, identifying what fits out-of-the-box and what doesn't. The output drives critical decisions: configure, customise, integrate, buy ISV solution, or change the business process. Done well, fit-gap is the bridge between requirements gathering and design; done poorly, it becomes a battleground of scope and budget.

The fit-gap framework.

For each requirement, classify:

• Fit — standard Dynamics 365 supports it as-is.
• Configure — standard with parameter / setup adjustments.
• Customise — requires development (plug-in, custom code).
• Integrate — needs connection to external system.
• Process change — business process should adapt to system rather than vice versa.
• ISV solution — third-party app fills gap.
• Out of scope — won't be addressed.

This categorisation drives the implementation path for each requirement.

Why fit-gap matters.

• Cost — customisation more expensive than configuration.
• Time — standard faster than custom.
• Maintainability — customisations require ongoing support.
• Upgrade impact — heavy customisation complicates upgrades.
• Risk — custom code has bugs.

Bias toward fit; customise only when business value clearly justifies.

The process.

1. Requirements list — output of requirements gathering.
2. Standard capability research — what Dynamics does out-of-box.
3. Gap identification — what's missing.
4. Solution proposal — how to address each gap.
5. Cost / benefit per gap — quantify.
6. Decision per gap — what we'll do.
7. Updated requirements — final scope.

Standard capability research. Sources:

• Microsoft documentation.
• AppSource marketplace.
• Partner expertise.
• Demonstrations.
• Sandbox exploration.

The team doing fit-gap must know what Dynamics does — not assume.

Gap categorisation by severity.

• Critical — process can't operate without it.
• Significant — workaround exists but painful.
• Nice-to-have — improvements only.

Critical gaps must be resolved; nice-to-have can be deferred or rejected.

Solution options per gap.

• Configure — change parameter / setup.
• Personalise — UI adjustment per user.
• Customise — code-based extension.
• Workflow — Power Automate orchestration.
• External integration — connect to specialist system.
• ISV solution — partner app from AppSource.
• Process redesign — change how business works.
• Accept gap — live with the workaround.

Each option has cost / benefit profile.

Configure vs customise.

• Configure — uses Dynamics's parameter and setup mechanisms.
• Customise — adds new code, new entities, new business logic via development.

Configure is faster, cheaper, more upgrade-safe. Default to configure; customise only when configure can't.

ISV solution evaluation.

• AppSource browse — find candidates.
• Vendor demos.
• Reference checks.
• Cost — both licensing and integration.
• Update / support model.
• Acquisition risk — small ISV might not be around in 5 years.

For specialised industry needs, ISV often the right answer.

Process redesign as option.

• The business wants to do X because that's how they've always done X.
• Dynamics does it differently but well.
• Could the business adopt Dynamics's way?

Process redesign saves customisation cost; requires change management investment.

Cost-benefit per gap.

• Cost of customisation — development, testing, ongoing maintenance.
• Cost of workaround — manual effort.
• Cost of process change — change management.
• Cost of integration — development and operations.
• Cost of ISV — licensing and integration.

Quantify in time and money; subjective for some.

Pareto analysis. Often:

• 20% of gaps are "must address."
• 80% have viable alternatives.
• Focus customisation effort on the critical 20%.

This focuses scope and budget where it matters most.

Customisation principles.

• Standard extension points — events, plug-ins, low-code, not base code modification.
• Solution-aware — packaged for ALM.
• Testable.
• Documented.

Quality customisations are maintainable; quick-and-dirty becomes technical debt.

Output of fit-gap.

• Gap log — every requirement with disposition.
• Customisation list — what gets built.
• ISV list — what gets purchased.
• Integration list — what connects.
• Process change list — what business adapts.
• Budget impact — total cost picture.

Sign-off. Stakeholders agree:

• What's in scope.
• What's out.
• What's customised.
• What's standard.

This sign-off prevents later "but we said we needed X" disputes.

Common pitfalls.

• Customising what standard does. Partner doesn't know standard capability; recommends custom.
• Ignoring customisation cost over lifecycle. Build cost is start; ongoing maintenance is years.
• Over-customisation pride. "Our way is special" — usually it isn't.
• Forgetting upgrade impact. Heavy customisations complicate every future upgrade.
• ISV impulse purchase. Without due diligence, ISV mistakes are common.

Bias for the standard. A core implementation philosophy:

• Assume Dynamics's way is reasonable.
• Customise only with clear business case.
• Standardise where possible.

The "Microsoft did a lot of thinking about this" perspective often produces better outcomes than "we know better."

Periodic re-evaluation.

• Each release adds capabilities.
• Customisations may now be standard.
• Periodic review identifies retirement candidates.

Over project lifetime, customisation count should be flat or decreasing, not growing.

Strategic positioning. Fit-gap analysis is where implementation scope becomes concrete. The quality of the analysis directly affects cost, timeline, and maintainability. Partners and customers should align on bias — toward standard — with explicit justification for each deviation.

For decision-makers:

• Demand thorough fit-gap.
• Question every customisation.
• Track customisations as technical debt.
• Refresh fit-gap periodically.

The discipline pays back continuously through cleaner upgrades, easier support, and lower total cost of ownership.