The finding list arrives before anyone owns it
Microsoft put Dynamics 365 Activate into public preview on September 9, 2026, and the first supported scenario is moving from Salesforce into Dynamics 365. The post describes CRM environment analysis, migration recommendations, and automated migration execution, and says early engagements have already processed over six billion data records. That is a real capability, and we think most teams will run it the wrong way round.
The wrong way round is signing up, pointing it at the org, and reading the findings. The right way round is writing the risk register first, with an owner and a decision date against each row, and then letting discovery fill in the evidence. Automation lowers migration risk only when someone has already said what the risks are. Otherwise it produces a longer list faster, and long lists are where migration programmes go to hide.
What Microsoft's post says and what it leaves out
Microsoft's post frames Activate around three paths: starting new from requirements to solution design, moving from a known source, and growing an existing Dynamics 365 environment. The move path is the one the preview covers, and the post lists data analysis, process mapping, customization identification, and dependency mapping as its parts. ERP scenarios are described as planned for later this year, with other source providers to follow.
Comcast and Ziwi Pets are the named early customers, with congruentX and Fusion5 as the partners. Comcast's Sathish Arumugam is quoted on the discovery capabilities speeding up their migration assessment, and congruentX's Marty Priest describes the partner's approach as human-led and AI-accelerated. The post gives no pricing or licensing detail and does not mention Dataverse or Copilot Studio by name, even though its headline promises a move to agentic business applications. Where those agents get built is a question the post doesn't answer, and it belongs on the register too.
Who owns each object before discovery runs
Discovery will surface customizations that need attention and map the dependencies between entities. The question to settle beforehand is who answers for each one. For every Salesforce object in scope, every trigger, every flow, and every managed package, write a name. A person who will sit in the review and say keep, rebuild, or drop, rather than a team alias that nobody checks.
We've watched this fail without any tooling involved. The assessment flags a block of custom fields on Opportunity that nobody currently employed can explain, the steering committee notes it, and the fields get migrated as they are because dropping them felt riskier than carrying them. Our sibling piece on the first conversation about legacy customization covers how the tooling changes that conversation. The register makes sure it ends with a decision somebody signed.
Which records the CRM actually masters
Six billion records processed tells you about scale. It tells you nothing about which of those records were authoritative. In most Salesforce estates we've seen, Account is partly mastered in the ERP, Contact is partly mastered in the marketing platform, and the CRM holds copies with local edits on top. Move a copy into Dynamics 365 as though it were the master and you now run two masters with no reconciliation.
So before discovery runs, answer for each object where the record is born, where it gets corrected, and which key survives the move. Our guide to durable business keys is the practical version of that question, and what a shared customer record needs covers the argument once two teams disagree about mastery.
Which integrations still point at the old org
The post describes dependency mapping inside the CRM environment. It does not say the tool inventories the systems outside it, and that gap is where the migrations we've seen go wrong. The middleware job that pushes closed-won opportunities to billing, the marketing platform that syncs leads overnight, the warehouse extract that feeds the board pack, the partner portal that reads Account through an old API user. Each one keeps working against Salesforce on cutover day until someone repoints it.
List every inbound and outbound integration with its owner before you sign up for the preview, and mark which ones only read. The case for listing integrations before the roadmap is that the map should exist before the plan does. Activate makes that ordering more urgent, because automated execution moves data faster than anyone can chase down undocumented consumers.
What stop and rollback mean once execution is automated
Automated migration execution deserves the most time in the risk review. Anything that executes needs a defined stop. Who can halt a run partway, what state the target environment is in when they do, and which reconciliation report both the Salesforce admin and the Dynamics 365 owner will accept as proof that the counts match. The post doesn't describe those controls. Write the answers down before the first run rather than discover them during it.
Retirement belongs on the same page. Decide the date the old org becomes read-only and the date it gets switched off, and put a name against each. We've argued before that modernization needs a retirement list, and a migration that ends with both CRMs alive is the most common way to pay for two licences while trusting neither.
Write the register before you sign up
The register we'd take into the preview has one row per question above, plus the agent question from Microsoft's own headline. Each row gets an owner, an evidence column that discovery will fill, and a decision date that doesn't move because the tool ran faster than expected. Then sign up, run discovery, and read the findings against the rows instead of the other way round.
If the first review after discovery ends with a longer finding list and the same number of owners as before, the tool did its job and the programme didn't. Take that into your next steering committee and ask who owns row one.
