Analysis Before a Dynamics Migration

A migration estimate is either based on an inventory or it is a guess. That sounds harsh, but the reason is simple. The effort of a migration hardly depends on the target. It depends almost entirely on the starting point. And in grown systems the starting point is always documented worse than everyone involved believes.

The questions to answer before the quote

The tenant move is a special case with additional checks. Whether it is on-premises to the cloud or a legacy system into a rebuild, the effort drivers are the same. And they can be quantified from the solution export.

How big is the data model, really? Not the fifteen tables everyone talks about, but the total number including the forgotten ones, with the field count per table. Every table is a migration object with mapping, transformation, testing and acceptance.

How much logic hangs on it, and on which technology? Classic workflows, business rules, plug-in steps, flows and scripts, each counted. The share of superseded technology is the decisive number here. What is outdated is not migrated but rebuilt, and that is a different price tag.

What does the system connect to on the outside? Dependencies on other solutions, and external connections in flows and endpoints. Each of these connections needs a counterpart in the target or a decision to switch it off.

And how much of it is still alive at all? Deactivated processes, unreferenced web resources, fields without use, global option sets without references. Everything confirmed dead before the migration does not have to be taken along. Nothing lowers the migration effort as directly as a smaller migration scope.

A side effect of this count is often priceless: it forces conversations that would otherwise happen in the middle of the project. If the list shows 40 tables and the business only knows 15, that is not an analysis error. It is the moment when someone looks at the remaining 25 for the first time in years (and most of the time someone suddenly shouts "but that one is important!" ;).

The special case of data quality

One limitation: the export quantifies the structure, not the data. Duplicate rates and fill levels need a look into the environment itself. For project planning, a two-part approach has proven itself. Do the structure analysis from the export up front, even without any access. Do the data analysis as the first project step afterwards.

What the numbers do in the project

The real value of the inventory is not the estimate but the negotiating basis. With the inventory you can actively shrink the migration scope: these 40 tables come along, these 20 are retired beforehand. These workflows are replaced by flows during the migration instead of being carried over 1:1. Without an inventory you migrate everything (to be safe), and "to be safe" is then the most expensive item of the project.

The inventory itself is the cheapest part of the whole undertaking. Putting it at the start is the single decision with the best ratio of cost to risk reduction that a migration project can make.