The best cloud migration strategy? It’s not lift and shift

Reading Time: 4 minutes

When migrating applications to the cloud, whether public or private, you have six major methods at your disposal:

• Retire
• Retain
• Re-host
• Re-platform
• Repurchase
• Refactor

The implementation strategy you choose for each application will determine your success or failure.

Unfortunately, a lot of organizations get it wrong. Many opt for re-hosting, also known as “lift and shift,” or re-platforming – lift, tinker, and shift. Those might at first seem like quick ways to get started in the cloud, until you have a conversation about the real costs of these methods.

When you do, it quickly becomes clear that the best way to go is refactoring. Here’s why and how you can get started.

What is refactoring, and why is it the best cloud migration strategy?

Refactoring is re-imagining how the application is architected and developed, using cloud-native features. It can improve the speed of access, the speed of deployment of new processes and features, and the ability to reduce manual intervention. Refactoring allows you to set up continuous integration/continuous delivery (CI/CD) toolchains and your pipelines.

Refactoring takes more planning and time, but the advantages are clear:

• Better resource consumption: By refactoring code, you can realize the value of a resource consumption model. Applications can release resources and scale according to the load at any given time. Your business can focus on optimizing cost per transaction, not the mechanics of infrastructure.
• Better speed to market: You can react faster with new confidence in the process to provide the guardrails required to deliver value. The need for resources dwindles thanks to automation, and instead of rolling out new product features every month, you could do so every three days.
• Reduced technical debt: Refactoring revisits old design choices and forces clean, modern code practices. Removal of technical debt allows for greater code reuse, cost effective use of resources, and greater visibility on value for the end user. Even if you had a smart design when the application was built, new capabilities are likely available now that weren’t then – refactoring allows you to keep up with those advances.

The downside to refactoring – and the issue that usually causes companies to hesitate – is that it takes a little longer; it might take a few extra months to get up and running. However, once you establish that pipeline and that manufacturing process, that changes everything.

For instance, you can have an endpoint that’s a database. That means no more worrying about backups, no more worrying about failover. You have data automatically shared across the planet, and if you need to fail over, it happens in seconds.

If you choose another migration method, you could lose those efficiencies. If you use the retain method, for example, and have a single app on an Amazon EC2 instance, the best you can do is one-to-one. At best, you might be able to run on a smaller EC2 instance. But you still can’t do multi-tenant because you don’t know what’s in the app. You can’t break it up into API services to achieve economies of scale.

Refactoring allows you to have a single service utilized by all applications and avoid the avalanche of issues and costs that come with keeping applications standalone and distinct.

The power of the pipeline strategy

Before you start refactoring the code, you should first ensure you have a proper pipeline in place. Think about it like this: The pipeline is the actual assembly line, and refactoring is what the pipeline does.

Pipeline migrations have big advantages. They give you an opportunity to standardize your DevOps and DevSecOps, and build rules into your code for policy and governance. You can educate staff on proper application development and delivery. You can reduce labor and resource costs while adding scalable automation. Security is no longer an external operation, and migration becomes a part of your CI/CD pipeline.

This makes everything that much easier, especially if one day you decide to switch cloud platforms. If you’ve already refactored the code and built your pipeline correctly, all you have to do is point to a new location and you’re good to go.

The importance of a receptive culture

Refactoring is not a simple solution. It takes time and patience. And it can’t be done if your company isn’t willing to buy into the process.

People tend to be creatures of comfort. There could be some pushback if you decide to go the refactoring route. The key is to create a culture that’s up for – and embraces – the challenge.

Make sure you reward those who do things the right way. Provide incentives for employees to go on this journey with you.

You need management buy-in, you need to constantly check – maybe every two weeks – your pipeline to ensure that all the steps are being followed or adding new ones that you may have missed, and you need company-wide understanding that, while things might run a little slower in the beginning, in the end, refactoring makes it all worth it.

If you’re looking to migrate to the cloud and want to learn more about refactoring, contact your SHI account executive today.