Fit-gap analysis is the most important phase of any Dynamics 365 Finance & Operations implementation. It's where your team determines what the platform does natively, what gaps exist between standard functionality and your business requirements, and — critically — how you're going to close each one.
A well-run fit-gap process produces a clear, prioritized list of gaps with agreed resolution approaches. A poorly run one produces 150 custom extensions you didn't need, a scope that's doubled by the build phase, and a go-live that slips by six months.
This post covers how fit-gap analysis works in D365 F&O implementations, what Microsoft's Success by Design framework expects from it, and how to track gaps in a way that keeps your project under control through go-live.
What fit-gap analysis means in D365 F&O
Fit-gap analysis in Dynamics 365 F&O is the process of systematically comparing your business requirements against standard D365 functionality, documenting where the standard fits, and identifying where it doesn't.
Each requirement is assessed against three possible outcomes:
- Fit: Standard D365 functionality covers the requirement with no modification
- Gap — configuration: The requirement can be met through D365 configuration (no code required)
- Gap — extension/customization: The requirement cannot be met through standard functionality or configuration and requires custom development
The third category is what drives your project's custom development workload. Every gap that requires an extension creates a new object that needs to be scoped, approved, built, tested, and maintained.
Where fit-gap fits in Microsoft's methodology
Microsoft's implementation framework for D365 F&O is called Success by Design. It structures implementations around formal checkpoints called Solution Blueprint Reviews (SBRs) — governance milestones where Microsoft FastTrack engineers assess whether the implementation is on track.
The fit-gap analysis happens primarily during the Initiate and Implement phases, with the Solution Blueprint Review at the end of the design phase serving as the formal gate. The SBR is where Microsoft expects you to have documented your customizations and validated your approach against standard functionality.
The five Success by Design phases map roughly to this flow:
- Discover: Project setup, team alignment, initial scoping
- Initiate: Requirements gathering, fit-gap analysis, solution design
- Implement: Build, configuration, custom development
- Prepare: Testing (SIT, UAT), cutover planning
- Operate: Go-live, stabilization, AMS
Fit-gap analysis is the primary work of the Initiate phase. The quality of this phase determines almost everything that comes after.
How fit-gap workshops run in practice
In D365 F&O implementations, workshops are run by workstream — Finance, Supply Chain, Manufacturing, HR — with the functional consultant leading a walkthrough of standard D365 processes with business stakeholders.
Each session should produce documented outcomes:
- Requirements confirmed as fits (standard functionality accepted)
- Configuration gaps (items requiring D365 configuration that are already confirmed as in-scope)
- Extension gaps (requirements needing custom development — the equivalent of SAP's RICEFWs)
- Accepted variances (requirements the business agrees to change their process for, rather than extending the system)
The critical discipline here is resisting the urge to log every small gap as a custom extension. The conversation that saves projects is: "Can we adapt the business process to use D365 standard?" Every time that answer is yes, you've eliminated development effort, testing cycles, and upgrade risk.
What gets logged as an extension gap
In D365 F&O, extension gaps — the ones that require custom development — typically fall into these categories:
X++ extensions: Code that extends or modifies standard D365 behavior. Microsoft enforces a sealed code model, meaning all custom code must go through formal extension points rather than modifying standard objects directly. This is the equivalent of SAP's Enhancements.
Integrations: Data flows between D365 and external systems — other Microsoft applications (Dataverse, Power Platform), third-party platforms (Salesforce, warehouse management systems, e-commerce), or legacy systems being retired. Integrations are often the highest-risk custom objects because they have external dependencies.
Custom reports: SSRS reports, Power BI datasets, and financial reports that go beyond D365 standard reporting. Finance teams in particular tend to have specific reporting requirements that standard D365 doesn't cover.
Data migration objects: One-time migrations of legacy data — chart of accounts, vendor masters, open purchase orders, historical transactions. Analogous to SAP's Conversion objects. Each requires mapping specifications, validation rules, and reconciliation processes.
Power Automate flows: Automated process flows that extend standard D365 approval and routing logic.
Each extension gap should be logged with enough detail to scope and estimate: a description of the requirement, the reason standard D365 doesn't cover it, the proposed resolution approach, and an initial effort estimate.
The tracking problem that kills D365 projects
Here's the typical failure pattern on D365 projects:
Weeks 1–4 of workshops: A consultant builds an Excel register with columns for requirement ID, description, fit/gap classification, resolution approach, assigned consultant, status, and estimate. It looks clean. Everyone has SharePoint access.
Weeks 5–8: The register has 200+ rows. Different consultants are updating their sections at different times. The PMO is pulling status from four consultants every Friday. Gap assessments get revised but status columns don't update. Estimate columns have conflicting numbers.
Month 3: The project enters the build phase. The register is the "baseline" — but 30% of the gaps have changed scope since they were originally logged. Some resolved through later configuration decisions. Others grew. New gaps appeared during detailed design.
Month 5 (UAT): A defect is raised referencing a requirement that was superseded by a scope change two months ago. Nobody can find the decision record. The conversation takes three steering committee meetings to resolve.
This pattern is so common it barely registers as a problem anymore. But at D365 consultant billing rates, every one of those coordination failures adds up fast.
What good fit-gap tracking requires
Effective extension gap tracking through a D365 implementation requires things Excel cannot provide:
Traceability from requirement to test. Every extension gap should link forward to its functional design document, technical design document, test scripts, and any defects raised during testing. If something fails in UAT, trace it to the original gap decision in seconds.
A single live version. One register, always current, not five versions across three SharePoint folders.
Approval workflow with a record. PMO sign-off on extension scopes should be a captured event with timestamp and approver — not an email you'll struggle to find in six months.
Integration with test management. When a test script tests an extension gap, that connection should be explicit. When the test fails, the defect links back to the extension object.
What replaces Lifecycle Services in 2026?
One important context for D365 F&O right now: Microsoft Lifecycle Services (LCS), which served as the primary project collaboration and customization tracking portal, is being deprecated in February 2026 in favour of Power Platform Admin Center.
LCS had limited fit-gap analysis tools that most partners didn't heavily use. The deprecation creates a genuine gap — there's no native Microsoft tool filling the implementation project management role that LCS partially occupied. Most partners are continuing with Excel + SharePoint + Azure DevOps, just without LCS scaffolding.
The discipline that separates successful D365 implementations
Teams that consistently deliver D365 implementations on time treat the gap register as a living connected artifact, not a status report updated once a week. The gap is connected to its design documents, test scripts, and defects — in one system, one version, accessible to the full project team. When something changes, the change is visible to everyone who depends on it.
Axia gives Dynamics 365 implementation teams a connected platform for fit-gap analysis, custom extension tracking, test execution, and PMO visibility — from the first workshop to go-live.