A regional law firm operates a collection of aging Windows servers, a SQL Server database, a file share and a client-facing web app. Management wants all workloads “in Azure by December,” but cannot tolerate client-document loss or a month-long service freeze. Some components can move to virtual machines quickly, some need application changes, and one database contains a legacy dependency that will not work in the target managed service. The architect must separate discovery, target design, data movement, cutover and modernization rather than presenting migration as a one-click upload.
For Microsoft AZ-305, designing migrations includes the Cloud Adoption Framework, evaluating servers and applications, choosing IaaS versus PaaS, database migration and unstructured-data movement. The existing Azure landing-zone architecture covers where controlled workloads land, while the compute selection comparison helps select target runtimes. This article follows the path from an existing estate into that target, including reversibility when requirements are imperfectly understood.
Discover dependency groups before building a migration wave
Inventory physical and virtual servers, operating systems, installed applications, databases, file stores, identity dependencies, connection flows, certificates, schedules and business owners. Pay attention to undocumented cron jobs, shared directories, hard-coded IP addresses and license agreements. A server inventory tells you what exists; an application dependency map tells you what must move together or remain connected during a phased migration.
Use supported assessment capabilities such as Azure Migrate where appropriate to gather utilization and compatibility evidence. The Azure Migrate service guidance is a source for current assessment and migration services. Validate measured peak demand and seasonal workloads rather than right-sizing the target from one quiet afternoon’s CPU average.
Align migration strategy to business risk
A rehost strategy moves a workload with limited redesign and may be useful for a time-constrained exit. Replatforming can shift parts of the system to managed services without rewriting every business function. Refactoring changes application architecture to gain different scale, operating or resilience properties. Retiring, retaining, and replacing workloads are also valid outcomes when the business case supports them. The correct strategy is per application, not an enterprise slogan.
Compare required uptime, cost of code change, platform dependencies, support life, compliance restrictions and rollback feasibility. A legacy tool with a short remaining life may be worth rehosting while a high-volume customer API justifies deeper modernization. Do not force every workload into Kubernetes because the company is adopting cloud, or move a database to a PaaS service before compatibility tests have passed.
Design the landing zone before the workload arrives
Target subscriptions, management-group policies, resource groups, network routes, private DNS, monitoring, backups and identity access must exist before production cutover. Migrating a server into a subscription without allowed private routes or diagnostic settings can produce an operationally invisible service. Landing-zone readiness is a release gate, not paperwork to finish after the migration.
Review Azure Policy and RBAC at target scope. A migration tool or operator may need elevated permissions temporarily but should not retain tenant-wide administrator access forever. Create time-bounded roles and clear logs for changes. Ensure the service’s storage and key requirements are met in both normal and disaster-recovery locations.
Choose rehost tools for the actual source
For supported server environments, Azure Migrate and associated services can help assess and migrate virtualized or physical workloads. Tool support, replication mechanics, cutover steps and source prerequisites vary by platform and version. Select after reviewing source operating system, hypervisor, disk layout, network addresses and expected downtime. A “supported” VM shape does not prove that its application licenses or external hardware integrations will run correctly in Azure.
Plan target VM sizes, disks, availability, network security and management. Rehosted workloads inherit many operational responsibilities: patching, agents, backup and high availability. Use the cost-aware architecture treatment to model compute spend, storage, outbound traffic and dual-running overlap. A rushed migration that leaves both original and new servers running indefinitely can create two estates to patch and pay for.
Evaluate PaaS modernization for the web tier
A conventional web service may fit Azure App Service, a containerized version may fit Container Apps or AKS depending on platform needs, and a bounded event handler may fit Functions. Check runtime support, file/session state, network integration, authentication and deployment process. A web application that relies on writing to local disk will need a durable state strategy before moving to a platform that replaces instances automatically.
Establish deployment slots or blue/green strategies where supported, configuration ownership, secret retrieval and automated health probes. Rehearse switching application traffic independently of migrating the database. A healthy HTTP status from the target app is not sufficient if it still writes transactions to the retired source system.
Treat database migration as a consistency project
Assess SQL Server feature compatibility, database size, collation, jobs, external integrations and performance behavior before deciding between SQL Database, Managed Instance or SQL Server on VMs. A migration can be schema-compatible but still fail when a particular application query is too slow or an agent job cannot execute. Test the behavior that pays the business’s bills.
Choose an offline or online migration approach according to size, change rate and downtime tolerance. Online replication or change-capture paths can reduce interruption but add synchronization and cutover complexity. Define the precise moment the target becomes authoritative. If clients write to both databases during cutover without a conflict plan, rollback and reconciliation can become more damaging than a longer controlled outage.
Plan file and object migration separately
For unstructured data, choose supported tools according to file protocols, total bytes, object count, change rate and available network bandwidth. Online copy may be appropriate for moderate volume; large offline transfer mechanisms can help where network delivery would exceed the deadline. Storage account access, naming, metadata, permissions and encryption must survive the move. A checksum or file-count comparison is valuable but does not automatically preserve every application-level file ownership rule.
Allow time for a final incremental synchronization while the original files may still change. Decide whether there is a change freeze, read-only period, or controlled reconciliation after cutover. Do not call an initial bulk copy complete while lawyers continue editing case files on the old share.
Rehearse end-to-end cutover with a rollback deadline
Build a cutover runbook including traffic freeze or switch, last synchronization checkpoint, database consistency validation, secrets and certificates, private DNS, external partner allowlists, smoke tests and monitoring thresholds. Establish exactly when rollback remains safe. Once customer transactions have been accepted in the new location, switching back to the source without replay or reconciliation can lose those writes.
Use a rehearsed test migration and a representative dataset, not only a tiny empty server. Verify client login, document retrieval, reporting, backup and a typical support workflow. Record actual downtime, failures, remediation steps and observed cost. The migration is successful when staff can complete the business process at the target and operators know where to investigate an incident.
Keep modernization separate from the deadline
A deadline-driven rehost may be justified as phase one, with a later backlog for managed database adoption, cloud-native security, improved deployment and more elastic compute. Conversely, an application with severe compatibility or data-residency constraints may need to remain temporarily on-premises with a secure hybrid connection. Both choices can be responsible when explicitly documented and funded.
An AZ-305 migration architecture should name dependency groups, target pattern, selected transport and service, permissions, expected downtime, consistency point, rollback rule and later modernization work. Cloud Adoption Framework thinking is valuable because successful migration is a coordinated change to business service ownership, not merely the movement of virtual disks from one place to another.