Events
Take the Microsoft Learn Challenge
Nov 19, 11 PM - Jan 10, 11 PM
Ignite Edition - Build skills in Microsoft Azure and earn a digital badge by January 10!
Register nowThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
This article describes the process and considerations for designing the intended migrated state of a workload in the cloud. The article reviews activities that are part of defining a workload's architecture within an iteration.
The article about incremental rationalization indicates that some architectural assumptions are part of any business transformation that includes a migration. This article clarifies typical assumptions. It also points to a few roadblocks that you can avoid, and it identifies opportunities to accelerate business value by challenging architectural assumptions. This incremental model for designing architecture helps teams move faster and obtain business outcomes sooner.
The following assumptions are typical for any migration effort:
In the Ready phase of the Cloud Adoption Framework, your organization deployed shared platform services as part of adopting Azure landing zones. In Ready your landing zone for migration, you prepared the landing zone to receive migrated workloads.
Based on this planning, you can assume that the following migration components are in place:
If these migration essentials aren't established, your organization should immediately revisit the Ready phase to address these needs. Without these components, your migration likely will have delays and setbacks and be less successful.
The workload that you're designing has a subscription assigned to it, ideally through a subscription vending process. The subscription might contain several workloads or just one workload depending on how your organization completed its resource organization for workloads. If you migrate a workload that has many application environments, you might even have multiple subscriptions based on the guidance for application environments.
Plan to deploy application-specific resources to a specific subscription, and plan to design a dedicated virtual network for the workload. For more information, see guidance for designing your networking architecture. You should especially focus on segmenting virtual networks.
Your network likely needs resources like load balancers and other application-delivery resources. You can use the N-tier architecture guide to plan these resources in Azure.
Your migration assessment tools should give you a way to do dependency analysis, like dependency analysis in Azure Migrate and Modernize. The tool helps you identify interdependencies between servers.
In addition to planning architecture for the workload itself, you might need to consider workload-to-workload dependencies. For example, some workloads might need frequent communication. If so, planning your migration waves and dependencies to account for this requirement helps make your migration successful.
You can use guidance in Azure Architecture Center, such as for spoke-to-spoke networking, to design how interconnected workloads work after migration.
A subset of your workloads with sovereignty requirements might lead to using confidential computing. As part of a sovereign landing zone deployment, management groups for confidential computing are created.
Within a sovereignty context, using confidential computing requires Azure Key Vault and customer managed keys as a supporting service. For more information, see encryption with customer-managed keys in Microsoft Cloud for Sovereignty.
As you finish your architecture design, revisit your cloud estimate to make sure that you're still within the planned budget. As you add supporting services like load balancers or backups, costs can change. Although you can use tools like business cases in Azure Migrate and Modernize to do detailed cost management exercises, you should periodically revisit your estimates as you adjust your architecture design.
If you're familiar with traditional IT procurement processes, estimating resources in the cloud might seem foreign. When you adopt cloud technologies, acquisition shifts from a rigid, structured capital expense model to a fluid operating expense model. Planning a migration to the cloud often is the first time an organization or IT team encounters this change.
In the traditional capital expense model, an IT team attempts to combine buying power for multiple workloads across various programs. This approach centralizes a pool of shared IT assets that can support each of those solutions. In the operating expense cloud model, costs can be directly attributed to the support needs of individual workloads, teams, or business units. It gives an organization a more direct attribution of costs to internal customers and the business objectives that they support. This more dynamic approach to financial management is often called financial operations (FinOps). Although FinOps isn't an Azure-specific consideration, it can be helpful to have an expanded understanding of FinOps. For more information, see What is FinOps?.
When you design your workload architecture for migration, you can use the pricing calculator with your assessment information to understand the price of the entire workload.
Also, after your workload is migrated, you should continue to work to optimize workload costs. For more information about how organizations can mature their cost management skills, see Improve the cost management discipline.
Migrations tend to focus on maintaining an existing architecture and transitioning it to your cloud platform. However, there are times when you might need to rearchitect your workload, even for migration. This list gives examples of when you might need to make architectural changes before you migrate:
Each of these criteria serves as an indicator of a potential migration roadblock. In most cases, you can address the criterion after you migrate the workload by right-sizing servers, adding new servers, or making other changes. However, if any of those criteria are required before you migrate a workload, remove the workload from the migration wave and evaluate it individually.
The Azure Well-Architected Framework and Azure Well-Architected Review can help guide conversations with the technical owner of a specific workload to help them consider alternative options for deploying the workload.
The workload is then classified as a rearchitecture or modernization effort in your cloud adoption plan. Because of the extra time it takes to rearchitect a workload, consider these alternative workload adoption paths as separate from the migration process.
You can use the following checklist to make sure that you cover critical architectural considerations:
Events
Take the Microsoft Learn Challenge
Nov 19, 11 PM - Jan 10, 11 PM
Ignite Edition - Build skills in Microsoft Azure and earn a digital badge by January 10!
Register nowTraining
Learning path
Solution Architect: Design Microsoft Power Platform solutions - Training
Learn how a solution architect designs solutions.
Certification
Microsoft Certified: Azure for SAP Workloads Specialty - Certifications
Demonstrate planning, migration, and operation of an SAP solution on Microsoft Azure while you leverage Azure resources.