How to Plan to Migrate to the cloud?!

Creating a cloud migration strategy

As we mentioned in the previous section, there could be various reasons for cloud migration, and those play an essential role in your cloud journey. Your cloud strategy helps you to determine a migration strategy and prioritize applications.

In addition to primary business drivers for cloud migration, you could have more reasons related to the data center, business, application, team, and workload for cloud migration.

Cloud adoption is not just about choosing the platform, security design, and operation, you also need to consider people, processes, and culture in addition

to technology. For cloud migration success, you first need to align leaders and earn team commitment by upskilling them. You need to define the vision across the organization to ensure a successful cloud transition.

Often, migration projects adopt multiple strategies and utilize different tools accordingly. The migration strategy will influence the time it takes to migrate and how the applications are grouped for the migration process. The following diagram shows some of the commonly used strategies for migrating existing applications to the cloud:

you can do a Lift & Shift of the server or application from the source environment to the cloud. Migrating a resource only needs minimal changes for it to work in the cloud. To take a more Cloud Native approach, you can refactor your application to fully utilize the cloud native feature, for example, converting monolithic applications into microservices.

Choosing a cloud strategy:

Steps for cloud migration?

Since you may need to perform and manage multiple applications in the cloud, it's better to set up a Cloud Center of Excellence (CoE) and standardize this process with a cloud migration factory. The cloud CoE includes experienced people from various IT and business teams across the organization that act as a dedicated cloud team focused on accelerating the building of cloud expertise in the organization. The cloud migration factory defines migration processes and tools, as well as the steps that need to be taken, as shown in the following diagram:?

The cloud migration steps include the following:

• Discover: Discovery of cloud migration portfolios and on-premise workloads
• Analyze: Analyze discovered data and workloads
• Plan: Plan migration to the cloud and define the migration strategy
• Design: Design the application as per the migration strategy
• Migrate: Execute the migration strategy
• Integrate: Integrate with dependencies
• Validate: Validate functionality after migration
• Operate: Plan to operate in the cloud
• Optimize: Optimize your workload for the cloud

Discovering your workload

In the discovery phase of your migration project, you discover and capture detailed data about your cloud migration portfolio, for example, the scope of your migration project. You identify servers and applications in your portfolio, their interdependencies, and current baseline performance metrics. In addition to that, workload discovery includes understanding the existing storage, such as the database and file system, networking configurations, security and compliance needs, application release frequency, DevOps model, escalation path, operating system maintenance and patching, licensing requirements, as well as other associated assets.

It is essential to understand that your discovery landscape will depend on various factors:

• What has already been migrated to the cloud?
• What application dependencies are there, along with resources and assets?
• What are the business drivers for cloud migration?
• What is the estimated duration for the entire migration project?
• How many phases is the migration process going to happen in??

Organizations often do not have complete information about the following:

• The inventory of the number of servers
• Server specifications such as the type and version of OS, RAM, CPU, and disk
• Server utilization and performance metrics
• Server dependencies
• Overall networking details?

Performing thorough portfolio discovery helps in answering questions such as the following:

• Which applications, business units, and data centers are good candidates for migration?
• How suitable are the applications for migrating to the cloud??
• What known or unknown risks are associated with migrating an application to the cloud?
• How should the applications be prioritized for migration?
• Which other IT assets is the application dependent on?
• What are the best migration strategies for the application?
• Is it better to have some downtime for the application than to perform a live migration due to its dependencies and risks??

Analyzing the information

To identify server and application dependencies, you need to analyze the network connectivity data, port connections, system, and process information on the hosts. Depending on your tool, you can visualize all the contacts from a server to identify its dependencies, or you can run queries to list all the servers running a specific process, using a particular port, or talking to a specific host.?

To right-size your target environment, you can analyze the performance metrics for your servers and applications:

• If a server is over-provisioned, you can revise your right-size mapping information. You can also optimize this process by leveraging the utilization data for the server/application instead of the server specifications.
• If a server is under-provisioned, you might assign a higher priority to the server to migrate to the cloud.?

Creating a migration plan?

The next phase in your migration project is planning cloud migration. You will use the information you gathered during the portfolio discovery phase to create an efficient migration plan. By the end of this phase in your migration project, you should be able to create an ordered backlog of applications that can migrate to the cloud.

The main goals of the migration planning phase include the following:

• Choosing a migration strategy
• Defining the success criteria for the migration
• Determining the right size of the resources in the cloud
• Determining a priority for applications to migrate to the cloud
• Identifying migration patterns
• Creating a detailed migration plan, checklist, and schedule
• Creating migration sprint teams
• Identifying tools for migration?

The order of application migration can be determined through three high-level steps:

• Evaluate each application across several business and technical dimensions associated with a potential migration to accurately quantify the environment.
• Identify the dependencies for each application with qualifications such as locked, tightly coupled, and loosely coupled to identify any dependency-based ordering requirements.
• Determine the desired prioritization strategy of the organization to determine the appropriate relative weighting of the various dimensions.

The initiation of an application or server migration depends on two factors:

• First, the prioritization strategy of your organization and the application priority. Your organization might place varying emphasis on a few dimensions, such as maximizing ROI, minimizing risk, ease of migration, or another custom dimension.
• Second, the insight gained through the portfolio discovery and analysis phase can help you identify application patterns that match its strategy.?

For example, if the organizational strategy is to minimize the risk, then business criticality will have more weight in identifying the applications. If ease of migration is the strategy, applications that can be migrated using rehost will have higher priority, as rehost is a more straightforward process than other strategies. The outcome of planning should be an ordered list of applications that can be used to schedule the cloud migration.

The following are the planning aspects of migration:

• Gather baseline performance metrics for your applications before migration. Performance metrics will help you design or optimize your application architecture in the cloud quantitatively. You might have captured most of these performance details during the discovery phase.
• Create test plans and user acceptance plans for your applications. These plans will help in determining the outcome (success or failure) of the migration process.
• You also need to have cutover strategies and rollback plans that define how and where the applications will continue to run based on the outcome of the migration.
• Operations and management plans will be useful for determining the ownership of roles during migration and post-migration. You can leverage Responsible, Accountable, Consult, Inform (RACI) matrix spreadsheets to define these roles and responsibilities for your application that span the entire cloud migration journey.?
• Identify points of contact within the application team that can provide timely support in case of escalations. Close collaboration across the teams will ensure the successful completion of the migration as per the schedule (sprint).?

You can create multiple teams to assist in the migration process, depending on various factors such as your product backlog, migration strategy, and organizational structure. Some customers create groups focused on each migration strategy such as a rehost team, a refactor team, and a replatform team. You could also have a team specialized in optimizing your application architecture in the cloud. The multi-team strategy is the preferred model for organizations that have a large number of applications to be migrated to the cloud.

The team can be divided into the following segments:

• First, the team can validate the essential components to ensure your environment (dev, test, or prod) is working, adequately maintained, and monitored.
• The integration team will determine the application configuration and also find the dependencies, which will help reduce the waste that's made by another team.
• The lift and shift migration sprint team migrates large applications that don't require refactoring or re-platforming. The team will use automation tools to deliver small amounts of incremental value after every sprint.
• The replatform migration sprint team focuses on application architecture changes in order to migrate applications to the cloud, for example, modernizing application design for microservices or updating the operating system to the latest version.
• The refactor migration sprint team is responsible for managing various migration environments such as production, testing, and development. They make sure all the environments are scalable and functioning as required by monitoring them closely.
• The innovation migration sprint team works collaboratively with groups such as the foundation and transition team to develop a package solution that can be used by other groups.

It's recommended that you run a pilot migration project while planning and continuously building a product backlog so that these adaptations and lessons learned can be incorporated into the new plan. It's best to target non-production migration waves first in the pilot phase. The successful results of the pilot project and sprint can also be used to help secure stakeholder buy-in for the cloud transformation program.?

Designing the application?

During the design phase, your focus should be on successfully migrating applications and making sure your application design meets the required success criteria and is up to date after it has been migrated to the cloud. For example, if you are maintaining user sessions in the on-premise application server (so that it can scale horizontally), make sure that a similar architecture is implemented in the cloud after the migration, which defines the success criteria.?

For migration, first, you need to have a complete understanding of your organization's foundational architecture on-premises and in the cloud, which includes the following:

• User account
• Network configuration
• Network connectivity
• Security
• Governance
• Monitoring?

When thinking about your application's network design, you need to consider the following:

• Network packet flows entering the boundaries of your application
• External and internal traffic routing?
• Firewall rules for network protection
• Application isolation from the internet and other internal applications
• Overall network compliance and governance
• Network log and flow audit
• Separation of application risk levels, as per their exposure to data and users
• DDoS attack protection and prevention
• Network requirements for production and non-production environments
• SaaS-based multi-tenancy application access requirements
• Network boundaries at the business unit level in an organization
• Billing and implementation of the shared services model across the business unit?

The following diagram shows a migration design from on-premises to the AWS cloud, starting with the on-premises design:?

Now we transition to an AWS cloud design:

Performing application migration to the cloud

The migration execution step brings your plans to fruition. In the execution phase, you need to define a set of steps and configurations, as you will repeat them during the dev/test and production waves. Before executing migration, ensure that you have a migration plan and that you have identified the sprint teams and migration waves and schedules, have created a prioritized backlog, and have notified all the application stakeholders about the migration schedule, timelines, and their roles and responsibilities.

You must also ensure that the target environment in the cloud has already been set up with the foundational architecture and core services. You might have some application-specific pre-steps, such as performing a backup or sync before migration, shutting down the servers, or unmounting disks and devices from the server. Make sure you put in place your essential components, such as networking and firewall rules, authentication and authorization, and accounts. All need to be configured appropriately. You need to test your applications on the infrastructure to make sure that they have access to required servers, load balancers, databases, authentication servers, and so on. You need to pay special attention to application logging and monitoring to measure performance comparisons.?

Make sure you have good network connectivity with the cloud environment during the migration process. A good estimate of the amount of data that needs to be migrated also helps you properly estimate the time it will take to migrate your data to the cloud, given other factors such as bandwidth and network connectivity. You also need to understand the tools that are available to perform the migration. Given the number of devices that are available in the market, you might have to narrow down the selection criteria based on your requirements and other constraints.

As you know, rehost is often the fastest way to migrate your application to the cloud. When the application is running in the cloud, you can further optimize it to leverage all the benefits that the cloud has to offer. By quickly migrating your applications to the cloud by applying the lift and shift approach, you may start realizing the cost and agility benefits sooner.

Depending on the migration strategy, you typically migrate the entire server, including the application and the infrastructure that the application is running on, or just the data that belongs to an application. Let's look at how to migrate data and servers.?

Data migration

Cloud data migration refers to the process of moving existing data to a new cloud storage location. Most applications will require data storage throughout their progression into the cloud. Storage migration typically aligns with one of two approaches, but organizations may perform both at the same time:

• First, a single lift-and-shift move. This may be required before new applications can be started up in the cloud.
• Second, a hybrid model weighted toward the cloud, which results in newly architected cloud native projects with some legacy on-premises data. The legacy data stores may shift toward the cloud over time.

However, your approach to migrating data will vary. It depends on factors such as the amount of data, network and bandwidth constraints, the data classification tier (such as backup data, mission-critical data, data warehouses, or archive data), and the amount of time you can allocate for the migration process.?

For a small-scale database, one-step migration is the best option, which requires

you to shut down the application for from a couple of hours to a few days as per the complexity of the workload. During the downtime, all information from the database is extracted and migrated to the destination database in the cloud. Once the database has been migrated, it needs to be validated with the source database for no data loss. After that, a final cutover can be completed.

In the other case, if a system requires minimal downtime, a two-step migration process is more commonly used for databases of any size:

• In the first step, information is extracted from the source database.
• In the next step, data is migrated while the database is still up and running. You can configure change data capture (CDC) to ensure all data is migrated and the application is in a working state during migration.?

Server migration?

There are several methods you can use to migrate a server to the cloud:

• The host or OS cloning technique involves installing an agent on the source system that will clone the OS image of the system. A snapshot is created on the source system and then sent to the target system. This type of cloning is used for a one-time migration. With the OS Copy method, all operating system files are copied from the source machine and hosted on a cloud instance. For the OS copy method to be effective, the people and/or tool that executes the migration must understand the underlying OS environment.
• The disaster recovery replication technique deploys an agent on the source system that's used to replicate data to the target. However, the data is replicated at the file system or block level. A few solutions continuously replicate the data to target volumes, offering a continuous data replication solution. With the Disk Copy method, the disk volume is copied in its entirety. Once the disk volume has been captured, it can be loaded into the cloud as volumes, which can then be attached to a cloud instance.?
• For virtual machines, you could use agentless techniques to export/import your VM into the cloud. With the VM Copy method, the on-premise virtual machine image is copied. If the on-premise servers are running as virtual machines, such as VMware or OpenStack, then you can copy the VM image and import it into the cloud as a machine image. One main benefit of this technique is that you can have server backup images that can be launched over and over again.
• With the User Data Copy method, only the application's user data is copied. Once the data has been exported from the original server, you can choose one of three migration strategies—repurchase, replatform, or refactor. The user data copy method is only viable for those who know the application's internals. However, because it only extracts user data, the user data copy method is an OS-agnostic technique.
• You can containerize your application and then redeploy it in the cloud. With the containerization method, both the application binary and user data are copied. Once the application binary and user data have been copied, it can be run on a container runtime that is hosted on the cloud. Because the underlying platform is different, this is an example of the replatform migration strategy.?

Several migration tools in the market can help you migrate your data and/or server to the cloud. Each major public cloud provides its own tool for migration; however, you can also use other popular cloud migration tools such as CloudEndure, NetApp, Dynatrace, Carbonite, Microfocus, and so on. Some tools take a disaster recovery strategy for migration, and some disaster recovery tools also support continuous replication to facilitate live migrations. There are some that specialize in fork lifting your servers, performing database migrations across platforms, or database schema conversion. The tool must be able to support business processes that you are comfortable with, and you must have the operational staff to manage it.?

Integration, validation, and cutover

Migration, integration, and validation go hand in hand as you want to do continuous validation while performing various integration with your application in the cloud. The team starts by performing the necessary cloud functionality checks to ensure that the application is running with proper network configuration (in the desired geolocation) with some designated traffic flow. Instances can start or stop as desired when the basic cloud functionality check is complete. You need to validate that the server configuration (such as RAM, CPU, and hard disk) is the same as intended.?

The final phase of the cloud migration factory is the cutover process. In this phase, you take the necessary steps to redirect your application traffic from the source on-premise environment to the target cloud environment. Depending on the type of data or server migration (one-step, two-step, or zero-downtime migration), the steps in your cutover process may vary. Some factors to consider when determining a cutover strategy include the following:

• Acceptable downtime for the application
• The frequency of the data update
• Data access patterns such as read-only or static data
• Application-specific requirements such as database syncs, backups, and DNS name resolutions
• Business constraints, such as the day or time during which the cutover can happen and the criticality of the data
• Changing management guidelines and approvals?

Operating the cloud application

The operation phase of the migration process helps you to allow, run, use, and operate applications in the cloud to the level agreed upon with the business stakeholders. Most organizations typically already have guidelines defined for their on-premises environments. This operational excellence procedure will help you identify the process changes and training that will allow operations to support the goals of cloud adoption.?

The following are the IT operations that you would want to address in the cloud:

• Server patching
• Service and application logging
• Cloud monitoring
• Event management
• Cloud security operations?
• Configuration management
• Cloud asset management
• Change management
• Business continuity with disaster recovery and high availability?

In a DevOps (short for development and operations) approach, both the development team and the operations team work collaboratively during the build and deployment phases of the software development life cycle, sharing responsibilities, and providing continuous feedback. DevOps is a methodology that promotes collaboration and coordination between developers and operational teams to deliver products or services continuously. The software builds are tested frequently throughout the build phase in production-like environments, which allows for the early detection of defects or bugs.?

Application optimization in the cloud

Optimization is a very important aspect of operating in the cloud, and this is a continuous process of improvement. The following are the major optimization areas:

• Performance: Optimize for performance to ensure that a system is architected to deliver efficient performance for a set of resources, such as instances, storage, databases, and space/time.
• Security: Continuously review and improve security policies and processes for the organization to protect data and assets in the AWS cloud.
• Reliability: Optimize applications for reliability to achieve high availability and defined downtime thresholds for applications, which will aid in recovering from failures, handling increased demand, and mitigating disruptions over time.
• Operational excellence: Optimize operational efficiency and the ability
• to run and monitor systems to deliver business value and to improve supporting processes and procedures continually.
• Cost: Optimize the cost efficiency of an application or a group of applications, while considering fluctuating resource needs.

Creating hybrid cloud architecture

The value of the cloud is growing, and many large enterprises are moving their workload to the cloud. However, often, it's not possible to move entirely to the cloud in one day, and for most customers, this is a journey. Those customers seek a hybrid cloud model where they maintain a part of the application in an on-premise environment that needs to communicate with the cloud module.?

The common causes of setting up a hybrid cloud may include the following:

• You want to have operating legacy applications in an on-premise environment while you refactor and deploy in the cloud with a blue-green deployment model.
• A legacy application such as a mainframe may not have a compatible cloud option and has to continue running on-premise. You need time to refactor the tech stack.
• You need to keep part of the application on-premise due to compliance requirements.
• To speed up migration, keep the database on-premise and move the application server to the cloud.
• The customer wants to have more granular control of part of the application.
• Data ingestion in the cloud from on-premise for the cloud's Extract,
• Transform, Load (ETL) pipeline.?

Designing cloud-native architecture?

Cloud-native doesn't mean hosting your application on the cloud platform; it's about leveraging services and features provided by the cloud. This may include the following:

• Containerizing your monolithic architecture in a microservice and creating a CI/CD pipeline for automated deployment.
• Building a serverless application with technology such as AWS Lambda Function as a Service (FaaS) and Amazon DynamoDB (a managed NoSQL database in the cloud).
• Creating a serverless data lake using Amazon S3 (a managed object storage service), AWS Glue (a managed Spark cluster for ETL), and Amazon Athena (a managed Presto cluster for ad hoc queries).
• Using a cloud-native monitoring and logging service, for example, Amazon CloudWatch.
• Using a cloud-native auditing service, for example, AWS CloudTrail.?

The benefit of the cloud-native architecture is that it enables fast-paced innovation and agility in the team. It simplifies building out a complex application and infrastructure. As system administrators and developers, you focus strictly on designing and building your networks, servers, file storage, and other computing resources, and leave the physical implementation to your cloud computing provider. Cloud-native architecture provides several benefits:

• Fast scale-out, on-demand: You can request the resources you need when you need them. You only pay for what you use.
• Replicate quickly: Infrastructure-as-code means you can build once and replicate more. Instead of building your infrastructure by hand, you can structure it as a series of scripts or applications. Building your infrastructure programmatically gives you the ability to build and rebuild it on demand, when needed for development or testing.
• Tear up and tear down easily: In the cloud, services are provided on-demand, so it's easy to build up a large experimental system. Your system may include a cluster of scalable web and application servers, multiple databases, terabytes of capacity, workflow applications, and monitoring. You can tear it all down as soon as the experiment is completed and save costs.?

Summary

You learned how the cloud is becoming the most popular mainstream application hosting and development environment for enterprises. At the beginning of this chapter, you learned about cloud thinking and how it's related to solution architecture design. Since more organizations are looking to move into the cloud, this chapter focused on various cloud migration strategies, techniques, and steps.