Cloud Migration Strategies

Title: Cloud Migration Strategies

By Jonathan Maresky, Product Marketing Manager, CloudGuard IaaS, published April 2, 2020

When determining your cloud computing strategy, it’s important to understand that no two commercial situations are alike. Organizations may have varying areas of expertise, different commercial pressures, experiences, team structures, responsibilities, and so on.

While some companies are “born in the cloud” or already have strong cloud capabilities, other organizations may be driven to the cloud through so-called “push factors,” such as critical infrastructure products phasing out support, or “pull factors,” such as lack of CapEx available for investment in physical servers.

Cloud migration is the process whereby an organization relocates part or all of its data, applications, and workloads to a cloud infrastructure.

This article will discuss high-level cloud migration strategies in order to help you choose the most appropriate approach for your business.

High-Level Strategy

Once an organization has determined it is ready to move to the cloud, there are a number of context-specific decisions to be made. Having a general, guiding strategy is critical.

Laying out your goals and the issues you hope to address through your cloud migration strategy can help ensure your business and technology strategies are aligned. What do you hope to achieve?

• Are you trying to cut costs or improve time to market?
• Are you struggling to attract and retain skilled staff?
• Are you trying to improve the quality of your product or services?
• Are these goals urgent or long-term?
• Do you have compliance requirements that need to be met when moving to the cloud?

These factors are critical for determining what your cloud migration strategy should look like.

Vendor Selection

For a relatively small organization with a homogenous set of workload requirements, a single-vendor cloud strategy might be most appropriate, as there is little need to invest in multiple cloud vendors for technical redundancy or to avoid vendor lock-in.

A much larger organization, such as a global bank with diverse workloads and varying levels of technical requirements, would be more likely to pursue a multi-cloud strategy, as that would give each project team the flexibility to choose the vendor that best fits their requirements. In addition, larger organizations are more likely to have internal and external compliance requirements to fulfill, and these may require the ability to move workloads between cloud vendors at relatively short notice.

A hybrid strategy, in which both a traditional data center and cloud vendor/s are involved, may also make sense for medium to large enterprises, especially if the transition to the cloud will span over a number of years. This strategy may also be relevant if there is a need to evolve your cloud migration tactics more dynamically as you learn more about implementation of cloud technologies within your business.

The Six R’s

Once you’ve determined your cloud migration goals and vendor strategy, the next step is deciding how to go about migrating your workloads to the cloud.

First, you’ll want to conduct an audit of your existing applications. This can give you an idea of the level and nature of work required to move to the cloud. During this audit, you can classify your applications based on the approach you want the teams responsible for them to take to with their cloud migration. AWS outlines six “common migration strategies. These can be applied across the board or each team can choose the strategy most suited to their particular set up at the time, depending on the size of the organization and the complexity involved.

1. Rehost

The first and simplest strategy is rehosting your applications (also known as “lift and shift”). It involves moving them from physical servers running in a data center to virtual servers running in the cloud. Generally, this requires no code changes and relatively few changes to processes and surrounding technologies such as networking. It may also enable your organization to develop the cloud skills and experience needed for other cloud-native practices.

2. Replatform

Also known as “lift, tinker and shift,” this approach is similar to rehosting, but takes it a step further by integrating a number of fundamental cloud services at the application level. For example, AWS IAM (Identity and Access Management) might be integrated into your application to replace or complement more traditional data center-oriented IAM systems.

3. Repurchase

Also known as “drop and shop,” this approach involves replacing an existing on-premises application with a licensed cloud-based service. This may involve changing the licensing model your business uses, lowering the cost of maintenance, and potentially allowing a quicker and easier path to upgrades.

4. Refactor/Rearchitect

A more cloud-native approach is to take your existing codebases and modify or extend them to work within more modern cloud services. One example is to containerize your application code, run configuration, and run them within a cloud-based Kubernetes service such as Amazon’s EKS or Azure’s AKS. This may involve substantial rewrites to your existing codebase to enable it to function and to increase scalability; a complete rewrite may even be required in order to use truly cloud-native tools (e.g., serverless tools like AWS Lambda or Azure Functions).

5. Retire

With the last two “passive” strategies, the workloads are not migrated to the cloud at all. Your workload audit may uncover systems that are either redundant or no longer worth maintaining. These applications can be retired.

6. Retain

The final “passive” strategy, retention, involves keeping your application running and choosing not to migrate it to the cloud for the foreseeable future. There a number of possible reasons to retain your application outside the cloud, including:

• Regulatory constraints on where applications can run or high internal compliance demands on security
• Mission-criticality of software that can make planning a move to cloud technologies earlier in the migration cycle too risky and uncertain
• No business case for the disruption caused by moving the application
• Legacy systems not supported in cloud environments

Where to Begin

In addition to deciding your overall strategy and classifying the tactical approach per workload, you will need a plan how to build your cloud infrastructure to support the movement of workloads. One approach is to let each team choose how to build its own systems in the cloud. There are, however, several disadvantages to this approach, as teams may duplicate anti-patterns of implementation and repeat each other’s mistakes or violate internal/external compliance rules.

An alternative approach is to create a type of centralized “center of excellence” or cloud infrastructure team. This team can choose to lay down the core systems on which other teams can run their workloads.

When it comes to establishing these guard rails, there are certain design elements that should be prioritized over others.

Accounts

The most basic unit of your cloud architecture is the cloud account. Using one account across your organization almost always fails to scale, as you end up bumping into account limits. It is therefore important to determine account boundaries. Will the account be used to represent a particular business unit, an individual team, or a grouping of software services? How will this operate with your finance department? Who should receive the bill? It’s important to figure this out early on, as costs can rack up quickly.

IAM

The next most basic unit of architecture is the identity and access management system. As your cloud infrastructure grows, you will need to consider the security implications of user access to the various cloud services and data, and the sooner the better. Imposing these rules retrospectively on systems that are already running can be complicated.

Networking

Migration to the cloud involves either the virtualization of your existing network or a complete redesign. The VPC (AWS) or VNet (Azure) service allows you to set up an isolated network to run a separate set of services within your account. Careful consideration needs to be given to internetwork communication between your organization’s services and basic network resources such as IP addresses.

Data Migration

While it’s easy to move compute services to the cloud, migrating data can be a little more challenging. Major data stores can be large, complex infrastructures that require careful planning to move. This requires a deep enough understanding of how to move your data to the cloud while conforming to your organization’s performance, compliance, and operability standards.

Conclusion

Once you are clear on your high-level cloud strategy, developing a successful cloud migration strategy requires meticulous planning and consideration of every aspect of your business. Choosing the right cloud vendor strategy for you—be it a straightforward single-vendor migration, a multi-cloud vendor approach, or a hybrid strategy—is the next step. Finally, you’ll want to architect your cloud migration by first considering the key infrastructural components before beginning to onboard applications.

I hope this blog post has been interesting and valuable.

Please look out for upcoming blog posts on containers/Kubernetes and serverless services.

If you’re starting your journey to the cloud, perhaps you’d like to read my new white paper about Five Best Practices for Secure Cloud Migration.

You can read more about Check Point’s cloud security solutions here or schedule a demo with one of Check Point’s cloud security engineers here.

To understand how to design and implement secure cloud architectures, check out this white paper.

Follow and join the conversations about Check Point and CloudGuard on Twitter, Facebook, LinkedIn and Instagram.