This post has the same title as the official Microsoft guide Assess an enterprise and consolidate assessment reports with DMA.
The page was lately removed but luckily I was able to find it on the WayBack Machine.
Microsoft is use to drop tools without forecast, like Database Diagram for example.
So if you need to migrate your SQL Server estate to Azure and you want to see the big picture through Power BI look no further: in this page you will find all the needed tools.
Prerequisites
You need to download these three tools:
- PowerShell-Modules: If the link is broken download it from here
- LoadWarehouse script: If the link is broken download it from here
- DMA Reports Power BI template: If the link is broken download it from here
Keep in mind that you can also find the three files in this discussion: https://techcommunity.microsoft.com/t5/microsoft-data-migration/assess-an-enterprise-with-data-migration-assistant-update/bc-p/2416149#M188 , until the post will be nuked by Microsoft
Setup the PowerShell-Modules
Download the .zip and put the content into the folder C:\Program Files\WindowsPowerShell\Modules\DataMigrationAssistant

You may need to unblock the PowerShell files after you save them to the WindowsPowerShell directory to ensure that the modules load correctly. To unblock a PowerShell file, right-click on the file, select Properties, select the Unblock text box, and then select Ok.

Importing the DMA output files
If you have used the DMA tool in bulk to assess your SQL Server estate you now have the output saved in JSON.
We are going to run this command to import them to SQL Server. This command is also going to create two databases DMAReporting and DMAWarehouse
dmaProcessor -processTo SQLServer -serverName "localhost" -CreateDMAReporting 1 -CreateDataWarehouse 1 -databaseName DMAReporting -warehouseName DMAWarehouse -jsonDirectory C:\temp\
These are the parameters:
| Parameter | Description |
|---|---|
| processTo | The location to which the JSON file will be processed. Possible values are SQLServer and AzureSQLDatabase. |
| serverName | The SQL Server instance to which data will be processed. If you specify AzureSQLDatabase for the processTo parameter, then include only the SQL Server name (don’t include .database.windows.net). You’ll be prompted for two logins when targeting Azure SQL Database; the first is your Azure tenant credentials, while the second is your admin login for the Azure SQL Server. |
| CreateDMAReporting | The staging database to create for processing the JSON file. If the database you specify already exists and you set this parameter to one, then objects don’t get created. This parameter is useful for recreating a single object that has been dropped. |
| CreateDataWarehouse | Creates the data warehouse that will be used by the Power BI report. |
| databaseName | The name of the DMAReporting database. |
| warehouseName | The name of the data warehouse database. |
| jsonDirectory | The directory containing the JSON assessment file. If there are multiple JSON files in the directory, then they’re processed one by one. |
The import should take few seconds to execute but I’ve also seen it run for minutes.
The speed is determined by the size of the JSON files
If you incur in the error Error writing results for file C:\***** to database I have found a workaround: copy the JSON file to another machine and fire the import there.
This is definitely an environmental problem and I have seen it happen sometimes. Just use another computer.
Loading the data warehouse
Now that the two databases are created we need to run the LoadWarehouse script. This will take the data from the ReportData table in the DMAReporting database and load it into the DMAWarehouse.
As soon as you open the script you will face this suggestion:
|
1 2 3 4 5 6 |
/* IMPORTANT - Before running the script, press CTRL+SHIRT+M to set the database name parameters. RUN EACH STEP INDIVIDUALLY. TAKE CARE TO READ THE COMMENTS. */ |
So click CTRL+SHIRT+M and set the name of the two database you have created.
In my case I’m going to use the default names DMAReporting and DMAWarehouse.
If you have chosen a different name it’s now time to change the variable
This trick will allow you to set the name of the two database all over the LoadWarehouse script.
As you can see the script is divided in 4 steps and they suggest to run each step individually.
- Step: all good, it will run without problem
1234-- Step 1 - cleans object types. (this should be a temp step until tool is fixed)UPDATE <Report Data Database, sysname, DMAReporting>..ReportDataSET ImpactedObjectType = 'Database Options'WHERE ImpactedObjectType = 'DatabaseOptions' - Step: same here, no problems
12345678910111213141516171819202122-- These scripts use 3 part names. Ensure you update your database names-- Step 2 - Capture any missing rulesINSERT INTO <Warehouse Database, sysname, DMAWarehouse>..dimRules (RuleID, Title, Impact, Recommendation, MoreInfo, ChangeCategory)SELECT DISTINCT rd.Ruleid, rd.Title, rd.Impact, rd.Recommendation, rd.MoreInfo, rd.ChangeCategoryFROM <Report Data Database, sysname, DMAReporting>..ReportData rdLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimRules drON rd.RuleId = dr.RuleIDAND rd.Title = dr.TitleWHERE dr.RuleID IS NULL-- Capture any missing object typesINSERT INTO <Warehouse Database, sysname, DMAWarehouse>..dimObjectType (ObjectType)SELECT DISTINCT rd.ImpactedObjectTypeFROM <Report Data Database, sysname, DMAReporting>..ReportData rdLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimObjectType otON rd.ImpactedObjectType = ot.ObjectTypeWHERE ot.ObjectType IS NULL - Step: here comes the problems. If you run the third step from the official LoadWarehouse you will incur in a bug.
You first have to go to the table dbo.FactAssessment > Design, and allow NULLs for the SourceCompatKey.
Sometimes the TargetCompatKey might be affected too.

You can now execute the third step after you uncomment theINSERT INTO
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849-- Step 3 - Run select statement first to ensure no NULL keys (except dbowner which is expected to be null at this point).-- IMPORTANT - Once happy uncomment out the INSERT statement and run again-- INSERT INTO <Warehouse Database, sysname, DMAWarehouse>..FactAssessment(DateKey, StatusKey, SourceCompatKey, TargetCompatKey, Categorykey, SeverityKey, ChangeCategorykey, RulesKey, AssessmentTargetKey, ObjectTypeKey, DBOwnerKey, InstanceName, DatabaseName, SizeMB, ImpactedObjectName, ImpactDetail, AssessmentName, AssessmentNumber, ServerVersion, ServerEdition)SELECT dd.DateKey AS "DateKey",ds.StatusKey AS "StatusKey",sc.SourceCompatKey AS "SourceCompatKey",tc.TargetCompatKey AS "TargetCompatKey",dc.CategoryKey AS "CategoryKey",dsev.SeverityKey AS "SeverityKey",dcc.ChangeCategoryKey AS "ChangeCategoryKey",dr.RulesKey AS "RulesKey",AssessmentTargetKey AS "AssessmentTargetKey",ot.ObjectTypeKey AS "ObjectTypeKey",dbo.DBOwnerKey AS "DBOwnerKey",dma_rd.InstanceName AS "InstanceName",[Name] AS "DatabaseName",SizeMB AS "SizeMB",COALESCE(ImpactedObjectName, 'NA') AS "ImpactedObjectName",COALESCE(ImpactDetail, 'NA') AS "ImpactDetail",AssessmentName,AssessmentNumber,ServerVersion,ServerEditionFROM <Report Data Database, sysname, DMAReporting>..reportdata dma_rdLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimDate ddON CONVERT(CHAR(8),dma_rd.ImportDate,112) = dd.[Date]LEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimStatus dsON dma_rd.[Status] = ds.[Status]LEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimSourceCompatibility scON dma_rd.SourceCompatibilityLevel = sc.SourceCompatibilityLevelLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimTargetCompatibility tcON dma_rd.TargetCompatibilityLevel = tc.TargetCompatibilityLevelLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimCategory dcON dma_rd.Category = dc.CategoryLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimSeverity dsevON dma_rd.Severity = dsev.SeverityLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimRules drON dma_rd.RuleId = dr.RuleIDAND dma_rd.title = dr.Title -- there is a ruleid being used for 2 different titlesLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimAssessmentTarget astON dma_rd.AssessmentTarget = ast.AssessmentTargetLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimChangeCategory dccON dma_rd.ChangeCategory = dcc.ChangeCategoryLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimObjectType otON CASE WHEN dma_rd.ImpactedObjectType IS NULL OR dma_rd.ImpactedObjectType = '' THEN 'NA' ELSE ImpactedObjectType END = ot.ObjectTypeLEFT JOIN <Warehouse Database, sysname, DMAWarehouse>..dimDBOwner dboON dma_rd.InstanceName = dbo.InstanceNameAND dma_rd.Name = dbo.DatabaseNamewhere IsLoaded = 0 - Step: This step is optional and I never use it
123456789101112131415-- Step 4 - update database owners-- This step is optional. This will enable the powerbi reports to filter on specific teams / owners-- Populate database owners-- Repeat for every instance / databaseINSERT INTO <Warehouse Database, sysname, DMAWarehouse>..dimDBOwner (InstanceName, DatabaseName, DBOwner)VALUES ('ExampleInstance', 'ExampleDatabase', 'ExampleOwner')-- Once DBOwner dimension is populated update factassessment tableUPDATE faSET fa.DBOwnerKey = db.DBOwnerKeyFROM <Warehouse Database, sysname, DMAWarehouse>..FactAssessment faJOIN <Warehouse Database, sysname, DMAWarehouse>..dimDBOwner dbON fa.InstanceName = db.InstanceNameAND fa.DatabaseName = db.DatabaseName;
DMA readiness with Power BI
And here we are at the last step.
Double click on the DMA Reports Power BI template that will prompt a window in which you can enter your ServerName and the Database Name:

The Power BI template will automatically load the data from the DMAWarehouse database.
Don’t forget you can select multiple databases by using CTRL + Left click.
If you right click on one database and go to Drillthrough > Remediation Plan , you will see all actions you need to take to finalize the migration.
Conclusion
I’ve been using Power BI since 2016 and it has been getting better every year.
I like the way we can easily create dashboards and share them. Much easier than SSRS.
Is good to see that Microsoft was able to create a simple template that allows you to check at a glance the job you have to do before migration. But don’t get fooled: you still have to check for false positive like you have to do for every software that does bulk assessments.
Unfortunately this useful template is no longer maintained and one day it will not work any more.
In exchange Microsoft is proposing the Azure Migrate option which is still in preview.
…and you know what “preview” means for Microsoft, right?



