Study Azure AZ-305 Migration Strategy: key concepts, common traps, and exam decision cues.
On this page
Migration design in AZ-305 is not only about moving workloads into Azure. It is about choosing the right change depth for the business timeline, operational risk, and long-term platform goal. If you miss that, you either over-modernize a deadline-driven migration or preserve too much infrastructure when the real goal is operational simplification.
Start with the migration objective
Goal
Strongest first fit
Why
move quickly with minimal application change
rehost or near-like-for-like migration
lowest immediate change risk
reduce infrastructure management over time
replatform toward managed services
better long-term ops posture
redesign parts of the app for cloud-native behavior
refactor or modernize
architecture benefit justifies more change
discover dependencies and build a migration plan
Azure Migrate style assessment workflow
planning and dependency mapping come first
Ask these questions before choosing the path
Is the business optimizing for speed, cost, risk reduction, or modernization?
Can the app tolerate code or platform changes before the deadline?
Is the current dependency footprint simple enough for managed Azure services?
Does the target operating model favor less infrastructure ownership?
Common migration lanes
Scenario clue
Strongest first reasoning move
“move this quarter with minimal change”
start with rehost or conservative replatform
“reduce patching and server ownership”
favor managed platform targets where dependencies allow
“current architecture is tightly coupled and hard to scale”
modernization may be worth the added change effort
“need inventory and dependency discovery first”
assessment and migration planning tools come before target selection
Common traps
Trap
Better rule
assuming modernization is always the best answer
the right answer depends on time, risk, and business constraint
assuming lift-and-shift is always safest
preserving everything can preserve unnecessary cost and ops pain
picking the target platform before understanding dependencies
dependency discovery shapes what can realistically move where
treating app migration and data migration as identical
they often move on different timelines and with different risk controls
What strong answers usually do
anchor the migration path to business urgency and acceptable change
choose the least disruptive path that still satisfies the long-term goal
use assessment and dependency mapping before large migration decisions
distinguish between infrastructure move, platform change, and application redesign
Decision order that usually wins
Decide whether the move is rehost, refactor, rearchitect, or replace.
Match migration tooling to the chosen modernization depth.
Keep discovery/assessment separate from runtime cutover.
Prefer the least disruptive migration pattern that still meets the target-state requirement.
Read app dependency and downtime tolerance before choosing the migration lane.