É muito difícil responder isso. Não é tão simples, envolve questões políticas também. Pode precisar de muito mais informações, mas pode ser que apenas uma dê para decidir.
Vou dar um exemplo de um sistema que peguei em um emprego novo que tive que tinha 120 mil linhas de códigos, e quando liguei o warning pela primeira vez na vida dele deu 600 mil, ou seja, 5 por linha de código. Tecnicamente não tinha dúvidas, justifiquei mais do que isso e pedi para começar do zero. O diretor não aceitou, pronto, estava decidido.
Se você tem certeza que dá consideravelmente mais trabalho e ninguém te impede, então não tem porque decidir diferente. O problema é que as pessoas costumam errar no trabalho que dará refazer. Precisa ter muita experiência para perceber se realmente dá menos trabalho, e geralmente só se vai mudar completamente a filosofia, se já tem uma base boa para começar outro. Tem que ter certeza que terá muito benefício. Eu sou favorável a refazer coisa ruim, mas sei que a maioria tomará essa decisão de forma equivocada.
- 5 anos é pouco para algo ser velho, tem sistemas rodando bem com dezenas de anos, até mesmo rodando em console, mas isso não diz muito também
- quem fez não determina muito, tem que ver o código
- Muita boa prática que as pessoas seguem na verdade são más práticas (tenho palestra sobre isso, esse erro é cometido até por experientes), então sem saber mais sobre isso pode não ser problema
- SOLID é uma dessas boas práticas, têm sistemas SOLID mais mal feitos que outros que não seguem. Em alguns casos fazer SOLID pode ser uma má prática, o maior erro é não considerar contexto e seguir receita de bolo cegamente, então pode trocar um ruim por outro ruim, só que quem refez acha que está bom
- A falta de canonicidade é grave, mas pode ser resolvido incrementalmente. Na maioria das vezes não precisa refazer por causa disso
- Número disso ou daquilo não indica que algo é ruim, pode mudar e passar ter outro problema, toda moeda tem dois lados, nenhum vale mais. Pode ter motivo para ser assim, tem que ver o caso específico, pode ser um ou dois casos, não justificaria
- Ser escalável não é necessariamente um defeito, pra quem fazer algo que não será usado?
- Problemas pontuais de forma geral podem ser refeitos pontualmente sem o sistema inteiro sendo refeito, embora é claro que olhando os detalhes pode encontrar algo muito crítico, pode ter o banco de dados usado de forma errada.
Se tudo isso junto torna inviável, então deve refazer. Mas pelas observações eu tenho a impressão que o sistema terá um monte de coisa nova que talvez não justifique.
Tem o lado de quem vai por a mão e não quer mexer em algo claramente ruim, mas ruim não é o mesmo que inviável. De outro lado tem quem paga. Será que realmente sai mais barato refazer? Vai dar orçamento fechado? Se der, então o problema é seu.
Eu entendo tudo isso que fala, e pode ser um caso para refazer, mas nunca é tão simples quanto parece. No fim das contas é você que terá que conviver com o rolo atual ou ter o trabalho de fazer do zero. Não existe cenário similar, cada detalhe muda o cenário. Se encontrar algo similar então só está ruim porque seguiram as tais boas práticas e ficou tudo ruim. Porque só terão dois sistemas parecidos quando seguiram receitas de bolo que divulgam por aí. Se fizeram sem seguir nada, fica aleatório, um não será igual a outro.
Não sei se consegui ser claro que sempre é mais difícil do que parece refazer do zero, especialmente reproduzir as mesmas regras de negócio. Em geral não conseguirá, não terá quem consiga ajudar da mesma forma. Quem vai usar precisa saber antes que não será igual. Não dará resultados iguais, a não ser por sorte, e a usabilidade mudará. Muitas vezes os usuários se rebelam porque preferiam usar o antigo, mesmo que ele fosse pior.
Faz sentido para você?
Espero ter ajudado.
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).