Cloud Migration
Early prototyping often turns into a full cloud migration without proper planning. Predict and avoid unexpected expenses, create accountability, and accelerate time to value.
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 elevated 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.
6 R’s of the 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.
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.
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.
Cloud Migration Success Stories With IBM Cloudability
A Modern Approach to Cloud Migration Costs and Planning
Migrating to the cloud is complex, and successful cloud migrations require organizations to adopt a “cloud-smart” mindset, determining when to migrate workloads by focusing on those that maximize the business value while minimizing effort and cost.
Download this e-book to embark on your cloud migration and understand the considerations and steps that are needed to complete a successful migration journey including:
- Understanding your costs
- Developing your migration strategy
- Executing your migration plans
- Preparing for a soft landing in the cloud
- Optimizing cloud costs and operational best practices