Skip to article
Migration Discovery and assessment

Discovery appliance

A discovery appliance is the Azure Migrate appliance that discovers source servers and sends configuration, dependency, and performance metadata to Azure for migration assessment.

Source: Microsoft Learn - Azure Migrate appliance Reviewed 2026-05-13

Exam trap
Changing production before checking the exact Azure scope, owner, identity, dependency, and rollback or recovery procedure.
Production check
Can you name the Azure scope, owner, resource ID, dependency, and rollback or recovery path without guessing?
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Azure Migrate appliance, migration discovery appliance, assessment appliance, server discovery appliance
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-13
Learning paths Graph Migration concept cluster Discovery appliance
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Discovery appliance is the Azure Migrate appliance that collects server inventory, dependency, and performance metadata from source environments for assessment. In Azure, it helps teams build migration inventory, support right-sizing, detect dependencies, and provide evidence for wave planning before workloads move to Azure. Plainly, it is a named part of the architecture that operators can point to when they need evidence, ownership, and a safe change path. A useful glossary entry should explain where it appears, what it controls, what depends on it, and which signal proves it is healthy.

Why it matters

Discovery appliance matters because a small Azure design choice can shape customer experience, security posture, operational visibility, and incident recovery. When it is shallowly documented, teams may troubleshoot the wrong tenant, policy, storage account, migration project, disk, telemetry path, or SQL table while the real dependency remains hidden. In enterprise Azure work, the value is shared language: application, platform, security, data, finance, and operations teams can discuss the same object without guessing. That reduces incident time, improves audit quality, clarifies ownership, and makes production changes safer because failure modes and graph relationships are visible before change. Treat Discovery appliance as production owned when customer traffic, regulated data, migration planning, shared infrastructure, or release automation depends on it.

Technical context

Technically, Discovery appliance appears in Azure Migrate projects, VMware or Hyper-V discovery, physical server discovery, appliance configuration manager, discovered server inventory, and assessment reports and interacts with Azure Migrate, Azure Monitor, Azure subscription, and Resource groups. Configuration is reviewed through appliance registration, project key, discovery scope, and credential configuration, while operators validate live state through discovered server count, appliance health, last metadata upload, and credential status. Scope determines which permissions, logs, commands, and dependencies matter.

Exam context

Compare with

Assessment Azure Migrate VM patch assessment

Where it is used

Where you see it

  1. In Azure Migrate, a discovery appliance appears when teams register an appliance and begin collecting server inventory for assessment during production review when operators collect repeatable evidence.
  2. In migration planning, it appears when discovered server metadata feeds sizing, dependency mapping, and migration wave design during production review when operators collect repeatable evidence.
  3. In troubleshooting, it appears when a server is missing from assessment because credentials, network reachability, or appliance upload has failed during production review when operators collect repeatable evidence.

Common situations

  • Discover on-premises servers before migration assessment.
  • Collect performance data for right-sized Azure recommendations.
  • Troubleshoot missing machines in migration planning inventory.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Discovery appliance in action for food manufacturing Scenario, objectives, solution, measured impact, and takeaway.
Scenario

IronGate Foods, a food manufacturing organization, needed to address factory servers were documented in spreadsheets that did not match actual utilization or dependencies. The architecture team used Discovery appliance as the control point for a measurable production improvement.

Goals
  • Discover 600 on-premises servers
  • Group workloads into migration waves
  • Reduce over-provisioned Azure VM estimates by 25 percent
Approach using Discovery appliance

Migration architects deployed Azure Migrate discovery appliances in two datacenters, connected approved discovery credentials, and collected configuration and performance metadata for several weeks. Assessment outputs were compared with application owner interviews, and wave plans prioritized low-dependency workloads first. The team validated Discovery appliance in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Discovery appliance in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes
  • 642 servers were discovered and classified
  • Projected VM spend fell 31 percent after right-sizing
  • First migration wave completed without dependency surprises
What to learn

A discovery appliance turns migration planning from guesswork into measured inventory and dependency evidence.

Scenario 02 Discovery appliance in action for public healthcare Scenario, objectives, solution, measured impact, and takeaway.
Scenario

SummitCounty Health, a public healthcare organization, needed to address legacy clinical systems needed migration assessment, but security teams were concerned about credential handling. The architecture team used Discovery appliance as the control point for a measurable production improvement.

Goals
  • Collect server metadata without broad admin exposure
  • Protect discovery credentials and project keys
  • Produce auditable assessment evidence
Approach using Discovery appliance

The cloud team configured the appliance with least-privilege discovery accounts, restricted network paths, and documented handling of project keys. Metadata collection was reviewed with security, and assessment output was stored in the approved migration project for application-owner validation. The team validated Discovery appliance in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Discovery appliance in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes
  • Clinical server discovery completed within the approved security model
  • Credential exceptions were reduced to zero
  • Assessment signoff finished two weeks earlier than planned
What to learn

Discovery appliances are operational tools, but their credential and metadata handling must be designed like security controls.

Scenario 03 Discovery appliance in action for logistics Scenario, objectives, solution, measured impact, and takeaway.
Scenario

BlueRoad Freight, a logistics organization, needed to address migration waves kept slipping because servers appeared in CMDB records but not in Azure Migrate assessments. The architecture team used Discovery appliance as the control point for a measurable production improvement.

Goals
  • Find missing servers before wave planning
  • Improve assessment refresh reliability
  • Reduce migration replanning meetings by 50 percent
Approach using Discovery appliance

Engineers filtered discovered servers by appliance name, checked last upload times, and corrected blocked network paths from several warehouse subnets. The appliance configuration manager was monitored during discovery windows, and wave planning used only refreshed inventory with owner confirmation. The team validated Discovery appliance in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership. Runbooks were updated so support engineers could identify the correct scope, identity, dependency, telemetry signal, and approval record without asking the original implementer. The final design connected governance with day-to-day engineering work, which made the change understandable to security, operations, finance, and application stakeholders. The team validated Discovery appliance in a lower environment, captured before-and-after evidence, and promoted the change through a controlled release with rollback ownership.

Potential outcomes
  • Missing server count fell from 87 to 9
  • Assessment refresh reliability improved to 96 percent
  • Weekly replanning meetings were cut in half
What to learn

When migration inventory looks wrong, the discovery appliance is often the first place to validate evidence.

Azure CLI

CLI checks for Discovery appliance are useful because they turn portal assumptions into repeatable evidence. Start with read-only commands that show scope, state, owner, permissions, destinations, configuration, metrics, or discovered inventory. Run mutating, security-impacting, or cost-impacting commands only after approval, because the wrong scope can affect production availability, spend, access, or telemetry.

Useful for

  • Discover on-premises servers before migration assessment.
  • Collect performance data for right-sized Azure recommendations.
  • Troubleshoot missing machines in migration planning inventory.

Before you run a command

  • Run az account show, confirm tenant and subscription, and verify the operator identity has approved read access for the exact Azure scope.
  • Confirm resource group, service name, resource ID, environment, owner, and change record before collecting evidence or modifying production configuration.
  • Prefer read-only commands first; review any command that changes access, policy evaluation, disk state, migration discovery, telemetry, or data distribution before running it.

What the output tells you

  • Whether the target tenant, policy, storage account, migration project, disk, trace resource, or SQL pool exists at the expected Azure scope.
  • Which state, assignment, property, identity, key reference, attachment, metric, trace, table design, or discovered inventory value is visible to the operator.
  • Whether the issue is wrong scope, stale configuration, missing permissions, weak evidence, failed discovery, disk pressure, trace sampling, or table distribution skew.

Mapped commands

Discovery appliance operational checks

direct 
az migrate get-discovered-server --project-name <project> --resource-group <resource-group>
az migratediscoverMigration
read-only Microsoft Learn 
az migrate get-discovered-server --project-name <project> --resource-group <resource-group> --appliance-name <appliance>
az migratediscoverMigration
read-only Microsoft Learn 
az resource list --resource-group <resource-group> --resource-type Microsoft.Migrate/projects --output table
az resourcediscoverMigration
read-only Microsoft Learn 
az resource show --ids <migrate-project-resource-id>
az resourcediscoverMigration
read-only Microsoft Learn

Architecture context

Discovery appliance belongs to Migration architecture decisions where identity, monitoring, cost ownership, reliability, and production support need shared evidence.

Security
Security for Discovery appliance starts with least privilege, trusted configuration, and evidence that access matches workload risk. Review credential handling, network reachability, project key protection, least-privilege discovery accounts, and metadata classification before approving production use. A common failure is assuming that a working feature, successful deployment, visible resource, or populated dashboard proves the configuration is safe. Use Microsoft Entra groups, managed identities, RBAC, private connectivity, diagnostic logging, source-controlled definitions, and approval records where applicable. Keep exceptions ticketed, time-bounded, and owned. For regulated workloads, align the term with classification, retention, break-glass, and incident-response procedures. Remove broad access, stale keys, unreviewed contributors, and undocumented exception paths before Discovery appliance becomes an incident path.
Cost
Cost for Discovery appliance appears through licensing impact, compute capacity, transaction volume, diagnostic retention, policy remediation, storage consumption, migration assessment effort, disk performance choices, and the human effort required to recover from mistakes. Review assessment rework, migration right-sizing, appliance operations, duplicate projects, and over-provisioned target estimates before expanding production use. Some costs are direct, such as retained logs, provisioned disks, storage transactions, or SQL pool capacity; others are indirect, such as failed releases, duplicated troubleshooting, emergency restores, and support escalation. Tag related resources, monitor usage, and separate exploratory work from production. A cost review should connect spend to a real owner and measurable value.
Reliability
Reliability for Discovery appliance depends on repeatable configuration, tested dependencies, and clear failure signals. Watch appliance uptime, metadata upload cadence, discovery credential validity, network connectivity, and source inventory drift because drift often appears later as failed releases, blocked sign-ins, missing telemetry, slow migration assessments, VM disk pressure, or poor query behavior. Use lower environments, source-controlled definitions where possible, deployment validation, monitoring, and recovery notes before changing production. Operators should know which tenant, endpoint, policy, appliance, VM, dependency, or downstream application fails first and which metric or log proves the failure. The goal is predictable recovery: detect Discovery appliance drift, preserve service, restore safely, and explain the incident without guessing.
Performance
Performance for Discovery appliance depends on workload shape, service limits, data volume, network path, diagnostic destination, policy evaluation, disk throughput, trace sampling, SQL distribution, and the monitoring path used to confirm success. Review metadata collection cadence, dependency mapping volume, source environment scale, upload throughput, and assessment refresh time before increasing capacity or retrying blindly. The better fix might be correcting access scope, reducing log noise, improving discovery cadence, choosing a different disk SKU, tuning trace collection, or changing table distribution. Measure under representative production conditions. Operators should connect symptoms to evidence: latency, throttling, backlog, failed operations, dropped logs, skew, or stale state.
Operations
Operations for Discovery appliance should focus on ownership, observability, and safe repeatability. Standardize names, tags, owner groups, environment labels, diagnostic destinations, runbook links, approval records, and change windows so support teams do not reverse-engineer the platform during incidents. Use read-only CLI, API, policy, diagnostic, or portal checks first, then compare live state with intended configuration. For production, connect alerts, audit events, cost records, graph links, and release notes to the same term. The support question should be simple: who owns it, what changed, and what proves the current state?. Capture owner, scope, evidence, and recovery procedure before changing Discovery appliance in a production environment.

Common mistakes

  • Changing production before checking the exact Azure scope, owner, identity, dependency, and rollback or recovery procedure.
  • Treating a portal screenshot as sufficient evidence when CLI output, Activity Logs, diagnostics, and source-controlled configuration are repeatable.
  • Assuming a name match proves the correct resource when tenants, subscriptions, disks, storage accounts, workspaces, and SQL pools can look similar.