Sooner or later, most organizations face a problem with legacy systems. Such systems could have outdated or restrictive functionality or they could be very expensive to operate.
Even if a legacy system was architected properly years ago, it is very stable and it does its job, the language it was developed in might no longer be commonly used, and you might experience problems finding talent to support the system. If your legacy system services external clients, you might face a problem with having to replicate the system for each new client. At some point, the number of instances will become unmanageable, and so you would want to implement a new multi-tenant solution.
Replacing your legacy system
Replacing large legacy systems is always a daunting task. First, it’s expensive. The system might have been developed and enhanced over many years, so there would be a lot of functionality to reproduce in the new architecture. Second, such initiative is hard to sell because, apart from you, most people will not care about your pain in supporting the system as long as it provides adequate functionality. Third, if you spend a couple of years developing a new replacement system on the side, business and technology would move ahead during that time, and you might end up with an outdated system by the time you finish the project.
One approach which worked well for me was developing a new replacement system module by module and integrating completed components into a legacy application. Basically, what you would do is come up with a high-level architecture for the new system, then implement one module with a proper back-end functionality. Then, attach the new module to the legacy system and make the front-end in a style that matches the old system. Since you will keep all business logic in the back-end, it will be relatively easy to adjust front-end to a different style at a later date.
This way, the users will not realize that some modules within their application are served on the back-end from an entirely different system. Depending on the nature of your application, you can use iFrame or API calls to integrate new modules. You may also need to do some data replication to facilitate the integration of the two systems.
Yes, this approach adds a little extra work for the integration of two systems, but benefits will far outweigh such costs.
The benefits
Such modular replacement of a legacy system provides a number of benefits. First, you do not need to secure budgets and undertake a major system redesign project. Second, you can provide new or enhanced functionality to customers as soon as each module is completed. If you are a technology firm, you could be marketing and selling new features to clients now and not months from now. Third, as you retire the old system piece by piece, you would start saving on supporting it gradually as well. Finally, this agile approach will allow you to make necessary changes to your plan or priorities at any time.
