TWA, as an analogy for Cloud Migrations?

I had the good fortune to have lunch at the TWA Hotel at JFK Airport earlier in the week, which got me thinking about what happened to TWA and why there was still a branded hotel. I didn’t get an answer to the latter, and several reasons were provided for TWA’s eventual demise. Still, one theme (outside of corporate mismanagement and a serious accident, amongst others) was consistent in that there appears to have been a lack of investment or focus on the domestic US market, which was undergoing a period of rapid change, allowing its competitors to grow domestically and then to challenge them on the international routes they had initially been focused on, increasing competition, lowering margins etc. This, coupled with the other issues, eventually led to their acquisition by American Airlines.

This may be a stretch for an analogy. Still, after focusing on the recent trend in Cloud Repatriation (https://www.linkedin.com/pulse/cloud-repatriation-valid-option-richard-hogan-wo5ee/?trackingId=RBSM4l1DS5muNyiYUVJf3w%3D%3D) in my last article, I think I can draw a rough parallel between TWA and the success or failure of cloud migrations.

One of the drawbacks of the rush to the cloud is that it is rare for organisations to take the opportunity to look at how to modernise not only the applications but also the operating model and longer-term IT strategy.

For this analogy, I will assume that the cloud is the prestigious international routes and the applications and operational aspects related to the domestic routes (see, I said this was a bit of a stretch). As noted in my previous article, I have noticed a distinct trend in cloud migrations, which is to migrate workloads as quickly and efficiently as possible, often meaning that applications are migrated instead of transformed.

Unfortunately, one of the side effects of this approach is that the organisation’s technical debt is moved from one location to the other while simultaneously adding additional issues relating to cloud management, which apply to applications not designed for cloud hosting, including unexpected costs and complexity. Often, this is a deliberate choice, with the strategic goal of modernising the applications once out of the data centre and into the cloud, whether this step is completed or not is a different story.

Technical debt is not always an issue if the organisation is aware of the debt and keeps a log of all items, including plans (and allocated budget) to resolve or mitigate the risk associated with the identified Technical Debt (amongst other actions). These actions will help organisations manage their technical debt appropriately, but going back to my analogy, the more prestigious projects tend to get the budget and the go-ahead, see the rise of adoption of Generative AI projects in the enterprise as an example of investing in new technology, with the potential risk of ignoring the known technical debt, the i”f it isn’t broke, then don’t fix it” approach.

While this approach will not directly cause a company to fail, it may lead to avoidable but expensive re-adjustments of the organisation’s IT strategy, such as relocating workloads from the cloud to on-premises.

If this article has morals or advice, it would be wise not to ignore the technical debt accrued when performing a re-host or lift and shift migration to the cloud. Yes, the transformation of legacy applications can be expensive, time-consuming and complex, but neglecting these applications, which are quite often the core systems that organisations rely on for their day-to-day business, or in other words, don’t focus on the prestigious international routes, without having a plan, (and more importantly actioning it) to manage the less glamorous, but, perhaps, more critical domestic business.

Follow on LinkedIn