A reunião mensal com o fornecedor virou um ritual desconfortável. O chamado crítico aberto há três semanas continua sem solução, o prazo prometido mudou pela terceira vez e, quando alguém pergunta pelo andamento do backlog, a resposta vem em jargão técnico que ninguém na sala consegue verificar. O gestor encerra a chamada com a sensação de sempre: a de ser refém do próprio sistema.
A vontade de trocar existe há meses. O que trava a decisão é o medo. E se o fornecedor atual dificultar a saída? E se ninguém mais entender o sistema? E se a operação parar no meio do caminho? O receio é legítimo, mas nasce de um enquadramento errado: tratar a troca como rompimento, quando ela deveria ser tratada como projeto.
Essa é a tese deste artigo: trocar de fornecedor de software é projeto, não evento. Tem fases, responsáveis, critérios de conclusão e plano de contingência. Quem conduz assim troca sem parar a empresa. Quem trata como briga de rescisão costuma pagar duas vezes: na saída malfeita de um e na chegada atropelada do outro.
O que é a transição de fornecedor de software?
Transição de fornecedor de software é o processo planejado de transferir a responsabilidade técnica por um sistema de uma prestadora para outra sem interromper a operação da empresa. Na prática, envolve reunir os ativos do sistema, como código-fonte, acessos, documentação e contrato, auditar o que será herdado e conduzir um período de convivência em que o novo fornecedor assume gradualmente enquanto o antigo ainda responde por dúvidas e pendências.
O ponto central da definição é a palavra planejado. A diferença entre uma troca tranquila e um desastre raramente está no fornecedor novo: está no que a empresa preparou antes de comunicar a saída ao antigo.
Quais sinais mostram que a relação com o fornecedor esgotou?
Problema pontual se resolve com conversa. O que justifica a troca é padrão repetido. Os quatro sinais mais confiáveis:
- SLA descumprido de forma reiterada. Um atraso é incidente, atraso todo mês é comportamento. Se você acompanha SLA e indicadores do fornecedor de TI e os números pioram trimestre após trimestre mesmo depois de conversas formais, o recado está dado.
- Dependência sem transparência. Ninguém na empresa sabe onde o sistema está hospedado, o que foi entregue no último ano nem como as horas cobradas foram usadas. Fornecedor saudável explica, fornecedor problemático mistifica.
- Medo de perguntar. Quando o time evita questionar um orçamento com receio de azedar a relação ou de sofrer retaliação no suporte, a relação já azedou. Parceria não convive com medo.
- Toda mudança pequena vira orçamento grande. Ajuste simples custando caro e demorando semanas indica código mal cuidado, desinteresse comercial ou os dois. Para a decisão de trocar, o sintoma importa mais do que a causa.
Um sinal isolado pede conversa franca com prazo para correção. Três deles juntos pedem plano de saída, mesmo que a decisão final ainda demore. E registre os episódios por escrito, com datas, chamados e promessas: esse histórico organiza a conversa de saída e protege a empresa em uma eventual disputa contratual.
O que reunir antes de sinalizar a troca?
A regra de ouro da transição: primeiro as chaves, depois a conversa. Antes de qualquer sinalização ao fornecedor atual, confirme que a empresa tem em mãos:
- Código-fonte acessível. Acesso próprio ao repositório onde o código vive, testado por alguém de confiança, e não apenas prometido em contrato. Já detalhamos o que sua empresa deve ter em mãos de código-fonte e documentação; esse kit é a base de qualquer transição.
- Acessos e credenciais em nome da empresa. Domínio, hospedagem, banco de dados, serviços de terceiros e certificados precisam estar em contas da empresa, não em contas pessoais do fornecedor. Cada acesso no nome errado é um ponto de dependência a corrigir.
- Documentação existente. Manuais, diagramas, histórico de chamados, atas de reunião. Não precisa ser perfeita: o novo fornecedor trabalha muito melhor com material incompleto do que com nada.
- Contrato relido com atenção. Propriedade intelectual do código, condições de saída, obrigação de transição assistida. As cláusulas que protegem em um contrato de desenvolvimento de software valem ouro exatamente neste momento.
Se algo estiver faltando, regularize enquanto a relação segue formalmente normal. Sinalizar a saída sem ter as chaves inverte a mesa de negociação: quem deveria prestar contas passa a ditar condições.
Como funciona a auditoria de herança pelo novo fornecedor?
Antes de assumir, o fornecedor novo precisa examinar o que vai herdar. Essa auditoria olha código, infraestrutura, integrações e pendências, e produz um diagnóstico em três colunas: o que dá para assumir como está, o que precisa ser estabilizado logo e o que merece reconstrução no médio prazo. Sem esse exame, qualquer promessa de prazo e de preço é palpite. O resultado da auditoria vira anexo do acordo com o novo fornecedor, com prioridades e prazos combinados em cima de fatos, não de suposições.
A auditoria também protege a sua empresa de expectativas irreais. Sistemas herdados quase sempre carregam dívidas acumuladas, e é muito melhor conhecê-las no primeiro mês do que descobri-las em produção, na frente do cliente. Desconfie de quem promete assumir tudo em uma semana sem ter olhado uma linha de código.
Vale lembrar que a escolha do novo parceiro merece o mesmo rigor da primeira contratação, ou até mais. Nosso checklist para contratar uma software house ajuda a filtrar candidatos, com atenção extra para experiência comprovada em assumir sistemas de terceiros.
Como fazer a virada sem parar a operação?
Existem dois cenários. Na transição assistida, o fornecedor atual participa da passagem: reuniões de repasse, respostas a dúvidas, acompanhamento por um período definido, muitas vezes remunerado por isso. É o cenário ideal e vale negociá-lo com elegância. Na transição abrupta, a relação rompeu e o antigo não colabora. É pior, mas administrável quando a empresa reuniu os ativos antes: com código, acessos e documentação em mãos, o novo fornecedor reconstrói o entendimento estudando o próprio sistema.
Nos dois cenários, o instrumento mais valioso é o período de sombra: um intervalo em que o novo fornecedor já opera, atendendo chamados e fazendo entregas supervisionadas, enquanto o antigo ainda responde por emergências. Como estimativa, sistemas de médio porte costumam pedir de 30 a 90 dias de convivência; o número certo sai da auditoria, não de regra de bolso.
Um cuidado extra que evita dor de cabeça: congele novas funcionalidades durante a janela de virada. Transição é momento de estabilidade, não de evolução. Cada mudança feita no meio do repasse aumenta a chance de retrabalho e confunde a atribuição de responsabilidade quando algo quebra. Combine com as áreas internas uma fila de pedidos que será retomada, com prioridade, assim que o novo fornecedor assumir por completo.
Complete o plano com dois cuidados. Primeiro, comunicação interna clara: o time precisa saber quem acionar para cada assunto durante a convivência, com canal único de chamados para evitar ruído. Segundo, um critério objetivo de encerramento: o antigo só é desligado depois que o novo completou ao menos um ciclo inteiro de operação, incluindo um fechamento de mês e uma correção urgente resolvida de ponta a ponta.
Troca de fornecedor bem conduzida é projeto com começo, meio e fim
O medo que adia a troca por anos costuma custar mais caro do que a própria troca: cada mês de relação esgotada significa SLA descumprido, evolução parada e dependência crescendo. Com os ativos reunidos, a auditoria de herança feita e o período de sombra combinado, a virada deixa de ser salto no escuro e vira cronograma administrável. O roteiro vale para sistemas sob medida, sites e integrações: muda o tamanho do projeto, não a lógica.
A DevCore assume sistemas herdados com esse método: auditoria técnica, plano de transição e convivência supervisionada até a operação estabilizar. Para quem prefere internalizar o ritmo de evolução depois da virada, também alocamos uma equipe de desenvolvimento dedicada (squad as a service) que assume o sistema no dia a dia. Se a sua relação atual já deu os sinais deste artigo, converse com o nosso time antes de sinalizar qualquer coisa ao fornecedor de hoje.
Perguntas frequentes sobre troca de fornecedor de software
Quanto tempo leva uma troca de fornecedor de software?
Depende do tamanho do sistema, da qualidade da documentação e da colaboração do fornecedor atual. Entre a auditoria de herança e o fim do período de sombra, o intervalo costuma ficar entre algumas semanas e poucos meses. O prazo confiável sai da auditoria, nunca de promessa comercial feita antes de olhar o sistema.
E se o fornecedor atual se recusar a entregar o código-fonte?
Releia o contrato, formalize o pedido por escrito e busque orientação jurídica: a cláusula de propriedade intelectual é o seu principal argumento. Em paralelo, um novo fornecedor pode mapear o sistema pelo que está em produção e preparar alternativas. A recusa, por si só, confirma que a decisão de trocar estava certa.
Devo avisar o fornecedor atual antes de contratar o novo?
Não. É legítimo e prudente contratar a auditoria e o planejamento da transição de forma reservada. Comunique a saída quando tiver acessos confirmados, contrato relido e plano de convivência pronto. A ordem dos passos é o que protege a empresa.