SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsevaluate-azure-migration-assessment

evaluate-azure-migration-assessment

Data & analytics

View repository

Updated 10-16 00:31

About this skill

Evaluate Azure Migration Assessment

These claims were checked on 2026-09-15 against the bundled skill-contract.yml, ARM API contracts, and assessment output contract.

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. Before calling ARM, 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 when starting a fresh assessment. 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 when retrieving a completed report. 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 when rendering the combined readiness and SKU recommendation. Include the portal report link.

Check it worked

  • Positive verification: When reusing existing assessment data, confirm it was retrieved and rendered without triggering a refresh. When a fresh assessment was requested, require a successful assessment job, completed report retrieval, and selected report timestamps later than the recorded trigger time.
  • Cleanup verification: Clear the ARM token and signed operation URL, then remove the temporary run directory only after any requested report has been saved elsewhere.

Notes

  • Follow the transport rules in references/command-execution.md whenever calling ARM.
  • 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