Migration is not a file-copy exercise. On the Microsoft AZ-305 exam, architects are expected to evaluate migration solutions using the Microsoft Cloud Adoption Framework, assess on-premises servers, applications, and data, and recommend migration paths for IaaS, PaaS, databases, and unstructured data. The architect must decide not only how to move a workload, but whether the workload should be changed as part of the move.
The best migration plans begin with business intent. Some workloads move to exit a datacenter. Others move to improve resilience, security, scalability, deployment speed, or operating cost. Those motivations determine whether a simple rehost is enough or whether modernization creates more value.
Inventory comes before architecture
You cannot design a credible migration for an estate you do not understand. Discovery should identify servers, applications, databases, network dependencies, authentication methods, data flows, utilization, owners, business criticality, licensing, and unsupported components. Dependency mapping is especially important because applications that appear independent may share databases, file servers, middleware, or identity services.
Azure Migrate and related tooling can help build this evidence. The architect uses the inventory to group workloads into migration waves and to avoid moving a front end while leaving an essential dependency behind.
Assessment turns inventory into decisions
Assessment asks whether a workload is technically and economically suitable for a particular Azure target. It should consider compatibility, sizing, utilization, performance, operating-system support, data requirements, network latency, and licensing. A migration should not blindly reproduce years of overprovisioning from the datacenter.
Assessment is also where modernization opportunities appear. A database running on a VM may be a candidate for a managed database. A scheduled script may be a candidate for serverless automation. A monolithic web application may remain on VMs initially if the business needs a fast move, then be modernized later.
Rehost minimizes change
Rehosting moves workloads with limited architectural modification, often to IaaS. It can be useful when timelines are short, application change is risky, or the organization must exit existing infrastructure quickly. The tradeoff is that much of the original operating model moves with the application.
Rehost should not be dismissed as unsophisticated. It can be a rational first stage when the business value comes from relocation rather than immediate redesign. The architect should make the tradeoff explicit and define whether modernization will follow later.
Replatform reduces operations without rewriting everything
Replatforming moves components to managed services with limited code change. Examples include moving a database toward a managed Azure service or placing an application on a platform service rather than maintaining full virtual machines. The value is reduced infrastructure management and often improved built-in availability.
Compatibility still matters. An application may depend on operating-system behavior, unsupported extensions, local file paths, or instance-level database features that prevent an easy replatform. Assessment should find those issues before the migration window.
Refactor and rearchitect pursue deeper change
Refactoring changes application code or structure to better use cloud capabilities. Rearchitecting changes larger system relationships, perhaps separating services, adopting event-driven patterns, changing data stores, or redesigning deployment. These approaches can unlock scalability and resilience but require more time, testing, and organizational capability.
Microsoft’s current modernization guidance emphasizes replatform, refactor, and rearchitect as different points on a continuum. A real migration program can use all three across different workload components. The architect should avoid forcing the entire estate into one strategy.
The landing zone should exist before migration waves begin
Moving workloads into an ungoverned Azure subscription creates technical debt immediately. Before migration, the organization should have a landing-zone foundation for identity, subscriptions, policy, networking, monitoring, security, and cost ownership. That foundation prevents each migration team from inventing its own cloud environment.
The Microsoft Azure infrastructure certification path covers many landing-zone technologies, while AZ-305 focuses on sequencing them correctly: platform readiness should precede broad workload migration.
Migration waves should follow dependency and business logic
Wave planning groups workloads that can move together. Low-risk systems are often useful early candidates because they validate tooling and operating procedures. Highly connected systems may need to move as a group. Business calendars, regulatory deadlines, peak seasons, and maintenance windows also affect sequencing.
A good wave has a clear entry condition, technical plan, validation criteria, rollback decision, and ownership. “Move these ten servers on Saturday” is a schedule, not a migration plan.
Data migration deserves its own design
Moving compute and moving data are different problems. Database migration may require schema compatibility, replication, synchronization, cutover, and transaction consistency. Large unstructured data sets may need offline transfer, staged synchronization, or bandwidth planning. The final delta and downtime window often determine the migration method.
Architects should also decide whether data should be transformed or reclassified during the move. Migration is an opportunity to improve lifecycle, encryption, retention, and data ownership rather than simply copying every historical file into a new platform.
Network and identity dependencies can dominate the cutover
An application can be successfully deployed in Azure and still be unusable because DNS, routes, firewalls, certificates, identity, or hybrid connectivity were not updated. Cutover planning should include those dependencies explicitly. Hybrid periods may last weeks or months, so the temporary architecture needs to be secure and supportable.
Latency is particularly important when an application tier moves before its database or identity dependency. A design that worked inside one datacenter can perform poorly when every request crosses a WAN link.
Rollback must be defined before production cutover
Rollback is not “put it back if something goes wrong.” The team needs criteria for when rollback is still possible, how data written in the new environment will be reconciled, who makes the decision, and how long the rollback path remains valid. Database changes and one-way data transformations can make rollback much more difficult than compute rollback.
For critical workloads, the architect should ensure the rollback plan is tested or at least rehearsed with realistic data and dependencies. Confidence based only on documentation is weak.
Validation should prove business function, not only VM health
A migration is not successful because the destination resource shows a healthy status. Validation should confirm that users can authenticate, transactions complete, integrations work, performance is acceptable, monitoring is active, backups run, and security controls apply. Business owners should be involved in defining those acceptance criteria.
The distinction matters because many migration failures are functional rather than infrastructural. The server is running, but a batch job cannot reach a file share or an application cannot resolve a legacy DNS name.
Modernization can continue after the move
Organizations often assume they must completely modernize before migration or not at all. In reality, a staged approach can be effective: rehost to meet a datacenter deadline, stabilize operations, then replatform or refactor components that offer clear value. The architecture roadmap should explain that sequence so the rehost does not become permanent by accident.
The cloud architecture certification path provides useful context because modernization decisions are fundamentally about operating model, reliability, scalability, and delivery speed rather than about Azure branding.
Cost estimates should include transition cost
Migration programs often run source and destination environments in parallel. Data transfer, temporary connectivity, migration tooling, consultants, testing, licensing overlap, and staff time all contribute to transition cost. The destination architecture may be cheaper long term while the migration period is temporarily more expensive.
Architects should make that curve visible to stakeholders. Otherwise, a predictable temporary increase can be misinterpreted as evidence that the cloud strategy is failing.
How AZ-305 migration scenarios usually reveal the answer
If the requirement emphasizes minimal application change and speed, consider rehost. If the organization wants managed services with limited code change, consider replatform. If scalability or architecture constraints require deeper change, consider refactor or rearchitect. If many workloads are moving, expect a landing zone, assessment, dependency mapping, and wave planning.
If the problem is database compatibility, choose the migration target and tool based on engine features and downtime tolerance. If the problem is massive unstructured data, think transfer bandwidth, staged copy, and final synchronization. If the problem is cutover risk, look for validation and rollback design rather than another infrastructure component.
Decommissioning is part of migration economics
A migration does not finish when Azure is live. Source systems, old network paths, backup jobs, monitoring tools, licenses, and datacenter resources need an explicit decommissioning plan. Leaving the old environment running indefinitely preserves cost and operational complexity and can create an unofficial fallback that nobody tests.
Decommissioning should occur only after validation, agreed stabilization time, data-retention checks, and confirmation that rollback is no longer required. The migration plan should state who owns that decision and how the organization proves that the old dependency can be safely retired.
The durable lesson
A good migration is a controlled change in operating model. Discovery tells you what exists. Assessment tells you what fits. Landing zones provide a governed destination. Wave planning controls sequence. Migration methods move compute and data. Validation proves the workload works. Modernization then improves the parts that justify deeper change.
That end-to-end reasoning is more important than memorizing a migration product. AZ-305 tests whether you can connect business motivation to technical strategy and guide a workload from its current state into a supportable Azure architecture without losing control of risk.