Author: Stephen Sadowski, Vice President of Service Delivery

Introduction

One of the most interesting and challenging things Uturn does is to assist clients with modernizing their applications for utilization on AWS. While Uturn does not traditionally provide code support, it is absolutely necessary for us to be evaluate the readiness of an application and recommend a modernization and migration path.

Sometimes this is very straightforward, but other times, especially with neglected legacy applications, the challenge for taking this path is immense. Let’s take a look at some of the problems that need to get addressed along the way.

Background

To frame the conversation, in my opinion Legacy Applications are a form of technical debt. As any person that deals with finance and accounting will likely tell you, there’s good debt and bad debt. It is up to the debt owner and experts to categorize the Legacy Application, but the assumption for purposes of this article is that it is good debt – it provides value exceeding its cost. It does, however, have a cost that can’t be avoided, which would be why it is being modernized as opposed to replaced.

Before recommending any path of modernization for a client’s application, I actually have a very small 3 item checklist that needs to be completed:

1. The client has (or has access to) developers intimately familiar with the code.
2. The code has been reviewed, updated, or changed recently.
3. The code is modern enough to be run or compiled with a current interpreter or compiler.

The checklist itself may be mundane, but legacy applications suffer from neglect and bit rot, and that can be an impediment to successfully completing a containerization or modernization project. It’s also important to note that even if every answer to the list is ‘no’ it is still possible to modernize an application, though it will very likely take a larger investment from both a time and money perspective. Below I will dig into each checklist item individually and expand on the value and importance of each.

Evaluation

As each of the checklist items is important, I’ll tackle them in order.

First, there need to be available developers who are intimately familiar with the code. Maintaining any application can be a tough task, but maintaining an older application can be a massive effort. Older code, older language sets, specific institutional decisions, and organizational capabilities all have an impact on a developer’s ability to work within the scope of the application as it was written.

Setting aside the fact that the application would be changing to suit the needs of a modern environment, the lack of anyone that has strong and deep working knowledge of the software architecture and how its functionality was implemented is absolutely necessary in order to affect the changes required to building a new version for a completely new target platform, even leaving out the fact that the system requirements may be different or even that the CPU architecture could be different, such as in the case of moving from x86 to ARM.

Second, the code has been reviewed, updated, or changed recently. Building on the first element of the trifecta, the question becomes that of maintenance. If there are developers that have solid working knowledge of the application, are those developers creating and releasing patches, hotfixes or even new features? If the answer is yes, a checkmark goes into this box.

The reason behind this question is really rather simple: are there people that can do the work, not just understand the work that may need to be done – which is the reason for the first question. These people may need to step up and actually lead new teams to complete the modernization effort, so being able to transfer knowledge about how change is implemented in the application is critical to success.

Third, the code is modern enough to be run or compiled with a current interpreter or compiler. This element isn’t as important as it could be part of the modernization effort, but if this item is already done it shortens the length of time that may be required.

In many ways this is easier for compiled applications, especially for compilers that have compatibility modes that allow you to take advantage of the modern compiler while still using code written at an earlier time – though this may not always be true. For interpreters, this could be a much more massive undertaking because of breaking changes in the interpreters themselves. Examples of this might be going from Python 2 to Python 3 or PHP 3 to PHP 8.

These are, of course, doable – they just require more effort than something that has already been updated, and that effort needs to be accounted for.

Conclusion

The critically important element throughout this list be completely honest with yourself about the status of the items above. As stated previously, saying no to any or all of these items does not eliminate the ability to modernize an application, however it does change the impact and increase the probable investment in terms of time, labor, and direct cost.

If you have questions about modernizing your application for cloud migrations, reach out to me or any of the Uturn team at info@uturndata.com.