An independent IDC study commissioned by Microsoft found that organisations migrating workloads to Azure achieved a 704% three-year ROI, 19.2% lower infrastructure costs, and a 77% reduction in unplanned downtime. Those are headline numbers. What the press release does not tell you is that the outcomes vary enormously depending on which migration strategy you choose, and most enterprises pick the wrong one for at least half of their workload portfolio.
Microsoft's Cloud Adoption Framework documents five core strategies, often called the Five Rs: Rehost, Refactor, Rearchitect, Rebuild, and Replace. Rehost (the lift-and-shift approach) is the fastest to execute and the most expensive to run long-term. You move VM images to Azure with no code changes, you preserve all your operational debt, and you pay cloud prices for on-premises behaviour. It has its place: applications heading for retirement, workloads with genuine compliance constraints that prevent PaaS adoption, or situations where you need to exit a data centre on a fixed deadline. Outside those scenarios, it is the wrong default.
Refactor, making targeted code changes to target PaaS services like Azure App Service, Azure SQL, or Azure Cache for Redis, is where the economics improve sharply. Well-executed refactoring typically reduces monthly cloud spend by 30 to 50 percent compared to an equivalent rehosted workload, according to Azure CAF guidance and third-party analyses. The investment is modest compared to a full rearchitect, and the operational model becomes significantly simpler.
For larger, longer-lived systems, the pattern that Microsoft's Azure Architecture Center formally documents as the Strangler Fig is the most reliable vehicle for migration without business disruption. Named after the strangler fig tree, which grows around an existing tree and gradually replaces it, the pattern works by introducing a facade, typically Azure API Management, between clients and the legacy system. New functionality is built as standalone services on Azure. The facade routes requests to the appropriate system: legacy for unchanged functionality, new services for migrated or new capabilities. Over time, as functionality migrates, the facade routes an increasing share of traffic to the new system. When migration is complete, the legacy system is decommissioned.
The Azure Architecture Center documentation (last updated December 2025) makes two important qualifications. First, the Strangler Fig requires that requests can be intercepted. If your legacy system has direct database coupling or proprietary protocols that cannot be proxied, the pattern does not apply cleanly. Second, for data migration, the recommended approach is shadow writes: the new system writes to both the legacy and new databases simultaneously, with an ETL synchronisation process, until the new data store is validated and the legacy one can be retired.
The migration decisions that cause the most pain are not technical; they are sequencing decisions. Which services do you migrate first? The answer from the CAF and from practice is: start with the services that are least coupled to everything else, not the ones that are most visible. Early migrations should be learning exercises, not heroic projects. The architectural muscle you build on a low-risk service is what makes the high-stakes migration eighteen months later predictable rather than terrifying.
Source: Azure Architecture Center, Strangler Fig pattern (learn.microsoft.com); Azure Cloud Adoption Framework, Migration strategies (learn.microsoft.com); IDC ROI study cited by Microsoft/Rishabhsoft, 2024.