Cloud Migration – Where to start?

Pandemic uncertainty has forced most organisations to chart a course to the public cloud at full speed to gain the flexibility they need. Having said that, your applications should be your top priority when moving to the cloud. Where do you start? That is the challenge many face. What will you migrate to? Based on what criteria will you make your decision? What cloud services will you use? 

Migration strategies will be the focus of this post. The post will cover three key areas in migration strategies:

• Overview of the seven common migration strategies (7 Rs)
• Key criteria for workload assessment
• The Up & Out assessment model

Let’s get to it!

The 7 Rs

The 7 Rs is a common cloud migration strategy that refers to Rehost, Replatform, Rearchitect, Rebuild, Replace, Retain and Retire migration options. This methodology is used by AWS, Microsoft, Gartner, and others. However, I have seen other methodologies with as many as 8 Rs and as few as 4 Rs. Some organizations like to break down alternatives further while others like to merge alternatives. For example, “Remediate” is often the 8th “R” alternative added to the common 7 Rs.

5 + 2

The 7 Rs can be broken down into two groups: Five migration strategies that will migrate applications to public cloud services and the remaining two alternatives that will either stay on-premise or be retired.

Retain

Some applications are not suited for the public cloud and are better off retained on-premise.

What might drive you to this alternative:

• Latency-sensitive applications.
• Applications with high availability requirements (e.g. 99.999%) that cannot be satisfied in the public cloud.
• Applications that have hardware or operating system dependency that is not supported in the cloud.

It is ok to say no to applications that are not well suited for cloud migration.

Retire

This one is not a migration strategy but rather phasing out an application.

What might drive you towards this alternative?

• The application is no longer in use.
• There is a superior alternative in the application portfolio.
• The application requires an unsupported operating system or legacy hardware that is expensive to support.
• Application has a legacy coding that is difficult to find developers with that skillset.

Replace

Here you replace your on-premise application with a SaaS alternative. For example, replacing Microsoft exchange server on-premise with cloud-based O365.

Rehost

In this option, you “lift & shift” or as some call it “Copy & Paste” the application is migrated as-is from its current physical or virtual server environment onto a virtual server running on a public cloud with no code changes. An example is migrating a SQL database server to SQL virtual machine running on AWS or Azure as IaaS.

What might drive you to choose this alternative?

• On-premise data centre will be shut down and applications need to be migrated quickly to the public cloud.
• The application can only be run as a virtual machine.
• For regulatory or compliance reasons, no code change is allowed to the application.

This alternative offers the quickest cloud migration path. However, you are sacrificing cloud-native benefits for speed.

This option is well suited for organisations that need to exit their on-premise data centre quickly and business value is not an immediate consideration.

Replatform

Often referred to as “Lift, Optimise and Shift” or as some call it “Repackaging”, this alternative makes limited configurations to the application to point it to different cloud-native services. This is done before migration without changing the source code.

An example is replacing a SQL virtual machine with Azure or AWS Database as a Service (DBaaS) offering. The advantage of this alternative is the use of cloud-native services without having to change the code. This improves operational efficiency and often results in better pricing.

What might drive you towards this alternative?

• The application can easily be reconfigured.
• Replatforming will result in cost efficiencies and/or performance improvements.
• Planning to elevate the application to containers through reconfiguration.

This is the most common migration path as it gives organisations a system improvement without the time, cost, and risks associated with rearchitecting or rebuilding an application.

Rearchitect

In this alternative, the application architecture and code are heavily modified to take advantage of cloud-native services but features and functionality are kept the same. This strategy is considerably more complex, expensive, and requires a higher level of expertise. This alternative also offers true modernisation.

What might drive you towards this alternative?

• The application needs recoding to work with other applications in the cloud.
• There is a drive to adopt PaaS services to drive costs down.

This is best suited for organisations that seek application modernisation and are ready to move up the stack from IaaS to PaaS services.

Rebuild

This is a more drastic version of rearchitect. If rearchitect is home remodeling, then the Rebuild alternative is the complete teardown and rebuild of the home from the grounds up! An example would be to move applications from IaaS to serverless architecture. The application having a new code will allow developers to take advantage of advanced cloud-native services such as AI, analytics, self-healing, automation, to provide additional features and functionality. Although this alternative is the most complex, riskiest and costliest migration path, it also offers the best business value.

What might drive you to choose this alternative?

• The application needs new features and functionality to keep up with the competition.
• Business requirements to utilise advanced cloud services such as AI, Analytics, IoT, BlockChain, etc.
• Strategy to utilise DevOps capabilities to develop the application.

This is best suited for organisations that are looking to push the boundaries of cloud technologies to gain a competitive advantage.

Business vs Technology Lens

How do you assess each application to determine which migration strategy is the best fit? How do you priorities which ones to migrate first? The application assessment needs to evaluate applications from two different lenses: Technical and Business. I often see an emphasis on the technical part but the business lens is overlooked. The explanation: most of the assessments are driven by IT which is mostly staffed by .. smart yet technical people!

Business Lens (top Down)

We will breakdown the business assessment into five key areas:

• Business Benefits
• Financial
• Security & Compliance
• People & Processes
• Performance Requirements

There are many factors to consider, too many for a blog post. The following are only a few examples of points to consider:

Business Benefits

It is important to understand the business value metrics. Does the application contribute to sales? If yes, by how much? It is important to identify metrics to use to score each application to use when other metrics are equal. For example, an application with the highest revenue-generating, most customers served, etc. will take higher priority in migration.

Financial

An area to consider in financial is the Return on Investment (ROI) and Total Cost of Ownership of application considered for cloud migration. How much will it cost to migrate to the cloud? How much to run? What quantifiable business benefits will you gain to justify the cost?

Security & Compliance

You need to consider application-specific security or regulatory requirements. For example, in the EU, financial services need to develop a cloud exit plan for important applications. Do you have the resources and expertise to do that? If the answer is no, then these applications should not be a top priority in your cloud migration.

People & Processes

Often organisations have applications with outdated technologies on-premise. However, as they migrate to the cloud, the use of new technologies requires a new Skillset. Does your organization have skills in-house to migrate and operate these applications in the cloud? If the answer is no, then these applications might not be a top candidate for cloud migration.

Application Requirements

You need to understand application requirements to assess the complexity. Example of questions to ask:

• What is the data classification (Public/Confidential/Restricted/Secret)?
• What are the application’s data encryption requirements (in transit, in use, at rest)?
• Will the application require Dev, Test, and Production?
• What are the availability requirements (99%, 99.9%, 99.99%)?

Technology Lens (Bottom Up)

We will breakdown the technology assessment into five key areas:

• Application Architecture
• Application Fundamentals
• Performance Requirements
• Networking
• Dependences

Application Architecture

There are many architectural considerations when assessing an application for cloud migration. Let’s consider a few questions:

• Is the application stateful or stateless?
• Does it scale up or out?
• Does it have a single point of failure in the design?

Application Fundamentals

There are a few application fundamentals that need to be assessed. Fundamentals such as:

• What is the required operating system? Is it supported in the cloud?
• What type of license does the application have? Is it transferable to the cloud?
• Will vendors support applications in the cloud?

 Performance Requirements

You need to understand performance metrics. Metrics such as:

• Storage I/O requirements
• Storage capacity requirements
• CPU/RAM requirements
• Database I/O requirements

 Network

You need to understand the application network requirements. Some of the key areas to assess:

• Application latency tolerance?
• Bandwidth requirement?
• Multicasting requirement?

 Dependencies

It is important to understand application dependencies and how moving an application to the cloud will impact interdependent systems. What will the application require once it moves to the new environment? This could be a database, a middleware, firewall rules, security policies, etc. As you build the dependencies tree for each application, it will be easier to identify which applications should be migrated first. Lack of dependencies understanding can wreck a cloud migration. 

Application dependency mapping is a complex exercise. The good news is, there are many tools today that simplify that process.

Up and Out

The 7 Rs method is a great proven approach for assessing your application’s cloud migration alternatives.

We place each application in a shoebox and we label it as rehost, replatform, etc, then it gets shelved and job done.

However, there is one issue with that approach ..

It is too simplistic!

It treats cloud migration as a one-stop bus ride when in reality cloud migration is a journey with multiple stops and destinations.

There is a cloud migration assessment model that represents cloud migration on 2 axis, Up and Out.

Moving Up

The vertical axis represents the application modernisation by moving up the technology stack. The vertical axis is represented by the 5 cloud migration alternatives. Alternatively, the vertical axis could be represented by virtual machines, containers, and serverless architecture. Often an application will move up the stack during its life cycle. An organisation might choose to rehost or replatform initially due to time constraints and later on rearchitect the application to a container-based architecture.

Moving Out

Moving out means migrating the application from on-premise to somewhere else. I intentionally choose not to say cloud as there are other alternatives that you might want to consider. Alternatives such as Co-Location and Hosting in addition to the public cloud.

For example, an organisation might be pressed for time to move out of its on-premise data centre and migrating everything to the cloud is not a realistic goal. So what are the alternatives?

One alternative, an organisation I have worked with used, was to move to a colocation facility. This allowed the client to reap many of the benefits of the cloud. It was a close entry point to the target cloud; it offered maximum throughput and the lowest latency. It served as a staging area, enabling the organisation to migrate at its own pace to the cloud.

The Up and Out axis are often used together. For example, you might decide to lift and shift an application to the cloud due to time constraints, then replatform it (lift, optimise and shift) after migration. Once the application has been running in the cloud and the organisation developed the skills, rearchitecting is the next step on the application roadmap.

Using the Up and Out model helps remind the business that migration is not a one-stop bus ride but rather a journey.

I hope you have found the post informative and thank you for reading and stay safe.

Regards,

Nick