Design Migrations — Topic Lesson

This lesson covers five core learning objectives for the AZ-305 exam migration pillar. You will learn to architect migration strategies using the Cloud Adoption Framework, evaluate on-premises workloads for cloud readiness, migrate infrastructure and platform services to Azure, design database migration patterns, and plan unstructured data transfers to Azure using native Microsoft services. Each objective is grounded in Azure's native migration tools and aligned with the Well-Architected Framework principles of cost optimization, operational excellence, and security.

Reference: Ch. 4, §4.3, p. 158–165 of the AZ-305 exam book.

Why This Matters

Cloud migration is the fastest-growing enterprise workload in Azure deployments. Organizations migrating from on-premises datacenters face a critical trilemma: minimize business disruption, control costs, and ensure compliance throughout the migration journey. Poorly planned migrations cause budget overruns exceeding 30 percent, extended downtime windows lasting hours or days, and data loss in the worst cases. This lesson teaches you to make defensible architectural decisions—from choosing rehost versus re-platform strategies—using Azure's native tools. A structured migration strategy rooted in the Cloud Adoption Framework reduces risk, prevents scope creep, and enables organizations to capture 25 to 40 percent cost savings within 2 years of cloud adoption.

Prerequisites

• Familiarity with Azure compute services (Virtual Machines, App Service), storage tiers (Blob, Files, Table), and networking (Virtual Networks, Network Security Groups) fundamentals
• Understanding that this lesson builds on foundational Azure concepts covered in AZ-900 and AZ-104 exams
• Understanding of on-premises infrastructure components: hypervisors (VMware vSphere, Hyper-V), relational databases (SQL Server), file servers (SMB shares and NFS), and legacy application architectures
• Awareness of Azure subscriptions, resource groups, role-based access control (RBAC), and identity management concepts
• Basic knowledge of infrastructure-as-code patterns and Azure service naming conventions

Learning Objectives

Upon completing this lesson, you will be able to:

1. Design migration strategies using Cloud Adoption Framework phases (Strategy → Plan → Ready → Adopt → Govern → Manage) and articulate clear business drivers, realistic timelines, and governance models aligned with organizational priorities
2. Evaluate workloads for cloud readiness using Azure Migrate Hub, Server Assessment tools, dependency mapping analysis, and Total Cost of Ownership (TCO) modeling to predict cloud costs accurately
3. Migrate infrastructure and platform services using Azure Migrate: Server Migration for agentless replication, Site Recovery for advanced scenarios, and App Service Migration Assistant to achieve minimal downtime and rapid modernization
4. Design database migration patterns using DMS (offline and online modes), SQL Managed Instance for compatibility, Azure SQL Database for modernization, PostgreSQL/MySQL for open-source workloads, and Cosmos DB for global scale
5. Plan unstructured data migrations using Storage Migration Service for incremental syncs, Data Box family for bulk transfers, AzCopy for CLI-driven transfers, and Azure File Sync for hybrid access and cloud-tiering

Building Blocks

Building blocks are foundational concepts and services that enable successful cloud migration. Understanding these deeply helps architects make sound design choices throughout the migration journey.

Cloud Adoption Framework (CAF) — Think of CAF as a complete blueprint for enterprise-scale migration encompassing governance, organizational structure, and process discipline. CAF is Microsoft's structured model spanning six interconnected phases: Strategy (defining business case and ROI targets), Plan (comprehensive inventory and prioritization), Ready (landing zone pre-configuration and policy setup), Adopt (wave-based execution), Govern (ongoing policy enforcement), and Manage (steady-state operations and optimization). Why it matters: Organizations following CAF reduce rework by 30 percent, minimize compliance violations, accelerate time-to-value, and establish reusable governance patterns across multiple business units.

Azure Migrate Hub — Imagine a central command and control center orchestrating all discovery, assessment, and migration planning activities across your enterprise. Azure Migrate Hub aggregates server inventory, database catalogs, web application metadata, and detailed dependency maps from appliance-based discovery running in your on-premises datacenters. It feeds validated data to downstream tools: the TCO Calculator for cost projections and to migration tools for execution. Why it matters: Eliminates information silos between teams, prevents duplicate assessments, ensures consistent prioritization across stakeholders, and provides a single source of truth for migration planning.

Rehost, re-platform, refactor migration strategies — These three primary approaches represent increasing levels of cloud optimization. Rehost (lift-and-shift) moves VMs unchanged to Azure, preserving the original OS, applications, and configuration; it is fastest (weeks) but leaves 10 to 15 percent of cost savings untapped. Re-platform adds OS or database layer upgrades while keeping application code mostly intact; it takes longer (weeks to months) but captures 20 to 30 percent savings. Refactor completely rebuilds applications on cloud-native patterns (containers, serverless, microservices); it is slowest (months) but achieves 40 to 60 percent savings. Why it matters: Choosing the right strategy balances business urgency against cost optimization potential and risk tolerance.

Database Migration Service (DMS) — DMS is Azure's dedicated orchestration platform for both offline migrations (one-time transfer with brief maintenance window) and online migrations (continuous replication with minimal downtime) for SQL Server, PostgreSQL, MySQL, and MongoDB to their corresponding Azure managed services. Online migrations use binary log replication to synchronize data continuously; cutover is a matter of minutes once validation completes. Why it matters: Enables near-zero-downtime migrations for mission-critical databases, reducing business impact during system transitions and allowing incremental validation.

Data Box family of appliances — Physical, sealed appliances designed for bulk data transfer when network is constrained or dataset is massive: Data Box Disk ($40 per order, 40 TB capacity), Data Box ($4,000, 100 TB), and Data Box Heavy ($10,000, 1 PB). Customers physically ship appliances to Microsoft datacenters where engineers ingest data into Blob Storage, Data Lake, or other Azure services. Useful for migrations exceeding 100 TB or organizations with limited bandwidth (under 10 Mbps). Why it matters: Avoids months-long network uploads, provides predictable transfer timelines, and offers cost-effective pricing for large-scale data movement.

Landing zone architecture — A landing zone is a pre-built, governance-enabled Azure subscription architecture that serves as the foundation for workload deployment. Pre-configured with networking (hub-spoke topology or virtual WAN), Azure Policy assignments enforcing governance rules, identity and access management, and cost allocation tags. CAF Ready phase builds these. Landing zones accelerate workload onboarding by weeks. Why it matters: Eliminates ad-hoc resource creation, reduces misconfiguration risk, enforces compliance from day one, and enables rapid scaling across multiple business units.

[!IMPORTANT] The choice between CAF phases, assessment depth, and migration strategy directly impacts project success and cost outcomes. Organizations that skip Planning phase typically face 30 percent cost overruns; those that skip Ready phase encounter governance violations within 90 days. Conversely, organizations investing in proper governance (Strategy, Plan, Ready) before Adopt typically achieve 3-5x faster deployment in subsequent waves and capture 40 percent cost savings.

Deep Dive

LO40: Cloud Adoption Framework Strategy & Planning Phases

The CAF begins with the Strategy phase, where organizational leadership articulates the business case for migration: Is it cost reduction (CapEx to OpEx), agility and time-to-market, compliance and regulatory alignment, support for innovation, or workforce flexibility? A clear strategy statement might read: "Reduce annual infrastructure spend by 30 percent while enabling global disaster recovery and supporting rapid application deployment within 18 months." Without explicit strategy articulation, migrations drift, accumulate scope creep, and fail to deliver expected ROI.

The Plan phase follows logically. Teams conduct a comprehensive digital estate assessment: cataloging all servers (operating systems, CPU, RAM, disk, software inventory), databases (type, size, complexity), applications, and unstructured data repositories. Azure Migrate Hub automates discovery using lightweight appliances deployed as VMs in your vSphere or Hyper-V environments. Appliances scan networks continuously, discovering new resources, and forwarding metadata to the Hub.

TCO Calculator projects realistic 3-year cost comparisons. On-premises costs include capital expenditures (hardware refresh cycles), operational costs (power, cooling, facilities), and labor (database administrators, systems administrators, compliance teams). Azure costs include compute (pay-as-you-go or reserved instances), storage (tiering to cool/archive saves 60-80 percent for infrequently accessed data), networking (egress charges, inter-region replication), and licensing (SQL Server CAL costs, Windows licensing under Azure Hybrid Benefit). A realistic TCO typically shows cost parity or Azure advantage within 2 to 3 years, with significant savings beyond that.

Ready phase builds landing zones. Pre-configured subscriptions include networked virtual networks (hub-spoke topology for hub-and-spoke networks, or virtual WAN for larger enterprises), Azure Policy assignments enforcing governance rules ("all virtual machines must have backup enabled", "all storage must use encryption at rest"), and identity setup (Microsoft Entra ID integration, RBAC bindings). This prevents teams from spinning up insecure or non-compliant resources.

Adopt executes migration in waves. Wave 1 targets non-production systems and lower-risk workloads for process validation. Wave 2 migrates tier-2 business applications. Wave 3 handles mission-critical systems with highest availability requirements. Each wave validates cutover procedures, tests rollback scenarios, and refines runbooks based on lessons learned. Typical Adopt timelines span 3 to 12 months depending on portfolio size, complexity, and organizational change capacity.

Govern enforces post-migration policies. Cost controls (budget alerts, reserved instance optimization) prevent runaway spending. Backup policies (RPO targets of hours, RTO targets of minutes) ensure data protection and compliance. Security baselines mandate encryption, network isolation, and access logging. Change management procedures and deployment approvals prevent unauthorized modifications. Manage is steady-state: monitoring via Azure Monitor, patching schedules aligned with compliance requirements, cost optimization using Advisor recommendations, and disaster recovery drills performed quarterly. Steady-state management also includes rightsizing reviews (identifying over-provisioned resources quarterly) and capacity planning (predicting growth and reserving capacity).

[!TIP] Use the Azure Cloud Adoption Framework Assessment Tool to evaluate your organization's readiness across Technology (tools and capabilities), People (skills and roles), and Process (governance and change management). Results inform realistic timelines and resource requirements.

LO41: Assessment & Evaluation Using Azure Migrate Hub

Azure Migrate Hub is your central discovery and assessment platform. Appliances (lightweight VMs typically sized at 2 vCPU, 4 GB RAM) deployed in vSphere, Hyper-V, or physical datacenters scan networks for servers, databases, and web applications. Appliances collect metadata: CPU core count and utilization, RAM size and utilization, disk capacity and I/O patterns, operating system and version, installed software and versions, and network connections (MAC addresses, IP addresses, gateway configuration).

Server Assessment analyzes this metadata and recommends appropriate Azure VM SKUs. It reports readiness status: "Ready" (can migrate without modification), "Conditionally ready" (requires OS upgrade or driver support), or "Not ready" (unsupported OS or proprietary hardware with no cloud equivalent). Suggested SKUs are right-sized based on actual utilization patterns. A server with 4 vCPU and 16 GB RAM configured on-premises but showing 20 percent average CPU and 60 percent RAM utilization typically right-sizes to 2 vCPU and 8 GB SKUs—reducing costs by 50 percent immediately.

Dependency mapping reveals inter-server communication patterns. Agent-based mapping deploys lightweight agents on source servers to monitor network traffic, identifying which servers communicate with which over what protocols. Agentless mapping (for VMware) sniffs network traffic without agent deployment. This mapping is absolutely critical for grouping related workloads into coherent migration waves. Unmapped dependencies cause application outages post-cutover when a web tier server depends on a database server that hasn't been migrated yet.

TCO Calculator imports assessment results and models realistic 3-year cost comparisons. Sophisticated models account for on-premises hardware refresh cycles (replacing servers every 3-5 years), power consumption (measuring in watts per server), cooling costs (data center power distribution efficiency), facility costs (square footage in expensive real estate), and labor costs (domain expertise commands premium salaries). Azure costs include compute (varying by SKU and region), storage (tiering provides significant savings), outbound bandwidth, and license conversions. Results project cost payback periods (typically 18 to 36 months) and long-term savings potential.

[!NOTE] Underestimating on-premises operational costs is the leading cause of inaccurate TCO models. Include realistic labor costs: database administrators ($100–150k salary), systems administrators ($80–120k), and compliance/security staff. These costs often exceed hardware costs over 3 years.

LO42: IaaS & PaaS Migrations Using Azure Migrate & Site Recovery

Azure Migrate: Server Migration replicates on-premises VMs to Azure with minimal downtime. Agentless replication (for VMware vSphere and Hyper-V hosts) snapshots VM disks at the hypervisor level—this approach is fast, requires no changes to source VMs, and completes in hours for typical environments. Agent-based replication (for physical servers and edge cases) deploys a lightweight mobility agent to each VM, enabling push replication from the source. Both methods produce periodic checkpoints: incremental snapshots captured every few hours. Final cutover stops the source VM, performs one final incremental sync (typically under 1 minute), and starts the target Azure VM. Total downtime: 1 to 5 minutes.

Azure Site Recovery provides continuous replication and test failover capability. It excels when you need ongoing disaster recovery capability after migration: Site Recovery maintains a continuously-updated replica in a secondary region, enabling rapid failover if primary region fails. ASR supports more source types (Hyper-V on-premises, VMware, physical servers, even Azure-to-Azure replication). It enables test failovers (running a temporary VM clone to validate failover procedures) without disrupting production replication.

App Service Migration Assistant scans IIS web applications running on Windows Server and rates Azure App Service compatibility. For compatible .NET applications, it can automate migration to App Service. For legacy applications (VB6, COBOL) or complex custom integrations, it identifies required refactoring. Container migration (packaging applications as Docker images, deploying to Azure Container Instances or Azure Kubernetes Service) may be necessary for unsuitable candidates.

Here is a PowerShell example for configuring Database Migration Service:

Here is an Azure CLI example for initiating server migration:

LO43: Database Migrations with DMS & Managed Services

Database migrations are among the most complex and risky migration tasks. A database outage can impact the entire business; data loss is catastrophic. This section covers the services and strategies for safely migrating enterprise databases.

Azure Database Migration Service handles offline and online migrations for enterprise databases. Offline migrations have a brief maintenance window (typically hours); data transfers in one pass, then applications redirect to Azure. Online migrations use continuous replication (binary log streaming) so applications see zero downtime: DMS continuously syncs data while applications keep running on-premises. Online mode is preferred for production systems but requires careful coordination during final cutover.

SQL Managed Instance is a managed database engine offering near-100 percent on-premises SQL Server compatibility: CLR functions (C# in SQL), SQL Agent jobs (scheduled tasks), replication, and complex stored procedures all work unchanged. Use SQL MI for lift-and-shift migrations of complex SQL Server workloads. Typical annual cost: $3,000 for a 4-vCore instance. Best for: legacy SQL Server 2005 and later, mixed workloads with custom features.

Azure SQL Database requires schema refactoring (no CLR, limited SQL Agent support) but offers dramatically lower cost (~$500 per year for basic tier) and built-in high availability with automatic failover to a secondary replica. Best for: new cloud applications, simplified schemas, cost-sensitive projects, compliance requirements.

PostgreSQL and MySQL migrations use DMS in online mode with schema conversion via Azure Database Migration Assistant (ADMA). ADMA automatically translates on-premises stored procedures, triggers, and functions to cloud-compatible equivalents. PostgreSQL compatibility is 95 percent, MySQL compatibility is 90 percent across most workloads.

Cosmos DB (NoSQL) accepts migrations from MongoDB and other document databases. Cosmos DB enables global distribution (replication across world regions), automatic failover, and high throughput, but requires application refactoring: Cosmos DB uses eventual consistency (not strong consistency), doesn't support joins (normalize data differently), and charges based on provisioned throughput.

Here is a Bicep template for provisioning a Database Migration Service:

LO44: Unstructured Data Migration Services

Storage Migration Service is Azure's native tool for migrating SMB file shares and NFS exports to Azure Files and Azure Blob Storage. It handles permission mapping (translating on-premises ACLs to Azure RBAC), quota enforcement (matching on-premises share quotas), and incremental sync (resumes interrupted transfers automatically). Zero-downtime migration is possible via dual-mounting: servers access on-premises share while sync runs in background, then DNS switches to Azure.

Data Box Disk (40 TB per order) is a portable USB-connected SSD array suitable for smaller migrations (< 100 TB). Data Box (100 TB per appliance) is a sealed physical appliance; Data Box Heavy (1 PB capacity) for massive transfers exceeding petabyte scale. Customers ship appliances back to Microsoft datacenters where engineers ingest data into Blob Storage or Azure Data Lake. Timeline is dominated by physical transport (typically 2 weeks), not data capacity: shipping data takes days; network transfer would take months.

AzCopy is the command-line tool for asynchronous, resumable transfers. It is free and suitable for transfers under 100 TB. AzCopy supports various source/destination pairs: on-premises files to Blob, Azure Files to Azure Files (cross-region replication), and Blob to Blob. It is particularly useful for incremental syncs: you can run AzCopy daily to sync changes without re-transferring unchanged files.

Azure File Sync mirrors on-premises SMB file shares to Azure Files with optional cloud-tiering. Files not accessed within a configurable period (default 30 days) automatically move to cool tier, reducing on-premises NAS capacity requirements by 60 percent while maintaining local access speed for frequently-used files. Ideal for shared network drives with variable access patterns (archival folders mixed with active projects).

Worked Examples

Worked examples illustrate how to apply the five learning objectives to realistic business scenarios. Each example spans multiple learning objectives and includes the decision-making process teams follow during real migrations.

Example 1 (Easy): Assess a 50-VM VMware Estate for Migration Readiness

A manufacturing company runs 50 Windows Server VMs and 5 Linux VMs in VMware vSphere. Initial goal: understand cloud readiness and cost implications before executive decision gate.

Approach: Deploy Azure Migrate appliance (small VM in vSphere, 2 vCPU, 4 GB RAM). Configure it to discover the vCenter cluster. Migrate Hub scans all 55 VMs, collecting CPU, RAM, disk, and OS metadata. Server Assessment recommends D4s_v3 for typical Windows Server VMs (4 vCPU, 16 GB RAM, $221/month), B2s for light Linux VMs (1 vCPU, 2 GB RAM, $37/month). Assessment flags 5 VMs as "conditionally ready" (require OS updates before migration).

TCO Calculator imports assessments and projects 3-year costs. On-premises annual spend: $180,000 (hardware refresh cycles, power for 55 VMs, cooling infrastructure, 1.5 FTE staff). Azure 3-year cost: $380,000 (compute: $216k, storage:$90k, licenses: $74k). Break-even point: 2.5 years. Identify 10 IIS applications suitable for App Service re-platforming (saves $50/month each = $6,000/year). Final ROI analysis shows strong business case.

Outcome: Executive board approves phased migration; IT roadmap established with 6-month Adopt phase starting Q3. Wave 1: non-production (2 months). Wave 2: tier-2 applications (2 months). Wave 3: critical systems (2 months). Total: 6 months from first cutover to final production migration.

Example 2 (Medium): Migrate SQL Server 2019 Database with Online Replication

A financial services firm hosts a mission-critical 500 GB SQL Server 2019 database on-premises with scheduled batch jobs (using SQL Agent) running nightly. Goal: migrate to Azure with zero downtime, maintaining transaction consistency.

Approach: Select DMS online migration mode (continuous replication). Provision Azure SQL Managed Instance (4 vCore) in the landing zone subnet with appropriate network connectivity. DMS creates source connection (on-premises SQL Server), target connection (SQL MI), and initiates continuous binary log replication. Replication begins streaming changes from source to target in real-time.

Validation phase: run DBCC consistency checks, compare row counts between source and target, verify login mappings (translate on-premises domain accounts to SQL MI logins), test SQL Agent job migration. Performance testing: confirm query latency on SQL MI matches or exceeds on-premises baseline.

Test failover: redirect application connection string to SQL MI for 1 hour production traffic (real users, real transactions). Monitor query performance, SQL Agent job execution, and backup completion. Confirm no data loss or transaction failures. After successful test, failback to on-premises SQL Server to preserve current production.

Cutover day: pause SQL Agent batch jobs (final writes stop), execute final DMS sync to capture any changes (typically 10 seconds), redirect live application traffic to SQL MI, verify transaction processing resumes normally. Monitor for 4 hours before marking migration complete. Rollback plan: if critical issues emerge within 6 hours, DMS supports reverse direction (failover back to on-premises) while maintaining data consistency.

Timeline: 3 days setup and validation, 2 weeks continuous replication in background, 1 day cutover window. Total production downtime: 5 minutes (batch job pause to connection string update).

Example 3 (Hard): 200 TB File Share Migration with Hybrid Access & Tiering

A retail company hosts a 200 TB SMB file share on-premises serving 200 concurrent users. Goals: migrate to Azure Files, enable access from cloud-connected offices, reduce on-premises storage footprint by 60 percent via cloud-tiering.

Approach: Order Data Box Heavy appliance (1 PB capacity, $10,000). In parallel, configure Storage Migration Service on-premises with a proxy server to mirror the share to Azure Files Premium (SMB protocol). Data Box ships and arrives at company datacenter in 2 days. Operations team loads 200 TB of data onto the appliance over 1 week (parallel to migration proxy activity). Ship appliance back to Microsoft; physical transport takes 2 weeks. Microsoft ingests 200 TB into Azure Files Premium in the target subscription.

During parallel phases: Migration Service proxy continuously syncs 200 TB of data to Azure Files. Changes made on-premises (new files, modifications) automatically sync to Azure. Progress tracking shows completion percentage increasing daily.

Test failover phase: temporarily reconfigure DNS to resolve the file share name to Azure Files endpoint. 200 users connect from cloud-connected offices. Monitor latency (target: <100 ms), validate permissions inheritance (on-premises ACLs translated to Azure RBAC), confirm performance meets baseline (typical file operations: open, read, save complete in <1 second). Run this for 2 hours without disrupting production.

Cutover: Set on-premises share to read-only (create snapshot for archival). Update DNS permanently to Azure Files. Enable cloud-tiering: files not accessed in 30 days auto-tier to cool tier, reducing hot tier usage by 60%. Monitor for 24 hours post-cutover. Archive on-premises NAS appliance and reclaim datacenter space.

Timeline: 1 month total (2 weeks physical transport, 2 weeks parallel sync, 1 week validation and cutover). User interruption: <1 second during DNS propagation.

Visual Explanations

Diagram 1: Cloud Adoption Framework Phases & Timelines

Diagram 2: Discovery & Assessment Flow

Diagram 3: IaaS Migration Methods

Diagram 4: Database Migration Targets

Diagram 5: TikZ - Data Migration Timeline

Table 1: Azure Migrate Tools Overview

Table 2: Database Target Selection Criteria

Table 3: Data Transfer Method Comparison

Table 4: VM Readiness Determination Criteria

Table 5: Cloud Adoption Framework Governance Controls by Phase

Each CAF phase requires specific governance controls to ensure compliance, cost control, and operational excellence. The table below maps phases to representative controls and Azure tools that enforce them:

Table 6: Migration Strategy Comparison

Common Mistakes

Myth 1: "Lift-and-shift migrations automatically capture all cost savings." Reality: Rehost migrations capture only 10 to 15 percent of potential cost savings overall. Many legacy on-premises deployments over-provision infrastructure for peak load scenarios that occur only a few days per year. Over-sized VMs (common legacy configurations), unused resources (zombie VMs), and unoptimized database configurations multiply Azure bills. A 4-vCPU VM on-premises configured for peak load but running at average 20 percent CPU utilization frequently right-sizes to 2-vCPU equivalents, cutting costs in half immediately. Best practice: execute rehost quickly (weeks), then schedule optimization within 90 to 180 days using Azure Advisor recommendations, Cost Management spend analysis, and performance baselines.

Myth 2: "Online database migrations guarantee zero downtime." Reality: Online migrations using continuous replication approach zero downtime but are not truly zero-downtime magic. The final cutover requires careful coordination: if the application writes to the database during the final sync window, replication can lag several seconds, causing data conflicts or lost transactions. Solution: plan a brief maintenance window (5 to 15 minutes) for final validation of data consistency and connection string updates. Use DMS test failover to validate cutover procedures on test data before production, ensuring your team understands the process and timings.

Myth 3: "We can migrate each server individually without dependency mapping." Reality: Unmapped dependencies cause critical application outages and frustrated users. A web-tier server depends on a backend database; a middleware server depends on a legacy LDAP directory; a file server holds configuration files for distributed applications. Migrating one without the other breaks end-to-end functionality. Solution: always run Azure Migrate's dependency analyzer (agentless monitoring or agent-based traffic capture) to identify inter-server communication patterns and shared resources. Group dependent workloads into coherent migration waves; coordinate cutover timing across application tiers to maintain service continuity.

Practice Exercises

Exercise 1: CAF Strategy & Business Case Development

Your organization is considering cloud migration as part of a broader digital transformation initiative. Define a realistic 3-week Strategy phase: articulate 3 business drivers, set 3 measurable migration goals, and identify 3 key success metrics (cost, availability, deployment velocity) that will determine whether the migration succeeds.

▶Solution

Business Drivers: (1) Cost reduction: target 25 percent savings in annual infrastructure spend through elimination of hardware refresh cycles and reduction in operational staffing in infrastructure spend, (2) Agility: enable faster application deployment for competitive advantage, (3) Compliance: enable multi-region disaster recovery to satisfy regulatory requirements for data residency.

Migration Goals: (1) Migrate 70 percent of on-premises infrastructure to Azure by end of Q3, (2) Reduce annual CapEx budget by $50,000 through elimination of hardware refresh cycles, (3) Enable 99.95 percent SLA for critical systems (vs. current 98 percent on-premises).

Success Metrics:

• Cost savings: Target 25 percent reduction in infrastructure spend by year 2
• Availability: Target 99.95 percent SLA compliance (maximum 22 minutes downtime per year)
• Deployment speed: Reduce application deployment from 4 weeks to 1 week through Azure's agile infrastructure

Deliverable: Executive summary (2 pages) + high-level migration roadmap with business case ROI calculation.

Exercise 2: Server Assessment & Readiness Analysis

Server Assessment reports 120 discovered servers: 45 marked ready, 60 marked conditionally ready, 15 marked not ready. Analyze why servers would receive each classification. What remediation steps would you recommend for each group before migration?

▶Solution

Ready (45 servers): Current OS versions (Windows Server 2016+, RHEL 7+), all software compatible with Azure, hardware drivers available. Action: Schedule for migration waves immediately.

Conditionally ready (60 servers): OS versions outdated but upgradeable (Windows Server 2012, CentOS 6), driver support available after firmware update, unsupported software has cloud alternatives. These servers are typically 5-7 years old and have received security patches but lack modern OS features. Action: Upgrade OSes in-place pre-migration (1-2 week effort per batch of 10-15 servers), or plan upgrade post-migration in Azure with minimal disruption using Azure Update Management. Action: Upgrade OSes in-place pre-migration (1-2 week effort per batch), or plan upgrade post-migration in Azure with minimal disruption.

Not ready (15 servers): OS completely unsupported (Windows Server 2003, CentOS 5), proprietary hardware with no cloud equivalents, license incompatibility. Action: Decommission legacy applications; refactor critical apps via containers; or replace with cloud-native alternatives (e.g., replace legacy mail server with Microsoft 365).

Exercise 3: VM Right-Sizing & Cost Optimization

A business-critical web server configured with 8 vCPU, 32 GB RAM, 500 GB disk. On-premises monitoring shows 25 percent average CPU utilization, 50 percent RAM utilization. Server Assessment recommends D4s_v3 (4 vCPU, 16 GB RAM, $221/month). Evaluate whether this recommendation is right-sized. How would you validate sizing post-migration and capture additional savings?

▶Solution

Analysis: The on-premises VM is significantly over-provisioned. At 25 percent CPU and 50 percent RAM, a D2s_v3 (2 vCPU, 8 GB RAM, $110/month) would likely suffice, cutting costs in half. However, Server Assessment uses conservative recommendations to ensure stability. Best practice: migrate with recommended size, monitor continuously for 2 weeks post-migration, then right-size downward if CPU and RAM stay below 40 percent utilization. Annual savings per VM: $1,300/year. Portfolio savings (100 similarly-sized VMs): $130,000/year.

Exercise 4: Database Workload Migration Path Selection

You have a mission-critical SQL Server 2019 instance with: CLR functions (C# code in SQL), SQL Agent jobs (automated administrative tasks), full-text search indexes, and replication between datacenters. Would you migrate to Azure SQL Database or SQL Managed Instance? Justify your choice and discuss tradeoffs.

▶Solution

SQL Managed Instance is the correct choice. Azure SQL Database does not support CLR functions, SQL Agent, replication, or full-text search—all present in your workload. SQL MI offers near-100 percent compatibility with on-premises SQL Server. Financial tradeoff: SQL MI costs 20 to 30 percent more than SQL Database (4-vCore SQL MI: ~$3,000/year vs. SQL DB Premium: ~$1,500/year), but avoids months of refactoring effort worth thousands in engineering hours. Long-term strategy: after migration stabilizes and you understand application requirements better, migrate to SQL Database if schema simplification becomes feasible.

Exercise 5: Data Transfer Method Selection for Constrained Network

You need to migrate 2.5 TB of business-critical data to Azure. Network constraints: 10 Mbps bandwidth (severely limited, production traffic takes priority). Timeline: 30 days available. Recommend an optimal transfer method, justify cost/time tradeoffs, and calculate time savings vs. network transfer.

▶Solution

Data Box Disk ($40) is optimal. Network calculation: 2.5 TB = 20,000 Gb / 10 Mbps = 2,000 seconds = 33 minutes continuous, or 2.8 days with realistic 25 percent utilization (preserving production traffic priority). Data Box Disk: ships in 2 days, supports offline transfer (no network impact), returns within 1 week. Total elapsed time: 1 week vs. 2.8+ days of production network saturation. ROI: saves network bandwidth (freed for production), completes predictably, costs only $40 per order. Scale benefit: for 100+ TB, use Data Box ($4,000); for 1+ PB, use Data Box Heavy ($10,000).

Exercise 6: Post-Migration Cost Optimization & Governance

Two weeks post-cutover, Azure Cost Management flags a production VM sized E16s_v4 (16 vCPU, 128 GB RAM, $2,500/month) that consistently uses less than 10 percent CPU and 20 percent RAM. Identify optimization opportunities using Azure tools, calculate potential savings, and describe governance controls to prevent similar over-provisioning in the future.

▶Solution

Optimization Steps: (1) Azure Advisor right-size recommendation: downgrade to D4s_v3 (4 vCPU, 16 GB RAM, $221/month) → savings $2,279/month = $27,348/year. (2) Cost Management: group VMs by department and owner; identify cost anomalies. (3) Azure Policy: create policy to prevent VM SKUs costing >$500/month; flag violations automatically for review. (4) Remediation process: resize VM, monitor for 2 weeks, confirm stability before finalizing change.

Portfolio Impact: If 5 similarly over-sized VMs exist, annual savings reach $136,740. Governance: use Azure Policy to prevent future over-provisioning; mandate right-sizing reviews at 2 weeks, 90 days, and 1 year post-migration.

Summary & Concept Map

This lesson has presented five interconnected learning objectives that form the foundation of cloud migration architecture and design. The concepts and tools covered here represent industry best practices and align with Microsoft's battle-tested approaches from thousands of customer migrations.

Key Takeaways:

• Cloud Adoption Framework provides structured governance across all migration phases, reducing rework by 30 percent and preventing compliance violations
• Azure Migrate Hub integrates discovery, assessment, and dependency mapping into a single unified platform, eliminating information silos
• Lift-and-shift is fastest (weeks) but leaves 10-15 percent cost savings untapped; plan re-platforming within 90-180 days for optimization
• Online database migrations with DMS achieve near-zero downtime through continuous replication; plan brief maintenance windows for final cutover validation
• Data Box family enables cost-effective bulk data transfer when network is constrained; AzCopy and File Sync suit smaller, incremental transfers

Concept Map:

Connections & Next Steps

Recommended learning sequence for AZ-305 exam preparation:

1. LO40 (CAF Strategy & Planning): Review Ch. 4, §4.1–4.2 of the exam guide. Understand the complete CAF cycle (Strategy → Plan → Ready → Adopt → Govern → Manage) before executing any migration. Key insight: CAF governance prevents scope creep, ensures compliance, and enables repeatable migration success across multiple business units.

2. LO41 (Assessment & Evaluation): Hands-on lab exercise—deploy Azure Migrate appliance in a test environment (VMware or Hyper-V). Practice Server Assessment sizing recommendations and dependency mapping. Use TCO Calculator to model realistic 3-year cost comparisons with your own on-premises cost data.

3. LO42 (IaaS Migration): Create a non-production test VM (Windows Server 2019 on-premises). Migrate it using Azure Migrate: Server Migration with agentless replication. Practice cutover procedures, including test failover and full rollback to validate your team's readiness.

4. LO43 (Database Migrations): Set up a test SQL Server 2019 instance (or PostgreSQL 12+) on-premises. Practice DMS online migration to Azure SQL Managed Instance. Validate schema consistency, run DBCC checks, measure actual cutover time in your lab environment.

5. LO44 (Unstructured Data): Test AzCopy or Azure File Sync with a small SMB file share (10–100 GB). Calculate Data Box Disk cost vs. network upload time for datasets exceeding 100 TB. Understand cloud-tiering benefits for archive-heavy workloads.

Related AZ-305 topics and deeper study areas for comprehensive preparation: Azure Well-Architected Framework and Review process (particularly the cost optimization pillar), Azure Hybrid Benefit licensing optimization for on-premises SQL Server and Windows Server, Azure Reserved Instances for post-migration cost control, disaster recovery patterns (Site Recovery, backup vaults, geo-redundancy), Azure governance and compliance (Policy, Blueprints, Management Groups), identity and access management (RBAC, Microsoft Entra ID integration, managed identities), monitoring and cost optimization (Azure Monitor, Azure Advisor, Cost Management).

Further reading: Microsoft Cloud Adoption Framework for Azure documentation, Azure Migrate product documentation and tutorial videos, Azure Database Migration Service guides, Data Box service documentation and sizing calculator, Azure Well-Architected Framework white papers.