What Dynamics 365 Activate changes about discovery

"Tell us how your process works."

That is how a Dynamics 365 implementation has started for years. Interviews, workshops, process diagrams, a few hundred questions. And then, somewhere in workshop four, someone says: "oh right, we do that as well."

On September 9, 2026, Microsoft announced Dynamics 365 Activate. It is in public preview, and for now it covers migrations from Salesforce to Dynamics 365. ERP is described as coming later this year.

What it actually does

Activate analyzes an existing Salesforce environment and builds a picture of its data, business processes, customizations and dependencies. That much was expected.

What is easy to miss is that it does not stop at analysis. According to Microsoft it also analyzes requirements, generates configurations and executes the data migration itself, with guardrails, in a Microsoft-hosted experience. Microsoft states that in early customer engagements it has processed over six billion data records.

So this is not a documentation generator. It is an implementation tool that starts at discovery and keeps going.

The interesting part is not the migration

For me the interesting part is what this does to the discovery phase.

The opening question shifts. From "tell us how you work" to "show us how you actually use your system." That is a different starting point, and a better one, because the second question has a verifiable answer and the first one has an aspirational one.

Microsoft makes a point in the announcement that I did not expect to see stated so plainly: the goal is explicitly not to recreate the existing CRM in a new system, but to decide what to preserve, what to simplify and what to redesign.

That is worth repeating in plainer language. An implementation should not be a house move. You do not take the old furniture with you just because it happened to be standing in the old house.

What it reads, and what it cannot see

Here is the obvious point, which I am going to make anyway because it is the one that decides how you scope the project: Activate reads the system, not the organization.

It does not see the spreadsheet where the scheduler keeps what the customer actually wants. It does not see why a field has been used for something other than its label for the last three years. It does not see the working arrangement between the technician and the account manager that was never written down anywhere.

None of that is a criticism of the tool. It is a statement about where the information lives. A source system is a record of the decisions that were implemented. It is not a record of the decisions that were worked around.

The risk is not that the tool is wrong. The risk is that a complete-looking inventory feels like a complete understanding, and that the workshop which would have surfaced the workaround gets cut because the analysis is already done.

In field service this counts double

In D365 Field Service the gap between the source CRM and the operation is usually wider than in sales.

The installed base, the assets, the maintenance obligations and the real scheduling logic are rarely complete in the source CRM. They sit in a maintenance package, in the ERP, or in the head of the work planner. I have written separately about how the installed base and agreements hang together, and about what the Scheduling Operations Agent does to scheduling design.

If your discovery is only as good as your source CRM, a field service implementation is precisely the case where that is not good enough.

What this does to scoping

There is a commercial consequence that is getting less attention than the technology.

If the complexity of a source environment can be established earlier and more objectively, then the conversation about scope and risk moves forward in the project rather than surfacing halfway through the build. For anyone who works with fixed prices per phase, that is the difference between an estimate and a guess.

It also changes what an environment quick scan is for. Less time counting what exists, more time on the question of what should exist. That is the part a tool cannot sign off on.

So no, discovery does not disappear

The inventory gets faster. What remains is interpreting, challenging, designing and steering decisions.

Which is, honestly, what discovery should have been about all along. The hundreds of questions were never the point. They were the price of admission for getting to the questions that mattered.

If you are planning a Dynamics 365 implementation and wondering how much of the first phase you can compress, that is a conversation worth having before the scope is fixed, not after.

Working with me

I have specialized in D365 Field Service since 2019 and I am PL-600 certified. I take on the full track as principal contractor: the functional work myself, development and integration through a fixed subcontractor.

I currently deliver Field Service and Universal Resource Scheduling for a US-based healthcare technical services company, working across time zones, so North American programs are familiar ground rather than an experiment. I work remotely across the EU, hybrid in the Netherlands, with working hours flexible into US time zones. Rates on request.