What should a D365 Finance & Operations health check review?

Look at: whether the design fits how the business runs, whether standard features are used where they fit, and whether configuration matches the design. Check that someone owns the design and that decisions are written down.

Warning signs:

• –the design exists only in people's heads;
• –customizations cover what standard features already do;
• –configuration differs between environments with no clear source of truth. Microsoft recommends a dedicated "golden configuration" environment for this.

Look at: whether customizations follow the extension model and are maintainable. D365 F&O doesn't allow overlayering of Microsoft models; customizations are built as extensions. Microsoft's Customization Analysis Report (CAR) runs a predefined set of best practice rules against your models, and Microsoft's go-live prerequisites include running it and addressing critical issues.

Warning signs:

• –the CAR has never been run, or its warnings are ignored;
• –patterns the CAR flags, such as direct SQL in X++, nested data access loops, or inserts inside loops where a set-based operation would do;
• –code that only one person understands, with no code review.

When we open a customer's X++ code for the first time, we look at the extension architecture before the details: Chain of Command, event handlers and extensions rather than unsupported modifications; calls to public, extension-safe APIs rather than dependence on internal implementation details; direct database operations, nested queries and transaction handling; hard-coded or company-specific logic; and dependencies on ISV code. The quickest indicator of whether code will survive Microsoft's updates is whether it is built on supported extension points. A technically elegant piece of X++ can still be a bad customization if an update can change the internal method it depends on.

Look at: which interfaces exist, who owns each one, how failures are detected and handled, and whether each interface fits the volumes it carries. Microsoft's implementation guide is direct: "Planning for failures is critical." It recommends that retries can't create duplicates (idempotent requests) and that monitoring covers every system in the integration landscape, with alerts on key processes.

Warning signs:

• –no list of interfaces with an owner for each;
• –failures found by users rather than by monitoring;
• –retries that create duplicate records;
• –interfaces never tested at production volumes.

Look at: the migration strategy (scope, sources, tools, load sequence, roles), the mapping and cleansing rules, the results of each test load, and how results are reconciled with finance and operations. Microsoft recommends defining the strategy early, updating it as the project moves, and testing the migration at least once in both system integration testing and user acceptance testing.

Warning signs:

• –each test load is run differently and nobody compares the results;
• –reconciliation is planned only for cutover weekend;
• –user acceptance testing runs on hand-entered data instead of migrated data. Microsoft's go-live prerequisites call for migrated data, including master data and opening balances.

The strongest readiness signal isn't "all records loaded." It is whether the business can reconcile migrated data against an authoritative source and formally sign it off. For finance, the first check is the trial balance by legal entity and fiscal period: the source general ledger balance must equal the D365 F&O balance, down to the accounts and dimensions that matter. Then come the subledgers: receivables, payables, inventory quantity and value, and fixed assets against the general ledger, plus open customer and vendor transactions, bank balances and tax balances where they apply. A practical go-live gate: no unexplained material differences, documented exceptions, and sign-off from finance and the process owners.

Look at: which processes are slow, when, and why. In Lifecycle Services, the SQL Insights tab on the Environment Monitoring page shows executing and blocking statements, and offers predefined queries such as the current blocking tree and the most expensive queries. Trace parser shows the call tree of X++ methods, so you can see where the time goes.

Warning signs:

• –performance testing left out of scope, on the assumption that the cloud service takes care of it. Microsoft's guidance notes that solution design, configuration and customizations can affect performance;
• –no performance testing in a Tier-2 or higher sandbox before go-live;
• –slow batch jobs that nobody has traced.

Microsoft also notes that some blocking is normal in a healthy system. It becomes a problem when it is excessive or slows business activity.

Look at: whether roles and duties match how people actually work. In D365 F&O, users get access through security roles; roles contain duties, duties contain privileges, and privileges contain permissions. Microsoft recommends assigning duties rather than individual privileges to roles, and segregating related duties to reduce the risk of fraud and errors.

Warning signs:

• –users testing with broad or administrator access instead of their real roles. Microsoft's go-live prerequisites call for testing with the correct security roles;
• –custom roles built from individual privileges, with no clear duty structure;
• –no review of custom roles after Microsoft's service updates;
• –segregation of duties discussed only after go-live.

Look at: how code moves from a developer to production. Microsoft's ALM guidance for finance and operations describes source control in Azure DevOps, a branching strategy, automated builds that create deployable packages, packages applied to a sandbox before production, and production deployment of a tested release candidate.

Warning signs:

• –deployable packages built in Visual Studio on a developer machine rather than by a build pipeline; Microsoft advises against this;
• –code checked in directly to test or release branches;
• –no automated tests and no regression testing before updates;
• –build environments on a later service update than production.

Look at: whether the plan is realistic, whether the real risks are on it, and whether decisions have owners and dates. Compare the plan with what has actually been delivered, not with what was reported.

Warning signs:

• –the go-live date has stayed fixed while scope and testing have slipped;
• –the risk log lists generic risks but not the ones the team talks about;
• –no cutover plan with go/no-go criteria. Microsoft's Success by Design guidance expects a cutover plan, mock go-lives and a support model before the go-live readiness review.

Look at: whether key users are trained, have tested their own processes end to end, and are ready to sign off. Check that the support model after go-live is agreed.

Warning signs:

• –key users seeing the system for the first time in user acceptance testing;
• –test cases that don't cover the full scope of requirements;
• –sign-off expected from people who haven't tested.