By Ryan Kelly
At 10th Magnitude, we’ve worked with hundreds of clients to help transform their businesses with Microsoft Azure, and we’ve learned that there are many ways to go about migrating your applications to Azure.
We’ve found that Azure migrations are like snowflakes; each one is different, so there’s no one-size-fits-all solution. Your current data center plays a huge role in migration, but let’s not forget about factoring in configuration, network requirements, business goals and available resources. It may seem daunting to choose a migration approach based on all of these factors, but in this blog post, I’ll outline some considerations that can help you determine your individual path forward.
What problem are you trying to solve?
The first step in this process is to figure out what problem you are trying to solve. It may sound simple, but this is critical for successful cloud adoption.
“I want to save money” is the most frequent answer we hear. But what is it about your current solution that is costing you so much? Is it licensing? Aging hardware? Scaling? Pinpointing the specific issue will help you focus your solution.
“I want high availability” is another common answer. But is your application ready to take advantage of the features in Azure that allow for high availability? Are you ready to invest in performing some application modernization, such as distributed caching, a clustered database or external session management? A plan forward may mean migrating piece-meal, and that’s completely doable.
“I want to deliver my software faster” is something we also hear that the cloud promises. But do you currently have a continuous integration strategy? Without changing your deployment processes to fit your new cloud world, the same issues you experience on premise will continue to haunt you as well as raise additional concerns, such as resource governance. Manual installations, virtual machines (VMs) that become pets or are abandoned and not deallocated can become sources of great headache just like on premise.
How does the cloud really save you money?
There’s a misconception that just by moving VMs from on premise into the cloud that you can save money. Sometimes this is true depending on your current data center contracts, but for the most part this kind of “lift-and-shift” ends up costing you the same amount (or more).
Capex vs. Opex is what a lot of people point to when talking about cloud savings. Taking the hardware, extra IT resources and power costs (capital expenses), and converting them to a managed, pay-as-you-go approach (operating expenses) seems like a big win upfront. But remember, because Microsoft is now taking over those aforementioned headaches for you, they’re factoring in those costs, as well as the cost of keeping resources open for new provisioning. It’s important to do your homework first and see if this conversion is enough to save you a buck or two.
That being said, Azure does allow you to deallocate your VMs and stop paying for them, which is an easy optimization for non-production environments—a flexibility that you probably don’t have in your current data center. The ability to take advantage of Platform as a Service (PaaS) features can also greatly help reduce cost.
IaaS vs. PaaS is probably the toughest, yet the most rewarding decision you can make. By taking advantage of Azure’s PaaS features, you can gain high availability, auto-scaling and cost savings all in one. What makes it difficult is that it will most likely mean changes to your application. It’s fine to start in Infrastructure as a Service (IaaS) and move some features of your application to PaaS later, but new applications should try to use PaaS features as early as possible to maximize cost savings.
Speed of delivery can seem intangible, but think of the time your developers and IT personnel won’t be spending on all-night deployments. The key to keeping up with the current rate of change in the IT world is to be able to deliver your features faster than your competition—to be able to pivot and iterate quickly, fail fast and often, and deliver a quality product with more business value. By taking advantage of the ease of deployment to Azure (especially PaaS components), this is within your reach, making your developers and IT folks happier and more productive.
Let’s talk strategy
It all starts with discovery. The number one priority that will help make your migration clear is starting a discovery process. This not only includes finding out what Azure has to offer, but also figuring out what your current environment looks like. I bet there are a lot of software components, network requirements, network shares and users that have been slowly added to your environment over the years and not documented. Knowing the shape of your current on-premises environment will allow you to have a clearer picture of what comparable features the cloud may have to offer you, as well as inform your discovery process within Azure.
Low-risk, high-ROI workloads go first. When Microsoft has migration discussions with customers, they find that non-production systems far outnumber production applications. These low-risk environments are the perfect candidates to be the “canary in the coal mine,” if you will. How do your applications behave in Azure? What key considerations do you need to take into account? Moving these lower environments will help deepen your discovery and expose the “unknown unknowns” that can so often rear their ugly heads when making the leap to a new platform.
Focus on your applications, not servers. By giving due diligence to each application instance, the needs of the application can be removed from the particular server, allowing you to more easily treat your servers like cattle, rather than pets. When you can recreate a server with its installed applications, you put yourself in a prime position to deal with failover, disaster recovery and scaling.
Test, test, test…then test again. Take this migration opportunity to do a full regression test of your applications. Formalize your testing plans so that they are repeatable by others and tribal knowledge isn’t lost to the ether. I would recommend having a test plan for—at the very least—a smoke test, full regression and performance test. This will be the bare minimum to give you some level of comfort that your applications are working properly and respond within an acceptable timeframe.
Think hard about HA and DR requirements. High availability and disaster recovery can be costly endeavors in more ways than one. Your mission-critical applications are very important and can severely impact your business if they go down, but you also need to consider the cost of availability. There are many options and offerings in Azure, and some are going to cost more than others. Clustered servers in availability sets (the IaaS scenario) may be easier to implement with your current applications because less of a modernization effort will be necessary. However, keeping multiple copies of databases with ingress/egress costs and having extra servers around (plus factoring in design and setup of such a system), makes this option a higher price tag. It may be worth the effort to use the inherent high availability and scalability of the PaaS features. As I’ve mentioned before, this is most likely to cause application changes, but by taking advantage of the platform, you ultimately save time in design, setup and execution.
Planning and execution
Leverage software processes that you already know. The easiest way to get started is to treat the migration just like you would a software project. Many have adapted the agile methodology to great success because of the tight feedback cycles, focus on delivery and ease of course correction. By iterating over tasks, your team can apply the knowledge that they have gained from previous efforts to make better estimates. As priorities change, so can the order of tasks that the team completes. The complexities of the migration can be broken down into simple tasks with clear acceptance criteria to determine completeness. As a result, it will be easier to gain efficiencies and predict an accurate timeline.
Cross-communication will be essential. It’s likely the team completing your migration will be cross-functional—and potentially large. They will need to communicate effectively and transparently with each other. This is often hard when each function within the team has its own goals. Therefore, you need to set one goal and have one team. This cultural shift is known as the DevOps approach and has caused a disruption in how companies think about their organizational and workflow structure.
There’s a lot to think about when approaching a migration, but by breaking it up into pieces, doing due diligence in discovery, and creating a highly effective team with new and existing processes, it becomes much easier to approach. Once more, I need to stress that every migration will be different with regard to business and technology needs, but the guidelines I have laid out should set you down the right path.