Cloud migration projects continue to garner interest from organizations seeking a variety of benefits. Executives understand that these complex projects require multi-disciplinary teams to increase the odds of success and realize the promised ROI (return on investment).
Unlike piecemeal approaches, a data center move to the cloud presumes you will decommission your existing data center within a reasonable time-frame. It also presumes that you will follow through with necessary steps to realize cost savings such as:
- Actually retiring physical infrastructure
- Actually reducing IT (Information Technology) staff where necessary
- Actually realigning IT roles and processes to provision, monitor, and service cloud-based infrastructure
- Abandoning legacy applications in favor of modern, agile applications that are cloud-ready
- Allocating outside resources to get evaluations done in a timely manner versus internal-only evaluations that commit shot clock violations with regularity
Let’s assume you’ve properly evaluated cloud vendors for security, financial stability, and desired service level agreements. What makes a wholesale move to the cloud different than migrating to a physical data center?
Quite a few things will be different, but let’s discuss just three elements that should command your due diligence.
Performance will be different
It might be better or worse and you certainly don’t want to learn this after you move. You’ll need to model, measure, and test all of your applications before moving. Different applications will require different approaches to getting the performance you want.
It’s likely that your monthly bandwidth budget will need to increase and you might have to spend money on WAN (Wide Area Network) optimization and redundant networks. Most organizations have no idea what performance demands exist with their current applications because they’ve never measured them. Generalizing versus measuring is certain to yield unpleasant surprises.
Incident Response will be different
When you rely on a matrix of service providers, your response to incidents should be well thought out and even rehearsed per application. Your cloud providers may not be able to give you satisfactory estimates of time to fix or even the reason for outage.
Some companies don’t even have a formal Incident Response process documented. Such ad-hoc approaches will be exposed as amateur when you move to cloud. If you don’t revise (or build) your Incident Response plan prior to moving to the cloud, you’re just asking to do it one outage at a time.
ROI will be different
Like a weight loss program, the ROI advertised is not typical and your results will vary. Plan on duplicate carrying costs while you work out the kinks. Plan on application development projects to move in-house or legacy applications to cloud-friendly platforms. Plan on organizational training and education to change the way your company expects to use IT infrastructure. Plan on cultural changes to your IT staff that could involve re-staffing the right kinds of skills. Plan on resistance and clinging to physical infrastructure that will decrease your ROI.
What about a roll-back’s effect on your ROI? Yup, plan on a roll back if the cloud affects your revenue or reputation. Of course, testing minimizes roll-backs and ROI will elongate with more testing time.
Moving a data center to the cloud is a multi-disciplinary project that requires project management, a focus on business objectives, and a deep understanding of the applications being moved. Devote the budget and resources to understand how to plan and execute this move for a successful outcome.
Maximize your move to the cloud with governance and oversight and a healthy does of realistic expectations that the change will introduce.
This book pays for itself in a few minutes by saving you days of searching online.
I wrote this book to strip the mystery from a data center move, and to:
- jump start project managers who want to understand the WBS (Work Breakdown Structure) category foundations
- inform Executives about their budget process and cost model
- warn Stakeholders to get Governance right
- slice the Gordian Knot of decision paralysis
- arm Human Resources to recognize key contributors versus the lazy, blanket recognition that demoralizes technical staff
Written in plain language, and organized to accelerate everyone’s understanding, the book is particularly useful as a tool to quickly on-board others.