Trocar a equipe responsável por um sistema em produção exige cuidado.

O maior erro é começar alterando código antes de entender como a plataforma funciona.

Um sistema legado pode possuir tarefas agendadas, integrações, servidores, chaves, rotinas manuais e dependências que não aparecem no repositório.

Por isso, a primeira fase deve ser de descoberta.

Comece pelo inventário

Mapeie:

  • repositórios;
  • servidores;
  • banco de dados;
  • DNS;
  • domínios;
  • certificados;
  • storage;
  • backups;
  • cron jobs;
  • filas;
  • integrações;
  • serviços externos;
  • contas;
  • credenciais;
  • monitoramento;
  • processos de deploy.

O inventário cria uma visão do ambiente antes de qualquer mudança.

Descubra como produção é publicada

Perguntas simples podem revelar riscos importantes:

  • existe CI/CD?
  • deploy é manual?
  • alguém edita arquivos diretamente no servidor?
  • existe rollback?
  • banco é migrado automaticamente?
  • staging representa produção?
  • código em produção está no Git?

Não presuma que o repositório contém exatamente o que está rodando.

Acesso é parte da transição

Identifique quem possui acesso a:

  • servidores;
  • Git;
  • cloud;
  • DNS;
  • banco;
  • painel administrativo;
  • serviços de terceiros.

A saída de fornecedores antigos precisa ser planejada para remover acessos sem quebrar automações que dependam das mesmas credenciais.

Backup antes de mudanças

Antes de uma intervenção relevante, confirme se existe backup e se a estratégia de restauração é conhecida.

“Existe um arquivo de backup” e “conseguimos restaurar o sistema” são afirmações diferentes.

Observe antes de otimizar

Código antigo pode parecer estranho porque resolve uma condição que não está documentada.

Antes de remover processos ou refatorar grandes áreas, acompanhe logs, jobs, tráfego e comportamento.

Mudanças iniciais devem priorizar riscos conhecidos e problemas comprovados.

Classifique as pendências

Uma forma útil é separar:

Crítico: risco imediato de indisponibilidade, perda de dados ou segurança.

Alto: problema relevante que deve entrar rapidamente no plano.

Médio: dívida técnica ou melhoria operacional.

Baixo: otimizações sem urgência.

Isso evita transformar a transição em uma tentativa de “corrigir tudo”.

Documente enquanto descobre

Documentação de legado não precisa começar perfeita.

Registre:

  • arquitetura atual;
  • hosts;
  • serviços;
  • portas;
  • caminhos;
  • rotinas;
  • contatos;
  • dependências;
  • procedimentos;
  • pendências.

O documento evolui conforme o conhecimento aumenta.

Estabilize antes de modernizar

Quando o ambiente apresenta incidentes recorrentes, pode ser melhor separar o trabalho em fases:

  1. inventário;
  2. estabilização;
  3. documentação;
  4. melhorias;
  5. modernização.

Refatorações profundas durante uma crise aumentam risco.

Conclusão

Assumir um sistema legado é um processo de redução gradual de incerteza.

Quanto melhor o inventário e a observação inicial, menor a chance de uma mudança aparentemente simples produzir um incidente.

Precisa assumir ou estabilizar uma plataforma existente?

A Jumps atua em sustentação, infraestrutura e evolução de sistemas já em produção.

Conversar sobre sustentação →

Relacionado: Sustentação e Evolução · Quanto custa manter um sistema depois que ele entra em produção?.