Legacy systems should be seen as a software that has already become obsolete or was running for so long, that the people who created it are either retired or moved on to another company without leaving any documentation behind. There’s already a joke running around that some of those senior developers are the documentation, which is funny as long as you have them around to work on the legacy systems. For new workers it’s a lot of additional work, trying to understand how and why something has been done and how to merge it with new ideas. 

What has to be understood is that legacy systems are not just mildly annoying to your workers – they tend to be so inflexible that they ruin your customers’ experience and that’s something that might become a deal breaker. At some point they will have to be exchanged, because no matter how used to it everyone is, the technology might stop being supported and the main functionality will be lost. 

Does it mean it can be just thrown away to make some space for new implementations? No. And if you try to take this route it might not go well. 

They were once good 

I’m assuming that your legacy system wasn’t a disaster many years ago when it was first introduced. In most cases it was a software designed specifically for your business or at least it kept being adjusted to your business. People who worked on that for years made sure that core functionalities were working just fine, because if they weren’t your business would be gone. 

Just because you want to refresh your software or introduce some new solutions, doesn’t mean your legacy system was a horrible thing from day one. Even if at some point it became a multi-layered monster with no documentation to work on, there might have been some functionalities that cannot be omitted if you don’t want your product to collapse. 

Having a nice and clean, well-tested and easy-to-deploy code is a beautiful dream, but the mess that’s your legacy system is a mess for a reason. It’s important to understand the system in order to avoid any surprises when some of the essential features will not work and no one will be able to figure out why.

Layers and frequent deployments are important

When dealing with a legacy system keep in mind that you are not making a new system that will be doing exactly the same thing as the old one. The whole point of replacing a legacy system is to create a better software that is doing the same thing but better – dealing with more data, being more user-friendly etc. 

Trying to deploy the new system all at once is simply risky and if mistakes are found it might be necessary to dig in all functionalities at the same time. Therefore it’s better to begin with the core features and then implement new ones over time. The whole process of testing and teaching people how to use the new thing will be longer, but the risk will be greatly decreased. 

And it’s insanely important when talking about security issues. 

Don’t annoy your customer

Don’t test your customers. When implementing new systems make sure they work on different types of hardware, accept feedback and observe whether the changes are liked by people who will be using it. 

If your page suddenly loads much longer or looks funny on some kind of equipment, you have to fix it. Inform your clients that there will be some changes and monitor their reaction. They probably didn’t care whether your old software was obsolete if they learned how to use it by heart. Their experience is crucial for the financial success of new system’s implementation. 

Nevertheless… 

Modernization of legacy systems is quite tricky which shouldn’t stop you from doing it. At some point the legacy system will cause a problem – the technology will not be supported or you will have problems with hiring people who can operate your software.

Modernization isn’t something to be afraid of. It’s a necessary part of growing a business and if you can’t do it alone, it’s important to find a business partner who will help you transition to new solutions without completely throwing away your old ones.

Author: Andrzej Wodnicki, Managing Director at ITSG Global