This section describes the functional/business requirements for the Landorous use case, as follows:

1. We will discuss the challenges of the Landorous use case. As one of the world’s largest retail companies, this organization has many on-premises-based workloads. The core pain point for Landorous is that the maintenance outage every week causes a loss of millions, affecting the company’s cash flow. In addition, the maintenance outage is a painful process and time consuming. For 8 hours of maintenance outage each week, they lose approximately 1.5 million USD in revenue. The lead developer and teams need to work on weekends for the maintenance outage. Due to manual and redundant activities, several problems arise during the maintenance outage window every week. The company has outsourced some of its development work to third-party organizations, which costs a lot.
2. The business teams want to move fast and scale up. However, with the current infrastructure, this is very tough. Therefore, they have assessed that a simple web application integration to their integration platform takes 2 and a half months, excluding the functionality development work. Figure 1.1 shows the workload of the current ecosystem:

Figure 1.1 – The current workload in data centers

In addition, the core integration platform connects multiple systems that are situated either on-premises or on other public clouds, as shown in the following system context diagram:

Figure 1.2 – The system context diagram

3. The company wants to create new business opportunities as well as new departments. However, the current infrastructure needs a considerable investment for additional hardware and software. They also need extra management and support for new infrastructure in their on-premises data center. In addition, they are constantly struggling to find skills, and manual management is not helping them at all.
4. Some simple workflows – for example, validating the age of a customer for alcohol or validating an e-prescription for medicine – are manual, which causes a delay in service execution. The customer has expressed their dissatisfaction with that.
5. The on-premises data warehouse requires an extreme level of governance, security, optimization, and orchestration for maintenance. All those activities are primarily manual and dependent on a database administrator group.
6. Applications have been developed over decades based on legacy technology. There is a lack of documentation and automation for deployment.
7. There is a profound link between application data and its enterprise complexities. Any simple change to the application requires an extreme level of effort and investment. Therefore, strangling the Matrix from Hell in monolithic applications is very challenging.
8. A legacy workload inherits complex integration models with non-standard data models, which imposes challenges. For example, let’s assume that several COBOL applications have been running without support for the last year due to a lack of skills and expertise.
9. The customer wants to improve service quality as well as customer satisfaction. Therefore, they intend to use artificial intelligence (AI) to use modern technology, such as process mining, automated workflow, and business insight. However, setting up modern technology in their on-premises data center is very expensive, and the time to market is exponentially high.

As shown in Figure 1.1, the organization has a different kind of workload in its existing data center. The applications for the customer are too many, as shown in Figure 1.3:

Figure 1.3 – A typical hairball infrastructure for on-premises monolithic applications and integrated workloads

The company sets some goals for improvement, as follows:

• Decrease outages, reduce painful processes, and allow teams to move fast and scale.
• Increase cash flow with automation and reduce cost for infrastructure buildings and management.
• Validate a business case that will provide immediate and long-term net worth due to cloud transformation.

The company started a program to explore different business cases to achieve these goals, as follows:

• Add more workforce and increase skills and benefits for the existing workforce.
• Add an incentive for an additional working hour.
• Refresh technology and add new components to the existing data center.
• Cloud migration.

To help this organization migrate their workload to the cloud and get the maximum benefits from the program, we need to understand the requirements, business value proposition, current workload, main challenges, and other dependencies. We also need to define the correct roadmap for their cloud migration.

Let’s now understand the basics of cloud transformation, different industry strategies, and their potential benefits, which will help us define the roadmap for the organization.

There are many benefits of cloud migration and modernization, such as the diversity and agility of IT operations and providing a cost-effective secured platform and a ready-to-run platform for AI innovation. As a result, major cloud providers continuously improve their offerings by adding services, securing platforms, efficiently managing the infrastructure, and providing competitive advantages in many areas.

However, it is still essential to determine the right cloud migration solution for organizations. To design the right solution, we need to understand the core concept of cloud migrations. This section will cover cloud computing, explore the different cloud models, and explain what a cloud migration is.

What is the cloud?

According to the National Institute of Standards and Technology (NIST), the cloud can be defined as follows:

A model for enabling convenient, on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications, and services, that can be rapidly provisioned and released with minimal management effort or service provider interaction.

Therefore, a hosted data center is not cloud-based according to NIST. A hosted data center is a private cloud in the information technology (IT) industry. As a result, we will also consider the recent trends and terminology in the IT industry. Most cloud migration projects can be put into the following two categories:

• Cloud to cloud
• On-premises to cloud

In this book, we will mainly focus on on-premises to cloud migration projects.

Different cloud models

Cloud models can be primarily of two kinds – delivery models and service models. Figure 1.4 shows the model classification for the cloud:

Figure 1.4 – Two kinds of cloud models

In the following sections, we will look at each of these models in detail.

Delivery model

In addition to the public cloud, there are two other delivery models, known as the private cloud and hybrid cloud, as depicted in Figure 1.4.

Private cloud

Different sources define the private cloud with slightly different definitions. For example, this is how IBM Cloud Learn defines it:

Private cloud is a cloud computing environment dedicated to a single customer. It combines many of the benefits of cloud computing with the security and control of on-premises IT infrastructure.

In Preparing for Your Migration to the Cloud by Steve Francis, this is how it is defined:

Private cloud is simply a cloud that you build and operate yourself.

The core characteristics of a private cloud are as follows:

• It is dedicated exclusively to a single tenant.
• Security hardening rules and policies regulate it.
• It can be hosted on-premises in an organization’s data center or on a managed data center of the cloud provider.
• It is still able to have all the benefits of a cloud-native architecture.

Recently, among these three different delivery models, the hybrid cloud model is becoming very popular. The following section will discuss the different aspects of the hybrid cloud.

Hybrid cloud

Often, organizations cannot move all the workload to the public cloud due to migration costs, regulations, cloud service availability, and other reasons. As a result, these organizations often end up with cloud workloads and on-premises workloads in a hybrid cloud model. Another main reason for hybrid cloud is portability. Organizations often want to avoid cloud provider lock-in and deploy their workload so that applications and services can be easily decoupled from an underlying cloud provider workload. In addition, multiple cloud adoption is becoming a viral strategy. According to a 2017 survey by Cloudify, more than 51% of organizations have workloads in multiple clouds.

It is essential to select a suitable delivery model for cloud migration. Figure 1.5 shows a decision tree for the cloud delivery model:

Figure 1.5 – A decision tree for the cloud delivery model selection

If migrating the workload to the cloud is not possible due to some dependency and the result of return on investment (ROI) analysis, hybrid cloud can be a suitable option that allows organizations to continue innovation and modernization via the cloud without interrupting the legacy workload deployed on the on-premises data center.

The next step for cloud modernization readiness is to select a service model. There are multiple types of service models used in the industry. Often, a combination of multiple service models is used for cloud modernization and migration projects to optimize the benefit. At the same time, one dedicated service model may not be the correct answer for different workloads. This section discusses the different types of service models and their benefits and limitations.

Service model

Figure 1.6 shows the primary service models for the cloud. However, in addition to the primary services, two services, the business support service (BSS) and operation support service (OSS), are becoming popular. Therefore, the three service models can be described as follows:

• Infrastructure as a service (IaaS) provides companies with computing resources, including servers, networking, storage, and data center space, on a pay-per-use basis. The developers hide the low-level details, and they can focus on innovation.
• Platform as a service (PaaS) provides a cloud-based environment with computing, storage, network, and other capabilities to support the complete life cycle of implementation, deployment, and delivery of applications, without the cost and complexity of buying and managing the underlying hardware software, provisioning, and hosting.
• Software as a service (SaaS), or cloud-based applications, run on distant computers “in the cloud” owned and operated by cloud providers. The user can access them from their computers through the internet and a web browser.
• Business support as a service (BSaaS) provides support for continuous business insights. BSaaS is an advisory service. This service plans for workload migration to the cloud and continues the business as usual.
• Operation as a service (OpsaaS): Workloads on the cloud need continuous management through cloud operations, data operations, and security operations. Often, these operations are provided as a service to organizations. The cloud operation model is essential to continue operations to ensure high availability (HA), business continuity, resiliency, security, and DevOps. OpsaaS provides continuous support for different cloud operations.

Figure 1.6 – Service models

Understanding the service model and delivery model is essential. However, the application migration and modernization project are more significant than selecting the exemplary service and delivery models. Several different drivers, such as the current workload, application, user experience, complexity of the infrastructure, and business use cases, drive the cloud migration and modernization project in multiple phases. This book will discuss the different aspects of cloud migration and modernization. Let’s start by getting familiar with the definition of cloud migration.

What is cloud migration?

Cloud migration refers to when enterprises move some or all of their data center workloads and capabilities to a cloud-based infrastructure to enable cloud readiness. Cloud readiness is the capabilities provided by enterprises, as shown in the following diagram:

Figure 1.7 – Cloud readiness

Once we define cloud readiness, it will help us classify existing workloads and determine the cloud migration maturity model. In the following section, we will learn about different cloud migration and maturity models.

Cloud migration maturity model

The cloud migration maturity model is simply a classification of a workload to determine the priority and feasibility of a workload for the cloud migration process. It’s essential to classify current or as-is workloads based on their characteristics and cloud computing defined by NIST.

We can classify different workloads into four categories of current or as-is infrastructure, based on their score of cloud readiness.

Non-cloud

Not all legacy workloads deployed on-premises can be moved to the cloud. If on-premises workloads do not show any cloud-readiness characteristics, as shown in Figure 1.7, they cannot be migrated to the cloud. In addition, modernizing a legacy workload can be very expensive. If there is no sufficient business value for modernizing or migrating a legacy workload, organizations may keep them in their current state. These workloads cannot be migrated to the cloud efficiently. Therefore, they need to remain on-premises or be listed for either a Retain, Retire or Replace migration strategy – three things we will touch on later in this chapter.

Cloud-friendly

Cloud-friendly workloads are not primarily designed with cloud-ready architecture. However, they can be changed or refactored to achieve cloud-ready architecture. Workloads that can be decoupled from the underlying compute, storage, and network are especially suitable candidates for cloud-friendly workloads. They need a significant redesign, but it is possible to measure the efficiency of the migration process, and the business impact can be clearly defined. These workloads are suitable candidates for Re-Architect and Re-Innovate migration strategies, which we will touch on later.

Cloud-ready

If on-premises workloads have a cloud-ready architecture with observability, fault tolerance, interoperability, portability, security, and scalability, they are ready for cloud migration. As a result, these workloads are suitable candidates for Re-Host and Re-Factor migration strategies.

Cloud-native

Cloud-native applications are implemented with microservice architecture to implement most of the design principles of cloud-ready characteristics. Hence, these workloads are suitable candidates for Re-Host and Re-Platform migration strategies.

Main drivers for cloud migration

The main drivers for cloud migration can be financial, business strategy, agility for IT operations, and innovation. Here are some critical technical drivers for cloud migration:

• Most applications in a legacy environment suffer from the Matrix from Hell, which is the challenge of decoupling applications and packaging them in a format to run on the cloud regardless of language, framework, and other dependencies. If the current applications are containerized, this problem is already solved, and moving those applications to the cloud is easier.
• Organizations have been developing workloads for a long time, and decades of application evolution with legacy application development patterns often create the Matrix from Hell, as shown in Figure 1.8. Many monolithic applications are interconnected in such a complex way that changing them, such as adding new features and optimizing existing features, becomes very challenging. The Matrix from Hell makes the maintenance of applications extremely difficult. Even making a simple change in the application takes lots of effort – this increases the CPU, memory, and storage consumption of the application.
• It is difficult to access data in legacy applications. Therefore, introducing modern technology for data analysis is very challenging.
• Enterprises need to significantly reduce their time to market to survive amid extreme competitiveness. Therefore, there is a need to shift management for the computing, storage, platform, and network to the service provider so that developers can focus on innovation, ultimately reducing the time to market.

Figure 1.8 – The Matrix from Hell for a simple Node.js application

• Enterprises struggle to keep up with modern technology. This is not only due to a skills crisis but also because modern technology requires a specific platform setup. However, on the cloud, they are available as IaaS, PaaS, or SaaS. It is also straightforward to integrate with modern technology. For example, provisioning a blockchain platform on the IBM public cloud only takes a few minutes. With the IBM-managed Red Hat OpenShift platform, IBM takes responsibility for compute, storage, and network management and support. Therefore, developers are not burdened with maintenance, which is time consuming, and can focus on innovation.
• Operation cost is very high, and there are capacity limitations in an on-premises data center.
• Skill is limited to modern technology. Therefore, often, industries fail to scale along with demand due to a lack of skills and expertise.
• Compatibility with regulations and compliance often requires additional cost and effort.
• A constrained business process imposes additional challenges.
• Defining business uses is essential to driving a successful cloud migration project. In addition, these business use cases also help to define different key performance indicators (KPIs) to evaluate the cloud migration projects.

Before starting the journey to the cloud, we need to prepare and assess the cloud migration projects in the next section. Different industries follow different patterns for migrating a workload from on-premises to the cloud.

Cloud migration moves workloads from a source environment to a target environment. In most cases, the source environment is an on-premises data center, and the target environment is the cloud. This section will present the nine most used cloud migration patterns, known as the nine Rs.

Re-Host

Enterprises use the Re-Host strategy to move workloads (applications, databases, and so on) from an on-premises server to a virtual machine (VM) in the cloud without making significant changes. Re-Host is an overall strategy and is also known as lift and shift. Although this strategy makes the cloud migration process faster and cheaper, it prevents enterprises from benefiting from cloud readiness and can increase management costs even more than on-premises. Furthermore, as with other patterns, Re-Host is not always suitable for every type of workload migration to the cloud. Table 1.1 shows the benefits and limitations of a Re-Host strategy to move workloads:

Table 1.1 – The benefits and limitations of the Re-Host pattern

Re-Factor

This approach introduces cloud readiness to applications and databases to scale on demand and adopt cloud readiness features such as security, speed, and resilience. According to Gartner, the Re-Factor pattern restructures and optimizes existing code without changing its functional and non-functional behavior to remove technical debt, which later needs to be refactored. This strategy requires changing the code of existing applications, redesigning the integration between components, or replacing existing components with modern alternatives. For example, significant code needs to be changed to modernize a monolithic application to a set of microservice applications or replace a SQL database with a NoSQL database.

Figure 1.9 shows the simplified list of activities to migrate a workload from on-premises to the cloud using the Re-Factor migration pattern. Here is a list of activities to transform an as-is platform into a to-be platform:

• Containerize existing monolithic applications.
• Automate processes for data discovery, data and application dependency mapping, data movement, and synchronization.
• Replace the on-premises database with an appropriate database as a service (DBaaS), based on the data characteristics.
• Configure the application.
• Establish a DevOps pipeline.

Figure 1.9 – The activities to migrate a workload using the Re-Factor pattern

The benefits and challenges of the Re-Factor migration strategy are described in Table 1.2:

Table 1.2 – The pros and cons of the Re-Factor cloud migration strategy pattern

Re-Platform

Re-Platform is the middle ground between Re-Host and Re-Factor. Instead of moving a large set of workloads, only a few are moved to the cloud to take advantage of it. So, for example, instead of using an on-premises-hosted Db2 warehouse, which is very difficult to manage, enterprises can use the IBM Db2 WareHouse as a service on the IBM public cloud. The main benefit of Re-Platform is that it provides the capabilities to use managed services to reduce the cost and effort of operations significantly. In addition, no additional skill is required for the cloud alternative, as the components are included as a managed service. This pattern maximizes the benefits of the cloud and helps to enforce standard security for the managed service. As a trade-off, this pattern is comparatively more expensive than relocate base patterns, such as Re-Host and Relocate.

Figure 1.10 shows that applications, databases such as Oracle, SQL Server, and other middleware deployed on on-premises infrastructure can be moved to the cloud using the Re-Platform migration pattern:

Figure 1.10 – Migrating workload from on-premises to the IBM cloud using the Re-Platform pattern

Some of the aims of Re-Platform can be described as follows:

• To simplify and automate the movement from Oracle to other RDBMS (such as Postgres) on IBM Cloud data services or Cloud Pak for Data
• To adopt best practices to optimize the target database configuration for performance, HA, resiliency, and other non-functional requirements
• To containerize applications and deploy them on PaaS over the IBM public cloud

Replace

Replace is a very early stage of cloud migration. By the end of 2020, only 26% of the worldwide workload had moved to the cloud. The remaining 74% were still in on-premises data centers. Thus, enterprises are at an early stage of their cloud journey. Every step, they are learning and reinventing themselves. Therefore, it is common for enterprises to just drop existing platforms and rebuild their workloads on a public cloud environment. The benefits and challenges of the Replace migration strategy are described in Table 1.3:

Table 1.3 – The pros and cons of the Replace cloud migration strategy pattern

Re-Architect

Applications are rebuilt from scratch on public cloud infrastructure. Re-Architect can be explained as materially altering application code to shift it to a new application architecture, such as a PaaS on the cloud, and fully exploiting the application platform’s new and better capabilities from the cloud. Re-Architect pattern development can start by breaking apart application monoliths into smaller packages or microservices surrounding a more significant containerized workload, but this usually involves more significant code rewrites and, many times, a complete rethinking of how the application should be structured. Cloud-nativeness is a crucial goal for new applications.

Relocate

This strategy moves the on-premises workload to the public cloud. The difference between Re-Host and Relocate is that Re-Host ensures some optimization of the target platform through minor configuration changes, whereas Relocate does not focus on optimization. The main goal of Relocate is to move quickly to the cloud.

Retain

Enterprises often have legacy applications with complex dependencies that require major refactoring or are no longer valid for business cases. Retain is a suitable strategy for such workloads where they are identified and kept in the source environment for further processing.

Retire

Enterprises adopt this strategy to decommission legacy workloads that no longer have business requirements. In most cases, if an existing workload is not compatible for containerization or refactoring, it can be a suitable candidate for the Retire pattern – for example, they migrated the physical server on-premises to a VM on the cloud.

Figure 1.11 describes the workflow of the Retire migration pattern. Once the migration criteria are established, based on business requirements, DevOps culture, and other dependencies, workload migration takes place in multiple stages, such as planning, workload discovery, and design. Once the high-level design of the target platform is completed, the next step is to build the landing zone for the to-be platform and test its operational readiness. A continuous management operation ensures that the target platform is functioning, and the performance of the target platform is continuously measured and improved over time. Until the operation on the target platform is running at full capacity, sometimes, both the old and new target platforms are used to serve requests through load-balancing capabilities. In this transition phase, when both the old and new platforms co-exist, the KPIs and metrics for the new platform are established, using the KPIs for the old platform as a reference. Now, it is time to decommission the old VM and other legacy workloads no longer in use:

Figure 1.11 – Retiring a physical server by replacing the VM

Re-Innovate

In some cases, enterprises use the opportunity of cloud migration to re-invent themselves. For example, during the discovery phase of cloud migration, which we will discuss later, organizations might find out that AI SaaS solutions or workflow engines can replace some applications. Figure 1.12 shows that as-is workloads are modernized through Re-Innovation in the to-be state in the cloud:

Figure 1.12 – The as-is and to-be states of Re-Innovation

Let’s take the Landorous use case to understand the use case for different migration patterns. The migration strategy selection process is primarily driven by the cloud maturity model. Once the current workload is categorized, it can be planned for migration in multiple phases. In Table 1.4, we describe the cloud migration pattern selection for the Landorous use case:

Table 1.4 – The migration pattern for the Landorous use case

The key to migrating a workload to the cloud is to define a complete roadmap with detailed planning for every aspect of workload migration modernization. The next task is to define an end-to-end roadmap for the cloud migration project.

The proper roadmap for cloud migration makes all the difference between successful and failed cloud transformation projects. This section will discuss the roadmap in depth and show how to define the roadmap for cloud transformation projects.

The roadmap needs to answer the following seven questions step by step:

1. What is the final benefit of cloud migration?
2. What is the current state of infrastructure?
3. How do we collect information regarding the current state of infrastructure?
4. How do we transform the collected information into a migration process?
5. What are the different components (such as the delivery model, the service model, the maturity model, resources, and budget) of the cloud migration process?
6. How do we execute the cloud migration process?
7. What have we learned from the cloud migration process?

The answer to these questions is understood through the different stages of the cloud migration process, as shown in the following diagram:

Figure 1.13 – The different stages of the cloud migration roadmap

The different stages of the cloud migration roadmap are described in the following sections.

Discovery

The main goal of the Discovery stage is to identify the business goals and understand the current state of the workload. Sometimes, the business goal is financial or strategic. In addition, it is also necessary to determine the metrics to measure the success against the goal once the migration process reaches the operations stage.

Once the goal is identified, the next task is to determine the cloud migration approach for decision-making and data collection. There are two main approaches, referred to as top-down or down-top, for information-gathering and decision-making. In the top-down method, decisions are made by the chief technical officer (CTO) and other C-level executives. On the other hand, in the bottom-up approach, the individuals who own certain business functionalities that cloud services can implement make the decisions. The best-case scenario recommends that even in a top-down approach, the CIO collects information from individual business units and incorporates those decisions in their own decision-making. The next task for the discovery phase is to understand the current infrastructure. The following two stages, data collection and analyze, help fully understand the current footprint of the existing workload. First, however, the discovery phase initiates the process of identifying the candidate for migration, based on the following characteristics:

• Architecture
• Security
• The cloud migration maturity model
• Performance
• Scalability
• Strategic importance
• Plans
• The agility and diversity of IT operations

Data collection

At this stage, the necessary tools and methods are organized to collect information regarding the current state of the workload and the feasibility of achieving the business goal identified at the discovery stage. The platform, data, network tools, and technologies help collect data regarding the eight characteristics identified at the discovery stage. All functional and non-functional requirements for security, resiliency, HA, and so on are identified at this stage, along with the inventory information about the current state of the workload. All data is collected to answer the following questions:

• What workloads can move to the cloud?
• Where should workloads land on the target – private, public, PaaS, or CaaS?
• What level of cloud enablement and modernization is required to move the workloads?
• Where to start – identify the priorities for the overall collection period.

Analyze

Data from the data collection phase is analyzed to understand the current state. The findings at this stage are also used as input for the next planning phase. Another important task at this stage is identifying the metrics for measuring success. At this stage, workloads are classified and suitable candidates or opportunities are identified. The main goal of the data collection and analysis stage of cloud migration is to identify the feasibility of cloud migration. The deliverables of the analyze stage are as follows:

• Feasibility analysis: Identify all the essential data collected during data collection regarding the inventory of the current workload state, and all the business requirements and business use cases during the discovery phase to analyze the feasibility of cloud migration.
• Dependency analysis: Identify all the dependencies, risk factors, and possible mitigation plans.
• Workload classification: Categorize the current workloads into different classes. It is also essential to determine the priorities of a different kind of workload migration.
• KPI identification: Identify all the KPIs to evaluate the cloud migration and optimize the cloud resources, and evaluate all the workload and target platforms on the cloud.
• Governance standardization: Identify a standard method for processes, practices, policies, and procedures for the end-to-end project during the analysis of the cloud migration project.

Planning

Now that we understand the current platform, we need to plan for the cloud migration process. At this stage, the delivery model, service model, deployment model, maturity model, resource plan, and budget are planned and evaluated. Tools such as Cloud Advisor can prepare a perspective on modernization, combining tooling output and account team insights. These evaluations, as the outcome of Cloud Advisor, are used to review and align modernization outcomes with different evaluation metrics. In addition, the preparation of high-level business cases can provide measurement constraints for success evaluation. The main deliverables of the planning stage are as follows:

• Design a runbook for test planning for each workload deployment.
• Design a KPI evaluation plan.
• Plan a business use case evaluation.
• Plan resource optimization.
• Plan cost optimization.
• All risk factors and mitigation plans for different identified risks.

Operation

Once everything is planned and we have a descriptive view of the current platform, we start the cloud migration process. The cloud migration process must be agile and iterative. Therefore, multiple waves of the operation stage are executed iteratively. Each wave consists of six stages – planning, implementation, testing/validation, deployment to production, retrospective evaluation, and learning. Automation is the key to successful smooth operations for the cloud migration project. Cloud migration itself is a complex project. Manual operation is not suitable for such a complex project. Therefore, implementing automation for operations is the fundamental requirement for the success of cloud migration projects.

Governance

An overall governance method ensures standard processes, policies, practices, and procedures to optimize cloud resources. The core objective of governance is to establish a precise and structured definition for change, policy, resource, incident, and security management. In addition to the resources and workload governance, it is also essential to establish cultural and collaboration practices and methodologies to ensure overall success.

Learn

It is essential to evaluate the roadmap of the cloud migration process continuously. Then, based on the evaluation metrics for success, the roadmap of the cloud migration process is updated. The Learn stage is responsible for running the evaluation of the roadmap of the cloud migration process and providing input to any other stage, such as the discovery and planning of the roadmap. At this stage, one of the essential activities is to optimize the target platform on the cloud.

Cloud migration is a complex problem, and it requires a substantial amount of effort and budget. Therefore, cloud migration needs to be well defined, using best practices and suitable migration patterns. At the same time, it is also essential to be aware of different misconceptions regarding cloud migration. Therefore, the following section will discuss some common misconceptions about cloud migration.

Cloud migration moves a current workload, including compute, storage, data, services, system integrations, and configuration, from on-premises to the cloud. The core goal of this process is to achieve particular business objectives. These business objectives are measurable from the perspectives of efficiency and effectiveness. Therefore, it is essential to plan this process with suitable assessment and metrics, design principles, strategy patterns, and best practices, and the right people, tools, and technologies.

In addition, we also need to identify the priority, risk, and relationship between the business goal and migration strategy. Finally, we need to focus on data and the results of the migration process. However, often organizations get distracted by noise and myths. This section will clarify certain myths and unfair practices about the cloud migration process. These will be presented as quotations in each subsection, followed by an explanation of the myth. This section aims to help you understand what not to do in a cloud migration process.

Myth – re-hosting a workload without preparing for the cloud

As we all know, the most common challenge of on-premises is that it is difficult to scale up and down with a change in demand. The cloud consistently demonstrates excellent performance for scalability. However, just re-hosting workloads does not ensure scalability. The Re-Architect pattern or cloud modernization are essential to ensure scalability. In most cases, applications are modernized through containerization and integrating cloud readiness by design. However, deploying an application on a container platform is not enough for scalability. We need to design the network infrastructure and configuration for the container platform to achieve the goal.

To avoid this problem, a cloud maturity model is beneficial. A cloud maturity model defines workload classification and determines which workloads need to be redesigned to make them cloud-ready.

Myth – relocating a workload without a cloud-native design

Relocating workloads to the cloud ensures HA by design. Enterprise applications demand HA for each cloud service to keep up with high demand levels. However, this is not necessarily true. A cloud provider will provide a certain level of service as defined in its service-level agreement (SLA). However, most of the time, it does not ensure business continuity. Therefore, enterprises need to ensure that business continuity and disaster recovery are in the plan, and modernization or Re-Architect are mandatory patterns for a business-critical or production workload.

Myth – limited knowledge about cloud computing

A public cloud is not secure.

Security combines technology, tools, processes, practices, and cultures. In addition, appropriate implementation of regulation and compliance to avoid risks is essential in the cloud. Security can be ensured if it is the heart of development. Along with designing a secured infrastructure, developers carry a massive responsibility to secure an application. Although industries are still heading toward hybrid cloud solutions for their workloads, the cloud adoption by different industries, such as the financial and healthcare sectors, is also increasing. Therefore, the public cloud cannot blamed entirely for security issues when security is a shared responsibility including integrated processes, rightsizing, tools, methods, and practices.

Myth – cloud migration without an objective

Cloud migration is a technical strategy rather than a business strategy.

Cloud deployment directly impacts the revenue and business outcome for organizations. Therefore, it is essential to have a business objective for cloud migration. For any cloud migration project, there should be a proper business case analysis that will drive the migration project from the financial and technical points of view. As cloud migration projects are usually expensive, without the proper business case, there are chances the project might fail. The business case also helps to take correct technical strategy and decisions for the migration project and cloud platform. If an organization simply tries replacing an on-premises data center with the cloud as their platform of choice without any solid business case, it might end up as a waste of money and effort in the end. So we need to keep in mind that cloud migration should be driven by the business strategy, which could be to reduce the time to market, or allow for massive scaling up in case of increased business popularity.

Myth – limited or no assessment for cloud migration planning

We have a simple Excel sheet, which is enough for our workload analysis for cloud migration.

We need to remember that cloud migration is only beneficial if it is done right. Therefore, it is essential to plan the cloud journey properly with details.

Myth – inefficient assessment for cloud migration

One size can fit all.

The recent trend among enterprises is to choose a single cloud as their strategic cloud and put everything in that same cloud. The outcome is already visible – often, this is not the right decision. In addition to that, no single cloud migration pattern is suitable for every type of workload. Migration patterns vary for different technology/applications.

The landscape and business goals of the transformation need to be defined clearly for a successful cloud migration project. Often, enterprises prefer to use Re-Host as their only cloud migration pattern instead of Re-Architect. However, this is not always true. A proper analysis is essential to identify the correct cloud migration pattern for different workloads. In reality, 84% of digital transformation projects fail due to siloed data and unreliable integration approaches.

Myth – cloud migration versus cloud modernization

Move first, then innovate.

Monolithic legacy applications only focus on business logic and functionality. For example, developers often use files at a specific location to store the configuration. The main focus for developers is to implement the functionalities; unit tests, integration tests, and regression tests focus on business logic only. The data, integration, management, and DevOps are often a secondary focus for developers. Therefore, moving applications as is usually makes the management more expensive and cumbersome. A more holistic focus on configuration, management, DevOps, data, and integration can modernize an application and make it suitable for cloud migration.

This chapter covered the fundamentals of workload migration to the cloud. Then, we discussed different industry patterns and strategies for cloud migration and their value to organizations. Selecting suitable patterns and strategies for cloud migration can maximize the benefits of workload migration to the cloud. This section explained the characteristics of different migration patterns, enabling organizations to choose the most suitable patterns and strategies for cloud migration based on workload classification. Then, we explained a common scenario for organizations and the roadmap for cloud migration. Finally, we discussed the different stages of a well-defined end-to-end roadmap for cloud migration, along with some myths about cloud migration.

This chapter focused on the fundamentals of cloud migration. Workload migration alone cannot bring the maximum benefits for an organization; workload modernization and innovation are also required.

In the next chapter, we will discuss the fundamentals of modernization.