Quase todo contrato de software descreve com cuidado o que será construído. Poucos descrevem o que você vai receber.
São coisas diferentes. O que será construído é o sistema. O que você recebe é o sistema mais a capacidade de operá-lo sem depender de quem o construiu. A segunda parte não vem junto por padrão, e a hora de descobrir isso não é quando você decide trocar de fornecedor.
Vale como checagem antes de assinar e como pauta das últimas semanas de qualquer projeto. Uma transferência responsável não cabe numa reunião final. Cada item precisa ter um responsável, uma data e uma forma prática de confirmar que funciona.
1. O repositório, com o histórico inteiro
Na conta da sua empresa, não na do fornecedor, e não como um arquivo compactado enviado por e-mail no último dia.
O histórico importa mais do que parece. Ele é um dos melhores registros de por que as coisas são do jeito que são: a mensagem de commit que explica por que aquela regra estranha de cálculo existe, a discussão que antecedeu uma mudança de estrutura. Quem receber o código sem histórico recebe um sistema com pouca memória e pode gastar meses redescobrindo decisões já tomadas. Ou, pior, revertendo-as sem saber.
Falha comum: o código é entregue, mas o repositório de origem continua sendo o do fornecedor, e o que você tem é uma cópia que nasce desatualizada.
2. A infraestrutura no nome e na fatura da sua empresa
Servidores, banco de dados, armazenamento, serviço de e-mail. Tudo isso mora em contas de provedores, e essas contas têm dono.
Falha comum: está tudo sob a conta do fornecedor, misturado com a de outros clientes, e a transferência "fica para depois". Depois vira um projeto de migração com risco de indisponibilidade, feito às pressas e no pior momento possível, que é quando a relação já azedou.
Peça isso no começo. Contas em nome da sua empresa, cartão da sua empresa, e acesso administrativo seu, com o fornecedor convidado. É o inverso do arranjo usual, e é o arranjo correto.
3. Os dados, com a exportação já testada
Não a promessa de exportação. A exportação, feita ao menos uma vez, com você olhando o arquivo que saiu.
Existe uma distância grande entre "o sistema permite exportar" e "existe um caminho que produz um conjunto de dados completo, íntegro e que outra ferramenta consegue importar". A distância só aparece quando alguém tenta.
4. Domínio e DNS registrados por você
O item mais banal da lista e o refém mais frequente. Um domínio registrado na conta pessoal de alguém que trabalhou no projeto é uma dependência de uma pessoa, não de uma empresa. Quando essa pessoa some, muda de emprego ou simplesmente esquece a senha, o custo é a sua marca fora do ar.
5. As contas de terceiros, uma a uma
Gateway de pagamento, serviço de envio de e-mail, mapas, provedor de identidade, ferramenta de monitoramento. Cada integração tem uma conta e uma chave em algum lugar.
Falha comum: as chaves estão configuradas e funcionando, e ninguém sabe em qual conta elas foram criadas. Funciona perfeitamente até o dia em que precisa ser renovada.
6. Observabilidade, para você saber antes do cliente
Você precisa descobrir que algo quebrou por um alerta, não por um cliente irritado no WhatsApp. Isso significa registro de erros, métricas básicas de disponibilidade e alguém do seu lado recebendo os avisos.
Sem isso, a operação do sistema continua dependendo de quem o construiu, mesmo com o código todo na sua mão. É a forma mais silenciosa de dependência: você é dono de tudo e ainda assim precisa ligar para eles.
7. Documentação do que decidiu, não do que é óbvio
A documentação útil não descreve o que o código faz; para isso existe o código. Ela registra o que não está lá: por que essa abordagem e não a outra, quais alternativas foram descartadas e por quê, quais são os limites conhecidos, o que quebra se você mexer em determinado ponto.
Some a isso duas coisas operacionais: como rodar o sistema numa máquina nova, e como publicar uma alteração.
8. Alguém do seu lado que já fez, com supervisão
O último item não é um artefato, é uma pessoa. Antes do projeto acabar, alguém da sua equipe, ou um parceiro seu, precisa ter subido uma alteração em produção pelo menos uma vez, com o fornecedor olhando por cima do ombro e disponível para socorrer.
Treinamento em forma de apresentação não conta. Ou a pessoa fez, ou ela não sabe.
A pergunta que resume a lista
Se você quiser um único teste, é este:
Se o fornecedor desaparecesse amanhã, o que pararia?
Faça a pergunta antes de assinar, não depois. A resposta honesta separa quem construiu um sistema para você de quem construiu uma dependência de si mesmo. As duas coisas se parecem muito enquanto está tudo bem.
Onde a gente entra
No nosso caso a lista acima não é um encerramento, é uma fase. A última das quatro, e a única que dá nome ao resto: Posse.
Ela começa a ser preparada no início, não na última reunião. Propriedade, contas, acessos, documentação e transição precisam estar definidos no contrato e no escopo. Não porque a gente espere que o cliente vá embora, mas porque um produto que pode continuar com outra equipe tende a ser mais documentado e menos amarrado ao fornecedor.
A parte incômoda de trabalhar assim é que ela remove a trava comercial que muito fornecedor considera um ativo. É de propósito. Preferimos que a renovação aconteça porque o trabalho é bom.