Sistema abandonado pelo fornecedor: como retomar um software que ficou órfão sem jogar tudo fora

O sistema está no ar e a operação depende dele todos os dias. Mas a empresa que desenvolveu não responde mais, ou respondeu que "não atende mais esse tipo de projeto", ou simplesmente fechou. Ninguém na sua equipe sabe onde o código está hospedado, quem paga o servidor, ou o que acontece se algo quebrar amanhã. Cada mês que passa sem um problema parece sorte, não gestão. Quem já passou por um projeto travado sabe do que estou falando: o software vira uma caixa preta que sustenta o negócio, e ninguém tem a chave.

Esse cenário é mais comum do que parece. Na OCA, uma parte relevante dos projetos que chegam não é sistema novo, é sistema órfão. E a boa notícia é que, na maioria dos casos, dá para retomar sem começar do zero. Mas existe uma ordem certa de fazer isso, e pular etapas custa caro.

Por que fornecedores abandonam sistemas

Antes de resolver, vale entender a causa, porque ela muda a estratégia de resgate.

• O fornecedor era uma pessoa só. Freelancer que mudou de emprego, de país ou de área. O código pode até ser bom, mas todo o conhecimento foi embora com ele.
• A empresa fechou ou pivotou. Agências e software houses pequenas encerram operações, e clientes de manutenção são os primeiros a ficar sem resposta.
• O contrato acabou e ninguém renovou. O projeto foi entregue, ninguém assinou manutenção, e dois anos depois não existe mais relação comercial nem obrigação de suporte.
• A relação azedou. Disputa de escopo ou pagamento, e o fornecedor segura acessos como moeda de pressão. Esse é o pior cenário, e o que mais exige cuidado jurídico.

Em todos os casos, o erro original costuma ser o mesmo: os acessos e o código ficaram em nome do fornecedor, não da empresa. Se você está contratando um sistema agora, essa é a lição número um deste artigo.

Passo 1: recuperar a posse do que é seu

Antes de qualquer decisão técnica, você precisa de posse. Sem isso, nenhum novo fornecedor consegue trabalhar. A lista do que recuperar:

1. Código-fonte. Acesso ao repositório (GitHub, GitLab, Bitbucket) com histórico completo, não um arquivo .zip. O histórico conta a história do projeto e vale ouro na auditoria.
2. Infraestrutura. Contas da AWS, Google Cloud, Vercel, ou o servidor onde o sistema roda. Idealmente a conta deve estar no CNPJ da sua empresa, com o fornecedor como convidado, nunca o contrário.
3. Domínio e DNS. Verifique no registro.br ou no registrador em quem está o domínio. Domínio em nome do fornecedor é risco crítico.
4. Banco de dados. Acesso direto e uma rotina de backup que você controla. Se hoje não existe backup fora do servidor de produção, resolva isso esta semana, antes de qualquer outra coisa.
5. Serviços de terceiros. Gateway de pagamento, serviço de e-mail, APIs contratadas. Cada um tem uma conta e uma fatura, e você precisa saber de todas.
6. Documentação e credenciais. Senhas, chaves de API, variáveis de ambiente. Um cofre de senhas da empresa (não a planilha de alguém) é o destino certo.

Se o fornecedor ainda responde, formalize o pedido por escrito e ofereça pagar algumas horas pela transição organizada. Sai muito mais barato do que reconstruir conhecimento por engenharia reversa. Se o contrato original previa cessão de propriedade intelectual, o código é seu por direito; se não previa nada, converse com um advogado antes de escalar o tom.

Passo 2: auditoria técnica antes de qualquer promessa

Com os acessos em mãos, o próximo passo não é sair contratando desenvolvimento. É uma auditoria: um trabalho curto, de 1 a 3 semanas dependendo do tamanho do sistema, em que um time sênior lê o código e responde perguntas objetivas:

• O sistema roda em ambiente de desenvolvimento? Ou só existe em produção?
• Quais tecnologias foram usadas e elas ainda têm suporte? Um sistema em uma versão de framework descontinuada há cinco anos tem custo de atualização que precisa entrar na conta.
• Existem testes automatizados? A ausência não inviabiliza nada, mas muda o ritmo e o risco de qualquer alteração.
• Onde estão os pontos frágeis? Dependências abandonadas, senhas no código, partes que ninguém entende.
• Quanto custa manter esse sistema vivo por mês, entre infraestrutura e horas de manutenção?

O barato que sai caro aqui é o seguinte: contratar alguém que, sem ler o código, já cravou "tem que reescrever tudo". Reescrever é a resposta mais confortável para quem desenvolve, porque código alheio dá trabalho de entender. Mas nem sempre é a resposta certa para quem paga. Exija que a recomendação venha depois da auditoria, com justificativa por escrito.

Continuar, reformar ou reescrever: a conta que decide

Não existe resposta única, mas existe conta certa. Depois da auditoria, o cenário costuma cair em um de três casos:

Continuar com o que existe

O código é razoável, a tecnologia é atual, o problema era só a ausência de dono. Aqui o custo é baixo: um contrato de manutenção mensal e uma fila de melhorias priorizadas. É o melhor cenário e é mais frequente do que o mercado admite.

Reformar por partes

O sistema funciona, mas tem áreas problemáticas: um módulo instável, uma integração frágil, uma tecnologia defasada em um ponto específico. A estratégia é substituir por partes, mantendo o sistema no ar. Custa mais que manutenção pura, mas dilui o investimento ao longo de meses e nunca deixa a operação sem sistema.

Reescrever

Faz sentido quando a tecnologia está morta (não recebe mais atualizações de segurança), quando o custo de alterar qualquer coisa supera o de refazer, ou quando o negócio mudou tanto que o sistema resolve o problema errado. Nesse caso, trate como um projeto novo: escopo, prazo e orçamento próprios, com o sistema antigo rodando até a virada. Reescrita em produção, sem plano de migração de dados e de usuários, é onde os projetos de resgate morrem.

Um critério prático: some o custo estimado de 12 meses mantendo e reformando o sistema atual e compare com o custo da reescrita mais 12 meses de manutenção do sistema novo. Se a diferença não for grande, fique com o que existe, porque o sistema atual tem uma vantagem que o novo não tem: ele já funciona e já foi testado pela realidade.

Como evitar que o próximo sistema fique órfão

Antes de assinar qualquer contrato, pergunta isso:

• O repositório de código ficará em uma conta da minha empresa desde o primeiro dia?
• A infraestrutura e o domínio ficarão no meu CNPJ, com o fornecedor como colaborador convidado?
• O contrato prevê cessão de propriedade intelectual do código desenvolvido?
• Existe documentação mínima que permita outro time assumir? Peça para ver um exemplo de projeto anterior.
• O que acontece no fim do contrato? Um bom fornecedor descreve o processo de transição sem desconforto, porque não pretende te prender pela obscuridade.

Fornecedor que hesita em qualquer uma dessas respostas está te dizendo algo importante antes de você pagar a primeira parcela.

Onde a OCA entra nessa história

Resgatar sistema órfão é parte do dia a dia da OCA. Somos um time sênior que herda código de outros times com frequência, e por isso o processo acima não é teoria: é o roteiro que aplicamos. O sistema de gestão para imobiliárias que operamos em produção é um exemplo do tipo de software que não pode parar, e a mesma disciplina de acessos, backups e documentação que usamos nos nossos produtos, como o Revo App com mais de 40 mil usuários, é a que aplicamos em sistemas que assumimos.

Se o seu sistema está sem dono, o primeiro passo não custa nada: monte a lista de acessos do Passo 1 e marque o que sua empresa tem e o que está na mão do fornecedor. Essa lista sozinha já vira a pauta da conversa de transição. E se quiser uma auditoria honesta antes de decidir entre manter e reescrever, Converse com a OCA sobre o seu sistema.