Refactoring or rewriting: what to do with the old application

First: the underlying technology no longer receives security updates, and the components it depends on can no longer be installed on modern systems. That is no longer a business decision but a risk decision. Second: you can no longer find people who will work in it, and those who exist charge scarcity rates and refuse long-term maintenance. Third: the data model no longer supports where the product is going — you need multiple companies, multiple currencies or multiple warehouses, and the structure assumes everywhere that there is only one.

If none of those signals applies and the real frustration is that adding a feature takes too long, then you have a problem of code organisation and testing, not of technology. That is solved through targeted refactoring guided by measurement: where the time goes, which areas break most often, which modules generate the most incidents. The investment is several times smaller and shows results within months.

If the application does exactly what it should, nobody is asking for new features and incidents are rare, the best decision is to do nothing. Pay only for security updates and backups, document what exists, and keep the credentials safe. We have met companies talked into rewriting perfectly functional systems because they did not look modern; that money would have produced more almost anywhere else.

Call us when the cost of doing nothing has become visible: deliveries take months, every change breaks something else, only one person can still intervene, or the current supplier has stopped answering. We start with a short paid audit that ends in a reasoned recommendation — including, if that is what the numbers show, the recommendation to keep the current system and build separately only the part that blocks you.