little goatManter, integrar ou reescrever um sistema: como decidir
Compare alternativas para um sistema existente por fluxo, dependências e risco. Preencha e exporte uma matriz para discutir o primeiro passo com seu time.
Comece pelo fluxo que precisa melhorar, não pela idade da tecnologia. Um sistema antigo pode atender bem. Um sistema recente pode gerar retrabalho. Para decidir entre manter, integrar ou substituir, registre o problema, as dependências e a evidência necessária para aceitar uma mudança.
Este guia é para quem opera ou mantém um sistema web existente. A matriz abaixo organiza uma conversa técnica; não estima preço nem substitui a análise do código, dos dados e das restrições do negócio.
Qual alternativa responde ao problema?
| Alternativa | Quando investigar | Evidência antes de escolher | Cuidado principal |
|---|---|---|---|
| Manter e corrigir | O fluxo atende ao negócio, mas tem um defeito delimitado | Passos para reproduzir, causa investigada e teste da correção | Corrigir um sintoma sem compreender a dependência |
| Integrar | O mesmo dado é digitado em sistemas distintos | Fonte oficial, API ou meio autorizado de troca e regra para falhas | Duplicação, divergência de dados e limites do fornecedor |
| Substituir um fluxo | Uma parte concentra mudanças ou não pode mais ser mantida | Fronteira isolável, comportamento esperado e plano de retorno | Dependências ocultas e convivência temporária entre versões |
| Reescrever o conjunto | Restrições comprovadas impedem as opções menores | Regras inventariadas, capacidade de transição e comparação de custo total | Redescobrir regras durante a entrega e manter dois sistemas por mais tempo |
As alternativas podem coexistir: corrigir uma falha agora, integrar um serviço depois e substituir um módulo quando houver evidência. Uma biblioteca antiga exige avaliar suporte e segurança; sua idade, sozinha, não determina uma reescrita completa.
Matriz preenchível para um fluxo
Preencha um único fluxo. Os campos ficam apenas nesta página, não são enviados e serão apagados ao recarregar. Exporte para guardar seu rascunho. Não inclua senhas nem dados pessoais de clientes.
A escolha é sua: a matriz organiza evidências, sem atribuir uma nota automática ou recomendar uma contratação.
Exemplo de preenchimento: consulta de pedidos
Cenário fictício, sem resultado de cliente: o atendimento consulta o ERP e copia o status para responder a cada comprador. Ainda não sabemos quantas consultas ocorrem por dia nem quanto tempo isso consome.
- Fluxo e responsável: consultar o status; equipe de atendimento.
- Problema observado: alternar entre duas telas. Confirmar com quem executa a tarefa e registrar uma amostra autorizada.
- Impacto e custo: ainda desconhecidos. Medir tempo por consulta e frequência antes de projetar economia.
- Dependências: ERP como fonte oficial; verificar API, permissões e limites contratuais. Não presumir acesso direto ao banco.
- Mudanças esperadas: disponibilizar a consulta em outra interface; regras de atualização ainda precisam ser definidas.
- Aceite e retorno: comparar respostas com o ERP; em divergência, interromper o piloto e usar a consulta atual. Verificar também se esse caminho continua disponível.
A hipótese inicial é investigar uma integração de leitura. Ela depende da API e da necessidade real; não é uma recomendação universal. Se a informação já estiver disponível em um recurso do fornecedor, configurá-lo pode ser suficiente.
Experimente o comportamento na demonstração de migração incremental: um pedido muda de caminho, apresenta erro e volta ao legado. O exemplo permite observar a diferença entre reverter o tráfego e corrigir o serviço.
Como comparar custo sem inventar um orçamento
Peça que cada alternativa use o mesmo período de comparação e separe: investigação, implementação, licenças, infraestrutura, operação durante a transição, treinamento e manutenção. Marque estimativas e valores ainda desconhecidos. Não transforme horas de retrabalho em receita recuperada sem verificar se esse tempo pode ser aproveitado.
Inclua o custo de não mudar e os riscos de cada caminho, com as evidências disponíveis. Uma proposta menor pode excluir migração de dados e suporte. Uma proposta maior pode incluir itens de que você não precisa. Compare o escopo antes do total.
O que precisa existir antes de substituir uma parte
- Uma fronteira: quais entradas e saídas pertencem ao fluxo? Quem mais depende delas?
- Uma referência: quais respostas, regras e permissões precisam ser preservadas? Use exemplos autorizados e protegidos.
- Um aceite: quem compara o resultado e quais divergências impedem ampliar o piloto?
- Um retorno testável: o caminho anterior continua disponível? Se houve gravações, como tratar dados novos ou duplicados?
- Um responsável: quem acompanha erros e pode interromper a mudança?
A substituição gradual é descrita no padrão Strangler Fig de Martin Fowler. A fronteira e a convivência precisam ser construídas; trocar componentes aos poucos não elimina o trabalho de entender o sistema.
Migrar para a nuvem resolve esse problema?
É outra decisão. Mover a hospedagem pode atender a uma necessidade de infraestrutura e ainda preservar o mesmo fluxo manual. Se esse é o objetivo, veja migração de sistemas legados para a nuvem. Para comportamento da aplicação, use a matriz deste guia.
Leve um recorte para a primeira conversa
Não é preciso chegar com a arquitetura decidida. Traga um fluxo, exemplos do problema, dependências conhecidas e dúvidas. Evite enviar senhas, bases de produção ou dados pessoais no contato inicial.
A consultoria de evolução de sistemas web da Little Goat parte dessa discussão para avaliar o escopo. Você também pode exportar a matriz e usá-la com seu próprio time ou outro fornecedor.
Vamos conversar sobre seu projeto.
Conte o que você precisa, o que já tem e o que gostaria de mudar.
Fale com a Little Goat