Tipo de sistema
Existe um sistema na sua empresa que ninguém quer abrir. Ele funciona, sustenta o faturamento, e cada alteração é feita com medo. Esse medo tem nome: é risco concentrado, e ele cresce todo mês.
Não é a idade do código. É a combinação abaixo.
Se existe uma única pessoa que entende o sistema, a empresa tem um ponto único de falha que não está em nenhum inventário de risco.
Sem teste automatizado, toda alteração é uma aposta. O time passa a evitar mexer, e o sistema congela junto com o negócio.
Biblioteca, linguagem ou banco fora de suporte significa vulnerabilidade conhecida sem correção disponível. É problema de segurança, não de estética.
Quando a regra não está documentada em lugar nenhum, o código virou a única fonte da verdade sobre como a empresa opera.
Sistema fechado impede automação e relatório consolidado, e cada nova ferramenta da empresa nasce isolada dele.
O maior risco de um projeto de legado não é técnico, é operacional: parar a empresa no meio da virada. Por isso o método é por etapas.
Levantamento do comportamento real, incluindo o que não está documentado e o que a equipe faz por fora para contornar limitação.
Teste automatizado sobre o comportamento atual, para provar que o novo faz o mesmo que o antigo.
O sistema novo assume um módulo por vez, com o antigo no ar. Nada de virada única de fim de semana.
Migração final dos dados, treinamento e desligamento do legado só depois de estabilizar.
Está aqui porque é a proposta que mais aparece e a que mais fracassa. Reescrever do zero significa passar meses sem entregar valor nenhum enquanto o negócio continua mudando.
Na maioria dos casos. Módulo por módulo, com ganho aparecendo durante o projeto e não só no fim.
Quando a base tecnológica está fora de suporte a ponto de impedir qualquer evolução segura, ou quando o custo de manter já passou o de construir.
Custo de manter por ano, risco de parada, exigência regulatória e o quanto do sistema ainda é usado de verdade. A recomendação sai com esses números, e às vezes ela é manter e estabilizar.
Sim, e é justamente por isso que a migração é por partes. O sistema antigo continua no ar enquanto o novo assume um módulo de cada vez, com plano de retorno testado para cada etapa. Virada única em fim de semana é o modelo que mais dá errado.
É o cenário mais comum. A primeira etapa existe exatamente para isso: levantar o comportamento real a partir do código, do banco e de quem usa. Ao fim dela a empresa já sai com a regra de negócio documentada, o que sozinho já reduz o risco.
Depende do tamanho do que ele faz de verdade, que costuma ser menor do que parece. Por isso o primeiro passo é o diagnóstico, que devolve o mapa do sistema e a faixa de investimento por etapa. É o tipo de projeto em que orçar sem levantar antes é irresponsável.
Sim, e é o recomendado. Começar pela auditoria de arquitetura, ou por um módulo periférico, dá à sua empresa a chance de avaliar a FlowCore com risco baixo antes de entregar o núcleo da operação.