--- title: "Azure Migration: Four Decisions Before You Move" canonical: "https://data-driven.com/blog/migrating-to-azure-cloud/" pubDate: "2022-01-10T00:00:00.000Z" updatedDate: "2026-08-25T00:00:00.000Z" description: "Assess workload fit, dependencies, costs, security, and operating ownership before moving an application or data platform to Azure." tags: [azure, cloud-migration, learning] categories: [azure] --- Cloud migration moves an application, data platform, or supporting service from its current environment to a cloud platform. It can also change how the workload is built and operated. The move is not a benefit by itself. A useful Azure migration plan states what should improve, what must remain stable, and how the team will prove both. ## 1. Link the workload to an outcome Name the reason for moving each workload. It may need faster release cycles, a supported platform, better recovery, new analytics, or less infrastructure work. Turn that reason into acceptance criteria. Include availability, performance, recovery, security, and cost targets. A workload without a clear outcome may be better left in place, retired, or replaced. Microsoft's Cloud Adoption Framework organises adoption across strategy, planning, readiness, migration, governance, security, and management. Use it to connect the technical move to the operating model. ## 2. Discover dependencies before choosing a path Inventory the workload's servers, databases, identities, certificates, scheduled jobs, network routes, integrations, owners, and support windows. Observe real traffic where possible; documentation alone often misses a dependency. Then choose a treatment for each component: - **Retire** work that no longer has a justified use. - **Retain** a component when moving would add risk without value. - **Rehost** when a minimal move meets the outcome. - **Replatform or refactor** when a service change is needed to reach it. - **Replace** when a supported product fits better than migration. Use Azure Migrate and workload-specific tools to gather evidence. Validate tool coverage before assuming discovery is complete. ## 3. Model transition and operating cost Estimate more than target compute and storage. Include assessment, remediation, data transfer, parallel running, testing, licensing, support, backup, monitoring, and the people needed to operate the new design. Model normal and peak demand. Record which assumptions can change after migration, such as schedules, retention, scaling, and service tiers. Set cost owners and review dates before cutover. Cloud services make consumption adjustable, but they do not optimise themselves around your business priorities. ## 4. Design shared responsibility Microsoft secures the underlying cloud platform. The customer remains responsible for areas such as data, identities, access, application configuration, and the controls that vary by service model. Review the Azure shared-responsibility model for the services you select. Assign named owners for identity, network, data protection, vulnerability response, logging, backup, and recovery. Test those controls through the intended user and service paths. A policy document is not proof that the deployed workload enforces it. ## Plan a reversible migration wave Group workloads by dependency and business tolerance. Start with a wave that exercises the landing zone and operating process without putting the most critical service first. For each cutover, define: 1. entry and exit criteria 2. data synchronization and validation 3. user and integration testing 4. monitoring and incident ownership 5. rollback conditions and time limit 6. the point when the old environment can be retired A good Azure migration reduces a known constraint and leaves the team able to operate the new workload. The plan should make that evidence visible before the final cutover.