The Hidden Risk in D365 Projects Is Outdated Architecture

Most ERP risks aren’t bugs. They’re old assumptions.

I’ve reviewed a lot of solution blueprints over the years in Dynamics. The scary ones aren’t the ones with mistakes in them. The scary ones are the ones that were completely right when they were signed.

A blueprint is a snapshot of assumptions. What the platform can do. Where administration happens. When compliance obligations bite. Sign it in 2023 or 2024 and every one of those assumptions was defensible. The problem is that Microsoft ships four service updates a year, and your architecture document doesn’t update itself.

Risk registers track the visible stuff: data migration, integration defects, cutover readiness. I’ve never seen one with a line item for assumption decay. Yet on the reviews I’ve done, decayed assumptions cause more expensive rework than any bug. A bug gets fixed in a sprint. A wrong assumption gets built on for a year before anyone notices the foundation moved.

Three assumptions have expired in the last eighteen months. If your D365 F&O design predates them, it’s worth a re-read.

Assumption one: every process step is a person on a form

Look at the to-be process maps in most blueprints. A human keys the invoice. A human matches it. A human chases the exception. Automation, where it appears, means batch jobs and workflow approvals. That was a reasonable model of the product. It isn’t anymore.

On 27 January 2026, the Dynamics 365 ERP MCP server went generally available. It lets agents built in Copilot Studio, or any platform that supports the Model Context Protocol, execute finance and operations business logic directly. No custom code, no connectors, no bespoke APIs. Alongside it, agent management is in production ready preview inside the app itself: discover agents, configure them, manage what they’re allowed to touch.

This changes process design in two ways that blueprints rarely account for.

First, the design question for each process step is no longer “which form does the user open?” It’s whether this step needs a human to decide, a human to review, or a machine to execute. Those are three different designs. If your blueprint treats them as one, you will spend money customising screens for work that an agent will absorb within the life of the system.

Second, security. An agent needs an identity, roles, and a segregation of duties position, exactly like a person. Most role matrices I review don’t have a column for non-human identities. That’s not a criticism of the teams who wrote them; the requirement barely existed when they did. But an architecture that grants an agent broad table access because nobody defined the narrow version is a control weakness running at machine speed.

You don’t have to deploy agents on day one. You do have to stop designing processes as if they’ll never arrive.

Assumption two: F&O is the system and LCS is the console

For a decade, the operating model was stable. F&O was the system of record, Lifecycle Services was where you administered it, and the Power Platform was the innovation sandbox someone else worried about. Every part of that sentence is now out of date.

Since 1 May 2025, every F&O environment must have the Power Platform integration enabled. Microsoft links unlinked environments automatically. From February 2026, new customers can no longer create LCS projects at all; new implementations start in the Power Platform admin center, where F&O runs as an app hosted in a Dataverse environment. Existing customers keep LCS access while capabilities migrate across, and Microsoft has been moving them steadily, support and environment operations among the first.

This is a better model. One admin center and one environment model instead of two loosely stitched estates. But it quietly rewrites what “environment strategy” means in a blueprint.

If your architecture document describes environments as a list of LCS tiers, it’s describing tooling a new project can’t even provision. The current questions are different. Which environment group does each environment belong to, and what rules apply? What do the managed environment controls look like: sharing limits, data policies, IP firewall, solution checker enforcement? Who governs the Dataverse side of the estate, and who pays for its capacity? Where does each piece of automation actually run: X++, Power Automate, a plugin, an agent flow?

On projects I’ve reviewed, the Power Platform side is still routinely treated as out of scope for the ERP architect. That boundary no longer exists. The platform made the two estates one estate, and an architecture that governs only half of it isn’t a smaller architecture. It’s an ungoverned one.

Assumption three: compliance happens after posting

The oldest assumption of the three. Compliance is output: post the transactions, run the reports, file the returns. Electronic reporting produces the files at month end, and if something’s wrong, you correct it next period.

Clearance-model e-invoicing ends that. In Poland, large taxpayers must issue invoices through KSeF from 1 February 2026, with the mandate extending to other businesses from 1 April 2026. The invoice is only legally issued once the government platform validates it and assigns a KSeF number. In France, every company must be able to receive e-invoices from 1 September 2026, with large and mid-sized companies required to issue from the same date and e-reporting obligations arriving alongside. Other countries are on the same road.

Read that as an architect, not as a tax accountant. A document your system produces does not legally exist until an external platform accepts it. Your tax configuration and your customer master data just moved from the reporting layer into the transaction path, and your integration’s uptime went with them. A malformed VAT ID used to be a month-end correction. Under a clearance model, it’s a blocked invoice, which means blocked revenue, in real time.

Microsoft has built for this. The Electronic Invoicing service in Globalization Studio handles format transformation, submission, digital signatures, and response handling, and the Polish KSeF integration went GA in December 2025. But the service being available is not the same as your architecture being ready. Someone has to design the exception handling when the tax authority rejects a document, the retry behaviour when the government platform is down, and the operational process for the finance team who can no longer “just post it and fix it later.” If your blueprint files compliance under reporting, none of that design exists.

How to re-review a blueprint that’s already signed

Nobody wants to reopen a signed design. Do it anyway, with a narrow scope. Five questions, one workshop:

• Which steps in our to-be processes assume a human only because the design predates agents? Mark each step decide, review, or execute.
• Does our security and SoD model have an answer for non-human identities? If an agent posted a journal tomorrow, whose access did it use?
• Does our environment strategy name Dataverse, environment groups, and data policies? Or only LCS tiers?
• Which of our documents and integrations now sit in a path controlled by a government clearance platform, and what happens when that platform says no?
• When did we last check our design against the removed and deprecated features list? It changes every release. Someone should own reading it.

Half a day of work. On the programmes I’ve seen run this kind of review, the output is usually two or three findings that would each have cost months if discovered at UAT.

The platform moves on a quarterly rhythm that Microsoft publishes months in advance. The risk was never the pace of change. The risk is an architecture document with no review date, treated as settled because it was signed.

Most ERP risks aren’t bugs. They’re assumptions nobody re-dated.