The rise of cloud computing has changed everything. In a recent LogicMonitor survey, analysts expect 41% of enterprise workloads to run on public cloud platforms in 2020, with an additional 22% running in hybrid cloud. Gartner forecasts the total public cloud services market to reach $266.4 billion in 2020, with an increasing emphasis on growth in this area due to the economic impact of COVID-19. Yet even with this level of scale and over a decade of experiences to lean on, many organizations hit pitfalls that make them struggle to succeed with cloud adoption.
Obstacles to Cloud Adoption
At Credera, we have helped many clients make the transition to cloud. We see these five themes as common stumbling blocks:
As is lift-and-shift to the cloud bloats cost.
Designing around the first workload and using click-to-provision without a comprehensive plan for policies and controls.
Complexity, dependency gotchas, and competing priorities.
Over-provisioning, egress charges, data sprawl, and other “hidden” runaway costs.
Struggles with cloud security and compliance, including enterprise monitoring and management, access and data governance, meeting regulatory compliance standards, etc.
In this series, we’ll look at each of these issues and how to avoid them. We’ll start with the first obstacle: as is lift-and-shift to the cloud bloats cost. Why does this happen?
The “Lift-and-Shift” Approach
To kickstart cloud adoption, organizations often take a lift-and-shift approach, also known as rehosting. This pattern involves replicating existing systems (i.e., virtual machines [VMs] or physical servers) and relaunching them on a cloud provider with minimal changes.
This often results in higher costs, less-than-optimal performance, or broken apps, for several reasons:
Rehosting can reproduce inefficiencies by designing for peak capacity, since it recreates what was deployed on-premises.
Dependent systems that are not identified and migrated simultaneously introduce latency—this can be an issue with shared dependencies like database servers.
Application architecture is not optimized for the cloud platform (e.g., load balancer rules requiring a virtual appliance vs. a cloud-native solution).
While this list is not exhaustive, it doesn’t mean lift-and-shift is never the answer. It can be a good first step on a longer cloud adoption journey that enables a team to start taking advantage of cloud benefits, like paying only for what you need when you need it, elasticity and scalability, disaster recovery capabilities, and improved security. For some workloads like legacy enterprise applications, it may be the best fit. However, we recommend taking a step back to consider the bigger picture before launching a cloud adoption initiative.
Our Approach
Establish a Cloud Adoption Plan
Cost, security, availability, and operational effectiveness should be the foundation of any cloud migration plan, with each taken into consideration when developing a cloud strategy.
Establishing these management and government policies upfront, prior to beginning the migration journey, is essential for a smooth transition and helps ensure long-term success of your cloud environment.
At Credera, we recommend leveraging frameworks such as the Microsoft Cloud Adoption Framework, AWS Cloud Adoption Framework, AWS Well-Architected Framework, and our own Enterprise Governance in Azure Whitepaper to provide baseline best practices while developing a cloud adoption plan.
Start With Applications
Taking an applications-first approach to cloud adoption allows for easier assessment and planning than trying to move an entire data center all at once. Focusing on applications can provide better understanding of the dependencies involved so risk from individual VM migrations is minimized. Once an application workload is migrated and initial performance metrics are gathered, optimizations can be done as needed and are typically less complicated to complete.
It is common in enterprise environments that workloads can unknowingly be coupled together by shared servers, how traffic is routed through the network, and centralized services used by different applications. Dependency identification and mapping is a critical requirement for any migration activity and helps us better understand how an environment currently operates to minimize migration risks.
There are many third-party application and network dependency mapping tools available, with some offered by cloud providers themselves to assist in migration planning. Whichever tool is chosen, it is important to start collecting dependency data as far in advance from your planned migration start date as possible. Doing so guarantees that the greatest amount of insight (e.g., performance metrics, usage statistics, cloud SKU recommendations, etc.) is generated and dependencies for applications at varying time periods are captured.
Starting with applications can also provide opportunities for modernization that can result in better performance, increased operational efficiencies, and lower costs.
Use the Six Rs of Cloud Migration to Determine Best Plan
Incorporating the six Rs of cloud migration throughout migration planning will help establish the best strategy for how each application will be moved to the cloud and if a phased approach is necessary.
1. Rehost: Lift-and-Shift Rehosting is the process of taking what is currently running in an environment and standing it up in the cloud, without making any changes to how the application works. While it is the simplest of the cloud migration strategies, it typically should not be the end goal of a migration as it usually doesn’t take full advantage of the cloud provider features. Applications moved using this strategy should then be re-architected once they are running in the cloud, where changes are typically easier to make.
Another issue to consider is that lift-and-shift performance estimates and recommendations are only a best guess based on the information provided to the tools. Often a VM will perform differently on the cloud due to differences in storage technologies (e.g., input/output operations per second [IOPS], latency, etc.), network layout, and compute. Conducting test migrations and post-migration monitoring are important to ensure applications meet performance requirements in the new environment.
If you plan on using lift-and-shift as part of your cloud adoption strategy, we recommend optimizing your migrated systems for cost efficiency using cloud tools such as reserved capacity purchases, native advisory tools such as AWS Trusted Advisor or Azure Advisor, and cloud budgeting controls such as AWS Cost Explorer, Azure Cost Management, or GCP Cloud Billing. The default on-demand rates for VM instances—especially for 24-7 systems—represent the worst-case cost scenario, so understanding other cost options and how they apply to your business and your workloads is key.
2. Replatform: Lift, Change a Little, and Shift While keeping the overall application architecture the same, replatforming differs slightly from rehosting as some processes might be modified to run on managed services offered by the cloud provider. This allows for greater opportunity to take advantage of cloud provider features and efficiencies without having to redesign the application. Replatforming typically results in lower operational costs than rehosting due to transitioning much of the burden for processes like backups, maintenance, and recovery to the cloud provider.
During planning, identify applications that could tolerate small changes to become candidates for replatforming. While it can still be analyzed further for additional changes once it is migrated, taking advantage of a cloud managed service from the start is a step in the right direction.
3. Repurchase: Vendor or Product Shift Repurchasing typically involves purchasing a cloud-based offering of an existing Software-as-a-Service (SaaS) solution or selecting a new vendor to replace an existing application. This strategy is often used when you are locked into a specific proprietary data platform, though a cloud-based offering exists.
Identify any self-hosted SaaS solutions and check to see if a cloud-based equivalent exists. While migrating these services to the cloud may not change its overall architecture, it may allow for additional feature sets that were unavailable to the self-hosted version.
4. Re-Architect: Complete Redesign When a strong business case is made for an application to add features that increase the service’s performance, scalability, availability, and flexibility, a complete rebuild of the application is often necessary. Re-architecting is the most expensive and time consuming of each of these strategies, though it is also the best way to take advantage of every opportunity the cloud has to offer.
While the initial business value or desire to re-architect an existing application may not be strong enough to justify the effort, it should be the end goal for all services that are migrated to the cloud. As it is a cloud migration “journey” and not a one-time sprint, identify the current applications that, in order to meet business objectives, need to be overhauled from the start. Then identify applications that can possibly be stepped through the other migration strategies first, leading toward a rebuild at a later point in time.
5. Retire: Get Rid of It During the analysis and rationalization process, it is possible to discover some resources may be unused or no longer needed. In order to keep focus on items that do need to be migrated, and to reduce costs and administrative overhead, turn them off.
6. Retain: Keep It Where It Is There may be some applications or services that aren’t ready to be migrated, aren’t valuable enough to justify being migrated, or simply can’t be migrated because it is a legacy system that isn’t supported in the cloud. In that case, migrate only what is a priority and is necessary to meet the needs of the business. If it doesn’t make sense to migrate something, then don’t.
You should still take note of the items that are planned to be retained so they can be revisited later. As cloud maturity develops and an increasing number of services are migrated to the cloud, the value of retaining anything may decrease. Make sure to consider the bigger picture, and whether keeping systems running on-premises makes sense long term, taking into account ongoing data center costs, hardware support, licensing costs, and compliance requirements.
Design Solutions to Take Advantage of Cloud Features
Businesses move to the cloud for the promise of developing services that are cost efficient, highly available, scalable, and are at the cutting edge of what technology has to offer. These features are continually improving. Any opportunity to take advantage of these features should be taken into consideration throughout your migration planning and execution.
Cloud migrations shouldn’t look like you are just moving from one data center to another. It should instead incorporate every possible benefit cloud providers have to offer for the purpose of increasing the value of any service that is running within them.
Moving Forward With Migration
This is the first blog post in a multi-part series focusing on cloud migration and adoption. In the next piece we will dive into the chaos that can result from designing around first workloads, click-to-provision processes, without plans for policies or controls.
If you are interested in learning more about cloud adoption or are looking for a partner to join you in your journey, we have a team of highly experienced individuals who can help. Please feel free to reach out to us at findoutmore@credera.com.
Contact Us
Ready to achieve your vision? We're here to help.
We'd love to start a conversation. Fill out the form and we'll connect you with the right person.
Searching for a new career?
View job openings
