Assess your foundation
Before you can sink all the attention and efforts on migrating & modernizing workloads, you need to have established a baseline technical foundation. What I mean by that is you have 100% defined and implemented your Azure architecture, established hybrid network connectivity, determined region(s), understand how it scales, developed naming standards, tagging schemes, and have implemented policies to ensure compliance with these standards you worked so hard to define. You understand how to check for security compliance, how to run reports and remediate findings – heck, who you should even send the reports to. Your foundation sets up the success for the rest of your migration. There are many more facets to this phase, but don’t underestimate it. If you think you’re good, proceed with the recommendation in the next tip, after which you’ll know where your gaps lie.
Be proactive in your migration efforts
It can be a lengthy process trying to establish a migration strategy, what’s the business case? How are the financials? How will we handle disaster recovery? Do we have the expertise to manage the environment?
There are many questions that can cause paralysis by analysis. Some of the most cloud-mature organizations we’ve worked with were proactive in proceeding with a cloud migration before many of these questions were answered. Why? Because nothing accelerates that process faster than doing it. Similarly, gaps are exposed, new questions arise and get answered – and best of all the organization learns. This iterative approach is one of the most effective. Our recommendation is to find a workload for migrating using at least three of the “5 Rs”. Do a lift-and-shift, refactor something to run on Platform-as-a-Service, and re-architect something from monolithic to an event-drive cloud-native application. Those three scenarios will put your organization to the test and help you expose areas needing more focus. The applications can be prod, non-prod, and can be less critical to day-to-day business to lessen the risk.
Even if you have no plans to do a lift-and-shift, your team should have exposure to multiple migration methods, like a tool in their toolbelt.
Tools alone won’t cut it
In order to build a successful and realistic Azure migration plan that will gain the approval of executives and technical folks alike, assessment tools alone won’t provide the complete picture. Don’t get me wrong, all migration plans need solid source-data and analytics to aid in the process, where tools really flourish is gathering this data for us and saving what would have been many hours of script writing and data merging from exports from various systems. To pick up where tools often lack, our recommendation is to assemble a team of various business and technical people to supplement the tool’s data with business and human-driven decisions. Interested in using the “5 R’s” of cloud migration? You know, refactor, re-host, rearchitect, etc. etc.. Those labels and decisions are only possible by getting the right people in the room and hashing it out, the old fashioned way.
Lift-and-shift? Don’t forget about applications
Don’t fall into the trap that server migrations or lift-and-shift is the easy way out, therefor there’s no need to analyze the application portfolio (or build one to do so). You can’t move servers from one location to another without considering what dependencies they have on each other. You also can’t move servers between locations (on-premises, clouds, etc.) without considering the impact it might have should you move the front-end but not the backend database. The best way to mitigate this is to group servers by application/workload and plan to move applications, even if you’re doing it lift-and-shift style.
Find some quick wins
Short and sweet, the cloud is a big tool box, be on the look out for how you can use it to quickly and easily provide value to the organization. Could be a chat bot, a backup service, media service, the possibilities are endless.
Disseminate the hats
Most organizations have organically grown to have a handful (at best) of people who understand the public-cloud and have grown to be the gatekeeper of cloud services. Any and all cloud requests, work, and decisions flow through these few people. In the early stages that’s OK, in fact it’s probably good, Once you have a substantial amount of workloads in the cloud, those few people can quickly become a bottleneck and risk to the business – plus we want them moving on from the menial tasks and continuing to lead the organization in new technical endeavors (automation? AI, new clouds, etc.). To understand better who should be doing what, use the Microsoft RACI chart provided under the Cloud Adoption Framework and customize it to better fit your organizational structure & processes. Once you know who’s going to be doing what, you can develop a training plan to get these employees up to speed quickly.
Start training up on infrastructure-as-code
By now you know there’s no shortage of things to train up on when it comes to cloud adoption. Infrastructure-as-code (IaC) is the concept of managing infrastructure using code, mostly declarative templates in JSON. This concept has taken the industry by storm since cloud computing began to take off. It’s also a major learning curve for most organizations because it presses the DevOps agenda by blending the skills of IT infrastructure and development practices. Most of the workloads you build new or migrate will likely have accompanying templates written in various languages, or maybe a single language if you use something like Terraform. Further, these templates will be needed to standardize deployments of new resources, like a repeatable template for small, medium, and large virtual machines, or a database.
Find out how you’re going to provide this expertise, what tools might be used, where code will be stored, how teams will communicate.