BEST PRACTICES FOR PREPARING YOUR CLOUD MIGRATION STRATEGY
Written By: Samuel Torrero, Azure Presales Architect at Maureen Data Systems (MDS)
When thinking about migrating to the cloud there should be several aspects to cover before starting the actual migration, e.g., which migration approach to take, your cloud operations model and Landing Zone. We will discuss the basics of a good foundation to start with your migration to the cloud using the best practices.
You can also check out the webinar on this topic here:
- Best Practices for Preparing Your Azure Migration Strategy (ENGLISH)
- Planeando tu estrategia de migración usando las mejores prácticas (SPANISH)
To understand what we are responsible for the cloud we have the Shared Responsibility Model explained below. This model explains the parts of a workload that each part – cloud vendor and client – are responsible for; as you see, while you move forward from IaaS to SaaS, you as a client are responsible for less, which means that your team has more time available to focus on valuable activities instead of maintenance activities.
The goal of migrating an application to the cloud is not leaving it only in an IaaS model but modernizing it to a PaaS model. But we can discuss the specifics of that topic on a different occasion.
As we can imply from the options we have in the Shared Responsibility model, there are several options when it comes to migrating an application to the cloud:
We have two options considering IaaS scenarios:
- Lift & Shift: this is the most common scenario. Is the cheapest and fastest way to migrate an application as it involves “copy-pasting” your data on-premises to a copy of the servers on Azure. In a good scenario we can have an application up and running in as little as one week.
- Replatform: this scenario is similar to Lift & Shift but a bit slower since it considers upgrading the OS of the application, for example from Windows Server 2003 – which is not supported on Azure – to Windows Server 2016.
Another two options for PaaS scenarios:
- Rearchitect: this option involves changing major components of your application to make them cloud compatible, like using some PaaS services. A good example would be migrating an application using an Azure SQL instance instead of a SQL Server on a VM.
- Rebuild: this option implies building the application from scratch using cloud native technology; a good example would be to use Azure Kubernetes Service or Azure Functions to run the application code.
Considering SaaS, we only have one option available: to replace the application. Sometimes the effort of rebuilding or migrating an application is not worthy and it may be a better alternative to replace the application. An example of this could be replacing an in-house built CRM for an out-of-the-box solution like Microsoft Dynamics or Salesforce.
Finally, there are some applications that are “rediscovered” in the migration phase of a company which are no longer used. In this case the best option is to completely retire that application, so it no longer represents cost to the company.
Now that we know our options, we should also be aware of the general process to follow when migrating an application. MDS follows an agile migration process that is aligned with the Microsoft Cloud Adoption Framework – which we will discuss in a moment. This process involves using SCRUM for our sprints and different phases, which also have a templatized backlog of activities to improve efficiency and velocity.
Below you will find a diagram to better explain our process:
As you can see, we make use of different tools along the process to help improve accuracy of the discovery, as well as keeping track of the activities and testing.
Microsoft Cloud Adoption Framework (CAF)
CAF stands for Cloud Adoption Framework. It is a combination of Microsoft’s best practices with Partner’s and Client’s experience to create a repeatable framework that serves as a guideline for Cloud Projects, containing best practices for each of its phases.
We could spend at least 2 hours explaining the CAF in a deeper way, so if you want to know more about it get in contact with us at MDS. We can offer you and your team a workshop to understand the CAF completely and start using it.
Each phase should be followed carefully and implemented through the cloud project. It doesn’t matter if you have already started migrating, or if you already have workloads running on Azure; you can start using the CAF from the phase that you are at right now! The migration activities are located on the Adopt phase, but all the previous preparation is found mostly on the Ready phase.
Regarding Azure Landing Zones… we can see them as the foundation of a building. Prior to start building it we need to make sure that water, electricity, gas, etc. are set up and ready to give service to the building. In a similar way, Landing Zones help us to have all the aspects that our application will use ready before having the application up and running.
We can divide those aspects into two groups called Landing Zones Design Areas: Environment areas, and Compliance areas.
Environment areas should be fundamental in a Landing Zone, and most of the time they are configured from the beginning of every kind of landing zone. Compliance areas are not always needed, depending on the landing zone approach and the application needs.
When talking about Landing Zones there are different approaches for deployment. To decide which approach to take we must first define our Cloud Operations Model:
- Decentralized Operations: normally companies that have an application as their core business benefit from this model. This model gives full confidence to the application team regarding Azure security, billing, IAM, organization, networking, governance, management, and DevOps.
- Central Operations: this model is found in more conservative organizations. It can be identified because these organizations are focused on control by using a centralized IT management team that controls security, IAM, organization, etc.
- Enterprise Operations: more modern organizations use this model. This model focuses on democratization of resources, allowing each user and team to have certain amount of control of their own security, governance, IAM and billing, and take care of guardrails defined by the organization by using services like Azure Policy.
- Distributed Operations: very large, global organizations can sometimes use this model. In this model we have a combination of centralized and enterprise operations; it could be that in a specific location one its used and in a far location another one is used, depending on what is more convenient for that particular location given the context, goal and people.
Once we have defined our Cloud Operations Model, we can talk about the different deployment approaches for Azure Landing Zones. All landing zones should take a conceptual architecture as a baseline; this architecture takes into consideration best practices, a scaled-out mature environment and a strong foundation for management, governance, and security processes.
We can have the following deployment approaches for our landing zone. Before diving into the two different options, it’s important to make mention of the Azure Landing Zone Accelerators; these are templates that have built-in best practices, configurations for key governance policies, processes, and tools. Their implementation is portal-based so they are a great option to deploy fast and easy. Sometimes more customization is needed, and that’s where our two options come into play:
- Start small and expand: this option considers only the needed design areas for low-risk workloads. The goal is to deploy a landing zone in the fastest way possible with the minimum requirements for that particular application and continue to improve the landing zone model until every design area is considered.
- Enterprise scale: this option is better suited to applications that require built-in security, compliance, governance, or management. Enterprise or mission-critical applications can benefit from this approach, since it considers all the aspects that the application needs right from the beginning.
Both options have available templates like Azure Blueprints or Terraform modules, which can work as a baseline to further customize to your needs. Also, there are partner landing zones available – these are partner-developed landing zones that also can be used as a baseline to be implemented either by your partner or by you as a customer. When deploying a landing zone, you should review each of the different offerings available and choose whichever fits your application, motivators, and scenario best.
Your Cloud Operations model is also an important variable to consider – enterprise operations will normally benefit from an enterprise scale landing zone, since this approach considers the implementation of Azure policies, governance, and management from the beginning, which aligns with the service democratization approach of that operations model.
Azure Migration and Modernization Program (AMMP)
I want to wrap up by quickly talking about AMMP. AMMP stands for Azure Migration and Modernization Program; this is an initiative from Microsoft that’s available to clients and partners like MDS. Through this offering clients can have access to:
- Implementation guidance using Microsoft Cloud Adoption Framework and Well Architected Framework.
- Technical skill building.
- In-depth assistance from FastTrack for Azure engineers.
- Free tools/automation with Azure Migrate.
- Expert help from specialized partners like MDS.
- Cost-effective offers and incentives.
Microsoft is willing to co-invest with you to make your migration or modernization project a reality! MDS qualifies to nominate clients for this program, so don’t hesitate to get in contact with us – we can take a look at your project, understand it, nominate you and help you reach your business goals through good cloud migration, modernization, management and governance using Microsoft best practices.