O fornecedor sumiu e o sistema continua no ar: por onde começar

O sistema funciona. Os pedidos entram, os clientes usam, a fatura do cartão da empresa paga alguma coisa em dólar todo mês. O que não funciona é o telefone do fornecedor que construiu tudo isso. As mensagens passaram a demorar uma semana, depois deixaram de ser respondidas.

A reação natural é ir atrás dele. Cobrar, insistir, procurar um sócio, falar em advogado. Às vezes funciona, e quando funciona é o caminho mais barato.

Só que essa não é a primeira coisa a fazer, e a razão é desconfortável: enquanto você negocia com uma pessoa, você está perdendo prazo com máquinas. O domínio tem data de renovação. O certificado expira. O cartão cadastrado na nuvem é do fornecedor, e vai ser recusado em algum momento que ninguém escolheu. A conta de e-mail que recebe os avisos de tudo isso provavelmente é dele também.

O relógio que importa não está na relação comercial. Está nos ativos.

Faça o inventário do que você alcança hoje, não do que deveria ter

Antes de qualquer conversa, descubra o que a sua empresa consegue abrir agora, sozinha, sem pedir nada a ninguém. É um exercício de meia hora e ele muda completamente a conversa seguinte.

A lista é sempre a mesma, e quase sempre tem furos:

1. O domínio. Em nome de quem está registrado, qual e-mail recebe os avisos de renovação, e quando vence. Domínio perdido derruba site e e-mail ao mesmo tempo, e recuperar depois de expirado é caro quando é possível.
2. O servidor ou a conta de nuvem. A empresa é a titular, ou é uma conta pessoal do fornecedor com o cartão dele? Titularidade errada é o problema mais comum e o mais caro de resolver tarde.
3. O repositório do código. Existe, e alguém da sua empresa tem acesso? "O código está com eles" e "o código não existe" produzem o mesmo silêncio.
4. O banco de dados. Onde ele roda, quem tem credencial, e existe backup que alguém já restaurou de verdade. Backup nunca testado é hipótese.
5. As contas de terceiros. Gateway de pagamento, envio de e-mail, SMS, mapas, a API de inteligência artificial que aparece na fatura. Cada uma tem um dono cadastrado.
6. As lojas de aplicativo. Conta Apple e Google em nome de quem. Aplicativo publicado na conta do fornecedor não se transfere sozinho, e uma conta de desenvolvedor abandonada leva o aplicativo junto.

O que sai daí não é um plano, é um mapa de risco. Um item em que a sua empresa é titular e tem a senha é um item que ninguém tira de você. Um item em nome do fornecedor é uma contagem regressiva, e vale saber quanto tempo falta em cada uma.

O que vemos com mais frequência não é má-fé, é informalidade acumulada

Nos projetos que chegam para resgate, a versão dramática (o fornecedor que some com o código de propósito) é a minoria. O padrão comum é mais banal e mais difícil de resolver: ninguém formalizou nada, em nenhum momento, porque no começo a relação era boa e parecia burocracia desnecessária.

O desenvolvedor abriu a conta de nuvem no e-mail dele porque era mais rápido. O repositório nasceu no perfil pessoal de quem escreveu a primeira linha. O acesso ao servidor foi passado por mensagem, uma vez, para alguém que não trabalha mais na empresa. Não houve decisão ruim, houve ausência de decisão, repetida por dois anos.

Isso importa porque muda a abordagem. Contra má-fé, você precisa de advogado. Contra informalidade, você precisa de uma lista de pedidos específicos, por escrito, que uma pessoa ocupada consiga atender em uma tarde. A segunda costuma funcionar melhor, inclusive com fornecedores que pararam de responder: o silêncio muitas vezes é constrangimento, não estratégia.

Peça acesso, não explicação

Quando for escrever para o fornecedor, o erro é pedir uma conversa. Conversa exige agenda, e agenda é exatamente o que ele não está dando.

Peça transferência de titularidade, item por item, nomeando cada conta e o e-mail para onde transferir. Um pedido objetivo tem chance de ser executado entre duas outras tarefas. "Precisamos conversar sobre o projeto" não tem.

Duas coisas que valem a pena na hora de receber:

Credencial trafega por cofre, nunca por e-mail ou aplicativo de mensagem. Senha em conversa de WhatsApp fica no aparelho de todo mundo que participou, para sempre, inclusive de quem sair da empresa depois. Se o fornecedor mandar assim mesmo, troque tudo depois de receber.

Acesso de leitura resolve o diagnóstico. Para descobrir o que existe e em que estado, ninguém precisa de permissão de administrador. Acesso somente leitura, nominal e revogável, baixa a resistência do outro lado e é suficiente para avaliar. Permissão ampla é assunto da retomada, não da avaliação.

A pergunta final não é se dá para recuperar

É quanto de cada parte vale recuperar. E a resposta quase nunca é toda de um lado só.

Na prática, um sistema abandonado se divide em três: o que dá para retomar como está, o que precisa ser refeito por partes, e o que não tem recuperação viável e é mais honesto reconstruir. Um parecer técnico serve para dizer onde fica cada linha divisória, com o código na frente, antes de qualquer estimativa de prazo.

O que não funciona é decidir isso pela emoção do momento. Quem acabou de ser deixado na mão tende a dois extremos: ou quer jogar tudo fora e começar do zero, o que costuma ser a opção mais cara, ou quer preservar tudo a qualquer custo, porque já pagou uma vez.

O código continua lá enquanto você decide. As contas em nome do fornecedor, não.

Se a situação ainda não chegou nesse ponto e você só quer não chegar, o caminho é o mesmo inventário acima, feito hoje, com o fornecedor atual respondendo bem. Titularidade correta custa uma tarde quando a relação está boa, e custa um projeto quando não está.