Bulletproof Your Core App Migration to the Cloud: An Essential Readiness Checklist

Cloud Migrations

There is often a great deal of friction in the process of enterprise cloud adoption.

For example, business decision-makers often suffer from confusion over key questions about the true cost, risk, and the total economic impact of moving their core applications to the cloud. Assessing and selecting the right cloud migrations path, transition approach, operating model, and service provider(s) for core enterprise apps is one of the most strategic decisions that IT and business leaders undertake. Ideally, any such decisions should be founded on a rock-solid, data-driven business case. The importance of articulating the business impact of migrating mission-critical apps, legacy systems, and costly infrastructure services to a cloud-based delivery model cannot be discounted.  It is in fact essential that any non-trivial cloud-based transformation initiative be founded on a clear and quantifiable economic analysis that compels business stakeholders to accept the changes they often perceive as disruption to business as usual. I call this cloud readiness. Yes, a lot has been written and there are many practitioners and service providers who are ready and anxious to help.  However, it helps to have a definitive guide, or framework, to start with.  This is it.  And it’s based on hard-won experience on the battlefield of enterprise IT operations. First, I will give you some important building blocks.  Then it’s on to the checklist!

---

   

Your Operating Model is the Foundation

You need to establish a new IT operating model for cloud – plain and simple.  If you have not, you will find yourself lost in a sea of organizational and operational discontinuity.

What are the essential elements of an IT operating model?

• Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools.

• Governance – how we make and sustain important decisions about IT.

• Sourcing – how we select and manage the sourcing of our IT products and services.

• Services – our portfolio of IT products and services.

• Measurement – how we measure and monitor our performance.

• Organization – how we structure and organize our IT capabilities.

The following diagram is useful for illustrating the essential components of an IT operating model.

I will not delve into all of the elements of an IT operating model specifically designed for cloud operations.  There are a number of such frameworks in the public domain. Here is an example framework published by yours truly. It includes a handy framework for aligning business and IT stakeholders around a target set of process metrics that will be favorably impacted by the transformation to a highly automated cloud operating model, a portion of which is pictured in the chart below. . Such a measurement framework is an essential means of communicating the value proposition for moving operations to a cloud-based delivery model. Its purpose is to present stakeholders with a set of business and IT operational metrics that will be used for ongoing monitoring and measurement of performance, risk, and ongoing OpEx.

The Technology is Murky

We all know how difficult it can be to “unplug” core apps and legacy systems from their native hosting environments.  In fact, challenges abound:

• Many of these apps are bespoke in nature and represent a tangled web of software, hardware, hosting network, and support contracts.

• Legacy platform, middle ware, and service support dependencies frequently pose significant technical hurdles.

• Many of these apps are mission-critical to the enterprise and support key processes and functions, such as order and inventory management, finance, payments, and a variety of core business operations.

For IT there are a myriad of critical factors that must be weighed before moving core app workloads to the cloud.  Examples include which workloads are tied to end-of-life platforms, the impact of re-platforming older UNIX-based systems to Linux, and open-computing technologies.

Cloud Migrations

When defining the target environment for cloud migrations, a best practice is to create a reference architecture.  The reference architecture will guide application teams and features elements such as deployment standards, processes, and tools.  Standardization is essential to support operational consistency and service quality.  Reference architectures should be created to define various flavors of IaaS, PaaS as well as the service management and automation layers of your cloud. From an operational perspective, a reference model that articulates high-level technical requirements, high-level use cases, and defines the foundation components needed to support the service lifecycle of core apps once they are in the cloud is essential.  The diagram below is a great example of a high-level reference model for operations in a shared services and / or cloud environment.

The Business Case is Unclear

Making the business case for migration is complicated by the fact that many organizations lack a single, consistent, objective framework to guide informed, technically AND economically sound decision-making. To make matters worse, service providers supply varying degrees of the right data.  IT planners often have difficulty quantifying their baseline costs, efficiency levels, and requirements, let alone methodically scoring supplier options. IT planners need an objective, data-driven process to properly guide decision-making.  The process needs to take into account the business, technology, organizational, and operational requirements that are unique to the organization. Experience tells us that an application-centric approach to assessing the feasibility and TCO implications of moving core apps to a cloud deployment model is the best practice in virtually all cases. An objective planning and decision-making process must be predicated on accurate supplier data.  Here are a few foundational questions you will need to answer before undertaking your core app-to-cloud transformation initiative:

• What are the overarching drivers for migration, e.g., cost, agility, speed of change, elimination of the data center?

• Which applications are suitable candidates for a move and have you fully assessed the impact of any re-platforming, and / or architecture evolution and change?

• A primary question for many companies will be “public cloud” versus “private cloud.” Will one offer the same cost, scalability, regulatory compliance, risk tolerance, and flexibility as the other?

• What aspect of a cloud deployment should be managed internally or taken on by a managed cloud partner?

• What operational, cultural, and service-level issues and risks will I encounter as a result of a move, and what are the best ways to address and mitigate these?

• What are the total economic impact and TCO implications of a move — for specific applications, for a range of applications? Which cloud service provider or managed cloud partner offers the best SLAs, performance, risk profile, and cost benefits?

To assist in the decision-making process, a best practice is to rely on a data and analytic framework to drive workload-level optimization planning. The right decision-making tools will allow planners to assess the cost of computing for application workloads in various supplier and operational scenarios.  Factors such as which platform stack, e.g., LAMP vs. Microsoft; supplier pricing and terms, e.g., AWS vs. SoftLayer; and other operational dimensions can be analyzed as pictured below. Once you have defined your target operating model, reference architectures, and TCO analysis framework you are ready to begin effectively planning for core app migration to the cloud.  So without further ado, I present to you the readiness checklist.

Cloud Readiness Checklist for Core App Migration

1. Develop a standardized Cloud Services Profile that includes baseline data for application workloads. 2. Develop standardized Cloud Services Criteria for external providers that include, at minimum, the following:

• Operational health – does the provider have a consistent track record of meeting its SLAs? Is the service designed in such a way as to maximize resiliency?
• Technology fit – do the services offered match existing platforms, go-forward strategy, and technical maturity level or is it a “square peg in a round hole”?
• Industry & community fit – will the solution have proper adaptations to function within real-world constraints (e.g., special uptime / latency needs or time-shifted working hours)? Does the supplier comply with corporate social responsibility goals on things like emissions and working conditions?
• Cost – will the new solution provide ongoing operational savings within usage patterns and workload classification? When will transition costs be paid back? Is there cost certainty and has risk been quantified for unexpected contingencies?
• Contract terms – are core commitments of the supplier guaranteed in writing? How enforceable are they? Do you have sufficient flexibility to adjust the contractual framework as its business and the cloud market evolve?
• Scale up – can you scale the solution easily to match growth forecasts? Will you achieve meaningful economies of scale in doing so?
• Scale out – can you buy adjacent services from the same provider to build a more strategic partnership?

3. Develop a standardized Cloud Services Provider Profile that includes, at minimum, the following:

• Supplier attributes – ranging from date founded to financial ratios, these stay constant and are largely fixed over longer periods of time.
• Solution attributes – including design and architecture criteria, resiliency measures, latency to key hubs and end-consumer populations, intra-solution latencies (e.g., between DB and app servers), variety of configurations and ability to customize them further, scalability characteristics / burstable capacity, and many other dimensions. Solution attributes can be customized for particularly large deals, but typically evolve more slowly with the overall strategy of the supplier.
• Offer attributes – including price, SLA, and contract terms, which can be highly customized.

4. Develop a standardized Cloud Services Sourcing Framework that includes, at minimum, the following:

• Capture provider data to establish:
  • Supplier attributes
  • Solution attributes for X number of distinct solutions
• Define the range of possible offer attributes (e.g., prices / contract terms):

*Ingest* – capture business unit / application owner data:

a. Phone or web-based questionnaires to be answered in real time

b. Parsing of existing budgets or supplier bills / contracts

c. Download of syslog data

*Model* – make reasonable assumptions around any data that cannot be captured:

a. Overall market medians

b. Sliding scale assumptions based on buyer preferences and maturity level

*Normalize* – convert business unit / application owner data and any modeled assumptions into industry-standard metrics:

a. Volume metrics

b. CapEx / OpEx metrics

c. Cost per unit of supply (e.g., kilowatt, server, or Mbps)

d. Cost per unit of demand workload (e.g., cost per transactions)

e. SLA commitments

f. SLA performance

*Compare* – normalized client data to:

a. Previously-configured Provider solutions (listing only top 1-3 options if multiple solutions are configured) Provider-configured offers for the above solutions

b. Market medians for potential competitive alternatives

c. Client-designed scenarios (e.g., “We think we can cut our costs by 10% and improve our performance by 15% next year without you”)

*Validate and recommend* – use third-party reputation and industry expertise to confirm that the Provider solution is likely to provide improvements, providing a broad or narrow range of estimates based on proportion of ingested vs. modeled data.

While the checklist will get you started thinking about the right way to establish a comprehensive cloud migrations program for your core apps, the devil, of course, is in the details.  When you get into the details you will need to structure your analysis to cover the gamut of issues you will encounter during migration.  So, as a bonus, here is a way to think about the work breakdown structure and artifacts that you will want to produce before engaging with your business unit application teams: 1. PROJECT KICKOFF MEETING 2. VERIFY AND VALIDATE PROGRAM GOALS AND OBJECTIVES 3. CAPTURE CURRENT STATE

• Capture Current Contract and/or SLA Terms
• Determine Terms Risk
• Capture Service Dependencies
• Capture Service Support Profiles
• Capture Service Lifecycle
• Capture Service Roles
• Capture App Owner Preferences on Service Providers
• Capture Service Workload Capacity Allocation
• Capture Service Contracted Capacity

4. CAPTURE CURRENT WORKLOAD STATE

• Capture Service Workload Consumption
• Capture Service Workload Capacity Utilization
• Capture Service Workload Behavior
• Capture Service Workload Economic Modeling
• Capture Service Workload Historical Data
• Capture Service Workload Agility
• Capture Service Workload Portability
• Capture Service Transition Requirements

Once you have captured the data in steps 3 and 4 and have performed what is essentially a current state needs analysis, you can structure the output into a set of profiles to be used for optimization. The main idea here is to perform a macro analysis of workloads on the assets that are candidates for migration to determine optimal target state cloud deployment environment. The output of this work will be a suggested mapping of workloads to IaaS flavors based on optimal operational requirements and costs. 5. INTERPRET CURRENT STATE

• Populate Service Capacity Profile
• Populate Service Efficiency Profile
• Populate Service Cost Profile

6. OPTIMIZE SERVICE WORKLOAD PLACEMENT

• Create new Architecture Based on Capacity, Cost and Efficiency Analysis
• Populate Service Transition Cost Forecast
• Populate Weighted Buyer Target Service Profile
• Perform Supplier Option Pool Identification

7. EXECUTE CLOUD SERVICE PROVIDER CONTRACT PROCESS

• Generate Service Policy Profile
• Validate Price Tolerance for Candidate Suppliers
• Generate Target Service Supplier Priorities
• Generate Target Services Supplier vs. Current Scorecard
• Initiate Target Service Supplier Bidding Process (Single Supplier Only)
• Initiate Target Service Supplier Smoke Test (If Needed)
• Validate Service Transition Cost Forecast
• Initiate Target Service Supplier Contract Negotiation
• Execute Target Service Supplier Contract
• Communicate Final Suppliers to Account Team
• Populate Deal Sheet

The approach outlined here is embedded in a more detailed “playbook” that included program role definitions, program governance and work breakdown structures, RACIs, and detailed artifact definitions.

Post Migration: Quantifying and Eliminating Wasted Capacity

As a bonus, here are some ideas you can build on for how you can be smarter about consuming, paying for, and, in some cases, even monetizing unused cloud capacity.  A technique we have employed at RampRate employs a number of metering tools to quality check and accurately measure hourly usage and CPU utilization. Based on the usage data, RampRate considers all pricing scenarios from on-demand, reserved, to term utilization weight, to instance sizing, and provides the most cost-effective recommendations without compromising performance. We then examine Workload Packing options for further cost optimization (especially mature workloads). Targeted savings and efficiency recommendations are customized in an in-depth analysis of the cloud environment. Vital QoE (Quality of Experience) implications that justify cost are identified and QoS contractual inefficiencies are highlighted in the analysis. The chart below is one example of the savings analysis with savings resulting from efficiencies generated by smarter cloud capacity consumption. One of my favorite pastimes (I know, I need a life) is creating playbooks to help my clients systematically attack their toughest operational challenges.  You might suspect what is coming:  A Playbook for Migrating Core Enterprise Apps to the Cloud.  Indeed, I plan to publish the playbook in concert with some of my cohorts and partners early next year.