Three Questions to Ask Before You Start a Cloud Migration
Three Questions to Ask Before You Start a Cloud Migration
Can you? Will you? Should you? We're asking the important questions you should examine before making the jump to cloud computing.
Join the DZone community and get the full member experience.Join For Free
While many times cloud migrations can feel like they are at a standstill or going way too slowly, there are also times where migrations can actually be moving too fast. To determine whether your migration is moving along at the right pace, there are several things you might need to consider, such as your budget, your business requirements, and your personnel.
What Are Your Business Requirements?
There is an old saying: If you don't know where you're going, then any road will get you there. This applies as much to cloud migration as to any other technology transformation. It is important to know your strategic goals and success criteria at the enterprise level, not just for the project itself.
While cloud migration is typically a good thing, doing so without a fully developed plan can make it very difficult or even impossible to determine whether the migration was a success in the end. As mentioned, your business requirements should include criteria not just for IT, but also for the business side of things. If this doesn't happen, it is entirely possible for the migration to appear successful to one group, while the other thinks it did not go so well.
For example, the migration could meet business criteria of saving money (a success for the business team), but some features IT needed such as autoscaling or one-click server provisioning was not implemented. The business team might feel this migration was a success while IT would feel like the migration fell short of the goals they had in place.
To help with this, it is important not only to have success criteria for both sets of teams; it is also important to set goals that fit the context of the type of migration you are doing. Using the previous example, perhaps IT wouldn't have felt the need for one-click server provisioning if the goal was simply to move a single app over to the cloud to save some money on server costs. If the context and goals are both clear, it becomes much easier for the various teams to evaluate the success or failure of the migration, and the teams are more likely to come to similar conclusions.
Do You Have the Right Skills?
The demand for advanced skills in cloud and software development is already several times larger than the current pool of talent and resources can support. There's no indication that this gap will shrink in 2018.
While this tends to fit it tightly with the budget requirements, it is a good idea to try to get the right personnel in place to keep things at the pace you are needing. Given the quote above, this may need to be done by training members of your current IT staff so that they have the necessary cloud skills. Since these skills are in a shortage, it is certainly valuable if you have employees that already have these skills or those who can learn them and excel in a new or updated role.
In any case, making sure your personnel have the skills they need will help meet your business requirements as well as to ensure that important issues like security are not going unnoticed!
Just a few years ago the conversation around cloud was focused on moving virtualized on-premises infrastructure to either private cloud or public cloud environments. Today these multi-cloud platform options are being used to build new applications and the world of Dev and Ops are moving even closer together. Skills in infrastructure management and virtualization are giving way to declarative scripting and knowledge in open source projects from the likes of HashiCorp. One benefit that Morpheus provides is that both Dev and Ops get what they need without requiring a major skills upgrade.
Do You Have the Right Tools?
Large numbers of organizations have adopted cloud services to achieve cost savings, flexibility, and scalability of IT infrastructure. However, managing these services is often easier said than done, involving complexities like management and cost evaluation for multiple services running across multiple cloud platforms, resource consumption details, integration with other enterprise tools, and other factors.
One of the challenges of cloud migration is finding the services you need for your situation. In many cases, it can make sense to use more than one cloud provider. Perhaps what you need is a particular setup from AWS along with a particular setup through Azure. Later, maybe even a Google Cloud server may be needed for another set of tasks. This can mean that the knowledge needed and/or the learning curve for IT staff to handle these various tools becomes more and more expansive as your cloud implementation grows.
If you add hybrid clouds, provisioning, reporting, and the numerous other needs of the IT and business teams, this can begin to look overwhelming pretty quickly. Thankfully, there are cloud management platform tools such as Morpheus that allow you to unify orchestration of these tasks from a single control plane while still letting you utilize best-of-breed elements through API integration.
What do these types of tools do? Consider the example from above where an organization needs to work with two, three, or more cloud vendors. Rather than needing your IT staff to have or learn the administration for each vendor individually, you can instead have them master a single point of management which makes provisioning resources from AWS the same as it is for Google Cloud or Azure!
With a tool like this, hybrid clouds and reporting are also made a breeze and can all be managed within that single tool. This improves efficiency and also reduces stress levels of IT staff that need to manage all of these resources. This is a win for both business and IT, and can certainly be a great asset to your cloud migration!
Published at DZone with permission of John Pollock , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.