The Ultimate Guide to Cloud Migration
What is cloud migration?
Cloud migration leverages public cloud solutions to supplant or replace, existing on-premises IT resources. Though cloud migration initiatives often start with a like-for-like replacement of existing solutions, most organizations need a more sublime approach to cloud migration (e.g., accounting for existing on-premises fixed costs, legacy systems that are not cloud-native, and change management concerns of process and security).
More organizations than ever are looking at moving some or all of their technology workloads to the public cloud. But for many, the process behind migration is complicated, and burdened with open-questions:
- Will you pick a public or private cloud model?
- Will you straddle both with a hybrid operational model?
- Which workloads get prioritized? Low-risk dev and test workloads, or new applications that will drive innovation for the business?
- Will you move your applications to the cloud as-is, in a “lift and shift” model, or refactor your key applications to take advantage of cloud-native architecture?
- How does your developer strategy evolve with cloud?
- Do you have plans to adopt agile processes in a DevOps-style culture?
These questions run the gamut of operational, process, and finance, but the economic impact of cloud plays a key role in decision making. The C-suite may sign off on a business case built off operational efficiency, but they will go to bat for one built off economics. Build stakeholder buy-in for cloud with an economic framework.
The economic framework for cloud migration
Step 1: Pre-migration
Begin with an inventory of current resources—you can't quantify the size and scope of cloud migration without knowing what you are already working with.
If your plan is, in part, to shift the balance of spend towards OpEx and away from CapEx, you need to know what your costs are today. If part of the migration is retiring old and end-of-life infrastructure, it’s important to know where that infrastructure is, and the applications it supports.
This process of baselining is critical for two reasons: first, it helps tell you what the opportunity surface is for the migration. Second, it establishes the baseline from which you’ll measure the success of your cloud migration once you start moving workloads. Without it, you’ll never be able to quantify the business benefit of cloud migration.
The other main outcome at this stage is to understand the key drivers of your migration. Even if you plan to move your entire technology portfolio to the cloud, it won’t happen all at once, and there are shortcuts available to help prioritize which workloads get moved first, particularly from an economic point of view.
»Related content: [Webinar] 6 strategies to build a successful cloud strategy
These transformation drivers essentially start building the blueprint you can follow to move your business to the cloud naturally. Imagine your data center footprint today—maybe it’s using leased capacity from a colocation firm. If you have a lease ending in the next 24 months, that could be an inflection point that allows you to start shifting that co-located infrastructure to the cloud.
As another example, maybe you’ve got a long-term enterprise-style purchase agreement with a legacy software provider. If part of your migration plan includes reducing your dependence on those providers and adopting new and more modern cloud-native services, an upcoming expiration of that contract could enable you to focus on building a migration plan to move away from those services.
As you conclude this stage, you’ll ideally have two key sets of information. First, you’ll have data on what you have today (and granular total cost information) to create a pre-migration baseline. You’ll also have a roadmap of sorts that illustrates the inflection points in your organization that can drive an initial prioritization effort for your migration. That roadmap maximizes your ability to take advantage of the innovation brought by cloud but minimizes the impact of long term spend duplication.
Step 2: Migration business case
When most people think of the economics of cloud migration, this is the phase to which they’re most commonly referring. In fact, many of you have probably already done an exercise like this with a cloud provider (or two).
At this phase, you’ve probably been working with one or more cloud providers for a while and have a sense for their individual strengths and weaknesses. Unlike the first step, where you may have already established a baseline for the business case, you’ll probably do it in conjunction with a cloud provider and often an additional partner. Here you’ll establish the projected benefit of a cloud migration across all three axes—operational, architectural, and economical.
The most persuasive business cases begin with an actuals-based baseline total cost of ownership (TCO). Without an accurate baseline, you’ll be left to substitute estimates based on recommendations from the cloud provider or their partners.
These business cases will usually look at the characteristics of your infrastructure as deployed today—including both configuration data (how many vCPUs, server location, operating system, etc.) as well as performance data (e.g., min/max/average CPU utilization, consumed storage).
The best tools factor this data into sophisticated models developed in conjunction with the leading cloud providers to create a future-state configuration on the cloud of choice. These models usually take into account an optimized configuration—along with pre-purchase commitments, volume discounts, and more advanced Platform-as-a-Service (PaaS), these configurations are the key inputs that enable the public cloud to save customers 30-35% over their on-premises deployments.
Keep in mind that business cases tend to be a point in time snapshot, and may not include a model to showcase the cost of migration over time, the effects of developer transformation, etc. But working closely with many leading cloud providers and SI partners allows us to add this additional context to cloud business case exercises.
At the close of step 2, you’re probably looking at a business case artifact that demonstrates a savings opportunity for your business if you move to the cloud. Hopefully, that business case was developed by comparing the provider’s estimates to highly-accurate on-prem costs from a solution like Apptio Cloudability.
If you’re one of those customers that sees potential cost savings in the 30%+ range, you’re probably pretty excited! And for good reason - those cost savings can then be re-invested to support innovation projects. You’ll get the operating leverage associated with the cloud while saving money previously locked up in long-term CapEx commitments.
Now let’s talk about where the rubber meets the road. After you’ve established a business case for moving your organization to the cloud, forecasting the opportunity in cost savings and organizational leverage, the real work is just beginning.
Step 3: Migrating at scale
After you’ve established a business case for moving your organization to the cloud, forecasting the opportunity in cost savings and organizational leverage, the real work begins.
Think about your overall cloud shift as many smaller movements. Each "mini-migration" validates the right path. The important thing is to get started and learn along the way.
Hopefully, your completion of the business case has shown the opportunity to drive innovation for your business while saving money at the same time. But to capitalize on that opportunity, start migrating workloads to the cloud. To migrate at scale, there are two main sub-components: Build an actionable plan for migration, and measure the value of the migration as time goes on.
In pre-migration, you discover economic inflection points that identify good potential targets for migration. Now that we’re ready to begin moving workloads, the migration roadmap needs to be revisited. How do you decide which infrastructure, applications, and/or services move first? Where do they move? How do they move?
There’s no universal answer to these questions—you’ll want to evaluate your roadmap across a few different dimensions in this phase. This is a sample of the types of drivers that can affect your roadmap and overall migration plan
- Economically driven: Equipment and facility leases, enterprise agreements, infrastructure depreciation, etc.
- Operationally driven: Software and hardware lifecycles, equipment or software instability, workload profiles (low/high risk, dev/test, etc.)
- Capability driven: New business requirements, technical limitations, etc.
- Opportunistically driven: Dev/test workloads, other “low-hanging fruit”
Having a system in place to see your various workloads, organized by these dimensions is critical to prioritizing your migration—and these priorities are fluid. It’s not uncommon to reorganize your migration based on any number of factors and events that unfold over time.
There’s not a single "correct" way to migrate workloads to the cloud. Some of your most valuable services will be factors for refactoring. This process, where an application is optimized to run on a cloud platform, offers great benefits that often result in better performance and scalability at (maybe) a lower price. But that agility and long-term cost savings opportunity may come at a hefty upfront cost to design and architect the new application.
Regardless of how you prioritize your application migration or the method in which you move them to the cloud, it’s crucial that you be able to explain to business partners the value of your cloud migration. Value can mean a lot of things to a lot of people, but, at its core, think about how to communicate why the move to cloud is a good decision for your business. Key indicators of value:
- Are you actually seeing the cost savings you expected from the business case? If you forecasted a 30% cost savings but can measure that you’re actually saving 34%, those additional funds can be invested in accelerating your migration; bringing on additional developers, investing in new tools, etc.
- Can you quantify the operational benefits of the cloud? By outsourcing core infrastructure roles to your cloud provider, most teams see improved application uptime. Measuring that improvement tracked over the migration of key applications is another simple way to showcase the value of the cloud for your business.
- Has the cloud helped you drive innovation into the business? This is one of the most important factors and initially feels hard to measure. One obvious result might be that your developers can now adopt new agile development methodologies to deliver innovation built with cloud-native services. You can use data from those services to track the pace of that innovation through metrics like code commits, quality, release cadence, etc. You’ll likely see that the pace of innovation for cloud-based applications is much faster than their on-premises (on-prem) brethren.
Step 4: Evergreen
Unlike traditional on-prem deployments of infrastructure, legacy middleware, and classic stack-based applications, applications on the cloud enable continuous improvement by optimizing underlying infrastructure.
Optimization is not only enabled but encouraged. After migration, organizations may over-spec the underlying infrastructure for an application that was lifted-and-shifted to a cloud solution. In an on-prem world, such a mistake could have lasting economic penalties—at least for the duration of the depreciation cycle. In the cloud, conditions like that are remedied by simply picking a new instance type and seeing the rate change accordingly.
That kind of optimization is more operational in nature. Other scenarios may be economically-driven. Most providers include different pricing models that reflect the kinds of workloads best suited for them. For example, the AWS Reserved Instance model rewards always-on workloads with discounted pricing via upfront payment. Google’s Preemptible VMs are priced as a low-cost option for workloads that are ephemeral by nature and can be disrupted as needed.
For most teams, this step never really finishes. Workloads evolve, and cloud providers continue building new and innovative services. That churn makes it important to continually iterate on the best way to deliver your services to the stakeholders in your business.
5 priorities for an effective cloud migration strategy
Public cloud is a readily available answer to IT challenges, but there’s a real need to temper the ease of spinning up public cloud solutions with a gut-check on your readiness to execute a successful migration.
Migration readiness often starts with a reluctance to repeat past mistakes. Many cloud 1.0 adopters have war stories they’d rather not rehash with cloud 2.0. Public cloud efficiencies have become an undeniable draw for business managers who rely on technology but don’t want to manage IT.
Too many organizations signed up for the promise of cloud 1.0 without reading the fine print about fully-burdened costs. The reality of consumption-based pricing (standard storage rates, retrieval rates, and uploads rates) complicate the basic budgeting question: “How much do we need to budget for storage?” Cloud can be very expensive if teams don’t do their due diligence to understand migration factors.
Infrastructure and operations (I&O) teams are leery of ramping up public cloud spend without first ramping down or re-purposing on-premises (on-prem) equivalents.
Of course, organizations migrate to the public cloud for good reasons: financial and operational agility, scale, avoiding distractions from an organization’s core competencies, and more. These reasons can be validated with a robust analysis of the total cost of cloud migration. Teams must trade-off the expected savings from a public cloud migration against the costs of doing the migration itself.
Cloud migration is an incremental process. Fingers—and bridges—get burned when CIOs and IT leaders do not identify and communicate migration strategies to the business, including how (and why) prioritization is key to success.
#1 Define your migration roadmap and prioritization around inflection points
You face forks in the road when it comes to evaluating and renewing on-prem platform and infrastructure investments. When assets reach the end of their life, there is a sweet spot between the completed depreciation schedule (no more hit to OpEx) and no significant performance degradation driving up support costs. It’s not a permanent state, but this opens a window of opportunity to make a change and an optimal time to migrate.
A data center lease that comes up for renewal, scheduled tech refreshes, dev/test workloads that need more elastic capacity, and fully depreciated assets reaching end of life are all points of inflection to adopt public cloud.
#2 Limit your duplicate capacity footprint
There may be organizational pushback to execute a cloud migration strategy if you are already committed to on-prem spend. The arguments for public cloud (and those arguments were won years ago) easily get derailed if you are signing up for redundant capacity.
A full cloud migration needs redundancy during a transition (for disaster and recovery alone). But once migration is complete, organizations must decide between remaining on-prem infrastructure and platform footprints (e.g., switch off, decommission, or repurpose and optimize them until end of life).
#3 Prioritize virtualized infrastructure migration
An existing virtualized solution simplifies the transition to the cloud. VMWare vSphere is available with VMWare Cloud on AWS—with extension capabilities to an existing virtualized footprint.
Connectors like these ease the adoption of public cloud by extending direct hybrid support and reducing the challenges of change management challenges. If you have virtualized infrastructure in place, you can execute that part of the cloud migration strategy more efficiently than attempting a total lift-and-shift of applications.
#4 Identify on-prem infrastructure and platform spend already committed
The cost savings from public cloud are undercut if you have already committed to expanding on-prem capacity. In-flight projects on infrastructure or platform capacity need to be evaluated for scope, deliverables, and projected success before you build a business case for your cloud migration strategy.
#5 Define excess capacity
Industries with seasonal demand (e.g., retail) build on-prem infrastructure and platform capacity to satisfy peak demand—leaving excess capacity dormant for the rest of the year. This scenario is tailor-made for public cloud adoption.
Even if you use on-prem infrastructure and platform resources for normal capacity, surges in usage are better served by the pay-as-you-go option of public cloud. These bursts of usage need to be quantified prior to public cloud adoption. By defining on-prem excess capacity (and the time it’s used), organizations can include peak utilization costs into the TCO of public cloud services.
Today, organizations are using lessons learned from their own cloud 1.0 adoption and the experience of their industry peers to develop a robust cloud migration strategy. Cloud migration has to be incremental and (for the good of everyone) prioritized, allowing IT leaders to build credibility with quick wins and effective change management.
Cloud migration process
Assess the suitability of your workload for migration. Make your cloud migration process reflect the state of the business and the actual (rather than presumed) migration scenario.
Rehost (aka. lift and shift)
Taking what you do on-premises today and replicating it in the cloud is the most compelling, inexpensive, and—not coincidently—popular migration strategy. This like-for-like approach doesn’t ask for new functionality in the cloud. Many applications (particularly legacy) have no cloud-native awareness (e.g., not able to automate with cloud providers tools for dynamic resource allocations) and are not candidates for lift and shift.
Replatform (aka. lift-shift-tinker)
Retain the core architecture of your applications but make optimizations using cloud capabilities. Instead of investing time and resources to manage its own database, an organization may consider adopting Database as a Service. Nearly any custom-developed application less than a decade old is a good candidate for re-platforming.
Adopt something net-new in the cloud and retire or sunset existing resources on-premises. Consider the life-cycle of current on-premises workloads when evaluating a straight replacement. If you have spend commits for on-premises capacity (e.g., unfinished depreciation cycles), migration delivers duplicate capacity. The costs of extra capacity must be included in the ROI of your cloud migration. Include evaluations of sunk costs for in-flight projects on infra and platform capacity.
Refactor (aka. rearchitect)
The most problematic migration involves workloads that require dev work (redesign or rewrite) to make it suitable for the cloud. Assess the cost of that work and resourcing trade-offs. This is a prioritization issue. There are never enough resources for every challenge. Is refactoring an app to make it suitable for the cloud the right use of your finite resources? Priorities shape the answer.
Not all applications are ready to take advantage of cloud dynamics. If an application is proprietary and needs a complete rewrite for the cloud, it may be best to keep it on-premises until an alternative cloud-native solution is available. Switching to cloud solutions operationally turns off on-premises workloads, but that doesn’t make financial commitments disappear. Retained workloads will be burdened with depreciation and amortization of decommissioned on-premises resources.
Some workloads are just ready to be retired. Every decision needs a driver, and a migration plan calls out workloads you no longer want to support. The migration plan must be aware of ongoing financial liabilities associated with retired on-premises assets. However, it’s likely that an application or service scheduled for retirement has already finished its depreciation or amortization schedule.
Cloud migration challenges
No success metrics for cloud migration
A migration strategy is financially successful when organizations show that the TCO of public cloud services is less than the TCO of on-premises alternatives. But hybrid or cloud environments that deliver improved business outcomes, delivered at a higher cost, make a pure financial ROI comparison between cloud and on-premises incomplete. Quantifying measures of success is one of the key cloud migration challenges. Software development teams adopting Agile on cloud solutions delivers more code commits, higher quality, and faster release cadences. What price for that innovation? What price for the improved business outcome? Migration decisions that deliver surplus capacity, or retires assets that aren’t fully-depreciated, may cost more in the short-term yet pay-back over the long-term. Success cannot be measured solely by financial ROI. That’s the minimum bar you must get over. But there are other measures to consider too. Your migration plan must present all these considerations. C-suite buy-in for cloud migration wavers if the rationale is described as "It will cost us more, but look what we get in return." That doesn't pass the smell test with the C-suite. One of the biggest cloud migration challenges is to present the holistic benefits in language non-IT stakeholders understand.
No consideration of cloud migration costs
The costs of adopting the public cloud cannot be assessed just by comparing the TCO of public cloud with the TCO of on-premises alternatives. You must also include the cloud migration costs too. For example:
- Labor costs for planning, execution, and follow-up support.
- Sunk costs to determine early termination costs from decommissioned on-premises services.
- Overlapping costs to support transitional-hybrid (ex. duplicate environments in on-premises and public cloud during migration)
- Consumption-based charges from duplicate capacity deliver unexpected high-charges from applications requiring high CPU utilization and disk I/O consumption. This is not a cost to perform the migration, but organizations incur (possibly unplanned) public cloud charges when they are delivering two application portfolios in tandem.
Cloud migration tools
As cloud takes up a greater portion of your spend and time, you need cloud migration tools to manage it all. Cloud billing is often undecipherable. With many services just an internet connection and a credit card swipe away, cloud usage can quickly get out of control leading to cloud sprawl. And, with procurement, vendor management, and the like are looking to spread risk by utilizing the right clouds for the right workloads, they are employing multi-cloud strategies, working with many different IaaS, PaaS, and SaaS vendors. Fortunately, there are a host of new cloud management tools hitting the market that provide cloud leaders and stakeholders with the insights into capacity, utilization, and spend that they need to manage, benchmark, and justify cloud usage and budgets. Evaluate cloud migration tools with the following questions:
- What cloud migration tools are available today to manage long-term private, hybrid, and multi-cloud environments?
- Based on my long-term cloud strategy, what tools do I need to be successful both in my journey to cloud and future state?
- Knowing my future state, how do I minimize the number of interim cloud migration tools (and cost of those tools)?
- Which tools have value for multiple groups/teams/departments vs. tools that sit in a single team or department?
Cloud migration services from public cloud providers
Assessing the suitability of workloads for cloud migration is the preparatory step to executing the migration. Public cloud providers, inevitably, offer cloud migration services to accelerate and ease the operational headaches of a migration. As with any vendor solution, trust-but-verify recommendations and do due-diligence on the relative merits of each platform before making the move. Here are a selection of cloud migration services:
- AWS Migration Hub
- Azure Migrate
- Google Cloud Data Transfer Service
- AWS Snowball
- Azure Import/Export
- Google Transfer Appliance
Apptio Hybrid Business Management is the system of record for cloud migration
Create business value through informed and accelerated cloud and hybrid-related decisions with Apptio Hybrid Business Management.
With a unified view of cloud and on-prem costs, utilization, and capacity, you know the cost and consumption of IT resources and transform siloed decision-making into collaborative accountability.
- Compare costs. Get a single-view of hybrid IT and compare on-premises against costs in multiple cloud platforms.
- Optimize spend and resources. Take action on optimization recommendations across public cloud, private cloud, and on-premises.
- Migrate workloads. Identify and analyze cloud migration candidates and accelerate go/no-go migration decisions.