Over the years, cloud adoption and cloud migration initiatives have skyrocketed, and for good reason. There are tons of benefits to moving your workloads to the cloud: ease of access, less stress on maintaining hardware, and operational expense spending. However, as we’ve begun to move our clients to the cloud, we’ve found that doing a detailed analysis ahead of time will help make the decision on if adopting a cloud environment is right for you, what the costs will be, and what your cloud migration plan will look like.
Mirazon is a Microsoft partner, and while we assist clients with AWS, Wasabi, and other cloud services, we wrote this with Azure in mind. Drop us a line if you want to talk about your cloud migration plans in more detail, or check out more of our blogs about Azure and cloud computing!
Step 1: Before Making Your Cloud Migratino Plan, Analyze Existing Environment
Azure has a tool called Azure Migrate that will allow you to assess your on-prem workloads over a period of time. Depending on your hypervisor, there are different flavors of virtual appliances that can be deployed. This appliance gathers performance metrics that will help you size your cloud virtual machines (VMs). You can use the assessment section within the Azure Migrate tool to get recommendations for proper instance sizing, based on the observed workloads. Personally, for my clients, I like to let this run for about a month, because it gathers enough data to give me a more accurate sizing recommendation. Once you have these recommendations, you can derive more accurate pricing data for estimating and budgeting purposes.
It also has a dependency analysis tool that can be deployed to each on-prem VM. This tool can help you understand application dependencies for each one. This analysis will allow you to properly organize your batches of server VMs for your migration plan, which is critical for order of operations. If a certain three servers work together and need each other to function, then you know you need to batch move those together, for example.
The assessment tool can also help you rightsize platform-as-a-service offering such as managed SQL instances, or managed SQL databases. The tool’s mainly focused around their IaaS offering, but does help with a variety of other functions and systems. Here’s what the Azure console says:
Discovery and assessment of SQL Server deployments running in VMware, Microsoft Hyper-V and Physical/ Bare-metal environments and IaaS services of other public clouds is now in preview. [New] Discover, assess, and migrate ASP.NET web apps running on IIS servers for migration to Azure App Service. [New] Containerize your .NET and Java web apps and deploy on Azure Kubernetes Service and App Service containers. [New] Build a business case to understand the return on investment for migrating your servers, SQL Server deployments and ASP.NET web apps running in your VMware environment to Azure.
Step 2: Applying this Data and Making Your Cloud Migration Plan
Rightsizing is very important to optimize costs in the cloud. Taking an apples-to-apples approach in regards to CPU, RAM and disk specs from your on-prem equipment to your cloud instance can be cost prohibitive. We recommend finding the optimal instance size based on actual workloads, and this may not align with the specifications you have on your physical servers and storage. If you provision something too small to begin with, you can always resize it later. It’s better to start small and then resize as needed.
Additionally, understanding dependencies and the flow of data is critical to deciding at all if moving to Azure is right for you, and then will inform how you plan the migration itself.
Mapping the traffic flow of your on-premises environment is also very important. This will influence estimations of egress/bandwidth costs, and affect how you design your cloud environment. You can typically pull this from your current switching or firewall solution.
Once you’ve run through the assessment and gathered your dependencies and analyzed your workloads, you can begin to build your migration plan. This will define your order of operations, while understanding what your application interdependencies are, so you can line out your step-by-step plan.
Step 3: Making Your Cloud Migration Plan a Reality
This is the hard part. You have a variety of obstacles and things you need to do – get your downtime windows and your failback plans, communicate with your stakeholders, organize your team, delegate the tasks, build the cloud environment, and begin to move the data. Oh, and pray to the IT gods it goes well.
This is where using a strategic partner like Mirazon is great. We’ve done this more times than we can count and have a lot of experience. We can help you create the plan, execute the whole thing from start to finish, or augment your team to help you get the project done on time.
A Few Ancillary Takeaways
Implications for your DR Plan
Keep in mind during the planning phase that you need to fully understand what your new disaster recovery and business continuity process will look like with cloud workloads. Your roadmap should incorporate the proper backup and replication strategies and you need to validate that the platform features you’re using support this plan.
Also consider how you’re doing DHCP today. If you want to move DHCP running on a Windows Server VM to the cloud, you’ll need to come up with an alternative solution to handle DHCP roles. Azure does not support running DHCP on virtual machines.
It’s not unusual for people to assume that the cloud provider takes the onus on maintenance, which would include security. It doesn’t. Evaluate options for how you’re going to maintain and even enhance your security posture when you adopt the cloud.
If you have questions about whether the cloud is right for you, and how you can start making the move, call us at 502-240-0404 or email us at email@example.com for a free consultation!