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

> Vai trocar de fornecedor de software? Veja como garantir código, acessos e dados antes do aviso, organizar a transição e manter a operação rodando.

Fonte: https://pervian.tech/blog/trocar-de-fornecedor-de-software · Pervian Tech · publicado em 2026-10-01

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](https://pervian.tech/blog/sla-de-suporte-e-sustentacao-de-software) 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](https://pervian.tech/blog/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](https://pervian.tech/blog/propriedade-do-codigo-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:

| Item | O que levantar | Por que importa |
|---|---|---|
| Sistemas e módulos | Lista de aplicações, telas principais, quem usa | Define o escopo da passagem |
| Infraestrutura | Onde roda, servidores, versões, backups | Mostra riscos de disponibilidade |
| Integrações | Com quem conversa, de que forma, com que frequência | Integrações são o que mais quebra na troca |
| Rotinas agendadas | Tarefas noturnas, importações, envios automáticos | Costumam ser esquecidas e param em silêncio |
| Dependências | Bibliotecas, versões de linguagem, licenças | Revela dívida técnica e risco de segurança |
| Documentação | O que existe, onde está, se está atualizada | Define o esforço de passagem |
| Processo de publicação | Como uma versão chega à produção | Sem isso, ninguém consegue corrigir nada |

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](https://pervian.tech/blog/assumir-sistema-legado-sem-documentacao).

## 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:

| Fase | Quem opera | Quem acompanha | Marco de saída |
|---|---|---|---|
| Sombra | Fornecedor atual | Nova equipe observa e documenta | Inventário completo e acessos validados |
| Operação assistida | Nova equipe | Fornecedor atual dá apoio | Primeira publicação feita pela nova equipe |
| Operação plena | Nova equipe | Gestor da empresa, por relatórios | Encerramento formal do contrato anterior |

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](https://pervian.tech/blog/senhas-e-chaves-de-api-no-codigo).

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](https://pervian.tech/blog/reescrever-ou-refatorar-sistema-legado) é 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](https://pervian.tech/blog/documentacao-de-software-minima) 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](https://pervian.tech/blog/modernizacao-gradual-de-sistemas), 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](https://pervian.tech/blog/categoria/contratacao) 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](https://pervian.tech/servicos/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](https://pervian.tech/#contato).