Blog · Projetos

Handover de sistema: 9 itens que o fornecedor deve entregar

Por Marco Silva · 19 de setembro de 2026 · 9 min de leitura

O sistema ficou pronto, a equipe já está usando, a última parcela foi paga. Na cabeça de quase todo mundo, o projeto acabou ali.

Ele acaba de verdade um ou dois anos depois, no dia em que você precisa de uma mudança e o fornecedor não responde mais. É nesse dia que a pergunta aparece: onde está o código? Quem tem a senha do servidor? Alguém escreveu como isso funciona?

Quando a resposta para as três é "não sei", o sistema continua rodando, mas parou de ser seu. Este artigo é a lista do que impede isso, e ela precisa estar no contrato antes de existir a primeira tela.

O que é handover de sistema

Handover de sistema é a transferência formal da responsabilidade sobre um software pronto, do fornecedor que construiu para a empresa que contratou. Não é a reunião de apresentação das telas. É o momento em que muda de mãos tudo o que permite operar, corrigir e evoluir aquele sistema sem depender de quem o fez.

A diferença entre mostrar e entregar cabe em uma frase: demonstração prova que o sistema funciona na máquina do fornecedor; handover prova que ele funciona sem o fornecedor.

Handover e handoff não são a mesma coisa

Handoff é a passagem de bastão dentro do fluxo de trabalho — do design para o desenvolvimento, de um analista para outro — e acontece dezenas de vezes ao longo de um projeto. Handover é a transferência final de responsabilidade sobre o resultado, acontece uma vez e tem documento assinado. Confundir os dois é o que faz alguém achar que recebeu um sistema quando recebeu só um treinamento.

Vale a escala do que está em jogo. Segundo a segunda etapa do Estudo Mercado Brasileiro de Software — Panorama e Tendências 2026, da ABES com dados da IDC, divulgada em 15 de junho de 2026, as empresas brasileiras investiram US$ 35,4 bilhões em software e serviços em 2025. É muito dinheiro trocando de mãos em um mercado onde a lista de entregáveis raramente aparece por escrito no contrato.

Os 9 itens do handover de um sistema sob medida

Esta é a lista que eu entrego e a que eu recomendo exigir de qualquer fornecedor. A terceira coluna é o que importa: cada item tem um jeito de conferir que não depende da palavra de ninguém.

O item 8 é o mais pulado dos nove. Fornecedor sério não diz que faz backup: ele restaura o backup na sua frente, uma vez, e anota a data. Backup que nunca foi restaurado é uma hipótese, não uma proteção.

O teste que prova que o handover aconteceu

Existe um único teste que vale por todos os outros, e ele cabe em uma tarde.

Pegue o pacote entregue e peça a um desenvolvedor que nunca participou do projeto para subir o sistema em uma máquina limpa, sem falar com o fornecedor. Se ele conseguir, o handover aconteceu. Se ele precisar de uma ligação, o handover não aconteceu — faltou documentação, faltou senha, ou existe uma configuração que só mora na cabeça de alguém.

Esse teste custa poucas horas de um profissional de fora e é a coisa mais barata que existe antes de assinar o aceite. Depois do aceite, ele vira uma negociação. É o mesmo raciocínio que eu aplico na hora de escrever o que vai ser construído: se não dá para verificar, não dá para cobrar. Tratei desse ponto em escopo de software: como fazer o seu em 1 página.

Termo de aceite e documento de entrega de software

O termo de aceite é o documento que encerra o projeto e abre a garantia. Ele não precisa ser longo. Precisa ter cinco coisas:

1. A lista do que está sendo entregue, item por item, com os oito entregáveis anexados ou referenciados por onde estão.
2. A data da entrega, que é o marco de início de qualquer prazo de garantia.
3. O que está fora do escopo, escrito de forma explícita, para não virar discussão depois.
4. O prazo e a abrangência da garantia: o que é defeito (coberto) e o que é mudança nova (orçada à parte).
5. As duas assinaturas, porque documento assinado por um lado só é comunicado, não é acordo.

A quarta linha é a que evita quase todo o atrito do trimestre seguinte. Defeito é o sistema não fazer o que foi combinado que ele faria. Mudança é você querer que ele passe a fazer outra coisa. A fronteira entre as duas precisa estar escrita antes de alguém precisar dela.

O que a lei já garante e o que só o contrato garante

Boa parte do medo em torno de entrega de software vem de não saber o que a lei brasileira já resolve sozinha. Ela resolve menos do que se imagina, e o que ela resolve vem com uma ressalva importante.

Sobre a titularidade, o artigo 4º da Lei 9.609/1998, a Lei do Software, diz que os direitos sobre um programa desenvolvido durante contrato de prestação de serviços pertencem exclusivamente ao contratante. A ressalva está nas três primeiras palavras do artigo: "salvo estipulação em contrário". Uma cláusula no contrato do fornecedor inverte a regra inteira, e é exatamente o que muitos contratos fazem. Escrevi em detalhe sobre isso em propriedade do código no software sob medida.

A mesma lei, nos artigos 7º e 8º, obriga quem comercializa um programa a informar o prazo de validade técnica da versão e a assegurar, durante esse prazo, os serviços técnicos complementares para o adequado funcionamento. É pouco para um sistema sob medida, mas é um piso que costuma ser ignorado.

Sobre garantia, o artigo 26 do Código de Defesa do Consumidor fixa 90 dias para reclamar de vício aparente em serviço durável, contados do término da execução do serviço (inciso II e parágrafo 1º). Duas observações honestas: entre duas empresas nem sempre existe relação de consumo, então o CDC pode não se aplicar ao seu caso; e o prazo só começa a correr a partir de uma data — que é, de novo, a data do aceite. Nos meus contratos a garantia de 90 dias está escrita, justamente para não depender dessa discussão.

E há um item que quase nunca entra na conversa de entrega: o destino dos dados. Pela LGPD, artigo 16, dados pessoais devem ser eliminados após o término do tratamento, salvo as hipóteses de conservação previstas na própria lei. Na prática do handover isso significa uma linha no termo: o fornecedor declara que apagou as cópias da base que mantinha em máquinas e ambientes dele. O detalhamento do que a lei cobra de um sistema interno está em LGPD em sistema interno.

Como exigir isso antes de o projeto começar

Nenhum dos nove itens é difícil de produzir. Todos são difíceis de cobrar depois. A ordem prática:

• Na proposta, peça a lista de entregáveis do handover por escrito. Fornecedor que entrega tudo isso não tem motivo para não listar.
• No contrato, transforme a lista em condição de aceite, e o aceite em condição da última parcela. É o que dá força ao pedido.
• Nas contas, exija que hospedagem, domínio e serviços externos nasçam no CNPJ da sua empresa, desde o primeiro dia. Migrar conta depois é o item que mais trava troca de fornecedor.
• A cada etapa entregue, receba o pedaço correspondente da documentação, em vez de deixar tudo para o fim. Documentação feita no último dia é documentação escrita de memória.

Esse quarto ponto é a vantagem prática de entregar por módulos em vez de entregar o sistema inteiro de uma vez: o handover acontece em pedaços verificáveis, e não como um pacote gigante no último dia. Descrevi esse formato em MVP de sistema interno: 1 módulo em 3 a 5 semanas.

Quanto custa um projeto com handover completo

Handover não é serviço extra nem linha separada de orçamento. É parte do que você está comprando. Se um fornecedor cobra à parte para entregar o código e a documentação do que você pagou para construir, isso não é preço: é pedágio.

O pagamento é 30% na assinatura e o restante por etapa entregue e aprovada. Atendo um projeto por vez, e a stack é deliberadamente comum — React, Node, PostgreSQL e Docker — justamente para que o handover signifique alguma coisa. Código escrito em tecnologia rara é refém disfarçado de sofisticação. Os outros pontos a checar antes de assinar estão em contratar software sob medida: 8 cuidados antes de assinar.

Perguntas frequentes