In most cases, a lift-and-shift cloud migration does little more than provide basic redundancy. A better approach—that offers better efficiency and better value—is to move cloud-ready workloads over to Azure, keep legacy applications on-premise, and set up orchestration to manage cloud recovery and backup.
Following general evaluation and planning, when you reach consensus from each team on the vm ware to hyper-v migration plan, you’ll need to execute the plan. Getting down to the details in your mind, you’ll find yourself asking: How do I proceed? In this guide, we’ll break down the major steps involved in each phase of the Azure migration process.
Step 1 — Cataloging Your Apps
Practicably, it all begins by cataloging all the applications managed by IT, assigning a category to each app according to its attributes—such as server count or document type, for example. Next, you can roll up these attributes beneath general categories such as architecture, performance, risk, costs, security, operations, and compliance.
As you build this app migration catalog, it can be especially helpful to consider each application from two vantages: how an application should best serve business needs and the technical feasibility of where an application can reside and operate well enough.
Step 2 — Evaluate Business Needs
A primary driver for cloud migration is to transform and optimize many facets of your business in ways that are only feasible with cloud-based services. Performing a business-need migration assessment is one phase in the pursuit of these goals. This type of assessment expressly evaluates various technical and security aspects of each application, including the:
- Categorization of data, ownership, security risk and compliance requirements.
- Operational requirements such as maintenance intervals, SLAs, integrations, and monitoring.
- Complexity of existing interfaces, data structures, authentication, latency, coupling, and life expectancy of each application architecture.
Following this analysis, each app is scored in each of these aspects and these combine into an overall score that indicates the difficulty in migrating that application to the cloud.
Step 3 — Evaluate Cost/financial Impacts
It’s also important to assess and evaluate the financial impact to migrating the application—especially each of the following:
- Business continuity and resiliency, and all affected dependencies in case of a service disruption.
- Total cost of ownership, operational efficiency, and return on investment.
- Seasonal user loads, overall computing loads, user types, and minimum levels of scalability.
After scoring each of these, the quantitative results from these business-need assessments can then be taken as input into an overall score. That score gives a good indication of the difficulty in migrating each application—together with its corresponding financial impact. With this approach, it’s much easier to identify which migration-candidate applications you can expect to have the highest degree of value by choosing to migrate. Then you can prioritize these applications as you begin to map out the migration process.
Step 4 — Technical Considerations
Once your team decides which apps to migrate, it’s essential to consider each of the following before migrating applications to Azure:
With the Azure App Service, its often best to maintain any files that must remain persistent externally—outside of the App Service—into an environment such as simple, secure storage. Then, modify the app to use either the Azure Storage SDK (or an API) for storing such files.
Integration with on-premise apps
Undoubtedly, some of your cloud-based applications will need to communicate with apps that will remain on-premise. How will these apps communicate? One solution is to establish an API—which will require changes to both apps—and incurs additional risk by exposing the on-premise server to the Internet. Another good solution is to establish secure connectivity from the Azure App Service to your on-premise server(s).
There are many options, one of which probably meets your technical and security requirements. These include the following: Deploy into an App Service Environment using an Isolated App Service Plan, establish a site-to-site VPN, establish hybrid connections, or enable VNET integration with an Azure VNet.
For on-premise apps, you might be fine with Windows authentication—or no-authentication—if you’ve got mutual trust with Active Directory (AD). However—when migrating to Azure—you’ll need to enable Azure Active Directory authentication, which means modifying some of your configuration such that you can authenticate users through Azure AD.
App Settings and Connection Strings
Many of these settings will need adjustment, so remember to define them on the portal such that they can be overridden—if necessary—for different deployment slots.
Step 5 — Monitoring and Alerting
Some native monitoring tools can perform well enough, since Azure subnets are simply extensions of what’s visible inside the corporate network. Solutions such as SolarWinds, Level Platforms and other similar tools are easily configurable to monitor Azure resources. Keep in mind, however, that the Azure SDK includes a diagnostic API that provides more detail through dumps, event logs, and traces. Use this API to set up automatic alerts that will be sent when a critical event occurs.
Step 6 — Configuring Disaster Recovery and Failover
A key part of your cloud migration plan must include provisions for workload continuity and data protection by implementing a backup and recovery solution. Azure can be configured to natively protect your running servers’ resources and data with its geo-redundant recovery services.
Conclusion - Migrate
Now that you’ve gotten everything configured, including preparing your existing workloads and applications, you’re ready to migrate over to Azure. Looking for more help planning and carrying out your Azure migration? 5nine is here to help you develop a solid Azure migration plan and provide the software platform and know-how you need to get the most out of your cloud.