Ao trocar o fornecedor de um sistema, levante tudo o que a nova equipe vai precisar para mantê-lo funcionando: código-fonte atualizado, acessos, ambientes, banco de dados, integrações, rotinas e o histórico de problemas. Faça a passagem com prazo e responsáveis definidos e com um período em que o fornecedor anterior ainda responde a dúvidas.
Por que a transição costuma dar problema
- Código desatualizado: a versão entregue não é a mesma que está rodando em produção.
- Acessos presos: servidores, banco de dados, domínio e serviços externos registrados no nome do fornecedor ou de uma pessoa.
- Conhecimento só na cabeça: detalhes de funcionamento que nunca foram escritos.
- Integrações e rotinas esquecidas: processos que só aparecem quando param de funcionar.
- Pressa: a troca é decidida depois de um conflito e sobra pouco tempo para a passagem.
O que pedir ao fornecedor anterior
| Item | O que conferir |
|---|---|
| Código-fonte | Que é a mesma versão que está em produção, com o histórico de alterações quando houver |
| Acessos e credenciais | Servidores, banco de dados, nuvem, domínio, certificados e serviços externos transferidos para a empresa |
| Ambientes | Onde ficam produção e testes e como uma nova versão é publicada |
| Banco de dados | Estrutura, rotinas de backup e onde ficam as cópias |
| Integrações | Sistemas conectados, arquivos trocados e credenciais de APIs |
| Rotinas agendadas | O que roda automaticamente, quando e o que acontece se falhar |
| Documentação e histórico | Manuais, chamados abertos, problemas conhecidos e alterações recentes |
Sempre que possível, transfira os acessos para contas da própria empresa, e não para a nova equipe. Assim a empresa não fica presa a nenhum fornecedor.
O que a nova equipe precisa conferir
- Montar o ambiente: publicar uma versão de teste a partir do código recebido. Se não funcionar, falta alguma coisa na entrega.
- Comparar com a produção: confirmar que o código recebido corresponde ao que está em uso.
- Mapear integrações e rotinas: listar o que conecta o sistema a outros e o que roda sozinho. Quando não há documentação, a IA pode ajudar a documentar o sistema, sempre com validação da equipe.
- Levantar riscos imediatos: backups, componentes sem atualização e falhas conhecidas.
- Priorizar: corrigir primeiro o que mais afeta a operação.
Como organizar a passagem
- Responsáveis dos dois lados: uma pessoa do fornecedor anterior e uma da nova equipe, com a empresa acompanhando.
- Lista de entregas com prazo: use o quadro acima como checklist e marque o que foi recebido.
- Período de dúvidas: combine um tempo em que o fornecedor anterior ainda responde a perguntas.
- Mudanças grandes congeladas: evite novas funcionalidades enquanto a passagem acontece.
- Registro do que foi entregue: para saber o que existe e onde está, caso surja dúvida depois.
Erros comuns
- Encerrar o contrato antes de receber os acessos: depois disso, a negociação fica mais difícil.
- Aceitar o código sem testar a publicação: o problema só aparece na primeira correção urgente.
- Deixar contas no nome de uma pessoa: quando ela sai, o acesso sai junto.
- Evoluir antes de estabilizar: novas funcionalidades sobre uma base que ninguém conhece ainda aumentam o risco.
- Não registrar o que foi descoberto: a próxima troca começa do zero.
Se a passagem revelar falhas que voltam com frequência, vale uma investigação de bugs complexos antes de qualquer evolução.
Como a RTX ajuda
A RTX assume sistemas que não desenvolveu: avalia o código, o ambiente, as integrações e o histórico de falhas, corrige primeiro o que mais afeta a operação e mantém o sistema com correções e melhorias, de forma pontual ou contínua. Veja como funciona a sustentação de software.