Legacy Software Revelations

A long time ago, I posed a question on Twitter on what it means for software to be considered legacy. Since then, I’ve been correlating the few responses with my experience helping others with their migrations, prior client interviews, and the numerous articles I’ve seen ranging from Gartner to the smaller consultancies. There are other companies such as MuleSoft ESB or RedHat’s Migration Toolkit that make it a point to create interfaces to automate some of the migrations. Perhaps that was the wrong question. While old languages and other forms of technical debt over the years can result in something very smelly, they have not been considered high priority. At least not until the licensing and support costs get excessive (think at least $1.5m/year for a runtime license), or you are no longer able to upgrade to a supported version required to stay compliant.

Does your old COBOL or LISP application really need to be rewritten to Java or Python to be considered cloud-native if it still serves your business? I’m willing to bet it doesn’t as there is a lot more to it than just a lift and shift to a new platform. Instead, being able to merge it with today’s technology and practices will allow the business to continue to move forward leveraging their current investment while continuing to invest in the future.

Are you stuck going from fire to fire without making the progress you really want? Do you need help with your legacy system, but don’t have the people or expertise in your team to look at this kind of migration? Am I totally off base with this? Then reach out, and let me know.