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. That’s because public cloud efficiencies have become an undeniable draw for business managers who rely on technology but don’t want to manage IT.

Unfortunately, too many organizations signed up for the promise of cloud 1.0 without reading the fine print about fully-burdened costs. The reality is that the intricacies 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.

For this and other reasons, infrastructure and operations (I&O) teams are leery to ramp 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 leadership do not identify and communicate migration strategies to the business, including how (and why) prioritization is key to success. 

Five priorities for your cloud migration strategy:

5 priorities for a cloud migration strategy_emergeDefine 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 may be an optimal time to move to public cloud.

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.

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 make a decision about remaining on-prem infrastructure and platform footprints—be it to switch them off, decommission them, or repurpose and optimize them until they reach their end of life.

Prioritize virtualized infrastructure migration

An existing virtualized solution simplifies the transition to 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.

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.

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 leadership to build credibility with quick wins and effective change management.

Migration strategy options

Assess the suitability of your workload for migration. There are defined migration strategies for different scenarios. 

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 replatforming.

Repurchase

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.y

Retain

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.

Retire

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.

 

»Download these eBooks to optimize hybrid and cloud by right-sizing legacy spend, shifting savings to innovation and efficiently embracing cloud: 

»Read next, on Emerge: