Migrating to Microsoft Azure? Here’s what you need to consider

Organizations of all types are migrating their applications to cloud environments like Microsoft Azure. And for good reason: migrating to the cloud offers a host of potential advantages, such as cost savings, enhanced flexibility, improved security and compliance, superior data protection, and easier management.

Of course, there’s no free lunch: Being on the cloud is worth the effort, but it does take some effort. There are also some potential challenges to be aware of to ensure that your migration goes smoothly and efficiently.

In this article, we highlight some of the key considerations you’ll want to take into account when planning your migration from on-premises to Azure.

Application compatibility and cloud integration level (shallow vs. deep)

Azure has architectural demands associated with it, so it is important to check whether the application to be migrated is consistent with its architectural requirements. One preliminary consideration is to figure out which approach is most suitable for your application. There are four basic approaches, as explained below.

1. Rehost / lift and shift

This technique involves moving applications from the on-premises environment to the cloud with no changes to the underlying application.

• Use cases: Legacy migrations; teams with limited cloud or Azure skills.
• Pros: Less risk of breaking the application; faster and easier migration.
• Cons: Applications might use cloud resources less efficiently and be more difficult to scale and extend.

2. Refactor / repackage 

In this approach, you move an application to Azure with some code changes but not a major overhaul of the application. This allows you to leverage services like Azure SQL Database Managed Instances and Azure Container Service. You can also leverage Azure’s App Service, Azure Functions, and Logic Apps to help rearchitect, refactor, and rebuild your apps in Azure.

• Use cases: Sensitive and business-critical applications where disruption of ongoing functionality is a concern, but there is a need to modernize or improve infrastructure.
• Pros: Fast and relatively easy while letting you improve your infrastructure, for example, by adding DevOps automation tools or moving to container-based deployment.
• Cons: Cannot make major architectural changes, such as splitting the application into microservices, which would enable substantial efficiencies in the cloud.

3. Rearchitect

This strategy involves revamping the codebase of the application and moving it to a cloud-native architecture.

• Use cases: Applications that need maximum agility, scalability, and flexibility in the cloud.
• Pros: Allows you to create a highly scalable, resilient, easily deployable application that can leverage the full power of the Azure cloud.
• Cons: Complex, expensive migration, with a high risk of faults and service disruption in the early deployment stages.

4. Rebuild

The rebuild strategy involves setting aside the old application and building the same functionality from scratch using Azure platform as a service (PaaS) capabilities. Leverage services like Azure Functions and Logic Apps to build the application tier, and use Azure SQL Database or other hosted Azure data services for the data layer.

• Use case: Applications with relatively low complexity and few dependencies on other business processes.
• Pros: Inexpensive and avoids the complexity of software licenses. No dependency on middleware or existing infrastructure.
• Cons: You will typically not get the same level of functionality as in a custom-built app. It’s important to evaluate in advance which parts of the app can be successfully rebuilt in the Azure environment and which cannot.

External/internal dependencies

If the application to migrate has external dependencies, not all of them may be accessible through Azure. By analyzing and identifying those that are not accessible through Azure cloud, you can create workarounds for such dependencies.

Prioritizing migration components (your digital estate)

You also have to decide whether you will migrate your entire application all at once or migrate it to the cloud piecemeal—component by component or service by service. Use a dependency diagram to decide which components should be migrated and in what order. 

It often makes sense to start with the services that have the fewest dependencies, such as master data and related services, and then follow up with your outermost services, typically the ones closest to your customers. An alternative approach is to start with the services closest to your customers—the most outside services—so that you can control any impact on your customers. 

A sample template is shown below. The list can change as you revisit and revise your plan. You can download this table in a fillable PDF format for free here.

(download this template as a fillable PDF)

Master data consolidation

Cloud migration provides you with an opportunity to consolidate and create a single source of truth for your customer, supplier, and product data. You will need to enforce robust data quality management policies to ensure that your master data continues to remain clean. 

Third-party framework and class libraries

Azure does not support all third-party framework and class libraries. If an unsupported framework or class library is in use, the library will require some modifications or may even have to be rewritten. However, if the migration is in the IaaS (infrastructure as a service) model, code changes are not required because the vendor provides the virtualization, storage, network and servers, while the users handle the applications, data, operating system, middleware, and run times. Therefore, all third-party framework and class libraries that are part of the user-owned and user-managed application software can be migrated as is. The vendor provides the rest: hardware, networking, storage, compute resources, and virtualization. In the IaaS scenario, the server image in its entirety will be migrated to the Windows Azure virtual machine.

Compliance requirements 

Prevalent enterprise compliance requirements and regulations govern important factors such as data locations, whether data can be moved or stored outside the enterprise’s realm, and more. These considerations may be disrupted when the application is migrated to the cloud. Evaluate all such compliance requirements, and make sure they will be fulfilled even after migration.

UI analysis

It may not always be possible to migrate the user interface (UI) directly to Azure using the PaaS model. Some amount of reengineering work may be required to modify existing web application code to use Azure SDK (software development kit), and some non-web applications may have to be kept on-premises.

Database compatibility

Analyze whether the existing database is the best fit post-migration. Database compatibility issues could stem from partially or unsupported features in the target state that are currently in use at the source database.  In such scenarios, you must fix the root cause or implement an alternate methodology for each issue. You may also benefit from the new features by moving to a new database in Azure Cloud.

Security 

Security is an important consideration when applications are migrated. Be sure to provision for the same level of security as before and even enhance the security to levels more suitable for the cloud-based environment after migration. Consider data security, authentication, authorization, and all other applicable security factors. 

Data protection

Put protective measures in place, including backups, disaster recovery, encryption, and other measures suitable for your compliance requirements and business risks. Azure provides multiple services and mechanisms to protect your data. 

Authentication

Analyze the authentication mechanism in the legacy application and evaluate whether it will be compatible with the Azure cloud. Azure Web App supports Anonymous Authentication by default and Forms Authentication, but it may not support your custom authentication. Do you need to develop a new authentication mechanism to authenticate users?

Application maintenance/monitoring

It is also important to identify how logs are maintained and where they are stored. Recognize that cloud environments are dynamic, and performance is not static and not guaranteed. Monitor the performance of compute and data services, and use tools like the Azure Traffic Manager, NewRelic, or AppDynamics to perform real-user monitoring.

Conclusion

Cloud-based analytic platforms are designed to address the challenges of scalability, concurrency, and performance of conventional on-premises data warehouses and BI solutions, as well as to provide easy-to-use-and-customize user interfaces, prototyping tools and self-service business intelligence. The factors listed above should be considered carefully when preparing to migrate to Microsoft Azure.

With 17 years of data management and business intelligence services including seven years in big data services, iTalent has deep expertise in all relevant areas of data transformation and business analytics. If you’re interested in better leveraging your data or have a unique data challenge to overcome, contact me at itbi@italentdigital.com.

For more information about migrating to Azure, visit the Microsoft Azure cloud migration web page.

You may also like:

What is a chief data and analytics officer, and why do you need one?

Elevate your decision-making with Power BI's AI capabilities

How generative AI will impact enterprise community user engagement