Although cloud migrations have common patterns and methodologies, every cloud provider brings in a different flavor to it with their services and overall messaging. So, like we discussed earlier, AWS has a 6Rs migration methodology, but when it comes to Azure's methodology, it's pretty simplistic. As per https://azure.microsoft.com/en-us/migration/, it mainly categorizes migration into three parts:

• Discover: In this phase, you assess the current state of virtual machines, databases, and applications in an on-premises environment and evaluate their migration path and priority.
• Migrate: This is the actual process of moving your applications, databases, and VMs to the Azure cloud by using cloud native or third-party tools, which help you transfer the bits by means of replication.
• Optimize: Once your applications and data is in the Azure cloud, you can further fine-tune for costs, performance, security, and management by leveraging better architectures and more cloud native services. Also, this phase is more like an iterative one, as optimization has to be done regularly and repeatedly based on changing applications needs and newer cloud services.

For the preceding three phases, Azure has a set of cloud native services along with a few key partners that it recommends as alternatives. The following is a table that summarizes a few of those options. For the latest information, it's recommended to check out https://azure.microsoft.com/en-us/migrate/partners/:

Apart from the preceding tools, Azure also offers a different messaging service compared to AWS when it comes to hybrid cloud computing aspects. AWS focuses more on its cloud native services and how they can be leveraged or extended to manage resources, even in private on-premises environments, thereby bridging the gap between the private and public cloud to enable hybrid computing environments. When it comes to Azure, it takes it a step further with the notion of enabling a hybrid cloud with a key service in that space called Azure Stack. The way Azure defines this service is as follows:

The key use cases that Azure Stack tries to address are as follows:

• Edge and disconnected
• Cloud applications to meet varied regulations
• Cloud application model on-premises

Now, even though the preceding points may seem compelling to enable a hybrid cloud environment with a singular set of management tools and DevOps processes across the Azure public cloud and Azure Stack, there are some key cons as well, which the users have to be aware of in this approach. One of the main challenges here is that Azure Stack takes the user back to the days of managing servers and data centers, where you again have to do the heavy lifting around racking, stacking the Azure Stack boxes, and then of course manage the cooling, power-related operational aspects to keep it up and running. So, net-net, although Azure Stack enables deploying containers, microservices, and PaaS environments locally, since you still have to manage the underlying infrastructure, it is not a truly cloud native type of architectural pattern.