719 Cloud migration gets harder
Cloud migration gets harder

Cloud migration gets harder

❤ 188 , Category: Software,   ⚑

The chart below depicts the number of applications migrated over time in blue, and the degree of difficulty of moving those applications in orange. This is a fictional collection of applications; however, the concept that difficulty increases the more you migrate affects enterprises large and small as they move to the public cloud.  

See this chart: 

cloud migration difficulty IDG

What’s occurring is easy to explain, but the solution to the problem is not. 

Simply put, the applications and databases that are more modern, better designed, and built to be portable are the first to relocate to the clouds. This for good reason: The cloud teams want to get some wins on the scoreboard and can do so by removing risk and reducing the degree of difficulty. This is actually my advice as enterprises begin their journey.

Predictably, as the number of well-designed and modern applications that can be easily migrated decreases, migration teams are forced to face applications that are not as well designed or are built on older platforms that may not have an analog platform yet in a public cloud. Legacy applications come to mind, but also any application that needs significant refactoring to get it running correctly on a public cloud. 

As many of the enterprises approach the middle of the migration process, the degree of difficulty increases significantly, as shown in the chart, and it’s killing migration productivity. So, how does an enterprise that’s already freaked out about the vulnerabilities exposed in the pandemic get the remaining applications out of the enterprise data center?

See also  Swift language concurrency model proposed

Here are two approaches that seem to be working:

Leverage an MSP more often. Chances are, if you’re focused on a public cloud as a primary target for your workloads, you may now be considering some valid alternatives. MSPs offer more platform analogs for the more difficult-to-replicate platforms and provide an A-to-A migration path to move to a public cloud.

If you think that this is a cop-out, considering that you’re going to need to fix or modernize those applications and databases at some point, you’re right. But using an MSP will accelerate the downsizing of the existing physical data center faster. Once you’ve migrated to an MSP, you can focus on fixing or sunsetting applications on that quasi-cloud platform. From there, you can leave them or ultimately migrate them to a pubic cloud.

Create a devops toolchain and process to fix the applications and databases more productively. You’ll have to do the heavy lifting up front, but it’s really the right way to do things. In essence, it’s an application migration factory optimized using automation. Too many enterprises fix each application as a one-off. That won’t scale or be consistent.  

Of course, there are other approaches, including doing nothing and just fighting through it, degree of difficulty be dammed. I would encourage those enterprises to be a bit more open-minded to other solutions that may be difficult but ultimately remove problems moving forward. That’s a no brainer for me.          

Copyright © 2020 IDG Communications, Inc.

Leave a Reply

Your email address will not be published.

16 + 8 =