Evaluate On-Premises Servers, Data, and Applications for Migration — Lesson

A large international retail bank in Frankfurt starts its Azure migration confidently. The team picks ten "obvious" lift-and-shift candidates from a spreadsheet of 800 VMs and migrates the first one. It comes up fine in Azure but a downstream payment system breaks immediately — nobody knew the migrated VM was its database. Two weeks of firefighting later, the team realises the spreadsheet was last updated 30 months ago, and roughly 40% of the entries are either wrong, missing, or pointing to decommissioned hardware. They reset the plan, deploy the Azure Migrate appliance, and let it discover and dependency-map the estate over the next 30 days. The next ten migrations land cleanly because every VM's dependencies are now visible. This lesson is about doing that assessment work first — using Azure Migrate, Data Migration Assistant, SQL Server Migration Assistant, and dependency mapping — so that the migration plan is built on what the estate actually is, not what the spreadsheet says it was.

We will work through Azure's assessment story the way the AZ-305 exam expects you to: choosing among Azure Migrate (Server, Database, Web App, SQL assessments), the Data Migration Assistant (DMA), SQL Server Migration Assistant (SSMA), and using dependency mapping to discover hidden coupling. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill 4.3 on migrations, and Microsoft Learn on Azure Migrate.

Why This Matters

Assessment is the cheapest insurance any migration buys, and the easiest one to short-change under deadline pressure. A 30-day assessment costs almost nothing relative to migrating blind and discovering surprises in production. The AZ-305 exam tests this LO because architects routinely under-invest in assessment — partly because it doesn't produce visible "progress", partly because the spreadsheet looks adequate. Done right, assessment produces a sized, prioritised, dependency-aware migration plan that survives contact with reality on day 1 of cutover and every day after that.

The career payoff is concrete: every migration scoping conversation, every "we discovered a hidden dependency" post-mortem, every regulator's question about "did you assess each workload?", every cost-overrun root-cause analysis, and every post-migration optimisation review touches assessment. If you can match a workload type — Windows VM, Linux VM, SQL Server, web app, file share, SAP — to the right assessment tool and configure dependency mapping correctly, you will pass this slice of the exam and lead assessment work like a senior architect, turning a list of 800 VMs in a spreadsheet into an actionable migration plan with sequenced waves, evidence-based sizing, and known dependency closures.

Prerequisites

Before working through this lesson, make sure you can answer each prompt below in one or two sentences.

• VM sizing. Can you map a 4 vCPU / 16 GB Windows VM on-prem to an Azure VM SKU? — Self-check: which family is general-purpose?
• SQL Server compatibility levels. Are you familiar with versions / compatibility levels? — Self-check: which Azure target accepts the widest set of features?
• Network bandwidth basics. Can you estimate the bandwidth needed to replicate a 500 GB VM in 24 hours? — Self-check: roughly what Mbps is that?
• Dependencies. Do you know how application dependencies cause hidden failures? — Self-check: name three categories of dependency.
• Assessment methodology. Have you seen the typical TCO and "Azure readiness" reports? — Self-check: which one quantifies cost?

If any of these feels shaky, pause and review the migration-assessment intro in Unit 4 of the AZ-305 guide before continuing with this lesson.

Learning Objectives

By the end of this lesson, you will be able to:

1. Analyse an on-prem estate and translate it to an assessment scope (which inventory tool to use, which workloads to assess first).
2. Evaluate trade-offs between Azure Migrate server/database/web/SQL assessments, Data Migration Assistant, SQL Server Migration Assistant.
3. Design a dependency-mapping deployment (agent-based vs agentless) and read its output.
4. Recommend the right Azure target (VM, Managed Instance, Azure SQL DB, App Service, AKS) for each assessed workload based on compatibility findings.
5. Recognise anti-patterns — spreadsheet-only assessment, skipping dependency mapping, sizing without right-sizing, missing baseline window — and rewrite them.
6. Interpret an Azure Migrate readiness report (Ready / Conditionally Ready / Not Ready / Unknown) and act on each category.

Building Blocks

Read this section as a glossary. Each term: analogy, formal definition, why it matters.

Azure Migrate — Azure's hub-and-spoke assessment service. Like a survey crew that walks your estate before you move house. Formally, Microsoft.Migrate/migrateProjects plus an on-prem appliance VM that discovers and dependency-maps. Modules: Server Assessment, Database Assessment, Web App Assessment, SQL Assessment. It matters because Azure Migrate is the canonical Microsoft-recommended assessment tool — exam questions on this LO route to it.

Azure Migrate appliance — A virtual appliance you deploy on-prem (VMware OVA, Hyper-V VHD, or physical). Formally, a Windows Server VM that runs discovery, performance collection, agentless dependency mapping (via vCenter API or PowerShell), and posts findings to Azure Migrate. It matters because the appliance is the single point of integration with the on-prem environment.

Agentless dependency mapping — Dependency discovery without installing software on each server. Formally, the appliance uses vCenter / Hyper-V management APIs to capture network connections. Available for 30 days per assessment by default. It matters because agentless is the path of least resistance — no per-server agent install.

Agent-based dependency mapping — Dependency discovery via the Microsoft Monitoring Agent / Azure Monitor Agent installed on each server. Formally, agents send connection telemetry to a Log Analytics workspace, queryable for any time range. Persistent until you remove agents. It matters when agentless is not feasible (physical servers, non-vCenter VMware, time windows longer than 30 days).

Data Migration Assistant (DMA) — A downloadable Windows app for SQL Server assessment and migration. Formally, runs against an on-prem SQL Server, produces a compatibility report (deprecated features, blocking issues, recommended fix-ups) per target (Azure SQL DB / MI / SQL on VM). It matters because DMA is the canonical "what is incompatible if I move this SQL Server?" tool — paired with Azure Migrate's SQL Assessment for at-scale assessment.

SQL Server Migration Assistant (SSMA) — A downloadable tool for migrating non-Microsoft databases (Oracle, MySQL, Postgres, DB2, Access, Sybase) to SQL Server / Azure SQL. Formally, performs schema conversion, code translation (e.g., PL/SQL $\to$ T-SQL), and data migration. It matters because moving from Oracle / DB2 to Azure SQL is a common scenario the exam tests, and SSMA is the supported path.

Server readiness category — Azure Migrate's classification for each assessed server. Four values: Ready, Conditionally Ready (fixable issues), Not Ready, Readiness Unknown (data incomplete). It matters because the migration plan should sequence Ready servers first while remediating Conditional ones in parallel.

TCO assessment — A cost comparison of running the estate on-prem vs in Azure, factoring in hardware refresh, licensing, OPEX, and Azure pricing. Formally, an Azure Migrate output that takes the sized-for-Azure recommendations and computes monthly cost. It matters because the TCO is the input to the business case in CAF's Strategy phase.

Right-sizing — Sizing a target VM based on observed performance (CPU/memory utilisation over time) rather than provisioned size. Formally, Azure Migrate offers "as-on-prem" sizing (match the source) and "performance-based" sizing (recommend the smallest Azure SKU that handles the workload at 95th-percentile utilisation). It matters because performance-based sizing usually cuts cost by $30{-}50\%$.

Baseline window — The performance-collection period used for right-sizing. Default 1 day, configurable up to 31 days. It matters because a too-short window misses month-end batch peaks; a sensible default is $14{-}31$ days to capture cyclical load.

Deep Dive

1. Assessment tools — pick by workload type

[!TIP] Run Server Assessment for every VM; run SQL Assessment for every SQL instance; run DMA per-database for compatibility detail. The three together give you the full picture for Microsoft-stack workloads.

2. The Azure Migrate appliance — discovery to assessment

The appliance is a single VM deployed in the on-prem environment. It connects to vCenter / Hyper-V / physical inventory via supplied credentials, walks the inventory continuously, collects performance counters every minute, and uploads anonymised summaries to Azure Migrate. The migration team then runs assessments against the discovered inventory.

[!IMPORTANT] The appliance requires outbound HTTPS to *.migration.windowsazure.com and other Microsoft endpoints. In air-gapped or proxy environments, configure the appliance to use the corporate proxy or deploy Azure Arc-enabled servers as an alternative discovery path.

3. Dependency mapping — finding the hidden coupling

Dependency mapping answers "what talks to what?". Without it, migrating a VM in isolation breaks dependent systems. Azure Migrate offers two modes:

The agentless mode is recommended for first-pass discovery; switch to agent-based for workloads needing detailed process-level dependency or for longer windows.

[!WARNING] A common assessment mistake: run dependency mapping for 24 hours and miss the weekly Sunday-night batch process that connects the migrating VM to a critical downstream service. Run dependency mapping for $\ge 14$ days, ideally a full month, to catch cyclical patterns.

4. Sizing strategies — as-on-prem vs performance-based

Azure Migrate offers two sizing strategies. The exam tests recognising the difference.

Performance-based requires at least a few days of performance collection; with a 14-day window, it typically downsizes $40{-}60\%$ of the estate.

5. Database assessment — DMA, SSMA, and Azure Migrate's SQL module

SQL Server is its own assessment universe. The exam tests the difference among the three tools:

The flow: Azure Migrate identifies which instances exist and their sizes; DMA produces compatibility detail per database (which features won't work in Azure SQL DB but will in MI); SSMA handles the foreign-RDBMS scenarios.

[!TIP] The output of DMA includes a per-target recommendation: e.g., "this database can move to Azure SQL DB with no changes" or "uses cross-database queries; needs MI or VM". Match each database to the simplest target that accommodates its features.

6. Interpreting the readiness report

Azure Migrate's assessment report classifies each workload:

[!IMPORTANT] A Conditionally Ready workload with a fixable issue (e.g., 4 TB disk needing split into two managed disks $< 4$ TB) is not the same as a Not Ready workload (e.g., Windows Server 2003). The plan must distinguish them.

7. Web app and container assessment

Azure Migrate has dedicated assessment modules for web apps and containerised workloads.

Web App Assessment discovers ASP.NET and Java web apps on Windows / Linux servers and recommends App Service SKUs with compatibility flags. Common compatibility issues: classic ASP, COM components, legacy ISAPI filters, custom IIS modules — these typically force a "lift-shift to VM" outcome rather than App Service.

App Containerization is a separate Azure Migrate feature that takes an existing ASP.NET (.NET Framework) or Java app and packages it into a container with the right base image and config, ready for AKS deployment. It is the canonical answer when the customer wants to modernise but cannot rewrite to .NET 8 on Linux.

[!NOTE] Containerising a legacy .NET Framework app preserves Windows kernel dependencies — the resulting image is a Windows container, which requires AKS Windows node pools (slightly more expensive but operationally similar to Linux node pools).

8. Cost report nuances

The TCO report computes Azure cost across several dimensions. Architects should ensure the cost basis matches reality:

• Reserved Instance assumption. Default is Pay-as-you-go. Switching to 1 or 3 year RI typically drops cost $30{-}60\%$.
• Azure Hybrid Benefit. Apply AHB if the customer has Software Assurance — typically $\sim 40\%$ off Windows licensing.
• Storage class. Default is Premium SSD; downsize to Standard SSD or HDD where workload allows.
• Currency and region. The default region's pricing may differ from the target region.

[!TIP] Generate two TCO reports: a "conservative" (PAYG, no AHB) and a "realistic" (RI + AHB). Show both to the sponsor — the conservative number is what they pay if they do nothing; the realistic is what they pay with normal optimisation.

Worked Examples

Easy — pick the assessment tool

Problem. A customer has 200 Windows VMs in VMware, 50 SQL Server instances, and 10 Oracle databases. Recommend an assessment toolchain.

Solution. Deploy Azure Migrate appliance against vCenter; run Server Assessment for the 200 VMs and SQL Assessment for the 50 SQL instances. Run DMA per SQL database for compatibility detail. Run SSMA for Oracle against each of the 10 Oracle databases to plan migration to Azure SQL MI (or to keep on Oracle on Azure VMs if the schema is too complex). Plan a 30-day discovery window.

Medium — dependency mapping recommendation

Problem. A team needs to migrate a 3-tier application: web, app, database, hosted across 20 VMs in VMware. They have no documentation of dependencies. Recommend an assessment approach.

Solution. Deploy the Azure Migrate appliance with agentless dependency mapping enabled for 30 days (the maximum agentless window). For VMs needing process-level detail or longer windows, also install the Azure Monitor Agent and centralise to a Log Analytics workspace. Use the dependency map output to identify the 3-tier coupling and any unexpected cross-app connections (e.g., a shared file-share dependency). Plan migration waves so each wave is a complete dependency-closed group.

Hard — Oracle assessment with hybrid target

Problem. A customer has 50 Oracle databases. Some are small ($< 200$ GB) with simple schemas; others are large ($> 5$ TB) with extensive PL/SQL. Compliance prevents data-out-of-region. Recommend an assessment approach.

Solution. Use SSMA for Oracle against every database to assess schema complexity, PL/SQL compatibility, and data size. The output partitions the databases into three groups:

• Convert to Azure SQL MI — small schemas with mostly portable PL/SQL.
• Stay on Oracle — large or complex schemas where conversion cost > value. Run on Azure VMs with Oracle licences (BYOL).
• Refactor — medium databases worth re-platforming to PostgreSQL Flexible Server (after schema conversion via Babelfish or manual rewrite).

Compliance: ensure SSMA's data probes stay in-region; some PII may need redaction before assessment data leaves on-prem.

Visual Explanations

Figure 1 — Assessment-tool decision flow

Figure 2 — Appliance and dependency topology

Figure 3 — Assessment artifact summary

Common Mistakes

❌ Myth: "Our CMDB inventory is enough — we don't need Azure Migrate." ✅ Reality: CMDB inventories drift; Azure Migrate is current and includes performance data, dependencies, and readiness checks the CMDB lacks. Use the CMDB as a sanity-check, not a substitute. Why it's tricky: CMDBs are venerable; teams trust them; reality bites in production.

❌ Myth: "As-on-prem sizing is safer." ✅ Reality: As-on-prem preserves over-provisioning. Performance-based sizing with a $14{+}$-day window plus comfort factor is both cheaper and reliable. Why it's tricky: "Safer" feels true; the cost gap can be $30{-}50\%$.

❌ Myth: "Skip dependency mapping — we know our apps." ✅ Reality: Every team thinks they know their apps; dependency mapping routinely surfaces $20{-}30\%$ of connections nobody documented. Why it's tricky: Confidence is high; surprises are higher.

❌ Myth: "DMA is enough — we don't need SQL Assessment." ✅ Reality: DMA is per-database detail; SQL Assessment runs at scale across the estate. Both are needed. Why it's tricky: They overlap on the surface; the at-scale dimension is unique to Azure Migrate.

Practice Exercises

🟢 Exercise 1. A team has 400 VMs on VMware. Recommend a discovery approach.

▶💡 Hint

Appliance + agentless.

▶✅ Solution

Deploy the Azure Migrate appliance OVA in the vCenter. Configure vCenter credentials. Enable agentless dependency mapping for 30 days. Collect performance counters for at least 14 days before running the assessment.

🟡 Exercise 2. A migration sponsor wants to know Azure cost for the estate. Which output do they want?

▶💡 Hint

TCO report.

▶✅ Solution

The Azure Migrate assessment includes a TCO output that estimates monthly Azure cost per workload (configurable for Pay-as-you-go, 1-year or 3-year Reserved Instance pricing, AHB, and storage class). The sponsor reviews and signs off on the business case before migration proceeds.

🟡 Exercise 3. A SQL Server 2008 instance fails the Azure SQL DB compatibility check (uses cross-database transactions). Recommend.

▶💡 Hint

MI supports cross-database.

▶✅ Solution

Target Azure SQL Managed Instance instead of single DBs. MI supports cross-database transactions, SQL Agent, CLR — features that single Azure SQL DB lacks. Re-run the DMA compatibility check against MI to confirm no further blockers. Alternative: stay on SQL Server on Azure VMs if MI compatibility issues remain.

🔴 Exercise 4. A team plans to migrate 50 VMs but their dependency mapping ran only 48 hours. Diagnose.

▶💡 Hint

48 hours misses weekly / monthly cycles.

▶✅ Solution

48 hours captures daily patterns but misses weekly batch jobs, monthly reports, quarterly closes. Extend the mapping window to at least 14 days, preferably 30 days, before finalising the migration plan. Critical workloads with quarterly cycles may need a longer window or business-stakeholder review to flag known periodic processes.

🔴 Exercise 5. An Oracle database has 200 GB and complex PL/SQL. Recommend an assessment.

▶💡 Hint

SSMA + conversion-cost estimate.

▶✅ Solution

Run SSMA for Oracle to assess schema and PL/SQL conversion complexity. The output classifies objects: convertible, convertible-with-fixes, manual-conversion-required. If conversion cost is acceptable, target Azure SQL MI. If too high, plan to lift-and-shift to Oracle on Azure VMs (BYOL licensing) and revisit conversion later.

🟢 Exercise 6. True or false: agentless dependency mapping is available in Hyper-V environments.

▶💡 Hint

Agentless mapping has a VMware caveat.

▶✅ Solution

False (with nuance). Full agentless dependency mapping (the rich, time-bounded mode) requires VMware/vCenter. Hyper-V environments rely on agent-based dependency mapping through the Azure Monitor Agent + Log Analytics. Always confirm against the current Microsoft Learn matrix.

🟡 Exercise 7. Design a 14-day assessment plan for 200 VMs in VMware with 50 SQL Servers.

▶💡 Hint

Appliance + Server + SQL + DMA.

▶✅ Solution

Day 1: deploy Azure Migrate appliance, connect to vCenter, start discovery. Days $1{-}14$: collect performance counters; enable agentless dependency mapping. Day 7: install DMA on a workstation and run compatibility scans on the SQL Servers. Day 14: run Server Assessment (performance-based sizing, 14-day window, 30% comfort factor); run SQL Assessment; review readiness categories; produce TCO; merge with DMA detail; deliver the migration plan to the sponsor.

Summary & Concept Map

• Azure Migrate is the canonical assessment tool. Appliance discovers; Server / SQL / Web App / Database assessments produce readiness reports.
• DMA is per-database compatibility detail; SSMA migrates non-Microsoft databases to Azure SQL.
• Dependency mapping is essential. Agentless for VMware (up to 30 days); agent-based for everything else.
• Performance-based sizing beats as-on-prem in most cases. Use a 14-to-31-day window.
• Readiness categories drive the wave plan. Ready first, Conditionally Ready in parallel, Not Ready rebuilt or retired.
• Spreadsheet inventories are not enough. They drift; Azure Migrate is current.