Migration Discovery and assessment premium

Discovery appliance

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.

Back to glossary browser Open Microsoft Learn source
Aliases
Azure Migrate appliance, migration discovery appliance, assessment appliance, server discovery appliance
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-13

Microsoft Learn

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

Microsoft Learn: Azure Migrate appliance2026-05-13

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.

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.

Where you see it

Signals, screens, and Azure surfaces where this term usually becomes operational.

Signal 01

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.

Signal 02

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.

Signal 03

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.

When this becomes relevant

Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.

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

Real-world case studies

Different enterprise-style examples that show the term being used to hit measurable objectives.

Case study 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.

Business/Technical Objectives
  • Discover 600 on-premises servers
  • Group workloads into migration waves
  • Reduce over-provisioned Azure VM estimates by 25 percent
Solution 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.

Results & Business Impact
  • 642 servers were discovered and classified
  • Projected VM spend fell 31 percent after right-sizing
  • First migration wave completed without dependency surprises
Key Takeaway for Glossary Readers

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

Case study 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.

Business/Technical Objectives
  • Collect server metadata without broad admin exposure
  • Protect discovery credentials and project keys
  • Produce auditable assessment evidence
Solution 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.

Results & Business Impact
  • Clinical server discovery completed within the approved security model
  • Credential exceptions were reduced to zero
  • Assessment signoff finished two weeks earlier than planned
Key Takeaway for Glossary Readers

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

Case study 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.

Business/Technical Objectives
  • Find missing servers before wave planning
  • Improve assessment refresh reliability
  • Reduce migration replanning meetings by 50 percent
Solution 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.

Results & Business Impact
  • Missing server count fell from 87 to 9
  • Assessment refresh reliability improved to 96 percent
  • Weekly replanning meetings were cut in half
Key Takeaway for Glossary Readers

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

Why use Azure CLI for this?

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.

CLI use cases

  • 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 CLI

  • 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 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 Azure CLI commands

Discovery appliance operational checks

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

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.