Evaluate a migration solution that leverages the Microsoft Cloud Adoption Framework for Azure
Mapping Migration Strategies to Workload Requirements
The Microsoft Cloud Adoption Framework (CAF) provides five core migration patterns to move workloads to Azure, each matching different business and technical needs. These patterns are rehost (lift-and-shift), refactor (optimize), rearchitect (rebuild), replace (repurchase), and retire (decommission). Choosing the correct pattern requires evaluating the workload's specific dependencies, its required performance and uptime (SLAs), and any legal or security compliance constraints.
The selection process depends heavily on the workload's characteristics and its readiness for the cloud. For instance, a legacy application with complex dependencies but a need for a fast move might be a candidate for rehost using tools like Azure Migrate. An application needing minor code changes to better use cloud scaling features would fit the refactor pattern. A fundamentally new cloud-native design is needed for the rearchitect pattern. This mapping balances migration speed, cost, and long-term operational benefits.
To implement the chosen strategy, you use Azure Migrate and related services in a sequence of phases. The process begins with discovery, where tools automatically inventory servers and map their dependencies. Next, an assessment phase estimates costs and recommends target Azure services. Finally, the migration phase executes the data transfer, which often involves an initial copy, a period of resynchronization, and a final cut-over. Throughout all phases, you must enforce governance and cost controls using Azure Policy, budgets, and tagging to maintain security, compliance, and financial oversight.
Evaluate on-premises servers, data, and applications for migration
Discovery and Readiness Assessment using Azure Migrate
How Discovery Works
Azure Migrate assessments provide a centralized way to evaluate on-premises servers, data, and applications for migration to Azure. The assessment process begins with discovery, where a lightweight Azure Migrate appliance inventories servers, databases, and applications without installing agents on every machine. This inventory captures performance metrics such as CPU, memory, storage IOPS, and network utilization over time. It also maps application dependencies to reveal how servers and services interact with each other. These initial steps establish the performance baselines and topology required for accurate migration planning.
Readiness Evaluation
After discovery, Azure Migrate performs a readiness evaluation to determine whether workloads can migrate to Azure services. The assessment checks for compatibility issues with operating systems, database versions, storage sizes, and other configuration settings. Each workload is categorized as Ready for Azure, Conditionally ready, Not ready, or Unknown, which guides remediation efforts before migration begins. Assessment settings like target region, storage type, and compute families influence the readiness outcomes, ensuring that every workload is validated against suitable Azure targets.
Right-Sizing and Cost Estimation
The assessment then generates right-sized recommendations and cost estimates for target Azure resources. Performance-based sizing uses collected utilization data and percentile analysis, such as the 95th percentile, multiplied by a comfort factor to recommend optimal VM sizes, disk types, or database SKUs. As-is on-premises sizing bases recommendations solely on existing server configurations without considering actual usage patterns. Finally, the tool calculates monthly costs by aggregating compute, storage, licensing, and ancillary service charges based on selected pricing settings. This end-to-end cost estimation helps determine whether to rehost, refactor, or rearchitect workloads.
Confidence Ratings
To help assess recommendation reliability, Azure Migrate assigns confidence ratings to performance-based assessments. Ratings from one to five stars reflect the availability of required data points, such as CPU, RAM, IOPS, and network I/O metrics. Low confidence prompts administrators to extend profiling duration or switch to on-premises sizing, while high confidence confirms accurate recommendations. The assessment results, including readiness status, right-sizing, cost details, and migration guidance, are packaged into reports for stakeholders. Based on these insights, migration teams can choose the optimal approach and timeline for moving workloads to Azure.
Analyze Workload Migration Strategies for IaaS and PaaS
Workload Migration Patterns
Migrating workloads to Azure requires choosing between Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) based on workload requirements and architectural constraints. The lift-and-shift pattern moves applications directly to Azure Virtual Machines with minimal changes, offering a fast transition but keeping management overhead high. In contrast, replatforming makes minor optimizations to leverage managed services like Azure App Service, while refactoring involves re-architecting applications to run on container-based services like Azure Kubernetes Service (AKS). Each approach represents a trade-off: lift-and-shift minimizes migration effort and initial downtime, whereas refactoring requires significant development time but delivers superior long-term cost efficiency and scalability.
Resource Relocation and Automation
To automate the relocation of Azure resources, you can use Infrastructure as Code (IaC) or Azure Resource Mover. When using IaC, you export Azure Resource Manager templates or convert them to Bicep to deploy matching infrastructure in a target region. However, IaC templates only deploy structural resources and do not move underlying data, which means you must plan separate data-relocation steps. For direct resource transfers, Azure Resource Mover identifies dependencies and orchestrates the relocation of supported assets across regions, subscriptions, or resource groups.
Stateful Services and Data Relocation
Relocating stateful services requires selecting an automation tool based on the acceptable downtime and data type. For a hot relocation with minimal downtime, synchronous data replication copies data in near real-time across boundaries. Services like Azure SQL Database and Azure Cosmos DB provide built-in geo-replication to synchronize databases natively, though specific failover behaviors depend on the resource. For warm or cold migrations, Azure Site Recovery replicates virtual machines and their local storage continuously until the final cutover. File and object storage can be migrated using utility tools such as AzCopy, Azure Storage Explorer, or Azure Backup, while complex, large-scale data movements are best orchestrated by Azure Data Factory pipelines.
Strategic Alignment and Decision Criteria
Selecting the ideal migration strategy requires assessing application dependencies, performance profiles, and compliance standards. Simple legacy workloads with tight operating system dependencies often remain on virtual machines, while web workloads benefit from the operational savings of PaaS. Security boundaries, data residency laws, and network latency goals dictate which target services and migration pathways are viable. By aligning these technical characteristics with organization-wide cost, security, and operational objectives, you can design a robust and predictable migration lifecycle.
Recommend a solution for migrating databases
Azure Database Migration Service (DMS)
Azure Database Migration Service (DMS) is a fully managed service that coordinates moving databases from on-premises or other clouds to Azure with minimal downtime and end-to-end validation. It handles both homogeneous migrations (for example, SQL Server to Azure SQL Managed Instance) and heterogeneous migrations (such as Oracle to Azure SQL Database). By centralizing the migration tasks, DMS reduces risk and ensures that data integrity, performance alignment, and compatibility requirements are satisfied.
Choosing the Appropriate Target
To pick the right Azure destination, you must analyze the source database's characteristics and map them to Azure PaaS offerings. Key factors include feature compatibility (instance-level features, cross-database queries, SQL Agent jobs), performance requirements (compute size, I/O throughput, service tier), and business continuity needs (built-in high availability, read scale-out). Based on this analysis, recommend Azure SQL Database for modern cloud-native apps or Azure SQL Managed Instance for lift-and-shift scenarios that need near-100% SQL Server compatibility.
Configuring DMS
Configuring DMS involves setting up a migration project and choosing between online and offline migration modes. The main steps are: provision a DMS instance in Azure and configure the Azure-SSIS Integration Runtime if needed; create a migration project in the Azure portal and select source and target connection endpoints; run the pre-migration assessment wizard to identify compatibility issues and validate schema mapping; then choose offline mode for simpler cutovers or online mode for continuous data replication to reduce downtime.
Migration of Instance-Level Objects
DMS can orchestrate the migration of instance-level objects and extended features. You can include SQL Agent jobs (only T-SQL steps are supported—SSIS-based jobs must be scripted and redeployed), logins and groups (SQL logins are supported by default; enable Windows logins via Microsoft Entra ID access), SSIS packages (redeploy from SSISDB to Azure-SSIS runtime), and SSRS reports (convert to Power BI paginated reports using the RDL Migration Tool).
Validation and Cutover
After the initial data load, DMS continuously applies transaction log or differential backups in online mode and tracks progress in the Azure portal. Key validation and cutover tasks include monitoring replication status and error logs, running data consistency checks and final schema comparison, executing a controlled failover or cutover during a maintenance window, and leveraging failover groups for cross-region replication to ensure high availability and disaster recovery. This approach ensures that database migrations align with the enterprise standards of minimal downtime, data integrity, and performance alignment.
Recommend a solution for migrating unstructured data
Choosing the right tool for moving large amounts of unstructured data—like files, images, and videos—to Azure depends on your network, budget, and how quickly you need the data. You must compare four main options: Azure Data Box, Azure Data Box Gateway, AzCopy, and Azure Data Factory. The key factors to evaluate are their maximum speed, the file protocols they support, how they encrypt data, whether they can work offline, and their cost structure.
StudyCerts
StudyCerts