The amount of legacy code and legacy systems out there in production is clearly very substantial. But it seems that the very concept of legacy is at times unclear and subjective. Where one company is actively investing in development of new software in a particular environment, another is investing to modernize away from it. Ideally we would be able to continuously update and upgrade our existing code as technology evolves and new platforms are introduced.

A few years ago, we discovered that Eqela technologies had a very useful and important application in projects involving modernization of older software systems, often labelled "legacy systems". As a result, we have spent a lot of time over the past few years helping large companies and government organizations in the planning and execution of the modernization of their legacy IT systems, essentially converting very large amounts of code from old platforms and technologies like FoxPro, Visual Basic and RPG to more current platforms like C#, Java or JavaScript.

We ended up meeting with a lot of clients and potential clients. Clearly the pain brought by legacy systems is very much real, and the requirement for modernization and upgrade is really there, for various reasons. The amount of legacy code and legacy systems out there in production is clearly very substantial. But the amount of technologies involved is also substantial. From the more "obvious" technologies like eg. FoxPro, RPG or COBOL that are very clearly "old", we started to also get inquiries for modernization from "newer legacy platforms", such as PHP, older versions of Java and C# and Python. While the Eqela Transcend service was always clearly intended and targeted as a service for legacy modernization in particular, over time it started to be less clear to us what exactly the word "legacy" really means. Where one company is actively investing money and resources to development of new software in a particular environment, another is investing to modernize away from it.

And the more we have looked around and observed how software is being developed within the companies that we have come to contact with, the more it has seemed typical that on a daily basis, developers are developing on platforms that are not considered up to date by the company, and usually they know it very well. So when modernization discussions take place, these are of course the legacy platforms that will be discussed. In other words, brand new legacy software is being developed on a daily basis. So clearly the exact meaning of what is legacy and what is not is very subjective, and depends greatly on one's perspective. But whatever that perspective may be, there is an inherent, constant need for software teams to stay up to date and to evolve and improve their systems. Sometimes that involves more dramatic shifts like moving from RPG to Java or Visual Basic 6 to JavaScript. But sometimes the transformations are more subtle, like moving from Java 6 to Java 7, or from .NET WebForms to MVC. Or perhaps from Backbone.js to React. Various combinations exist. But those technology movements, and the pressure they put on software engineering teams, are very real.

But legacy is also not necessarily always as old as we may think, largely because the speed at which the overall industry moves is sometimes breathtaking. This month's cool new gadget is next month's legacy platform. And this is clearly visible in the technology roster of actual projects, especially in companies that are continuously starting new projects. Each project easily ends up being developed with a different technology platform as compared to the previous one, following whatever is current at the time of starting the project, ultimately resulting in a confusing mish-mash of different technologies, many of them ending up obsolete and unsupported. Indeed, one of the many reasons why we are having so many security issues in this world right now is precisely because those systems fall into the "unsupported legacy" category sometimes even before they are completed, and never even get a chance at being secure, properly maintained or updated.

Ideally, we would be able to continuously update and upgrade existing code in such a way that when the new technologies arrive, we would not need to redevelop from scratch nor would we need to accept that "it is what it is and let's just hope it keeps running", but could more easily take what we have and upgrade it. But obviously, given that it seems that the technology landscape moves faster than the developers in development projects, this is highly challenging. With the currently popular model where companies desperately scramble to find legions of developers to do this manually and with hard labour, clearly we don't have any reasonable hope of success. At present, a massive amount of money is being spent in development and redevelopment, poor code is being written, and the end result is just more legacy.

We at Eqela believe that automation is a key towards solving this problem. Many of the technical action points to perform in these technology upgrades are prime candidates for automation. One of the usual prime examples of an automated solution like this is of course the Eqela Transcend translation engine, which can take software source code written in one programming language, then rewriting it into a new version of the same software in another language. Aside from being amazing, this absolutely helps, and tremendously accelerates these projects. In addition to that though, we are also very aware that this does not magically solve all problems, and the actual process of modernization goes much further than just translating the source code from one language to another. Often, logic needs to be changed. Processes altered. User interface improved. Developers retrained. And many other things. All of which can also benefit from automation. The way it seems is that the exact process is individually unique to each customer organization, but the overall approach is not, and the applicable automation solutions in each case can be based on a common set of core principles and technologies.

We currently have many of those processes and technologies in place, proven and tested, with solid learnings and experiences resulting from several years of real world projects. We also have many more new ideas, and a lot more work to do to improve things even more. To be truly successful though, and to truly make a difference, we also need to continue to cooperate and collaborate with others. As such, we would want to also continue to explore common experiences and to form new partnerships with forward-looking companies and individuals that would hopefully also even stand to benefit from a more effective way to continuously upgrade their technology platforms. If that's you, I hope we will be able to connect. We have a lot of work to do and a lot of "legacy" systems and technologies to address.