The public cloud beckons. Gartner says that nearly half of large enterprises will have hybrid cloud deployments by the end of 2017. That significant growth stems from the clear business case for public cloud adoption. Enterprises want more cost-effective migration, disaster recovery and business continuity options. The public cloud delivers with a low cost, pay-as-you-go model. Elasticity helps IT teams manage unpredictable application needs. Teams can set their budgets on time and still adapt to shifting resource demands thanks to the public cloud’s economic advantages.
However, companies are still figuring out how to begin incorporating public cloud services into existing IT operations. High-priority considerations early in the process include: streamlining the migration process, reducing risk wherever possible and targeting early wins. These should be a CIO’s top concerns as the process gets underway.
In this slideshow, HotLink, a cloud solution provider, highlights six best practices to help IT leaders stay focused and see their businesses through a successful cloud migration.
Migrating to the Public Cloud
Click through for six best practices organizations should consider before migrating systems to the cloud, as identified by HotLink.
Understand the Basics
School yourself and your team on the basics.
You know those new-user guides? Don’t ignore them. Watch the tutorials. Read the “getting started” tips. Start by building one new workload. Once you’ve realized success, try out a few free migration or import tools for existing workloads. Then begin with straightforward projects, such as disaster recovery of workloads. You’ll gain public cloud experience while providing tangible benefits out of the gate.
Check Out the Technical Support
Before you pick a provider, check out the technical support.
A public cloud provider without available and skilled technical support probably won’t be a good value in the long run. Understand how to access technical support, who would support your team, the type of issues they can address, what SLAs they have and how escalations are handled. Also, be sure you understand the support cost structure. These are the people you’ll need to count on to make sure your cloud-based operations run smoothly. Vet them before you make a final vendor selection.
Have an Application Plan
Don’t make a move without an application-specific plan.
Which applications do you want to run in the cloud? Will certain workloads be in the cloud permanently, or will there be some you only use occasionally? Identify exactly what will move over – and when. Plan to start simple, and go slowly. The mission-critical, complex applications aren’t your best candidates for a pilot project. Look for a simple application stack to help you ease into cloud migration.
Work with Manageable Groups
Avoid the big bang approach.
You can’t realistically migrate large numbers of major workloads in a short period of time, as much as you might want to go big from day one. Instead, define a manageable group of virtual machines (VMs) for your first import, and take the time to test them completely before expanding your scope. Once you’re satisfied that the first imported VMs are performing well, tackle the next application stack. If you start incrementally and test continuously, you’ll avoid a long list of issues and have much more successful outcomes.
Communicate with Users
Communicate with your users about what’s to come.
Any new project rollout comes with some unexpected bumps in the road. Before you expose all of your users to that kind of turbulence, test-drive your public cloud initiatives with some friendly alpha and beta testers. Let your early adopters see you through the first stages before you open public cloud application usage to your entire audiences. This can make the difference between success and failure over the long term.
Above all: test.
Migrating your first VM to the public cloud is a major milestone, but simply powering on that VM is not testing. You need to have real users test that instance – the friendly testers at first, and then your general audience. Testing is the only way to identify hidden problems, such as broken dependencies. Anyone accustomed to using the application will spot missing configurations, and those users will make up your best testing team.