A “lift and shift” migration to Microsoft’s Azure cloud, provides quick redundancy for your services but does not enable your organisation to utilise the cloud’s full potential. Nor is it an efficient use of Azure’s resources. Taking the time to prepare a more selective migration will provide significantly more value to your organisation. Further, a targeted approach can help to mitigate the perils of a mismanaged move, which include impaired scalability, loss of data, and business interruption.
If you’re going to move apps and workloads to the cloud selectively, you’ll need an evaluation strategy and migration plan of attack.
Phase 1 – Evaluate each app’s suitability for migration
Step 1 – Catalogue your apps
Since your organisation is likely using tens or even hundreds of apps, an effective migration strategy will have to start with categorisation. Ultimately, you’ll be assigning a score for each app that will help you to determine whether its migration to the cloud is feasible and worthwhile.
The way you structure your catalogue of apps will need to consider each app’s technical platform, potential security and compliance issues, and the costs of both initial migration and ongoing cloud usage. The end goal of cataloguing is to establish an objective scoring system that prioritises your organisation’s business needs.
The following are the key factors to consider for assigning migration suitability/feasibility scores for your apps:
The hardware, OS, server subsystems, and build code unpinning each application will determine its suitability to migrate.
Security and Compliance
To be suitable for deployment in Azure’s cloud, applications must have effective identity management and permissions.
You’ll need to evaluate not only the direct costs of performing the migration but also the costs associated with potential service disruptions during the migration process.
Continuing cloud costs
Evaluating the costs of using apps in Azure is essential to determine their suitability. Factors to consider here include overall workloads, seasonal workloads, and capacity to scale. Our article “Six Tips for Reducing Costs in Azure” provides a more detailed look at estimating and optimising cloud computing costs.
Are your applications already in the cloud? Before moving your legacy apps to the cloud, you should check to see if your vendor has a cloud-native app already, or there may be a modern alternative that provides cloud-native features.
SaaS applications are born in the cloud and come out of the box with many security and compliance needs already sorted. Consulting an expert on moving to cloud-native apps willl save a lot of time and money.
Step 2 – Assign a score to each app and identify prime candidates
Having assigned ratings to each app, you can more easily identify which ones provide the least difficulty, the highest degree of value, and the lowest risk if migrated. These apps should take priority in the migration process.
Phase 2 – Considering app evolution and rearchitecting
Although it’s unlikely your applications will need to be redesigned entirely, many of your apps will need to be restructured to align with Azure. Before migrating, it’s essential to consider the following:
Linear upgrades for authentication
For apps that don’t need rearchitecting, linear upgrades will still be required. The most common linear upgrade is for authentication. For example, apps currently using Office 365 identity management will upgrade to Azure Active Directory. Note that you’ll need to configure such apps to enable authentication of users through Azure Active Directory or Active Directory Domain Services hosted in an Azure VM or on-premise server.
Common rearchitecting issues
More substantive rearchitecting of apps to be “cloud-first” is much easier than it used to be thanks to the advanced tools now at your disposal. The Azure Container Service, with its Azure App Services features, will be instrumental in the rearchitecting process. Common issues to consider include:
- File persistence
You may need to modify apps to use the Azure Storage SDK or an API to store files that must remain externally persistent in simple or on-premise secure storage.
- Cloud to on-premise integration
Establishing lines of communication between cloud-based apps and on-premise apps can be tricky since the apparent solution – creating an API – is a security risk because it exposes the on-premise server to the public internet. You’ll need to determine the best solution which could entail the establishment of a secure connection between the Azure App Service and your on-premise server via VPN, hybrid connection or deployment of an Isolated App Service Plan.
- Customisation of app settings and connection strings
Defining these variables on the portal such that they can be easily changed will make it much easier to complete the often-needed customisation adjustments for each deployment slot, thereby saving you a lot of time down the road.
Phase 3 – final considerations for migrating to Azure
Before pulling the trigger on migration, consider the following:
If users don’t have sufficient network bandwidth, assets migrated to Azure will not perform adequately. Ensure that you’ve established service level agreements with your internet service providers beforehand.
- Monitoring and alerts
Ongoing monitoring of migrated apps is essential to ensure both their functionality and their resource usage. Establishing a solid asset governance plan is critical in this regard, and the monitoring tools native to Azure will assist. The Azure diagnostic API can be used to set up automatic alerts for when critical events occur.
- Disaster recovery plan
You need to implement a backup and recovery solution that will ensure workload continuity and data protection.
Conclusion to this Azure migration checklist
Our three-phase approach to migration should be used as a starting point to evaluate the compatibility of your organisation’s apps with the cloud.