Discovering and Assessing at Scale with Azure Migrate

Large‑estate discovery usually starts with good intent and ends with a SharePoint folder no one wants to open.

Thousands of VMs. Hundreds of charts. Confidence scores everywhere.
And yet, no clearer answer to what should we migrate next or what’s safe to commit to.

Azure Migrate doesn’t struggle with scale because it can’t see enough.
It struggles because teams ask it to answer questions it was never designed to decide.

The Mental Model

Common assumption:

“If we discover everything thoroughly enough, the migration plan will reveal itself.”

Why it breaks:
Discovery creates evidence, not decisions. Azure Migrate describes the estate you pointed it at, faithfully and at volume, but it has no understanding of ownership, risk tolerance, political constraints, or deadlines.

At scale, more data without sharper intent doesn’t increase confidence.
It delays commitment.

The real skill is not discovering more.
It’s discovering just enough to make the next irreversible decision.

How It Really Works

Azure Migrate is best thought of as a distributed observation system with an opinionated reporting layer.

Appliances observe compute, storage, and performance signals
That data is normalised into Azure’s internal inventory model
Assessments apply assumptions to project Azure targets and costs

Those last two words matter: apply assumptions.

flowchart LR A[On‑prem / Other Clouds] --> B[Azure Migrate Appliances] B --> C[Observed Signals] C --> D[Assessment Assumptions] D --> E[Reports & Recommendations]

What Azure Migrate produces is not truth, it’s a scenario.
And scenarios are only as good as the questions they were built to answer.

Real‑World Impact

Design

Large, undifferentiated assessments push architects toward “average‑based” designs.
Averages erase the very workloads that drive platform decisions: spiky usage, licence‑bound systems, and business‑critical outliers.

If everything is assessed together, everything gets designed the same.

Reliability

Short or patchy performance histories create a dangerous illusion: high confidence with low representativeness. Month‑end, seasonal, and failure‑mode behaviour is routinely absent and rarely noticed until production.

Cost

The most over‑trusted output in Azure Migrate is right‑sized VM recommendations.

They are not wrong, they are conditional. Treating them as commitments rather than lower‑bound scenarios is how migration business cases quietly fall apart six months later.

Security

Discovery almost always surfaces forgotten systems.
That’s not just migration debt, it’s an exposure report you didn’t know you were running.

Implementation Examples

1. Scope Discovery to Force Thinking

Discovery boundaries should reflect decision boundaries, not network convenience.

Common scoping dimensions that actually matter:

Business domain or cost centre
Environment class (prod vs non‑prod)
Regulatory or data sensitivity zones

Creating multiple Azure Migrate projects is not overhead it prevents cross‑contamination of assumptions.

1
2
3
4
az migrate project create \
  --resource-group rg-migrate-finance \
  --name finance-migrate \
  --location australiaeast

If a group can’t explain why it shares a project, it probably shouldn’t share an assessment.

2. Use Assessments as Explicit Scenarios

Every assessment should answer a single, named question.

Examples:

“What’s the cost floor if we lift‑and‑shift Finance prod with no licence benefits?”
“What breaks if we assume 30% performance headroom instead of 50%?”

Encode those assumptions directly in assessment naming. Treat them as disposable models, not artefacts to defend.

If an assessment can’t be deleted without an argument, you’ve already over‑invested.

3. Translate Assets into Decision‑Ready Groups

Azure Migrate discovers assets. Migration requires cohorts.

The translation step is where most programmes stall because it’s organisational, not technical.

graph TD A[Discovered Inventory] --> B[Technical Filters] B --> C[Ownership & Risk Context] C --> D[Migration Cohorts]

Cohorts exist to enable decisions:

Can this move independently?
Who signs off the risk?
What failure is acceptable?

If those answers aren’t obvious, the grouping is wrong.

Gotchas & Edge Cases

Discovery without ownership leads to politically unusable data.
<30 days of history systematically under‑represents risk.
Disconnected networks fail silently, missing systems look like “clean estates”.
Assessment confidence scores measure data completeness, not decision safety.

Best Practices

Define the next decision before deploying an appliance.
Stop discovery once that decision can be made, even if coverage isn’t “perfect”.
Treat right‑sizing outputs as a floor, not a promise.
Use missing or inconsistent data as a risk signal, not something to smooth over.
Delete assessments aggressively; keep only those tied to active decisions.

🍺

Brewed Insight: Azure Migrate is excellent at telling you what you pointed it at.
The real architecture work is deciding when you’ve seen enough to move and having the discipline to stop looking.