Evaluate Azure Migration Assessment

When to Use

Use directly or from run-migration-assessment for Azure SQL Server instances.

Workflow

Step 1: Resolve the Resource

Collect subscription, resource group, and instance name using ARM resource identification if not in context. Initialize the API versions and instance endpoint from references/command-execution.md.

Step 2: Check Existing Assessment

Always check for an existing assessment first for a general request such as "run migration assessment".

Skip this check only when the user explicitly asks to refresh, rerun, replace, or generate a new/fresh assessment, or explicitly says to ignore existing results.

Invoke get-migration-assessment with the resolved identifiers.

• Existing data -> render it before asking anything else. Trigger a fresh assessment only after the user explicitly confirms.
• Enabled with no data -> continue to Step 3.
• Explicitly disabled -> offer ARM enablement, portal enablement, or Local assessment if the host tool allows.

Step 3: Trigger and Monitor Assessment

Record the trigger request time and run the assessment trigger from references/command-execution.md. Continue in the same command by polling MigrationJobOnDemand using the configurable attempt count and interval from that reference.

• 2xx or 409 -> continue.
• Other 4xx/5xx -> report the error and stop.
• InProgress -> continue polling in the same turn without asking the user.
• Succeeded with lastExecutionTime later than the trigger request time -> continue to Step 4.
• Succeeded with an older lastExecutionTime -> continue polling.
• Failed -> show jobException and stop.
• Still running after the polling window -> show the portal link and stop; the user can return later to refresh.

Step 4: Retrieve Telemetry

Run getTelemetry, capture its Azure-AsyncOperation URL, and poll it using references/command-execution.md. Save the full response to a temporary file.

• Succeeded -> decode the response.
• Failed or Canceled -> report the error.
• Timeout -> show the portal link and stop.

Step 5: Confirm Fresh Results

Decode the portal's four telemetry report families:

• Suitability / Suitability_V2.
• SKURecommendation_AzureSQLVM / _V2.
• SKURecommendation_AzureSQLMI / _V2.
• SKURecommendation_AzureSQLDB / _V2.

For each family, select the report with the newer telemetry ObservedTimestampUTC. Use Suitability for readiness and blockers, and the three SKU reports for sizing and recommendation details.

Compare the selected Suitability EndedOn with the trigger request time after converting both to UTC. Also require each available selected SKU report's ObservedTimestampUTC to be later than the trigger request time. If any selected report is stale, repeat telemetry retrieval and decoding up to three times for report propagation. Use the job only for running, fresh success, and failure state.

Use the selected fresh telemetry reports as the source for readiness, blockers, target SKU, requirements, recommendation details, and available monetary cost fields.

Step 6: Render

Use the recommended target and available cost from the fresh telemetry selected in Step 5.

Use assessment output to render the combined readiness and SKU recommendation. Include the portal report link.

Notes

• Follow the transport rules in references/command-execution.md.
• Run its PowerShell sections in order and execute each fenced block as one terminal command.
• The telemetry operation URL comes from getTelemetry.
• Treat a successful telemetry LRO as report-read completion. Use MigrationJobOnDemand for assessment-job completion.
• Use EndedOn as the generated time.
• Use only the recommended target and user databases in output.

References

• references/command-execution.md
• ARM resource identification
• Assessment output