There’s no doubt that public cloud offers a number of compelling benefits for IT leaders. Faster time to market, greater agility, and an OpEx vs. CapEx model are just some of the reasons why public cloud growth projections continue to soar. Before any workloads are migrated to public cloud, some groundwork is in order. This groundwork will help IT leaders determine which workloads are best suited for public cloud, as well as prepare and execute successful migrations. This article looks at both common cloud migration mistakes to avoid as well as the best way to succeed with your organization’s own cloud efforts.
The cloud migration conundrum: Charge ahead, wait, or retreat?
Many enterprise IT organizations are eager to embrace cloud’s disruptive change model. Toward that end, many have also begun to aggressively move forward with plans to migrate workloads to the cloud in order to speed their own digital transformations.
Yet, despite this momentum, results of a recent survey highlight that IT leaders are taking a more cautious and thoughtful stance before migrating workloads to public cloud. Does this mean that moving workloads to public cloud is a bad decision? Absolutely not. However, it does highlight the need for due diligence to avoid the potential cost of leaping too fast into cloud.
In November 2017, Cloud + Data Center Transformation (CDCT) commissioned an IDG Research survey of IT leaders, including directors and IT executives. The survey, “Stakes Rise for IT: The IT Transformation Journey,” found more than half of respondents had to back-track on some of their cloud efforts. In fact, 52% were forced to move one or more workloads back from the public cloud to an on-premise model.
Their reasons for this backpedaling from the cloud? Survey respondents highlighted a variety of reasons, including compliance issues, lack of control over resources or data, reliability and performance issues, security concerns, lack of monitoring, and high costs.
Given the repatriation statistics, it’s no surprise that 75% of respondents claim to be more cautious than they were a year ago — at least when considering whether or not to migrate a particular workload to public cloud.
Lessons learned: Looking before you leap into cloud
Such caution and prudence are wise. Some practices that help build chances for success? One prerequisite to any cloud migration is a thorough workload assessment.
About workloads and workload alignment
A workload consists of an application as well as the underlying resources required to make it operate. Such underlying resources include compute, network, and storage. They may also involve other considerations like location, cooling, heat, and power. Understanding what constitutes a workload is often the first step when deciding which workloads are most suited for cloud migration.
Workloads and workload alignment
Workload alignment is the process of identifying the most technically appropriate and cost-effective platform to support a workload’s business requirements. Services surrounding this process may also be referred to as workload and platform alignment.
How workload and platform alignment works
The process of workload and platform alignment helps to first identify key workloads, including their business function and underlying dependencies.
This methodology successfully pairs (or “aligns”) that workload to the most appropriate, underlying platform. If a cloud platform is identified for that workload, it might take many forms:
- Public Cloud
- Private Cloud
- Hybrid cloud
As part of this process, some workloads might be identified as ineligible for cloud migration. Timing, budget, and appropriate migration options per workload are also considered. Some options might include:
- Re-platforming
- Lift-and-shift
- Workload and system consolidation
- Retirement or decommissioning
When it comes to migrating workloads to the cloud, following this approach to align workloads to the right platform can bring organizations a higher chance for cloud success. In the process, it can also save them from making many of the following, expensive cloud migration mistakes.
Mistake #1: Unrealistic cloud expectations
Some organizations may fail right away if there’s a wide gap between their initial expectations for cloud and the reality they face. This can come in a few different forms.
One client wanted to be able to dynamically move all workloads between Amazon AWS and Microsoft Azure cloud platforms. Yet, this client could not clearly define why that expectation was necessary to meet the business need of their workloads. More importantly, current cloud resources and multicloud tools available are not really mature enough to easily make this type of move.
Organizations have also been chartered to move everything to the cloud as soon as possible. This can oversimplify what can often require a more careful vetting of legacy and upcoming workloads and their underlying dependencies.
Mistake #2: Failure to prioritize certain workloads over others
The “All Cloud Right Now” mentality described in Mistake #1 can lead to this second mistake. Some organizations do not take the time to identify which of their workloads are most suited for cloud migration in the short term. They also don’t prioritize those workloads first for migration while sorting out the needs of more complex workloads.
A workload and platform alignment exercise helps to identify and eliminate those workloads that are NOT good candidates for migration to a cloud platform. These might be legacy applications at the end of their lifecycle or those that would require significant redevelopment in order to work in the cloud. Some workloads may have more rigorous security and compliance requirements or other needs for availability and failover. Still others may be too complex or too costly to re-platform to cloud in their current state, given their existing dependencies.
Workloads already accessed via web browser or through the internet are often a more natural fit for the cloud, as these often require less effort to re-platform. Prioritizing these first for cloud migration can make good business sense while you work to prioritize (or eliminate) other workloads for cloud migration. But, there is a caveat when thinking to migrate even these types of workloads: Their surface web front-end simplicity can still mask much underlying complexity.
Mistake #3: Not considering workload dependencies
Workloads have technical dependencies, in terms of the underlying hardware and software resources they require. But, workloads also have other dependencies. These can relate to dependent data flows that impact how well they perform their specific business functions. Just imagine a thriving data warehouse environment with hundreds of jobs and workloads surrounding the operation of one or more database systems. Moving key workloads to the cloud without considering the data flowing both into and out of the system can lead to failure.
Here’s one case in point. Shortly after performing a workload alignment analysis for one client, a set of application workloads with all web front-ends was identified. On first glance, the workloads seemed easily scalable and ideal for migration to public cloud.
After further assessment, hundreds of apps were discovered within the organization that needed constant access and communication with a centralized database. There were roughly 50 apps that made up a single workload alone, with each app needing access to this database. Application owners already knew that the current state of this legacy application architecture was too large, monolithic, and entwined to make such workloads a good, short-term candidate for cloud migration. But, company management needed proof that such workloads (in their current state) could not be easily migrated.
In this case, a different discussion ensues. If your organization still wants these functions in the cloud, you may need to spend more time and money redeveloping or re-architecting such complex environments surrounding certain application workloads. This might involve re-architecture that adds containerization or virtualization to help detangle and logically separate these workloads into separate, micro services.
Mistake #4: Thinking a cloud move is just about technology
Moving workloads to a cloud platform involves not just technology migration. It can also involve cultural change, adoption of new processes and procedures, and retraining the organization in how to perform its key tasks.
In one client example, the organization began with the expectation that all workloads could be moved to the public cloud. After completing the workload and platform alignment exercise, the organization realized some workloads could move to the public cloud without much issue. The organization also concluded that its business was not as “cloud ready” as it needed to be. In this case, the company opted to start building a high-level roadmap and deeper framework in its core business to better prepare it for successful workload migration to the cloud.
In another case, cloud providers often tout the cost savings of a move from on premises, CapEx IT spending to more manageable, cloud-based OpEx (pay-as-you-use) spending. While this can be true, large organizations must consider how their finance organization operates. Many have likely developed detailed, divisional breakout charges for IT over the course of many years. Changing suddenly from this CapEx charging model to a public cloud OpEx model may not be possible overnight.
Similarly, the tools and internal expertise used to manage and monitor the operation of on-premise workloads may not easily translate to cloud-based counterparts.
Lastly, application owners and end users must also be able to embrace any process change caused by a move to cloud.
Mistake #5: Not gaining buy-in from key groups and stakeholders
Just like any large IT deployment, upgrade, or migration project, migrating workloads to the cloud also requires buy-in at several levels of the organization. At the top, it requires an executive stakeholder who is able to successfully communicate the importance of the project and seek buy-in across the organization.
Similarly, as mentioned in the prior mistake, a larger cloud workload migration also requires buy-in from key groups whose current activities and processes will be impacted. This includes finance, application owners, and workload end users. It can also include IT groups who currently manage or oversee the on-premise operation of such workloads.
You need to know if the application owner, for instance, has the time in their teams to build up an environment and test a new model. Are end users willing to go through some effort to help the company save money?
IT security, data governance, and compliance teams should also be consulted in the early planning phase for any intended cloud workload migration. This ensures that security and compliance issues are effectively addressed before the workload goes to the cloud prematurely. One thing an organization doesn’t want: Pulling workloads back from the cloud, due to privacy or security concerns identified too late by internal or external auditors.
Mistake #6: Thinking security is the cloud provider’s responsibility
Just because your workload is going to someone else’s cloud doesn’t mean your organization’s responsibilities for security will end. In fact, they may get more complicated at first. Many cloud providers adhere to what’s known as a “Shared Responsibility” model for cloud security. Make sure you understand the cloud provider’s security role and obligations as well as your own. The best place to start is often your organization’s security team.
While parts of your security team’s role will go away in a move to cloud, other factors will be added to their responsibilities. Their role may, in fact, become more complicated — especially in a move to a hybrid cloud platform.
Mistake #7: Not starting from an existing catalog
When determining an organization’s preparedness to migrate workloads to the cloud, check to see if the IT organization has already defined an internal service catalog of offerings that the IT department — and the business — support.
If an organization already has this type of catalog, it can mean some of the early groundwork surrounding workloads has already been done. If this type of catalog does not yet exist, the organization may not have a good understanding of workload SLAs, owners and dependencies. This makes it harder for them to discuss workload readiness, and the pros and cons of migrating specific workloads to a cloud platform.
Mistake #8: Not sweating the details
Just as with any migration, workload migrations to the cloud also require specific planning steps to be performed in advance. Sometimes, even the smallest omissions can mean the difference between a successful or failed migration.
Here’s one example: A client moved a large percentage of their workload to the cloud. The migration appeared to go smoothly. 1.5 days after deployment, however, one of the company’s shipyards called in with a problem. Data from the scale weighing the trucks passing through wasn’t coming into the now-migrated system. In this case, the need to connect this end device at the shipyard to the migrated system had been completely overlooked during pre-migration planning.
Again, it’s important to consider end devices collecting data for a workload and all of the workloads various data flows.
Mistake #9: Not fully vetting the cloud provider
Top-tier public cloud providers seem like a good bet for workload migration. But, even if you plan to use the most popular providers, it still makes sense to learn what each cloud provider will and won’t do for your specific workload.
This includes variations in feature availability from region to region within the same provider. Usage monitoring, security, charges, access, and features may differ — even with the same provider.
As organizations move higher up the stack from Infrastructure as a Service (IaaS) cloud services to Platform as a Service (PaaS) and Software as a Service (SaaS), they may also want to take more time discovering which cloud provider aligns the best with their business. Once an organization puts its resources into a significant SaaS cloud offering, it may be tough to move away later on.
Here as well, once workload requirements are defined, CDCT also works with clients to help them assess cloud provider offerings.
