Contrato de sustentação Magento: o que precisa estar escrito

Quando uma empresa troca de agência Magento, a justificativa formal quase sempre é preço ou insatisfação com prazo. Quando a conversa é honesta, a razão real costuma ser outra: o cliente não sabia o que estava acontecendo. Pagava todo mês, recebia entregas, e ainda assim não conseguia explicar internamente o que estava sendo comprado.

Boa parte disso se resolve no papel, antes de começar. Um contrato de sustentação Magento bem escrito não é proteção jurídica para o dia da briga. É o documento que define comportamento, e comportamento é o que separa parceiro de fornecedor de ticket.

Principais pontos do artigo

• Sustentação e evolução são escopos diferentes e precisam estar separados no contrato.
• SLA sem definição de severidade é número sem significado.
• O prazo de aplicação de patch precisa ser contado do boletim, não da abertura do chamado.
• Banco de horas mede volume, não resultado, e cria incentivo contra a proatividade.
• Plano de saída no contrato é sinal de confiança, não de desconfiança.

Os oito itens que precisam estar escritos

1. A fronteira entre sustentação e evolução. Sustentação é manter funcionando: correção, patch, monitoramento, ajuste. Evolução é construir novo: funcionalidade, integração, mudança de regra. Quando essa fronteira não está escrita, toda solicitação vira negociação, e a relação passa a ter atrito em cada pedido. Vale escrever com exemplos concretos, não com definição abstrata.

2. Severidade antes de SLA. Prometer resposta em quatro horas não significa nada sem definir o que é severidade 1. A escala precisa ser objetiva e ancorada em impacto de negócio: loja fora do ar, checkout inoperante, integração de pedido parada, falha estética. E precisa separar tempo de resposta de tempo de solução, que são coisas diferentes e frequentemente confundidas na mesma linha.

3. Prazo de patch contado da publicação do boletim. Este item mudou de importância em 2026. Com a cadência mensal de correções de segurança, o contrato precisa dizer em quantos dias, contados da publicação do boletim pelo fornecedor, a correção estará aplicada ou terá decisão registrada de adiamento. Contar do chamado não funciona, porque nesse desenho a descoberta depende do cliente, e o cliente não acompanha boletim de segurança.

4. Ambiente de homologação: existência e responsabilidade. Quem mantém, com que frequência os dados são atualizados a partir de produção, e o que obrigatoriamente passa por ele antes de subir. Sem isso, o ambiente existe no primeiro mês e apodrece no terceiro.

5. Propriedade do código e acesso ao repositório. O código customizado é da empresa contratante, e o acesso ao repositório é dela desde o primeiro dia, não no dia da rescisão. Contrato que não trata disso com clareza cria dependência artificial, e dependência artificial é a forma mais frágil de retenção que existe.

6. Backup, retenção e teste de restauração. Frequência, tempo de retenção, onde fica armazenado e, o item mais esquecido, com que periodicidade a restauração é efetivamente testada. Backup não testado é uma suposição, não um controle.

7. Cadência de comunicação proativa. Não é um item usual em contrato de sustentação, e deveria ser. Com que frequência o cliente recebe contato sem ter aberto chamado, e o que esse contato precisa conter. É o item que transforma trabalho invisível em valor percebido.

8. Plano de saída. Prazo de aviso, transferência de conhecimento, entrega de documentação e acessos, período de acompanhamento. Escrever isso no início parece contraintuitivo. Na prática, é o item que mais demonstra confiança, porque só evita escrever quem depende da dificuldade de sair.

O problema do banco de horas

O modelo mais comum de sustentação no mercado brasileiro é o banco de horas. Ele tem virtudes reais: é simples de entender, fácil de aprovar internamente e dá previsibilidade de custo.

Também cria um incentivo que trabalha contra a relação. Quando a unidade de medida é hora consumida, o trabalho que evita problema fica em desvantagem contra o trabalho que resolve problema. Uma revisão de índice que impede uma lentidão futura consome horas e não tem sintoma associado. Uma correção de emergência consome horas e é visível. Nos dois casos o cliente vê o mesmo número no relatório, mas apenas um deles ele consegue explicar para a diretoria.

O resultado é conhecido: o banco de horas tende a ser gasto em demanda reativa, e a manutenção preventiva vai ficando para o mês seguinte. Não porque alguém decidiu assim, mas porque o formato do relatório favorece isso.

Não estamos dizendo que banco de horas é errado. Estamos dizendo que ele precisa vir acompanhado de escopo mínimo garantido, ou seja, um conjunto de atividades preventivas que acontecem independentemente do consumo do mês: aplicação de patch, monitoramento, revisão de desempenho, atualização de dependência. Sem essa reserva escrita, o preventivo é a primeira coisa a ser sacrificada quando o mês aperta.

O que a comunicação proativa precisa conter

O item 7 merece detalhamento porque é o menos padronizado e, na nossa leitura, o mais determinante para a percepção de valor. O contato proativo funciona quando segue três blocos.

O que foi feito. Incluindo o que o cliente não pediu. O patch aplicado, o índice ajustado, a dependência atualizada. Trabalho não comunicado é, do ponto de vista do cliente, trabalho não realizado.

O que foi observado. O sinal que ainda não é problema. O tempo de resposta que subiu, o catálogo que cresceu, a fila que ficou mais lenta. Isso demonstra observação contínua, que é diferente de disponibilidade para atender.

O que sugerimos. Uma recomendação olhando para frente, com prazo. É o bloco que distingue parceiro de executor, e é o que costuma faltar.

Escrever essa cadência no contrato tem um efeito adicional: ela deixa de depender da iniciativa individual de quem está gerenciando a conta naquele momento. Vira obrigação institucional, que é o que a torna sustentável quando alguém sai de férias ou muda de time.

Contrato não é documento de arquivo

Um último item, que não é cláusula e sim prática: contrato de sustentação precisa de revisão programada. O desenho que fazia sentido quando a loja tinha metade do catálogo atual, um terço do tráfego e duas integrações a menos deixou de descrever a operação real em algum momento, e ninguém marcou esse momento.

Uma revisão anual, com pauta objetiva, resolve. Vale conferir se a escala de severidade ainda corresponde ao que hoje é crítico no negócio, se o escopo mínimo garantido acompanha o crescimento do ambiente, se o volume contratado bate com o consumo real dos últimos doze meses e se surgiram exigências novas, de conformidade ou de auditoria, que precisam estar refletidas.

O sintoma de que essa revisão está atrasada é conhecido: discussões recorrentes sobre se determinada demanda está ou não incluída. Quando isso acontece mais de duas ou três vezes em um trimestre, o problema não é a demanda, é o contrato descrevendo uma operação que não existe mais.

Como a Trezo trata esse cenário

A Trezo trabalha exclusivamente com Magento há mais de 16 anos, em operações de médio e grande porte nos setores de eletrônicos, beleza, farma, alimentos, agronegócio e autopeças. Somos parceiros AWS Partner Network e certificados ISO 27001, o que significa que infraestrutura e tratamento de dados seguem processo auditado, não improviso.

Se essa conversa está em aberto na sua operação e você ainda não tem um diagnóstico escrito para levar à diretoria, vale meia hora. Fale com nossos especialistas.

Perguntas frequentes