The inventory arrives before the workshop

Microsoft put Dynamics 365 Activate into public preview on September 9, 2026, with Salesforce as the first supported source. The post says the tool profiles data and entities, identifies relationships and dependencies, and surfaces the customizations that require attention. Partners and customers, in Microsoft's words, can then decide what to preserve, simplify, or redesign. That sentence changes the first conversation of a CRM migration.

Until now, the first conversation about legacy customization has been about inventory. The partner's discovery lead asks the Salesforce admin to walk through the org. The admin opens Setup and lists the Apex triggers and flows they remember. A month later a spreadsheet arrives with several hundred rows and no column for why any of them exist. If Activate does what the post describes, the spreadsheet exists before anyone books a room, and the room has to be used for the thing the tool cannot do.

Every customization stood in for a capability the platform lacked

Walk through what a ten-year-old Salesforce org usually holds. A trigger on Account that reassigns ownership because the standard territory model did not fit the sales structure in 2017. A custom object and a flow that email a manager, built because approvals were awkward then. Forty custom fields on Opportunity that turn out to be three teams' reporting needs, half of them blank since 2022. Each one was somebody's answer to a gap in the platform, in the licence, or in what the team knew that year.

That translation is the first review's real work. For each flagged item, the question is what the business needed and whether Dynamics 365 already covers that need as configuration. Microsoft's post says some of the complexity remains essential and some can be simplified and left behind. Simplify is the verb that decides whether this migration costs less than a rebuild, because it means the customization goes away and a standard feature meets the need. Somebody in the room has to remember the need well enough to say so.

What the post claims and where it stops

Microsoft's post is careful about scope. It describes environment analysis, recommendations, and automated migration execution, and says early engagements have processed over six billion data records, so the dependency map will be thorough. It will not tell you that the ownership trigger was compensating for a territory model the sales VP abandoned two reorganisations ago. Nothing in the post claims otherwise, and we read that as honest.

Comcast's Sathish Arumugam is quoted saying the discovery capabilities helped accelerate their migration assessment. Assessment is the word to notice. A faster assessment moves the slow part from finding things to deciding about them, and the post says partners will spend the recovered time on methodology, solution architecture, and change management. Our companion piece on the questions to settle before discovery runs covers owners, record mastery, and rollback. Here we are on the hour after the findings land.

The admin can describe it but cannot say if it is still needed

When inventory was the work, the partner and the admin could produce the list between them. When the list arrives first, the admin can explain how every item works and usually cannot say whether the business still needs it. The person who can is the sales operations manager who asked for the trigger, or the finance analyst who insisted on the validation rule that blocks closed-won without a signed contract date. Those people skipped discovery workshops because discovery was technical. This is now the one meeting they have to attend.

Our version of the first review has one row per flagged customization, a column for the need it met, a column for the target's standard answer, and a decision. The partner fills the third column. Only the business owner can fill the second. If nobody in the room can fill it, the item goes on the leave-behind list by default. We have argued before that a retirement list belongs inside the change plan, and it matters more here, because automated execution will carry an unexplained object across unless someone says stop.

Code that moves across is the rule an agent will not see

The post's headline promises a move to agentic business applications, and the body does not name Copilot Studio or say where those agents get built. We'd expect any agent built later on the target to reason over the standard data model and the process definitions held in configuration. A territory rule that moved across as a plugin, because nobody asked what it was for, sits outside both. The agent sees an owner change on Account and has no way to know why it happened.

That is the practical reason to prefer simplify over preserve wherever the target has a standard answer. A customization translated into a capability is one a report, a future admin, or an agent can find where the platform expects it. One recreated as bespoke code is a rule that will need explaining again at the next migration. SAP customers know this argument, and our view that clean core is a budget decision holds on the Microsoft side too. Somebody has to fund the rewrites and the retirements, or the code comes across as it is.

Ask what it was for before you ask where it goes

If you are signing up for the preview, change one thing about the kickoff. The week before the first review, send each business owner their team's flagged items and ask for one line per item saying what it was for. Then put those owners in the room with the partner and the admin and go down the list. Their answers will tell you more about the target environment than the dependency map does.

When the replies come back, read the blank lines first. They are your leave-behind list, and nothing the tool surfaced all day will be more useful.