The first step is a detailed assessment.

Is there a document that takes up different aspects of the previous project to identify pros and cons? Was there a requirements document that was used as a guide to developing the project that is now being called “legacy”? If not, then write one.

In your case, you have a sense of what the solution does. You know its impact, but you are also looking to make improvements. The dilemma you really have is to scrap the current and build new, or get your hands dirty on existing code.

I understand and know very well the attraction of starting projects from scratch. But I also know that new projects look shiny but hide a lot of uncertainty under the hood. These uncertainties are 0 to 1 challenges which one should factor into their expectations.

Legacy projects are not without their own set of problems but the biggest benefit with a legacy solution is that it is currently in working order.

For the business, what works is king.

You can start working on chipping away at parts of the legacy project that can be improved. You can start talking to your users, learning more about their pain points and what improvements they have been waiting for and prioritise them.

After a few quarters of work, much of the legacy code would have been re-written and you can then christen the product with a new name.

Check out https://rubygarage.org/blog/when-to-refactor-code for some technical reading on this topic

The discussion shared above was part of many Q&A sessions Harsh Singhal conducted with Data teams at various companies and colleges.