A Cloud Migration Checklist

Transcription

1 A Cloud Migration Checklist WHITE PAPER

2 A Cloud Migration Checklist» 2 Migrating Workloads to Public Cloud According to a recent JP Morgan survey of more than 200 CIOs of large enterprises, 16.2% of workloads are currently running in the public cloud, and in five years 41.3% of workloads will run in a public cloud. If that s the case in 5 years, what will happen in a decade? As AWS becomes a $14B business and Azure s market share continues to grow, enterprises are clearly leveraging the public cloud more and more each year. However, even though self-provisioning of new workloads on AWS or Azure is simple, migration of a running service to the cloud requires more planning. It s a common perception that migrating existing workloads to the public cloud especially those with a lot of data must be complex, time consuming and risky. But enterprise IT organizations are rapidly establishing good migration practices, and migration technology is evolving quickly to support them. In this white paper, we will provide the essential tips (plus a checklist at the end) to help guide IT organizations through the five key parts of the migration process: Discovery, Planning, Testing, Migration, and Ongoing Operations. 1. Discovery: Lay the Migration Groundwork Before you dive into the details of the migration itself, it s usually helpful to start with something more organic: your migration team. It is likely you ll be working with other members of your organization, so determine who those stakeholders are now and determine what level of involvement is most appropriate for them throughout. Getting people from the security and application teams early on, for example, can help mitigate issues that might have otherwise occurred mid-migration. Make sure to educate these stakeholders on your organization s cloud strategy so they understand the importance of their role. Once you ve got the people piece figured out, it s time to dive into the applications themselves. It s likely that your enterprise has hundreds (or even thousands) of applications to migrate to the cloud, so where do you begin? The first part is understanding which applications should be moved to the cloud first. There are many variables that will impact priorities, including identifying application dependencies, cloud-readiness, application SLAs, physical or virtual, etc. There are other variables that will also be crucial during the migration, like server names, IP addresses, # of VMs per application, VM OS and service pack, CPU, memory, attached disk space, shared storage, databases (size and type), licenses, bandwidth usage, integrations, and more. Due to all the information you ll need for your applications, we recommend preparing a thorough questionnaire that outlines all of these crucial pieces of information. You can send this to application owners to help evaluate migration readiness but also to have key information easily accessible during the migration itself. It is worth noting, however, that application owners may not even know all the information that s needed, and in some cases environment analysis tools might be required to fill the gaps. You can also use discovery tools like AWS inventory or ServiceNow to help further identify applications and their dependencies. 2. Planning: Pick your Strategies Applications According to Gartner, there are essentially three cloud migration strategies that IT can use when moving to the cloud: Re-platform (sometimes referred to as Lift and shift )- redeploy applications on an IaaS without making changes. Re-factor- Keep applications roughly the same, but reconfigure select components to take advantage of cloud-native tools, like replacing SQL with Amazon s RDS. Re-write- heavily modify existing code to carefully fit the cloud environment and take advantage of cloud-native tools. Although these three options exist, enterprises are finding that the smartest (and fastest) strategy is to start with option 1 (re-platforming) and move applications into the public cloud first. From there, they can evaluate performance and optimize as appropriate. That could mean simple changes like adjusting instance sizes, or changing some of the on-prem functionality to be more cloud centric (like our SQL to RDS example), or deciding to re-write it entirely while it s running in the cloud. The strategy thus becomes start with option 1, and then let your applications guide you. Data Migrating an application usually involves migrating data along with it. Consider the amount of data associated with each application, where it is currently stored and how frequently it is updated. If you are using the cloud for disaster recovery, there are several tools that can handle this type of data replication. If you are moving live applications, then you will want to consider tools that were purpose-built to address the associated complexity in keeping data synchronized during the migration and through cutover. Migration Solutions There are two primary architectures for cloud migration tools that exist today: Replication-based and streaming-based. Replication-based migration tools are typically re-purposed disaster recovery (DR) tools, which means they essentially copy and paste applications and data into the cloud. Example steps from a replication-based solution could be: Installing an agent on the source (and/or destination) systems. Replicating some (or all) of the dataset, which can take anywhere between hours to weeks depending on network

3 A Cloud Migration Checklist» 3 bandwidth and the tool s transfer optimizations (if any). Identifying and synchronizing the delta between the replicated copy (in the cloud) and the production (live) dataset on premises, and moving that before the cutover. Cutting over, at which time the workload begins running in the cloud. Streaming-based migration tools are typically a more effective approach for live and/or production applications, especially when you don t want to wait until all the data is moved before you can test or begin running your app. The streaming approach moves just an initial subset of critical data into the cloud so that your application can begin running in the cloud within minutes. Then, in the background, you continue to upload data into the cloud, as well as keep the on-premises data synchronized with any changes made in the cloud. This can save tens (or hundreds) of hours during a migration project, and can make streaming-based solutions significantly faster than replication-based. Ideally, you need to answer the following questions about what you consider important for your solution. Some considerations include: Agents: Many replication-based systems require installing agents in each application and/or in your cloud target. You ll need access to each application s system(s) and installation/ removal can add time and complexity. If you re moving a lot of applications, an agent-less solution may be a better fit. Apps and Data: Does the system handle just the data migration or can it also handle moving the application. Testing: Does the solution offer a way for you to test applications before they are migrated without taking production and/or live systems offline, and without transferring into data sets to the cloud first? Can you change cloud instances on the fly to test different configurations? Rollback: Can you revert the application back on-premises if needed? How long does it take? Customization: Can the solution automatically adapt the application for the targeted cloud? Monitoring: What tools are available to track migration process? Complexity: How will the system support multi-tier applications that require orchestrated shut down and restart? Cutover: What needs to take place once the data is migrated and you re ready to go completely cloud-only? Do you need to shut down application services on the source or destination first? Is there downtime? Do you have to uninstall any agents when you ve finished? Is there a chance that my data will be slightly out of sync and if so what is the RPO? Cloud migration technologies and tools have come a long way. It s important to identify the requirements that are important to your enterprise and then select the appropriate solution. 3. Testing: See How Applications Perform in the Cloud Testing your applications in the cloud before you officially migrate them is an important way to save time and mitigate risk. It gives enterprises the opportunity to easily see how applications perform in the cloud and make the appropriate adjustments before going live. As we mentioned previously, some migration tools will provide a way to run clones of live environments in the cloud so you can do realistic testing but without impacting data or uptime of the live system. While testing in the cloud, enterprises should also identify the key areas to leverage cloud provider s services things like DBaaS (Database as a Service), DNS services, backup, or other application-level managed services. Of course, be sure to review all the cloud environment prerequisites for supporting the migrated workloads like networking (subnets, services etc.), security, and surrounding services. In some cases, especially early in the migration project, it s useful to run a proof of concept for some of the applications you plan to migrate. These pilot projects will help you get a feel for the migration process, but also validate two crucial pieces of your migration: The resources and capacity your application requires. Your cloud vendor s capabilities and potential limitations (e.g. number of VMs, storage types and size, and network bandwidth). A good example where this is crucial is memory-intensive applications. You need to do the proper performance testing by simulating real-world load on the system so you can choose the right sized instance with enough memory to run your application in production. The pilot can also help you understand which storage services will replace your different traditional repositories (e.g., Amazon cloud EFS to replace your traditional NAS appliance). Ideally, a cloud migration solution will provide built-in functionality to run an application clone directly in the cloud. This is powerful because it allows enterprises to see how that application will run in the cloud with real data, but without impacting the live system s uptime or data. When testing is done, you can simply dispose of the test clone. The more you re able to test in the beginning, the smoother your migration will ultimately go. We advise running tests which validate both: Application functionality, performance, and costs when running in the cloud. Migration tools, and that they are providing the right capabilities to get your migration completed successfully. Ultimately, this testing will help ensure you have captured the right configurations (settings, security controls, replacement of legacy

4 A Cloud Migration Checklist» 4 firewalls, etc.), perfected your migration processes, and developed a cost-baseline for what your deployment will cost in the cloud. 4. Migration: Moving to the Cloud At this point, if you ve done good testing, your migration project should be on track for success. Still, we advise that enterprises use a phased, agile approach for moving applications to the cloud. After each phase, review the results and adjust your plan for lessons learned if needed. Having a migration solution that lets you revert back to the on-premises configuration, if necessary, can be a huge benefit at this phase, too. This essentially de-risks the migration process, because you ve always got a safety net to return to, adjust, and retry. If you re leveraging a replication tool for migration, be sure to validate data synchronization and consistency throughout migration. It is not uncommon for large data sets to end up out of sync during the replication process or as a result of the cutover. 5. Don t Forget to Consider Ongoing Operations Change your operational usage habits to meet the cloud s highly dynamic environment. For example, in the cloud, you have more flexibility to provision and adjust instance type and size based on real demand. Track your cloud vendor s product updates and don t be afraid to experiment as you continue to optimize. As your migration continues, build the maintenance and transparency layers in parallel so that IT can properly manage things like security, performance, availability (backup and DR) and cost. Learn which management tools are provided by your cloud vendor and learn how to use APIs to tailor your own solutions. Evaluate the marketplace to find 3rd party vendors that can support you with operations such as monitoring, backup automation and cloud firewall management as needed as well. Those are the five key phases- and the steps you should be taking along the way- for a successful cloud migration project. To help guide you along your own cloud migration journey, we ve compiled a cloud migration checklist that outlines these steps on the following page:

5 A Cloud Migration Checklist» 5 A Cloud Migration Checklist» 5 Your Cloud Migration Checklist We ve summarized the ideas above into this checklist to help you on your cloud migration journey: 1. Discovery: Create a list of your applications who is using what and how often Identify key stakeholders and involve them early Create a survey to send to application owners to define requirements and begin prioritizing your migration pipeline Which applications are cloud-eligible Which applications are cloud-desirable Understand application interdependencies and network configurations Specify security and compliance requirements Validate SLA and high availability requirements 2. Planning: Pick a strategy for each application: re-platform, re-factor, re-write Decide on data migration and synchronization strategy: Replication or Streaming Plan and design the cloud infrastructure including services like networking, security, etc. Determine the amount and size of instances and the right mix of storage Identify key capabilities for solution migration Agents or agentless architecture Migration for both apps and data Pre-migration testing On-prem rollback Customization Process monitoring, insights Support for complex, multi-tier apps 3. Testing: Test data migration and synchronization Measure performance Validate security controls required Evaluate your cloud footprint costs Document necessary changes to be done as part of the actual migration Plan the time required for application cutover 4. Migration: Migrate according to the plan and the runbook created Use a phased approach implement, review, adjust Apply lessons learned 5. Ongoing operations: Monitor application and cloud usage Implement bursting or scaled-usage to optimize user experience Empower IT to successfully manage ongoing operations Creating an effective cloud migration process for your enterprise requires change and flexibility. Moving enterprise applications to the cloud may involve some challenges but the right planning combined with the right solution will deliver speed, simplicity, scalability, and sanity to your migration project, along with all of the long term benefits of leveraging the public cloud. If you re thinking about migrating your applications to the cloud, one of our cloud migration specialists would love to help provide you with some guidance. You can reach us at info@velostrata.com or by calling Velostrata Inc. 20 N San Mateo Drive, Suite 4 San Mateo, CA USA Phone Website velostrata.com