How to deal with a legacy system?

Integrio CTO talks about challenges and solutions of legacy software modernization

Complications caused by legacy systems often cause "snowball effect": as the skill sets required to support them become exotic and applications with outdated code become incompatible with modern UI/UX and infrastructure requirements, their maintenance becomes a burden for organizations in terms of costs and time spent for maintenance. Today Alex Ptashniy, Chief Technology Officer at Integrio Systems shares some valuable insights into his experience in projects related to legacy systems modernization.

Hi Alex! Let's clarify the definition first - what do we call a legacy system

Howdie! Any IT system that runs with outdated code, framework or library can be called a legacy system. This includes any languages that are no longer being updated with new versions or older versions of languages that are still popular.

Companies still use systems built with older programming languages and frameworks and they actually work fine in many cases - so what reasons might be there to consider updating a legacy system?

As application components become no longer supported and updated, compatibility issues arise. Say you want to optimize your IT infrastructure cost and migrate to AWS cloud - for some legacy systems it can be just not possible without rewriting them onto modern stacks. "Old" applications often struggle to run smoothly on newer version of operating systems; in other typical cases there is a need to make applications mobile friendly, develop new features and functionality, create additional user portals, etc. - finding and hiring developers who are who have the skills and knowledge needed becomes harder and more expensive in the course of time. Applications made with modern stacks are more stable, secure, they are faster, capable of processing larger sets of data and way more flexible in terms of updating them - which is why any company would rather prefer to have an application built with modern technology stack to meet its business goals. Frequently the obstacle on the way of obtaining a security compliance e.g. PCI lies somewhere in legacy components. Incorporating innovative technologies like AI into an organization can be extremely challenging especially for large enterprises lumbered with legacy systems. Businesswise, older systems are less attractive to their customers when options made with newer technologies exist.

So considering all the disadvantages mentioned, it makes sense to assume that the only good choice is to build a new application from scratch.

Absolutely not! Well, of course if we look at the problem superficially, developing a new application seems to be an easier and faster way - however, should we dive deeper, we may find out that since many legacy platforms were being continuously developed for years, it might take a good while to create software with absolutely similar functionality. The other risk contained here is that while we focus on developing a brand new application, updating and supporting the old one becomes even more challenging making future migration into new system even more complicated.

So are there any other good options?

In our practice we often suggest customers modernizing their legacy systems when it is possible. It means updating the existing components and rewriting the legacy code into modern stack while keeping the existing logic and functionality of the application.

The conclusion is that there is no one-size-fits-all approach. How to make it right when it comes to modernizing a legacy system?

Well, first of all we should understand that it is a hard strategic choice and the first step any company should make is answering one simple question - "Why do we need to update the system?". The requirements for the future system must be developed based on the reasons and goals to be achieved with the update. In some cases it is acceptable to completely abandon old application and built a new one from scratch - this solution is often applied when the project scope is small enough to concentrate resources on developing a new application without harming the existing system. But in most cases companies prefer to keep their old applications and update them with new components to ensure that the entire functionality works well for all the users at every stage of the project.

Say I am a SaaS business owner or I have an enterprise system that was developed a couple of decades ago and I want to utilize the "keeping things steady" approach - I've already set the goals and developed a clear understanding why I need it. What are the next steps for me from here?

After business vision was built, technical side jumps in. Careful analysis of the existing application should be held. What components of the system must be updated? Which legacy components can co-exist with the new ones? After all the questions regarding low-level design of the new application have been answered, the important choice is architecture. Do we run the new system with a new database or use same database for the old version and the new one? Is there any data to be exchanged between the old application and the new one? After all these aspects were planned well, the development process can begin.

Analysing and planning such projects seems to be a great deal of work - how does it work in the context of client-vendor relationship?

As I mentioned before, for a client it is a matter of clear understanding your own system and the update requirements. The more preparation will be held by client the sooner success will be achieved. Vendor's work is all about experience and meticulous analysis of the existing system structure and functionality - while working on such a project vendor must never hesitate to ask questions in order to always stay on the same page with client. Sometimes it is hard to understand what solutions are there behind certain parts of the system but simply deleting them may damage the application and cause significant loss of functionality. It is extremely important to do any work of this cooperative manner. The experience is also related to the skills and capacities to work with legacy components many of which are exotic today. The ability to read, understand and refactor legacy code to refactor it ensuring that application works in the way it is expected to is also very essential.

With all the preparation work and careful analysis held by client company and vendor chosen, how to estimate the time it will take to implement such a project?

Based on the experience I had with Integrio Systems I can say that anything regarding such projects is very individual. As I mentioned before, legacy systems are harder to maintain in the course of time - which often results in their code becoming a mess. One example from Integrio Systems practice: we had a project where we had to recover source code as some parts of it were lost and in the very beginning it was not possible to estimate how much time it would take to understand how the system was built.

Why did they have this problem?

In this interview we already agreed upon the fact that modernizing a legacy system takes exceptionally meticulous approach. The company owning the product changed several vendors working on this application for fifteen years and they made an executive decision to actually modernize it only by the time they got in touch with us - so given the product was really large in terms of volume of data being processed, infrastructure, functionality and different vendors worked on it at different times with the vision of adding new functions without putting the entire system to order it was really confusing.

So did they have a strategic vision of what exactly they wanted to achieve with this innovation?

Apart from chaos in the code which caused really severe complications whenever they wanted to add a new feature, that case was rather a typical one: they needed to adapt their product to modern UI/UX trends, make it convenient for mobile users and move the entire application to a cloud - that was just not possible without modernizing legacy components.

Did they achieve the goals eventually?

Absolutely! Analyzing their situation was a challenge for us, however with our experience we managed to build the right solution for them. It took us some time to take a close look at all the code they had and understand how everything worked - also took a great deal of cooperative work with the client. In the end they had a faster, more secure application which provided its users with a "fresh" experience resulting in optimizing costs of maintaining the application and getting a bigger slice of the pie - new look allowed attract more users resulting in getting a bigger share in the market.

These are great insights, Alex! So in the end, can you briefly tell us: what criteria should companies follow when choosing a vendor for modernizing their legacy systems?

I believe there are two really crucial criteria: one is that vendors should not just be able to rewrite lines of old code into modern stack but have a capacity to deliver a comprehensive solution. It includes understanding business vision and strategic goals of the customer, being able to hold audit of the entire code and being able to simply tie all the loose ends which involves robust knowledge of the technologies involved in the project and ability to connect them to the business vision. The second one is meticulous approach, meticulous approach and, once again, meticulous approach. If you feel like your vendor wants to start working when still being at the surface in terms of understanding your system you should expect things not to work out as a good vendor is supposed to understand the importance of preserving all the parts of systems logic and functionality - which is not possible to ensure if things are not handled with care on such projects.

Thanks again, Alex! Many things are clear for us now.

Thank you, Eugene Makieiev. I'm always happy to discuss my experience.

Legacy systems remain to be a burden for many companies all around the world. However, today we found out that abandoning the old and building a new is not the only option and not even a good option sometimes. Want to know more about how we help companies innovate in Integrio Systems? Drop us a line at info@integrio.net - we are always happy to get in touch and consult you regarding your project.