Surviving the Riskiest Part of Your Cloud-Native Migration

published2 months ago
3 min read

During any IT transformation project, the desired end goal is always the same: A more agile, scalable, supportable and cost-efficient application that better meets the needs of your customers. The journey through the transformation, however, is almost always a rocky one.

One of the trickiest transformations that many modern IT organizations are currently working on is cloud-native migration—moving an on-premises monolith application to a cloud-based, microservices-enabled, modern architecture application. The process of moving from an on-premises monolith to a modern cloud-native application is a key step that drives many current migration projects.

However, during the course of a cloud-native migration, there are moments when your application can reach a high degree of vulnerability—becoming vulnerable to failure and problems that impact your customers’ ability to get their jobs done. If you are not aware of when these vulnerable periods occur during the migration or why they are happening, these periods can easily become longer than necessary, increasing your vulnerability and the risk to your application.

This is why, when you’re deep in the middle of a cloud migration, it’s best to simply “get in there, get on with it and get it done.” All as quickly as possible.

To decrease the vulnerability of your cloud-native application and reduce the risk to your application at critical periods of the migration, be sure to do these three things:

1. Limit the Complexity of Your Data Migrations

The data migration process itself is the hardest, most dangerous and potentially most time-consuming part. During the migration, there is a tradeoff you need to make between the complexity of the process and the impact that complexity has on the migration. A more complex data migration may be recommended to reduce downtime, yet a more complex approach means a potentially longer process. This longer process translates to a greater overall risk of a problem that could cause an unintended failure.

Your decisions are dependent on an important question: Will you spend time optimizing your data for a cloud-native database or will you initially use a more traditional database post-migration? Your decision will impact how long the process takes and the overall risk to your application. Improve application performance now but at increased risk, or accept lower performance initially but manage a safer migration?

The more complex your strategy, the riskier your migration. Sometimes a simpler strategy may require some short-term compromises, but the result will be a substantially shorter migration and, therefore, a lower overall application risk.

2. Reduce the Duration of In-Progress Migrations

A corollary exists for the code migration as well. How much time and energy should you spend performing refactorings to make your application more performant and provide better long-term supportability? Is it better to make these changes during the migration, or are you better off migrating your existing application as-is and holding off on refactoring your apps until the migration is complete?

The more changes you make, the greater the chance of a migration-related failure. Instead, perform as many code refactorings as you can in advance; then save the rest for after the migration is complete. This will limit the amount of work you have to do during the migration, which will reduce your risks considerably.

Your application is most at risk for something going wrong as soon as the migration starts until the time when the entire application is moved to the cloud. Reduce the length of this perilous time period as much as possible.

3. Leave Yourself Backout Options

You will take many steps along the way from an on-premises monolith to a cloud-native modern application. At each step, failures are possible. The more options you have to be able to revert a failed step, the less risky your migration will be as a whole.

As you take each step, think before you execute the step: How can you back out of this step if something bad happens while executing it?

If you can undo a step should a problem occur, you automatically reduce your risk. However, any step that cannot be reverted means additional trouble should a problem occur. When you can’t revert a step, you have to fix the problem in place in real-time. In such a scenario, you will be working under pressure with limited options and your ability to quickly and easily resolve any issues will be reduced.

Get in, Get on With it, and Get it Done

The less time you spend conducting your actual migration, the safer the process will be. As you plan for your cloud-native migration, figure out everything that can be done beforehand or that can be left until after it’s complete. Get in there, get on with it and get yourself into the cloud.

This article, written by Lee, first appeared in Container Journal, Nov 2022

Software Architecture Insights with Lee Atchison

Lee Atchison is a software architect, author, public speaker, and recognized thought leader on cloud computing and application modernization. His most recent book, Architecting for Scale, 2nd Edition (O’Reilly Media), is an essential resource for technical teams looking to maintain high availability and manage risk in their cloud environments. Lee has been widely quoted in multiple technology publications, including InfoWorld, Diginomica, IT Brief, Programmable Web, CIO Review, and DZone, and has been a featured speaker at events across the globe.

Read more from Software Architecture Insights with Lee Atchison