Cloud Migrations

This is a guide on cloud migrations.

Check out Audible on Amazon and listen to the newest books!

Cloud Migration Strategy

Cloud migration is systematic and documented strategy that helps to plan, to move data and application from on-premises architecture to the cloud. Apart from that, cloud migration also recommends adopting most efficient approach to migrate applications before going live. Now let's try to focus on identifying appropriate cloud migration roadmap.

Cloud migration roadmap starts always by deriving migration plan. It means before we start, we need to be clear on what all are the reasons for moving to the cloud, and what strategy is the best strategy to do that. It is followed by selecting the right cloud environment for which you need to do assessment and identify whether public cloud, hybrid cloud, private cloud, or multi-cloud model is the right fit environment for your cloud migration. Now you are aware about the environment. Your third step is always to focus on migrating your apps and data. But yes, you need to keep in mind cloud security concerns and also follow the policies and compliance needed by applications and data that you are migrating and fourth step is to validate post migration. You cannot declare a cloud migration to be successful until you are not able to get evidence of it.

You need to ensure that you are validating your migration in order to make sure that you are meeting the objective of migration. Now, after going through migration roadmap, let's try to figure out reasons why migrate to the cloud, and first reason is it decreases overall hosting cost. Because in cloud, you don't need to worry about cost and conditions of keeping physical server running. A third party data center which will be cloud provider will manage the server using subscription based model. Second reason why we can plan to migrate to cloud is it provides better agility and scalability. Because cloud-based services not only automatically scale capacity to growing demand, but also allows team to collaborate on application updates, or issues from anywhere, instead of on-site.

Third important reason of migrating to cloud is decreased footprint. Because server capacity is up and down to fit your cloud need, you only use energy and resources that is actually required in order to meet the demand. Fourth reason is it facilitates better disaster recovery, by providing you various different approach of adopting backup and recovery solutions. And finally, cloud provides greater security because cloud providers will offer greater security than on premises data centers by storing your sensitive data, applying various different security mechanisms on it in order to ensure that your data and access to application is secure. Apart from that, we need to be also aware about challenges that we may face while cloud migration. Let's go ahead and list some of them. And first challenge is downtime.

Because when you migrate, migration process might require taking in house servers temporarily offline. Second challenge is data loss. Now, when you move to the cloud, your company's data which is most valuable may also be at risk. So you need to take extreme care to minimize breach risk by applying appropriate cloud security controls, like privileged access management and encryption. And third challenge is interoperability. It is not easy to get your existing applications to communicate properly with selected cloud environments. To ensure you are able to do that, you need to adapt your processes to those of cloud providers. So finally we can say that we need to first identify the goal of migration, then adopt appropriate cloud migration roadmap taking care of cloud migration challenges.


Cloud Strategies

We need to always start by having proper assessment of applications and workloads. Because assessing applications and workloads for cloud readiness will help us to determine what applications and data can and cannot be moved to cloud environment. And if it can be moved, what is the best delivery model? Step two is to build appropriate business case.

Developing a business case for migrating applications to cloud computing would need an overall cloud computing strategy, which includes finding out specific information that describe the current state, and demonstrates advantages of cloud computing. Once you have the business case ready, you need to develop a technical approach where you need to identify what would be Platform as a Service, what all Infrastructure as a Service, whether you'll go with Container as a Service, Function as a Service or not. In short, you need to identify service model where actually you will be migrating your applications and workloads. Next step is to adopt a flexible integration model. Sometimes you will find that you need to integrate your applications which you are planning to move to cloud to other external systems.

You need to identify appropriate integration pattern that can help you to integrate your application with external services post migration of services. Step five is very important because its objective is to address compliance security, privacy, and data residency requirements. These are key issues that have impact over usability of applications. And finally, you need to manage the migration, where you need to think why, what and how application migration project need to be initiated. You will have all stakeholders sit together, and decide appropriate plan to migrate and post migration activities. Now let's go and focus on identifying suitable candidates for cloud migration, which will help us to determine what all components can be migrated to cloud. First suitable candidate is those applications that run infrequently and requires significant amount of computing resources.

Second suitable candidate is those applications which are business-to-consumer, where you don't know how many users will connect. This also applies to P2P or our peer-to-business applications. Third suitable candidate are those applications that serves multiple time zones. And finally, if your application is loosely coupled, it is one of the suitable candidates that can be considered for cloud migration. Now let's try to focus on the strategy, which we call as six Rs of migration. We'll start with first which is rehosting. It's a migration strategy that uses migration tool to replicate applications in cloud environment without need of redesigning the application again. Second strategy is replatforming where you redesign your applications and environment in order to make it cloud-ready.

Third is repurchasing, where when you want to move from an on-premises solution to cloud, you can identify the gap, and then plan selecting one of the services which are provided by cloud providers as Software as a Service. Fourth R is refactoring, where your focus is on refactoring the application, so that it can be tuned for cloud migration. Fifth strategy is retiring where you need to retire some of the applications which you are using on-premises, and select appropriate services provided by cloud providers in order to facilitate those services. And finally, it's retaining, where some of the applications can be retained in on-premises environment, while rest of them can be migrated to cloud. Now after understanding six Rs, we need to understand migration workflow, which will help us to identify strategies and where they will be applicable.

We'll always start the workflow with discover phase where we'll determine the strategy. Strategy can be refactored, repurchase, replatform, rehost, retain and retire. Now let's go through what activities need to be done as part of migration workflow when you adopt a particular strategy as it is displayed using a diagram. Refactor needs redesign, app code development, selecting appropriate lifecycle management or SDLC, and integration to external services. You need to validate once you have adopted refactor and you have migrated. Next strategy is repurchase, where you will be buying COTS or Software as a Service. And then you will install and setup whatever purchases are made. Post doing that, you need to validate. For replatform, you need to determine platform, you need to modify existing infrastructure for which you can use migration tool.

Once this activity is done, you need to validate. Rehost is all about complete reinstallation, reconfiguration and redeployment. Retain and retire depends on what you want to retain in your existing environment. And retire means what components you want to retire on existing environment and you want to have a cloud provided service. Irrespective of strategy, you need to plan transition. Once transition is planned, and your migrated application and data is tested, you can move it to production. Now these are some of the steps and strategies that you can adopt in order to identify right candidate that need to be migrated. Adopt right migration steps and build appropriate migration workflow, which helps you to decide the strategy that you want to use for migration and transition to production.


Cloud Migration Methods

Some of the critical reasons of migrating starts always with attempt to move from capital expense to operational expense. Why do we move from CapEx to OpEx? We move from CapEx to OpEx because CapEx can be depreciated over time, but it requires upfront cash. Whereas operating expense is incurred only when we use the system.

Second reason of migrating is to have savings on handling peak loads. And this is where cloud comes into play. It has ability to scale server capacity up and down to match spikes in demand. And this will help in lowering the cost for a cloud-based solution as compared to on-premises one. Third reason which will motivate us to migrate is short cloud contract periods. On-premises solutions usually requires a nonrefundable investment in hardware, as well as software licenses. Whereas cloud contract provides flexibility of cancelling or reducing the services with certain advanced notifications. And fourth reason is cloud's capability to facilitate better availability, performance, and security. And finally, all these put together will help us to have better time to market.

Now, after we have identified why we are migrating, let's go ahead and list down migration method. First, we need to deploy the cloud environment where we will provision, install, and test the necessary storage, compute, networking and security resources that will be needed to deploy our applications. Next, we need to implement monitoring and management services and components by setting up appropriate process, procedures. And using tools that will help us to manage and monitor the environment. Third task is to ensure that we have installed and configured applications and all the supporting middleware. And finally, we need to focus on harden production environment. And that we do by installing and using additional utilities for business continuity and security. Now, let's try to focus on three other Migration methods.

Where first is to execute a Trial migration that will help us to understand what benefits we will be able to realize Post-migration and what all are the issues that we may face. Followed by Trial migration execution, you need to focus on Executing operational readiness testing that will help us to understand whether team, processes and tools are ready for migration or not. And finally, we'll Go live in production. Assuming that you have successfully migrated, you need to plan Go live in production. Now, what all are the tools that can be used in order to help us in migrating? You'll have multiple different cloud providers. Those cloud providers will provide you migration tools. Let's try to list migration tools which are provided by AWS and Azure.

We'll first go through AWS cloud migration tools. It is considered as one of the best cloud migration tool if you are planning to migrate to AWS. AWS provides you AWS Server Migration Service which is a free service offered by Amazon Web Services to their customers who are planning to migrate their in-house workload to cloud. Second set of migration tools are Azure migration tools, where it provides you all migration services for free. Now, let's try to understand how AWS Cloud Migration Tool works. And to do that, we'll be using a diagram which is currently displayed on the screen. At the left-hand side of the diagram, we have vCenter Server, which is managing our virtual machines powered by vSphere. Now, we are planning to migrate to AWS. We need to first identify all the AWS services which we'll be using.

After provisioning those services, we need to come up with a plan where we will execute Scheduled task, Upload the required data. Convert data and protocol so that it can be adopted in AWS, and finally, Create AMI. Once image is created, using that image you can create instances where you can deploy your workload. This is how you can plan your migration strategy from on-premises to AWS. Now, let's try to focus on Azure Migration Tool, which always starts with Discover. Second task is to Map dependencies and determine network and storage topology. Third is to come up with Recommended optimization path for workload and cost modeling. Fourth step is to Determine best cloud computing service model provided by Azure for your intended task. And finally, come up with Cloud Migration strategy and plan that you can execute.


Migrating Workloads

Third type of workload is software as a service, which is offered by cloud providers for consumption by end user. [Video description begins] Software as a Service is abbreviated as SaaS. [Video description ends] You don't need any IT team in order to manage the software because it is taken care by software provider and cloud providers. Fourth type of cloud workload is hybrid and multi-cloud services. Hybrid services will contain multiple workloads where some of the workloads will operate on different infrastructure. And when we talk about multi-cloud services, you will have more than one public cloud provider where you have to distribute your workload. And finally, it is serverless, where developer need not worry about what amount of resources need to be dedicated to execute services and provide runtime behavior to their workload. Now we need to identify reasons for adopting hybrid cloud.

First reason is it provides better support for a remote workspace. Apart from that, it also facilitates in reducing the cost. And we know that cost is a key factor for many enterprises when they consider migrating to the cloud. When we adopt hybrid cloud, it provides great option for enterprises that wants more security and control over their data. But needs a cost effective approach to scale their operations in order to meet spike in demand. Third reason to go for hybrid cloud is improved scalability and control. Hybrid cloud environment gives businesses greater control over their data. As businesses need to evolve and the demand for IT services continuously fluctuates, organizations can scale their workload accordingly. And fourth reason of adopting hybrid cloud is its capability of ensuring more agility and innovation.

Ability to respond automatically to changes in demand is a key factor that drives innovation. And you'll find hybrid cloud to be one of the best environment for innovation. Apart from that we adopt hybrid cloud because of two other reasons. First is business continuity, because hybrid cloud model improves continuity and reduces potential downtime and the cost. Business continuity basically means that in the event of a failure or disaster, how businesses are going to operate. And finally we can adopt hybrid cloud because it provides improved security and risk management. Now let's try to go through steps that are required for migrating to hybrid cloud. And first task is always to identify the portion of businesses which are cloud-ready. You need to recognize those and plan to migrate them to cloud.

Second step is to assign quick size and time estimates. And this depends on various other factors like migration as is date, size as is, size and modification, migration along with modifications. Third is to plan migration schedule where you need to come up with a schedule to migrate selected portions to cloud. Now, once you have planned your migration, you need to now provision the environment where you need to establish new infrastructure with your cloud partner. And provision the required hardware and software based on agreed architecture. And plan to start migrating by creating and configuring virtual machines, setting up performance and other parameters, installing required softwares and patches. And finally, you are ready to transition to the new hybrid cloud that you have provisioned in the previous step.

At this particular phase, objective should be to start using the new migrated elements and retire the old architecture. Now, after going through steps of migration, let's go ahead and take a case where we need to discuss how do we migrate from on-premises to hybrid cloud. And we'll start activity by discovery, where we will discover customer's on-premises footprint, which includes number of VMs, networks, and applications. Step two is always to map dependencies and determine network and storage topology that is needed. Once you have identified network and storage topology, you need to come up with recommendations for optimizing workload, along with cost control mechanism.

Step four is always to determine best cloud computing service model, followed by coming up with migration strategy and plan. So when you are planning migration, you need to understand what benefits you will get when you migrate your workload to hybrid cloud, and what are the steps that you have to take in order to complete the migration.


Phased Cloud Migration

We need to have proper plan before we start migrating workload and data to cloud. And one of the approaches to adopt phased cloud migration, where we will divide entire cloud migration activities into multiple phases. Let's say to understand using a diagram, which is currently displayed on the screen. Our first step is always to define strategy, and architecture where we need to go through application portfolio, understand data and prepare high level roadmap, along with high level business case for migration.

Then we need to move to phase two, which is all about high level analysis and planning when we need to identify migration candidates. Once we have identified migration candidates we need to identify constraints and criteria and also go through details of application architecture. This will help us to derive appropriate migration plan, resource planning, schedule estimates and also cost benefit analysis. Now we are ready with our migration plan and scheduling plan as a result of phase two. We'll move to phase three, where we will design, develop and integrate for which we need to identify candidates for migration and come up with migration design. We need to identify transformation if it is needed for integration and design transformation. And finally we need to identify candidates for build and come up with design and build activities.

Outcome of design development and integration phase will be architectural artifacts, design documents, project plans, test plans as well as deployment plans. And finally, we'll go for phase 4 which is migration where we need to decide migration strategy which can be reinstalled, replatform, refactor. Once we decide our migration strategy we'll move for deployment where we need to identify cloud deployment models which can be private, hosted or public. The step by step phases are used in order to build a pipeline that can be fed to migration factory in form of a migration factory model. Now let's go ahead and prepare a cloud migration checklist where first checklist element will be to establish migration architect role. Choose level of cloud integration that we expect, considering on-premises data centres and cloud capabilities.

We need to also choose a single cloud or decide whether we'll go for multicloud. Once these decisions are made, we need to have a checklist that helps us to establish cloud KPIs. Apart from Cloud KPIs, we need to also ensure that our checklist contains performance baseline that helps us to measure the current performance of application and post migration performance. Apart from that, we need to also have a checklist which contains prioritized migration components. Once we have identified and prioritize migration components we need to ensure that checklist also contains items that helps us to perform necessary refactoring. And finally, we need to make a note of data migration plan in our checklist. Once checklist is ready it can be considered while you plan your migration.

Now once we understand what all are essential elements of checklist, let's go through KPI considerations for migration. And we have categorized it on basis of three important elements, which is presented in form of a table. First category is user experience. Sample KPIs can be page load time, what is the lag? What is the response time, and what is the overall session duration? Second category is application, and component performance, which is measured using KPIs like error rates, throughput, availability, and Apdex. And finally, infrastructure. Sample KPIs to understand infrastructure capability are CPU usage %, disk performance, memory usage and network throughput. And finally, let's go through phased migration workflow which is all about creating inventory and also planning cloud assessment, Post cloud assessment, you have to start planning phase where you will come up with migration tool selection, high level diagrams, low level diagrams.

That will be used in order to plan execution. Then comes phase three, which is execution where we'll identify the cloud, build cloud foundation infrastructure, set up migration tools and conduct a pilot run and validation and go for migration. Post execution we need to move to next phase which is validation and acceptance where we will cross-check validation of migrated workload and applications, conduct UAT and plan to hand over the project. And finally, once project is handed over and it is live, we need to go through post migration tasks which is all about cleaning and decommissioning activities and continuous support for migrated infrastructure on cloud.


Optimizing Lift and Shift for Cloud

Now let's try to understand why do we adopt lift and shift? First reason is it provides us a fast cost-effective and minimally disruptive migration. It lets us migrate quickly, without dedicating a large team to various different tasks. In this particular strategy, on-premises applications can remain in place during the migration, so that there is no interruption of services.

Second reason is, its potential for improved performance. Lift and shift strategy provides opportunity to run applications always on updated, better performing hardware, without need of buying hardware yourself. Third reason for lift and shift is, its capability to provide expanded capacity while consolidating on-premises. In short, you can add compute capacity storage, network bandwidth from the cloud, on a pay-by-use basis, while you consolidate your on-premises data center infrastructure, and cost at the same time. Next benefit that we realize is, capability of scalability on demand. Lift and shift strategy, helps enterprises to scale applications without purchasing, and physically installing new compute capacity. Apart from that you have two other interesting reasons. First, cost-saving elasticity.

You'll find that some applications may need cloud elasticity, that is, ability to automatically spin up and spin down resources, to precisely meet the demand. The greater your cloud elasticity, more your application can leverage it. And more you stand to save by exactly using amount of resource that is needed at any given point of time. And finally, lift and shift can be considered as one of the strategies, that helps us to have reduced on-premises data center costs. Now after we understand why use lift and shift, let's try to take up scenarios, that helps us to decide, when to use lift and shift migration. And first case is, when on-premises infrastructure cost increase. Second scenario is, when you want to migrate off-the-shelf applications. It will help you to migrate your applications, without re-architecting.

And third use case is, when you need less-costly, but more scalable backup and recovery capabilities. Cloud provides you better RPOs and RTOs, as compared to on-premises. Now we need to focus on understanding, how do we get optimized lift and shift migration. We can optimize lift and shift migration, by adopting various different steps. Now let's try to understand, what all are the steps that can be taken in order to have optimized lift and shift migration. And first step as it is indicated in the diagram currently displayed on the screen, as to define end-state cloud storage. Once you have decided end-state cloud storage, you need to now decide on backup. Because backup helps you to retain your data, and provide you data back to you, whenever you need.

Third step is to unpack migrated data. Now when the destination cloud data is ready, you can restore the backup, and you can unpack that migrated data to make it available on cloud. And finally, you need to monitor and test the efficiency, and performance of your new cloud environment. Finally, let's try to go through certain lift and shift migration patterns. We can classify lift and shift migration patterns into three categories. First is in-place migration, second is in-place, lift and shift to cloud, and third is, lift and shift to cloud and then migrate Operating System. Now let's try to understand using a diagram which is currently displayed on the screen. In in-place, lift and shift migration pattern, we migrate OS, then go for migrating application and data and test.

But when we go with in-place, lift and shift to cloud, we have migrate operating system, then we go and migrate application and data, we test, and finally, we lift and shift it to cloud. And when we adopt lift and shift to cloud and then migrate OS migration pattern, we need to first go for lift and shift to cloud, followed by migrating operating system, followed by migrating application and data, and finally, testing your migrated workload. So depending on your need, you need to first identify whether lift and shift works for you or not. And in case if it works, you need to identify the right lift and shift migration pattern.


Legacy to Cloud Migration

Now let's try to first understand the flow that we can use in order to migrate from legacy to cloud computing. And that we will do using a diagram which is currently displayed on the screen. As the diagram indicates, we have three different stakeholders. First is the Consumer, second is Service developer, and third is Provider.

Now let's try to understand who will be doing what for migrating legacy applications to cloud. Consumer need to conduct requirement analysis and then go for evaluating migration decision. During this particular activity, consumer will justify why migration is required. Post evaluation will go with analyzing the legacy system. This particular task will help service developer to understand the current system, analyze various different components like input, output, system responses, storage, and compute requirements. Next activity is to identify components that need to be migrated. Again, this is task which will be done by service developer. Once you have identified components to be migrated as a service developer, you need to extract functions or components.

Once you have extracted functions or components, you need to go for migrating the component. Post migration, as a service developer we need to check complete service, confirm that migration has been completed successfully. If it is successful, it should be made available for consumers to consume the service else we need to undo the changes. Now what is role of provider? Provider's role is to offer candidate service which is mapped with components that need to be migrated. And apart from that, provider will link migrated component. So by ensuring that all stakeholders are doing what they are supposed to do, we'll be able to have guidelines set for migrating legacy to cloud computing.

Now we'll discuss key elements of legacy to cloud migration, and we have divided it into three different phases as it is displayed in the diagram. First phase is plan phase, where we need to analyze context, analyze migration requirement, identify existing legacy system, and then define plan. Plan phase will provide legacy system model, migration requirement, and migration plan. From plan phase we need to have transition to design phase where we'll come up with cloud solution design. We'll select cloud service and platform, we'll also identify incompatibilities and adopt design principles in order to decouple legacy system components. Now what do we get as an output once design phase is over? We get cloud solution architecture and virtual machine specification.

Once design phase is over, we'll move to enable phase where first tasks that we need to do is to resolve all incompatibilities that we have identified. Then encrypt and decrypt entities, deploy system components, configure network, enable elasticity, and deploy systems. Post deployment you need to ensure that you are testing the system or output that you will get once enable phase is over as the system templates. Now, once you have completed enable phase you will get output which will be in form of work-products and that work-product will be system templates. We need to ensure that post enable phase you can again move to plan phase to consider other migration. And this is the reason why we can say that legacy to cloud migration has to be incremental and iterative in nature.

Now we need to talk about modernization of application, and why do we modernize? When we say modernizing application it means we are not facing any issues, but in order to catch up competitors, we want to modernize our application. Let's go through some of the reasons why do we modernize applications where first is to achieve competitive advantage in industry. Second, when you modernize your application becomes future ready because you will eliminate all the decoupling which exists in your system. Thirds reason is to get better performance and reliability by ensuring that you are considering all the outages, and risk and then you are coming up with plan to eliminate them in your modernize applications. Fourth reason is to ensure that your current stack is extensible.

Now once we have decided to modernize applications, let's go through certain steps that need to be followed for modernizing applications, and first step is to identify the mission critical application that you want to modernize. Consider all the available resources, decide appropriate modernization approach, never forget to track improvements, and finally plan end-to-end process change. So, depending on your need you have to decide whether you are going for migration or you are going for modernization. If you are going for migration you need to identify critical elements that you need to migrate and also identify components that you want to modernize in order to provide better user experience to end users.