How to Move to the Cloud

There's a popular misconception in many enterprises that they will completely escape the burden of CAPEX by moving all their systems to one or more public Cloud Service Providers (CSPs), and that benefit alone justifies the move. The truth is that any enterprise who wants to leverage the benefits of cloud computing will probably end up with a mixture of cloud and on-premise workloads. Furthermore, CAPEX avoidance is not, in the end, the sole driver for moving an application to the cloud. The challenge, then, is to determine what moves to the cloud, what stays on-premise, and how to plan out the shift. Here are a few recommendations on how to actually move to the cloud: 

Create a Cloud Strategy

Everyone wants the move to be successful. But how will anyone know what success looks like if it hasn't been defined? Moving systems to the cloud in and of itself is not a measure of success. Only by achieving measurable business objectives will your enterprise be able to measure the success of a move to the cloud. To do this, a Cloud Strategy needs to be defined by the enterprise that clearly describes any desired business benefits, how soon those benefits need to be realized, and what the portfolio landscape needs to look like to produce those benefits.

Let's assume you have a current, accurate CMDB and already know what's running on premise. If not, get an inventory of your application portfolio going ASAP, because it's critical, when creating an Enterprise Cloud Strategy, to have a solid understanding of the big picture. Before moving a single system to the cloud, an enterprise should understand the business benefits it wants to gain by such a move, as well as the time frame in which it wants to realize these benefits. Obviously, this requires having a solid understanding of the future desired state of the enterprise system portfolio.

Prioritize the Portfolio

As noted, having an accurate and current CMDB is an extremely helpful, and arguably necessary starting point for a successful migration plan.  Whether your enterprise has a good CMDB or not, you'll definitely want to map out all the interdependencies of the infrastructure and network components of your entire portfolio using an application discovery and dependency mapping (ADDM) tool. A quick search on ADDM will provide you a longer list of third-party tools than we have space to list here.

Once an ADDM has been created, it's a relatively simple exercise to group the enterprise portfolio into several migration phases, or steps, based on the complexity and business impact of each of the applications in the enterprise portfolio. Gartner identifies four basic cloud migration categories, including:

• Workloads that will not migrate: these are typically applications that are not architected well for cloud (i.e., x86 workloads), or application slated for retirement. Both represent either cost-prohibitive or very low value options for the cloud.
• Low-risk workloads: typically, these are non-DR workloads, including lower-level development, training and "demo" environments that at worst represent an inconvenience if disrupted, and at best, a learning opportunity for the more critical workloads to come.
• Moderate-risk workloads: these are typically workloads that are not critical to daily business execution, but are still considered important to the business. Examples of such applications could include Document Management, Business Intelligence, Project Management or Office Workflow applications.
• High-risk workloads: These short RTO/RPO applications include ERP, Supply Chain and Distribution applications, or any other application that's critical to the daily mission of the enterprise.

Asses the Business Impact

While an Enterprise Cloud Strategy addresses how Cloud fits into the business objectives of the enterprise system portfolio, and a prioritization exercise will help you group the enterprise portfolio into a general sequence for migration to some form of cloud, it's still necessary to look at the impact to the business of each application in the portfolio.

When you consider moving an application to the cloud, you are essentially moving your business data out of it's current data center to another physical location, so it's important to understand the impact this move has on your ability to access and protect that data, how it can impact data accuracy, and whether there are any regulations that control the movement of that data.

In addition to understanding the business impact of moving enterprise data to the cloud, the idea that cloud is inherently less expensive simply because there is no capital outlay is misleading. While traditional IT cost models include a heavy CAPEX component for the procurement of various hardware, very few manage the usage of IT resources (compute, storage & IO) at the application level. Yet that is precisely what cloud computing forces on it's customers. Every CSP charges at the service level, and at very small increments. Over an equal time period, operating expense in the cloud can far surpass what it might have cost to run the same application in an on-premise data center.

If you want to really understand whether moving an application to the cloud is a sound financial move, you need to understand the current and exact cost of running that application on-premise, first. This means understanding actual usage, facility, staffing and other costs, not just what you spent on hardware and licensing. Also, remember to consider that you will likely increase your networking costs as long as you have any enterprise applications in the cloud that need to be connected to remaining on-premise applications.

Assess the Cloud Model

Once you've assessed the business impact and real cost of moving an application to the cloud, and decided a move still makes sense for the business, it's time to decide which model best suits the needs of the business. Generally speaking, the least flexible, but least expensive model is Software as a Service (SaaS). Choosing this model means everything is managed by the CSP, and you have little input on application features. This is a great model for general use applications with moderate data security requirements. At the other end of the spectrum sits Infrastructure as a Service (IaaS), which is what most people think about when they think about moving to the cloud. IaaS offers the most control to your enterprise, as well as the most opportunity for unplanned costs when not managed diligently. Platform as a Service sits somewhere in between SaaS and IaaS, which is great for instances where your enterprise needs to control application source code, but doesn't want to be bothered with managing the infrastructure. Whichever option you choose for each application, it's a good idea to evaluate them all carefully before making a move. 

There's a lot of buzz about moving to the cloud right now. Before you take your enterprise down this multi-year journey, do everything you can to ensure that journey is successful. While there may be pressure to move quickly, there are risks to the business to consider. A well-considered Cloud Strategy is a great start, but it's also critical to assess the fit and impact of each application within the portfolio to the Cloud Strategy. Assessing the business impacts, both positive and negative, of moving each system off premise enables the creation of an effective and successful migration plan.