lift and shift – Cloud Stubborn

Most of us have heard about the crisis Southwest Airlines had over the Holidays. Most articles cite “problems related to legacy systems…” and “outdated scheduling software called SkySolver.” And, of course, there will be a huge financial impact as they try to make everything right with their customer base.

Most likely, the CEO, CFO, COO, CIO, and CTO of Southwest are receiving many calls and emails from vendors offering to “Let us fix it. We will convert everything to be cloud native…” This path sounds like the old saying, “No one ever got fired for buying IBM…” Southwest has a stated multi-cloud strategy, but legacy applications like SkySolver were obviously not priority cloud-native candidates. Though there will be pressure from investors, the industry, and the press to convert legacy applications like SkySolver to cloud-native, I would not initially recommend this approach.

Continue reading →

If you have legacy applications and are moving to the cloud, one popular pattern is to do a simple “Lift and Shift.” That means you don’t architecturally change the application but simply move it to your cloud of choice and run it just like you did before. This approach lets you more quickly “get out of the data center” and doesn’t initially imply that you have to refactor any part of the application to use native services provided by your cloud vendor.

In fact, if the application is stable but just legacy, your valid strategy might be to let it run forever in an “as-is” state. Nothing changes. Just get it running in the cloud and out of the data center.

This approach’s major downside is that Lift-and-Shift also carries forward all the Technical Debt accumulated for that application.

Continue reading →