Trocar de fornecedor de software sem perder código nem dados

O sistema funciona, mas cada pedido de ajuste demora semanas, os chamados ficam sem resposta e a fatura chega pontualmente. Você já decidiu, ou está quase decidindo, que é hora de trocar de fornecedor. O que segura a decisão é o medo: e se o atual fornecedor sumir com o código? E se ninguém mais souber como o faturamento funciona? E se o sistema cair na semana do fechamento?

Esse medo tem fundamento. Trocas mal conduzidas costumam terminar com a empresa sem acesso ao servidor, com uma senha de banco de dados que só existia na cabeça de um programador e com a nova equipe gastando meses só para entender o que já existe. Nada disso é inevitável. É falta de roteiro.

A resposta curta: trocar de fornecedor de software com segurança é garantir código, acessos e dados antes de comunicar a decisão, mapear tudo o que o sistema usa e conduzir uma transição por fases, com responsabilidades definidas. Este texto detalha esse roteiro: o que garantir antes de comunicar a decisão, como fazer o inventário técnico, como organizar a passagem de conhecimento e o período de transição, e o que colocar no novo contrato para que uma próxima troca, se um dia for necessária, seja simples.

O roteiro em sete passos

Para quem quer a resposta curta, a troca segura segue esta ordem:

1. Confirme que trocar é a decisão certa, e não uma renegociação de escopo ou de SLA.
2. Garanta código, acessos e dados antes de avisar o fornecedor atual.
3. Faça o inventário técnico de tudo o que o sistema usa e de onde ele roda.
4. Contrate a nova equipe com base nesse inventário, não numa demonstração.
5. Organize a passagem de conhecimento, com agenda e entregáveis definidos.
6. Defina um período de transição com responsabilidades claras, para ninguém achar que o incidente é do outro.
7. Feche o novo contrato com propriedade, acessos e cláusula de saída bem escritos.

As seções abaixo detalham cada etapa.

Quando a troca é a melhor decisão

Nem toda insatisfação pede uma troca. Às vezes o problema é um contrato de suporte mal desenhado, sem prioridades nem prazos de resposta, e o fornecedor entrega exatamente o que foi combinado, que é pouco. Nesse caso, revisar o SLA de suporte e sustentação pode resolver com menos risco do que mudar de equipe.

A troca costuma ser a melhor decisão quando aparecem sinais como estes:

• O fornecedor perdeu as pessoas que conheciam o sistema e quem ficou não consegue evoluir sem quebrar algo.
• Prazos e qualidade pioraram de forma consistente, não num episódio isolado. Se o problema é um projeto em andamento, veja antes o que fazer com um projeto de software atrasado.
• Falta transparência: você não sabe o que está sendo feito, não vê o código e não recebe relatórios.
• A tecnologia ou o modelo de trabalho não acompanham o negócio, por exemplo, a empresa precisa de integrações e de nuvem e o fornecedor só trabalha com servidor local.
• A relação comercial ficou desequilibrada: reajustes sem justificativa, cobrança por coisas que deveriam estar no contrato, dependência total de uma única pessoa.

Se dois ou três desses sinais se repetem há meses, o custo de continuar já está sendo pago. A pergunta deixa de ser "se" e passa a ser "como".

Antes de avisar: código, acessos e dados

Este é o ponto mais importante do texto. Não comunique a decisão antes de garantir o que é seu. Não por desconfiança, mas porque a relação muda no dia do aviso, e o que estava fácil de pedir pode ficar lento ou litigioso.

O que verificar no contrato atual

Releia o contrato procurando três coisas: quem é o dono do código-fonte, quais são as condições de término (aviso prévio, multa, obrigações de entrega) e se existe cláusula de transição. Se a cessão do código não está clara, vale entender o tema em propriedade do código-fonte no contrato e envolver o jurídico antes de qualquer movimento.

O que garantir na prática

Faça uma lista e confirme item por item que a empresa tem acesso próprio, com usuário em nome dela, e não apenas uma senha emprestada:

• Repositório de código: acesso de leitura, no mínimo, ao repositório oficial, com histórico completo. Uma cópia em zip enviada por e-mail não é suficiente: ela não traz o histórico de alterações e não garante que corresponde à versão que está em produção.
• Conta de nuvem ou servidor: quem é o titular da conta, em nome de quem estão as faturas, quem tem acesso de administrador.
• Banco de dados: um backup recente, testado, guardado num local da empresa.
• Domínios e DNS: o registro do domínio precisa estar em nome da empresa.
• Contas de serviços: e-mail transacional, gateway de pagamento, emissor de nota fiscal, lojas de aplicativos, certificados digitais.
• Credenciais de integrações: chaves de API com ERP, bancos, transportadoras, marketplaces.

Se algum desses itens está em nome do fornecedor, a transferência entra no plano de transição como prioridade. Contas de lojas de aplicativos e domínios, em especial, podem levar tempo para migrar de titular.

Inventário técnico do que existe

Com os acessos garantidos, é hora de entender o que existe de fato. O inventário serve a dois propósitos: dimensionar o trabalho da nova equipe e revelar riscos que ninguém mencionou.

Uma forma prática é montar uma tabela simples, preenchida em conjunto pela empresa e pela equipe técnica que vai assumir:

Um cenário comum: uma distribuidora troca de fornecedor e descobre, três semanas depois, que um script rodava toda madrugada para atualizar a tabela de preços vinda do ERP. Ninguém listou, porque "sempre funcionou". Com o inventário, esse tipo de surpresa aparece antes, não no balcão de vendas.

Se o sistema tem pouca ou nenhuma documentação, o inventário vira o primeiro diagnóstico. O caminho para isso está detalhado em como assumir um sistema legado sem documentação.

Passagem de conhecimento com o atual fornecedor

Mesmo com código e acessos em mãos, existe conhecimento que só está na cabeça de quem construiu o sistema: por que tal regra existe, qual cliente tem tratamento especial, qual integração é instável e como contornar. A passagem de conhecimento é a forma de transferir isso.

Como organizar

• Agenda definida: sessões curtas, por tema (financeiro, estoque, integrações, infraestrutura), com a nova equipe presente e fazendo perguntas.
• Gravação das sessões, com autorização dos participantes, para consulta posterior.
• Entregáveis combinados: diagrama da arquitetura, lista de rotinas agendadas, procedimento de publicação, problemas conhecidos.
• Uma publicação acompanhada: a nova equipe publica uma versão pequena em produção com o fornecedor atual observando. É o teste mais honesto de que a passagem funcionou.

Quando o fornecedor não colabora

Acontece. Se o contrato tem cláusula de transição, ela é o instrumento. Se não tem, a passagem pode ser contratada à parte, por horas ou escopo fechado, o que costuma sair mais barato do que a nova equipe descobrir tudo sozinha. E se não houver colaboração nenhuma, a nova equipe trabalha a partir do código, do banco e do comportamento do sistema em produção. É mais lento, mas é possível, desde que os acessos tenham sido garantidos antes.

Período de transição e responsabilidades

O momento mais arriscado de uma troca é o intervalo em que as duas equipes estão envolvidas e nenhuma se sente dona do problema. Um incidente na sexta-feira à noite não pode virar discussão sobre de quem é a vez.

Por isso, o período de transição precisa de datas e de uma divisão explícita:

A duração de cada fase depende do tamanho do sistema e do estado da documentação. Em sistemas de gestão de porte médio, costuma levar de algumas semanas a poucos meses, mas essa estimativa só se confirma depois do inventário.

Alguns cuidados para a operação não sentir:

• Evite trocar em período crítico: fechamento contábil, Black Friday, safra, virada de ano fiscal.
• Congele mudanças grandes durante a transição. Só correções e ajustes urgentes.
• Comunique os usuários-chave sobre quem atende os chamados em cada fase.
• Tenha um plano de retorno para a primeira publicação feita pela nova equipe.
• Revogue os acessos do fornecedor anterior no encerramento, de forma organizada, e troque as senhas e chaves compartilhadas.

O último item é frequentemente esquecido e é uma exigência básica de segurança. Se o fornecedor anterior tratava dados pessoais, vale também confirmar com o jurídico a devolução ou eliminação das cópias que ele mantinha, conforme o contrato e a LGPD.

Primeiros meses com a nova equipe

Uma nova equipe que chega prometendo reescrever tudo é sinal de alerta. Os primeiros meses devem ser de estabilização e de conhecimento, não de revolução.

O que esperar nesse período:

• Correções antes de novidades. A nova equipe resolve os problemas conhecidos e ganha confiança no código.
• Melhorias de base. Backup testado, monitoramento, processo de publicação automatizado e documentação mínima atualizada.
• Um diagnóstico honesto da dívida técnica, com prioridades em linguagem de negócio.
• Relatórios regulares do que foi feito, do que está em andamento e dos riscos encontrados.

Só depois disso faz sentido discutir evoluções maiores, como modernizar um módulo, trocar uma integração frágil ou migrar a infraestrutura. Decidir isso no primeiro mês, sem conhecer o sistema, é repetir o erro que levou à troca.

Contrato para que a próxima troca seja simples

A melhor hora de preparar a saída é na entrada. O contrato com a nova equipe deve deixar claro, desde o início:

• Propriedade: o código desenvolvido é cedido à empresa, e componentes preexistentes do fornecedor são listados e licenciados de forma perpétua.
• Titularidade: repositório, nuvem, domínios e contas de serviço em nome da empresa desde o primeiro dia.
• Documentação como entregável: arquitetura, procedimento de publicação, rotinas agendadas e integrações, atualizados a cada entrega relevante.
• Cláusula de transição: em caso de término, apoio à passagem de conhecimento por período e escopo definidos.
• Níveis de serviço claros para suporte e evolução, com relatórios periódicos.

Um checklist rápido para levar à negociação:

1. O repositório oficial está em nome da empresa?
2. A empresa é titular da conta de nuvem e recebe as faturas?
3. Há uma lista dos entregáveis de documentação e de quando são entregues?
4. O que acontece no término: prazo para devolver acessos, apoio à transição, eliminação de dados?
5. O fornecedor aceita que outra equipe trabalhe no mesmo código no futuro?

Se a resposta a alguma dessas perguntas for vaga, esclareça antes de assinar. Outros critérios para essa escolha estão reunidos na categoria contratação do blog.

Perguntas frequentes

O fornecedor de software pode se recusar a entregar o código-fonte?

Depende do contrato. Se o contrato cede o código-fonte à empresa, o fornecedor tem a obrigação de entregá-lo; se a cessão não está clara, a discussão fica mais difícil e vale envolver o jurídico. Por isso a recomendação é verificar a propriedade do código e garantir acesso próprio ao repositório antes de comunicar a decisão de trocar.

Quanto tempo leva a transição entre fornecedores de software?

Depende do tamanho do sistema e do estado da documentação. Em sistemas de gestão de porte médio, a transição entre fornecedores costuma levar de algumas semanas a poucos meses, passando por fases de sombra, operação assistida e operação plena. Essa estimativa só se confirma depois do inventário técnico de código, acessos, integrações e rotinas agendadas.

A nova equipe vai precisar reescrever o sistema?

Normalmente não, e uma nova equipe que chega prometendo reescrever tudo é sinal de alerta. Os primeiros meses devem ser de estabilização: correção de problemas conhecidos, backup testado, monitoramento e documentação. Só depois de conhecer bem o sistema faz sentido discutir evoluções maiores, como modernizar um módulo ou trocar uma integração frágil.

Como evitar ficar refém de um fornecedor de software?

A forma mais segura é deixar tudo em nome da empresa desde o primeiro dia: repositório de código, conta de nuvem, domínios e contas de serviço. O contrato deve garantir a cessão do código, documentação atualizada como entregável e uma cláusula de transição, para que outra equipe consiga assumir o sistema se um dia for preciso.

Como a Pervian Tech trabalha transições

Quando assumimos um sistema que veio de outro fornecedor, começamos pelo inventário: acessos, código, infraestrutura, integrações e rotinas agendadas, antes de qualquer promessa de prazo. Em seguida, montamos com a empresa o plano de transição por fases, com responsabilidades claras e um período de estabilização antes de evoluções maiores. Desde o primeiro dia, repositório, nuvem e domínios ficam em nome do cliente, e a documentação faz parte da entrega. É assim que trabalhamos em arquitetura de software: para que a empresa nunca fique refém de uma pessoa ou de um fornecedor, inclusive de nós.

Cada transição é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se você está pensando em trocar de fornecedor e quer entender os riscos antes de decidir, fale com a gente.