Passagem técnica ao trocar fornecedor de software: o que conferir

Ao trocar o fornecedor de um software, peça mais do que um link para o repositório. A passagem técnica só está pronta quando a empresa sabe quais ativos sustentam o produto, quem controla cada conta, como a operação continua e quais acessos foram testados. Um documento entregue sem demonstração pode esconder dependências que só aparecem no próximo deploy ou incidente.

Este roteiro é para quem manterá o mesmo produto com outro responsável técnico. Se a decisão de refazer o sistema ainda está aberta, examine primeiro as evidências para essa escolha. Se a operação vai passar para outro sistema, há também uma validação própria da migração de dados. A troca de fornecedor pode exigir ambos os trabalhos, mas eles não são o mesmo aceite.

Faça um inventário que mostre titularidade e acesso

Liste cada ativo necessário para desenvolver, publicar e operar o produto. Comece pelo domínio e DNS, repositório de código, hospedagem, banco de dados, armazenamento, automações de deploy, monitoramento, backups e serviços externos usados pelo produto. Inclua contas de faturamento e contatos de recuperação. Um nome de ferramenta na lista não responde quem é o titular da conta nem quem consegue administrá-la.

Para cada ativo, registre:

Não preencha “acesso entregue” porque alguém enviou uma captura de tela. Peça uma demonstração no ambiente apropriado: o responsável nomeado entra com a própria conta, encontra o recurso e confirma a permissão de que precisa. Uma pessoa com acesso de leitura ao código pode continuar sem permissão para publicar ou recuperar o serviço.

Confirme o código e o caminho até a produção

Peça o endereço do repositório, a branch usada para produção, as regras de proteção, o histórico necessário e as instruções para configurar o projeto. Depois, percorra o caminho de uma mudança pequena em ambiente de teste: como ela é revisada, quais testes rodam, quem aprova e onde o resultado do deploy aparece. O ensaio deve ser planejado para não afetar usuários nem sobrescrever alterações em andamento.

Se o repositório GitHub for transferido de proprietário, não presuma que integrações e acessos desapareçam. A documentação do GitHub informa que webhooks, secrets e deploy keys permanecem associados ao repositório transferido, e que colaboradores podem continuar com acesso. A transferência muda o titular; a revisão das permissões e dependências é uma tarefa separada. Em outra plataforma, confira a regra dela antes de agir.

Identifique também onde moram a configuração de produção, os comandos de build, as variáveis necessárias, as migrações e o procedimento para reverter uma versão. Não peça que o fornecedor copie senhas ou chaves para uma planilha de passagem. Registre o nome, a finalidade, o serviço e o responsável por cada segredo, sem o valor. O GitHub documenta segredos em níveis de repositório, ambiente e organização no Actions; esse é um exemplo concreto de configuração que pode ficar fora do código. O responsável técnico deve conferir o mecanismo usado no produto real e planejar a substituição de credenciais em canal apropriado.

Saiba quem mantém a operação de pé

Uma passagem útil explica onde aparecem alertas e logs, quem recebe cada alerta, como verificar a saúde do serviço, onde está o backup e como se testa a restauração sem expor dados desnecessários. Inclua o caminho para acionar provedores externos e a lista de tarefas recorrentes. O Google SRE Workbook descreve plantão, alertas e escalonamento como trabalho organizado; ter uma ferramenta de monitoramento contratada não define, por si só, quem atende nem quando.

Combine por escrito o último dia de responsabilidade do fornecedor atual e o primeiro do novo, com um ponto de contato para a transição. Veja o roteiro de custo de manutenção após o lançamento para separar serviços de terceiros, suporte e evolução. O documento de passagem deve apontar o acordo real, sem inferir cobertura contínua de um acesso administrativo.

Revise acessos sem interromper o serviço

Faça uma lista de usuários humanos, contas de serviço, aplicativos autorizados, chaves de deploy e integrações que ainda podem agir no produto. Para cada item, decida manter, reduzir, substituir ou revogar e identifique a dependência. A orientação do GitHub para deploy keys recomenda revisar chaves existentes e remover as não reconhecidas ou desatualizadas. Remover tudo de uma vez pode quebrar o deploy; testar primeiro a alternativa evita que o controle novo venha acompanhado de indisponibilidade.

Faça a sequência de forma verificável: crie o acesso do novo responsável, confirme que ele funciona, substitua o que depende da credencial antiga, teste o fluxo e só então revogue o acesso que saiu. Em caso de suspeita de comprometimento, trate a urgência com o responsável por segurança e com o plano de resposta aplicável. A ficha pública ou compartilhada entre fornecedores deve guardar decisões e evidências, nunca valores de segredos.

Encerre com uma ficha de aceite, não com “documentação enviada”

Antes de aceitar a passagem, peça que o responsável pelo negócio e o técnico revisem juntos uma ficha como esta. É um modelo editorial, a adaptar ao contrato e ao risco do seu produto.

“Preencher se houver” impede transformar ausência de informação em aceite tácito. Cada linha precisa de um resultado observado, de uma exceção aprovada ou de uma pendência bloqueadora. Guarde o registro da versão do produto e da data do ensaio, para que a evidência não seja confundida com o estado de semanas depois.

A pergunta final é: se o fornecedor anterior deixar de operar hoje, quem consegue fazer o próximo deploy, responder a um alerta e recuperar o serviço? Se não houver resposta demonstrada para uma capacidade necessária, mantenha a pendência visível e combine uma transição assistida. O inventário reduz suposições; a demonstração mostra o controle que realmente foi assumido.

Fontes técnicas consultadas em 19 de outubro de 2026. A ficha e os critérios são uma síntese editorial original e devem ser adaptados ao produto e ao contrato.