Considerations when migrating from AWS to Azure
As public cloud has become an integral part of any organization’s cloud strategy, cloud migration has been a much-discussed topic. The on-premises-to-public cloud migration (whether Azure, AWS or Google) has become a well-worn path.
There is a wealth of information about how to perform these migrations, and many partners and tools are available to help you make this migration easier. But what about organizations that have already migrated their applications to a public cloud but are now looking to make a switch?
If you are pondering a public cloud to public cloud migration project, this will give you some idea of what to consider in making the move, and reviews some reasons why an organization may be considering these types of migrations. I’m also going to pull some real-world examples and lessons learned from one of our recent AWS to Azure migrations.
Why would you want to perform a public cloud to cloud migration?
We are seeing an uptick in public-cloud-to-public-cloud migration projects. In theory this should be inevitable as more and more organizations run the majority of their applications in public cloud. Here are some specific factors that may lead an organization to make a change:
- Cloud supplier diversification – Enterprise clients may benefit from leveraging two (or more) public cloud providers as a procurement strategy or to hedge against vendor lock in.
- Staff skills – Cloud skills can sometime be scarce in the market. Clients’ in-house skill sets or partner skills can drive cloud platform decisions or changes in direction.
- Cloud transformation maturity – As organizations deepen their level of cloud maturity, early pilot projects may bear reconsideration to take advantage of new capabilities or to consolidate public cloud providers.
- Cloud provider relationship or agreements – Vendor agreements can drive cloud decisions. An example of this is migration to retire contract commitments or taking advantage of unique licensing benefits such as Microsoft Hybrid Use Benefit (HUB) licensing.
- Mergers and acquisitions – Even in the cloud, M&A activity can drive migration from one cloud vendor to another.
Considerations when migrating from one cloud provider to another
When performing a public cloud to public cloud migration, here are some considerations based on our experience, with specific examples, which come from a recent migration project where we successfully migrated a few production application landscapes from AWS (EC2 with S3 storage) to Azure. The system was based on the LAMP stack with some specialized email handling and archive retrieval workflows.
Migration approach
All of the major cloud providers have great documentation and tools for migrating into their cloud. When you start looking for cloud to cloud, the level of documentation and effectiveness of toolsets becomes more limited.
In our example migration, Microsoft has a great solution for migration to Azure – Azure Site Recovery (ASR). ASR even supports migrating workloads out of AWS. Since our client wasn’t looking to make many application changes, we immediately looked into a Lift-and-Shift approach with ASR, to migrate their environment as-is.
The challenge came in when we inventoried the source environments and realized that the server OS was built on the Amazon Linux AMI. This OS is not supported in Azure, which necessitated that we pivot our approach to the tried-and-true re-platform approach, building the new OS and migrating the application configuration and data.
Support nuances
There can be support nuances between all of the major cloud providers. You need to do your homework ahead of any migration to be sure all of your applications, OS’, and especially network devices and software are supported.
In our migration example our client had a group of developers that worked out of a small office and required a site-to-site VPN. The device that terminated that VPN at their office supported the AWS VPN tunnel, but not Azure VPN tunnel. We implemented Azure P2S VPN to get group of developers secure access to Azure.
Vendor lock-in and data portability
Many cloud providers have their own unique services and features. This may be part of the reason you selected that provider in the first place but now they may contribute to lock-in. This could include PaaS services, proprietary formats and APIs. Connectivity between providers can also be a challenge. Take a look at a recent Navisite blog post on AWS to Azure VPN connectivity.
Hidden cost of migration
Cloud providers make migration to their platform as easy and low cost as possible – but you’ll likely not enjoy the same benefit when exiting. Keep in mind most cloud providers charge some kind of data egress charge. This means that they will charge you for the data that leaves the cloud provider. This cost can add up if you had large amounts of data you need to migration. In our project our client had substantial data to transfer and these charges added up.
Skills transition
One of the biggest challenges to cloud migration has always been lack of available skills and expertise. When you are considering a cloud provider change, this challenge may reemerge. If you have a team of cloud engineers who have worked on AWS for the last 3 years transitioning to Azure is going to take some time. The skills may have some similarities but there will need to be a transition of skills or enablement.
Understand application architecture
As with all technology projects, life is easier when you fully understand your application architecture. This is a critical component of any cloud migration, and cloud-to-cloud migration is no different. Taking the time to fully understand your application dependencies, configuration and architecture will be time well spent before any migration.
In our migration example, documenting the application architecture was our first step in the migration process and came in handy when in the end we had to take a re-platform approach. As the code itself had been heavily maintained over many years, we took care to identify configuration items embedded within the code.
Robust testing
Planning for and executing a rigorous test strategy likewise applies for all technology projects. By closely coordinating with client management and end users we developed a test plan that was thorough, covering even rarely used or specialized workflows. This enabled us to detect and address issues while keeping the overall project on task.
The takeaway
These considerations may provide some food for thought as you evaluate a change in cloud providers. The best bit of advice I have heard is don’t wait until you have made the decision to migrate to have a migration strategy. As with any vendor relationship, it’s always good to have a “plan B”. With any cloud provider you should always consider and keep in the back of your mind how you can avoid lock-in and how you may execute a migration project.
A colleague of mine, Dean Hunter, once told me that cloud migrations are “easy until they are not”. You may have all the tools and documentation at your disposal, but still run into challenges. That is where partnering with an experienced cloud service provider such as Navisite can be invaluable. We have completed hundreds of cloud migrations and have the experience to help you through these projects and can help you understand and weigh the costs and benefits of any migration.