AZ-305 Migration Design: Cloud Adoption Framework, Azure Migrate, Database and Data Transfer

The Cloud Adoption Framework (CAF) assigns each workload one migration strategy, chosen from its business drivers and constraints: retire, rehost, replatform, refactor, rearchitect, replace, rebuild or retain. A single estate almost always uses several strategies at once, so evaluate each workload on its own rather than picking one approach for the whole datacenter.

Three pairs are easy to confuse. Refactor versus rearchitect: refactor improves the code within the same architecture, while rearchitect changes the structure (for example splitting out a service) to meet goals such as independent scaling. Rearchitect versus rebuild: rearchitect reuses the code that is sound, rebuild starts again. Replace versus rebuild: replace buys a SaaS product so the maintenance burden goes away; rebuild keeps it, on new technology.

Replatforming a database still needs the right target. Both Azure SQL Database and Azure SQL Managed Instance remove operating-system and engine patching, but only Managed Instance keeps instance-scoped features such as SQL Server Agent jobs and cross-database queries. Choosing the Azure SQL target by features is covered in the lesson on designing relational data storage; this lesson focuses on how the data gets there.

Plan a migration by preparing an Azure landing zone first, then moving workloads in waves that start with simple, low-risk systems, keep dependent components together and carry a rollback plan. CAF's Ready methodology builds the landing zone (subscriptions, hub networking, identity, Azure Policy, management and logging) before workloads arrive, and the Migrate guidance treats it as a prerequisite. Moving early workloads into ad hoc subscriptions leaves gaps that every later wave inherits.

Sequencing waves

• Start simple. Begin with less complex internal applications that have few integration points, so the team can refine its process and runbooks. Critical and heavily integrated systems come later.
• Non-production first. Moving development and test environments before production lets the team validate configuration, recovery and operations safely.
• Group by workload and dependency, not by datacenter rack or location. Components that call each other constantly belong in the same wave.

Direct and indirect dependencies

CAF distinguishes direct dependencies (frequent, latency-sensitive calls, such as a web tier querying its database on every request), which must move together, from indirect dependencies (occasional calls that tolerate latency), which can be split across environments for a while. When a component cannot move yet, for example a server tied to a hardware key, document it, keep hybrid connectivity such as a site-to-site VPN or ExpressRoute, and keep the split as short as possible.

Downtime method and rollback

For each workload, decide whether a planned outage is acceptable (offline migration) or the cutover must be near-zero downtime (online replication followed by a short switchover); that choice drives the tool. Every production wave needs a rollback plan: agreed go/no-go and rollback criteria, the owner who makes the call, and the steps to return. Rollback only works while the source environment is intact, so decommission source servers only after the workload has been validated and stabilized in Azure, not when a test migration passes. Azure Migrate server migration does not replicate back to on premises, and backups of the migrated Azure VMs restore the workload in Azure, so neither is a route back.

Azure Migrate discovers on-premises servers in one of three ways: the Azure Migrate appliance for continuous discovery, the Azure Migrate collector for networks that can't connect to Azure, or an imported inventory file. Choose by connectivity and by whether the assessment must rest on data read from the servers themselves.

One organisation can use different methods for different estates, such as the appliance in a connected datacenter and the collector in an isolated lab.

Dependency analysis

Dependency analysis shows which servers talk to each other so you can group them into applications and migration groups. Agentless dependency analysis uses the appliance to collect TCP connection data (processes, applications and destination ports) without installing anything in the guest operating systems; you view it as a map or export it. Microsoft recommends it. The older agent-based option, which needs agents in each server, is available only in the classic experience and no longer onboards new servers. Network monitoring tools show connectivity and health; they aren't built to group servers into migration waves.

An Azure Migrate assessment recommends an Azure target and size for each discovered server, either from collected utilization (performance-based) or from the configuration allocated today (as on-premises).

The confidence rating (one to five stars) of a performance-based assessment reflects how many of the needed data points were available over the chosen period. A low rating usually means the appliance hasn't collected for long enough, in other words a collection window shorter than the workload's busiest business cycle. The fix is to collect across a full representative cycle and then recalculate the assessment. The comfort factor adds headroom to a size but can't supply missing data points.

Assessment types

• Azure VM assessments size servers as Azure virtual machines.
• Azure SQL assessments evaluate discovered SQL Server instances and databases for readiness and right-sized recommendations across Azure SQL Database, Azure SQL Managed Instance and SQL Server on Azure VMs. This replaces Data Migration Assistant, the standalone assessment tool, which was retired on 16 July 2025. Database Migration Service runs migrations but its current version doesn't assess or recommend SKUs.
• Web app assessments check IIS and other web apps for readiness to move to Azure App Service or AKS.
• Azure VMware Solution assessments estimate how many private-cloud hosts a VMware estate needs, a different question from VM sizing.

Business case

An Azure Migrate business case compares the total cost of ownership of the current estate with Azure, using the servers and utilization already discovered, and adds a year-over-year cash-flow view. It also shows utilization-based insights on Azure targets and the effect of moving from capital to operating expense, which is what finance leaders usually ask for to justify a migration. Because it is built from discovery data, nothing has to be sized or entered by hand, and it covers servers that don't exist in Azure yet.

The business case's migration preference decides which targets it prices:

• Modernize with PaaS prefers platform targets where workloads are ready (Azure SQL for SQL Server instances, App Service for web apps) and falls back to Azure VMs for general servers or workloads that aren't ready.
• Migrate to all IaaS prices every workload as Azure virtual machines.

Licensing and discount options, such as Azure Hybrid Benefit for Windows Server and SQL Server licenses or savings plans, are separate pricing inputs: they change the cost of the chosen targets, not which targets are chosen.

Rehost servers with the Azure Migrate migration and modernization tool, whose replication method depends on the source: agentless or agent-based for VMware, a host provider for Hyper-V, and agent-based for physical servers and VMs in other clouds.

A policy against installing software in guest operating systems therefore points to agentless VMware migration or Hyper-V host replication. VMs in another public cloud have no VMware or Hyper-V layer to work through, so they always use the agent-based method.

Test before cutover

Once replication is complete, run a test migration: it creates an Azure VM from the replicated data in a virtual network you choose, which should be isolated from production. The source keeps running and replication continues, so the application owner can test, you clean up the test VM, and the real migration happens at cutover. Azure Site Recovery is the disaster-recovery service; for migrations, use Azure Migrate's own test migration.

Rehosting copies the operating system and installed software as they are. If the requirement is a new, current OS or database version, move the application or database into a freshly built target instead.

Choose Azure VMware Solution when VMware workloads must move quickly without being converted, and the team wants to keep vCenter, its runbooks and its VMware-compatible tooling. Azure VMware Solution runs private VMware clouds (vSphere, vCenter, vSAN and NSX) on dedicated hosts in Azure. VMware HCX migrates VMs into it, including live migration, without converting them to native Azure VMs. That makes it a strong fit for a fast datacenter exit. Azure Migrate and Azure Site Recovery both turn VMware VMs into native Azure VMs, which is the right outcome when the goal is to leave VMware, and the wrong one when the goal is to keep it.

Keeping IP addresses during phased moves

When VMs on one subnet move in different waves, the subnet must exist on premises and in the private cloud at once. HCX Network Extension stretches the on-premises layer-2 segment into Azure VMware Solution, so migrated VMs keep their IP addresses and default gateway and reach unmigrated neighbours as if they were local. ExpressRoute Global Reach provides the layer-3 path between the datacenter and the private cloud that HCX relies on; it doesn't stretch a subnet on its own. Moving whole subnets at once avoids the stretch, but only if the wave plan allows it.

Use Azure Migrate to discover web apps, assess their readiness for Azure App Service (or AKS) and migrate them at scale, which replatforms them onto a managed host with no web server operating system to manage. Azure Migrate discovers web apps running on IIS (and Tomcat on Linux), reports blockers, and can migrate ASP.NET web apps hosted on Windows servers in VMware to App Service agentlessly and in bulk, without code changes or a per-app manual move.

The alternatives each miss a common requirement: rehosting the IIS servers keeps the operating systems to patch; rewriting or repackaging each app by hand adds code change or manual effort per app. Choosing between App Service, containers and serverless for new designs is covered in the lesson on designing compute solutions.

Pick the SQL Server migration method from the Azure target and the allowed downtime: Database Migration Service covers most targets offline or online, transactional replication gives minimal downtime into Azure SQL Database, and the Managed Instance link gives near-zero downtime into Azure SQL Managed Instance.

Managed Instance link versus Log Replay Service

The Managed Instance link and LRS both target only SQL Managed Instance, because they rely on native backup or log restore that Azure SQL Database doesn't support. DMS online and LRS are both built on log shipping, so they share LRS's cutover behaviour and lack of failback.

If the team needs a new operating system or SQL Server version, moving the database into a new SQL Server VM with DMS beats rehosting the old server with Azure Migrate, which would copy the old OS and SQL installation across unchanged.

Move PostgreSQL with the flexible server migration service, MySQL with Azure Database for MySQL Import plus data-in replication when downtime must be short, and other engines such as Oracle or Db2 with SQL Server Migration Assistant.

PostgreSQL

Azure Database for PostgreSQL has a built-in migration service, driven from the Azure portal or the Azure CLI, that moves schema and data from on-premises, VM-hosted and other-cloud PostgreSQL to flexible server. Offline mode stops the applications during the copy. Online mode copies the data and keeps replicating changes until you cut over, keeping downtime to a minimum; every table needs a primary key. A pg_dump and pg_restore is offline and manual, and hand-built logical replication can cut downtime but isn't a managed, portal-driven migration.

MySQL

Azure Database for MySQL Import restores a physical Percona XtraBackup backup that you upload to Blob Storage, provisioning a flexible server and restoring the data files. For multi-terabyte InnoDB databases it is far faster than reloading a logical mysqldump export, although network speed affects the upload. Import is offline only, so for a short cutover capture the backup's binary log position and configure data-in replication from the source server until cutover. A flexible server read replica can't replicate from an external source; data-in replication is the mechanism for that.

Heterogeneous migrations

Moving to a different engine means converting the schema and code, for example PL/SQL packages and data types into T-SQL. SQL Server Migration Assistant (SSMA), with editions for Oracle, Db2, SAP ASE, MySQL and Access, produces an assessment report of what converts automatically, converts the schema, and migrates the data into SQL Server, Azure SQL Database or Azure SQL Managed Instance. Database Migration Service, Azure Migrate's SQL assessment and the Managed Instance link all assume a SQL Server source, so they don't fit a heterogeneous move. Mixed estates often combine tools: SSMA for an Oracle or Db2 database and the Managed Instance link for a SQL Server database in the same project.

Choose an offline transfer with Azure Data Box when the network can't carry the data in time, and an online tool otherwise: Azure Storage Mover for managed, tracked migrations of file shares and S3 buckets, and AzCopy for scripted copies. Start with the arithmetic: hundreds of terabytes over a link of a few hundred megabits per second takes months, so a deadline measured in weeks rules out every network option.

Data Box Heavy is retired; the current generation of Data Box appliances comes in larger capacities instead.

Seed offline, catch up online

If files keep changing during a bulk transfer, the data on the devices is stale by the time it lands. Seed the bulk with Data Box, then run an online pass (AzCopy sync or a Storage Mover job) that copies only new and changed files before the final cutover. An online pass is faster than another shipment for a small delta.

File shares

Storage Mover SMB migrations keep file fidelity, including ACLs and timestamps, and rerunning a job copies only the differences, which gives a quick final pass. AzCopy works but gives no central per-share tracking, and Data Box can't do the final incremental pass.

Objects from other clouds

Storage Mover cloud-to-cloud migration moves Amazon S3 buckets into Blob Storage: you create an Azure Arc multicloud connector for the AWS account, define an S3 source endpoint and a Blob container target, and run job definitions that you monitor from Azure; a later run in mirror mode copies only what changed. It does not rehydrate archived objects, so data in S3 Glacier or Glacier Deep Archive must be restored in S3 before the job starts. For a single scripted copy, AzCopy accepts an S3 bucket URL as its source and uses the Put Block From URL API, so Azure Storage pulls the data directly from S3 and the machine running AzCopy only orchestrates; its bandwidth isn't used for the data. Data Box and Azure File Sync can't read from S3.