Suporte para Sana 9.3, depois que a Sana parou.

A Sana encerrou o suporte do 9.3.0 ao 9.3.4 no fechamento de 2024, e do 9.3.5 no fechamento de 2025. As duas datas ficaram para trás, e os acordos de suporte estendido que cobriam a lacuna se esgotaram.

Nada disso desliga coisa alguma. Nenhuma licença expira, nenhum interruptor é acionado, e a loja que você tinha semana passada é a loja que você tem hoje. Muitas lojas Sana 9 continuam faturando bem e vão continuar por anos.

O que acabou é a rede de segurança por trás da loja: correções de segurança, correções de bugs da plataforma, um caminho de escalonamento, e aquele trabalho silencioso de compatibilidade que manteve viva uma integração de cinco anos com o ERP enquanto navegadores, provedores de pagamento e o próprio ERP se moviam por baixo.

Ficar é uma decisão legítima. Só é legítima se alguém substituir essa rede de segurança. Rodar depois do fim de vida sem ninguém nesse papel não é bem uma decisão, é uma aposta de que nada vai acontecer. Você ganha essa aposta na maioria dos meses. No mês em que perde, perde dentro do seu fluxo de pedidos e sem fornecedor para acionar.

A maior parte do que é reportado como “um problema do Sana” acaba não sendo. É a stack de baixo, uma customização, uma mudança no ERP, ou algo totalmente fora de casa. Separar isso rápido é boa parte do trabalho, e é justamente a parte difícil de fazer sem ter vivido dentro do código.

Quando é mesmo a plataforma, o trabalho corre em camadas:

• Conter onde controlamos o tráfego. Regras de firewall, política de borda e de proxy reverso, cabeçalhos, configuração da aplicação, e desligar superfície que você não usa. Uma parcela surpreendente do risco de plataforma se fecha aqui sem tocar na aplicação.
• Corrigir tudo aquilo sobre o que a plataforma se apoia. Numa instalação 9.3 típica isso é a grande maioria da superfície exposta, e a Microsoft ainda dá suporte a quase tudo.
• Ficar sabendo primeiro. Monitorar os avisos da plataforma e das dependências, para que um problema chegue até você por nós e não por um cliente ou um auditor.
• Dizer quais são as opções reais. Inclusive os casos em que a resposta honesta é que adiar a mudança virou a escolha cara.

Esse último ponto é o que gostaríamos de ler se fôssemos nós comprando. Um fornecedor de manutenção cujo interesse comercial é você nunca sair tem um incentivo óbvio para não levantar o assunto, e preferimos ser quem fala cedo.

“Estamos numa plataforma sem suporte” normalmente é tratado como um problema único e indivisível. Não é. Uma instalação do Sana 9.3 é uma aplicação ASP.NET MVC sobre .NET Framework, servida por IIS em pipeline clássico, sobre Windows Server. O Sana é um componente dessa stack. A Microsoft ainda dá suporte à maior parte do resto.

Na prática, é aqui que encontramos o risco real e corrigível numa loja 9.3 negligenciada:

• A versão do .NET Framework. Instalações do Sana 9 costumam estar no .NET Framework 4.6.x, que a Microsoft parou de suportar em abril de 2022. Migrar para 4.8 costuma ser simples, continua com suporte completo e fecha uma lacuna real. Também é invisível até alguém auditar você.
• O sistema operacional. O Windows Server 2012 R2 saiu de suporte em outubro de 2023. Um número relevante de lojas B2B antigas ainda está nele.
• Configuração de TLS e cifras. Versões de protocolo e conjuntos de cifras antigos que ficaram habilitados desde uma instalação de 2019, que reprovam em scans modernos e cada vez mais quebram integrações de pagamento.
• Dependências ao redor da aplicação. Bibliotecas dentro das suas próprias customizações, que são suas para atualizar e ninguém atualizou.

O reenquadramento útil: uma loja Sana 9.3 sem manutenção não é uma única coisa sem suporte. É um componente sem suporte apoiado sobre uma stack que costuma estar vários anos atrasada em correções que ninguém estava impedido de aplicar. Fechar isso é a maior parte do risco, e é trabalho que pode começar imediatamente.

A coisa de maior alavancagem que dá para fazer por uma loja numa plataforma congelada é parar de pedir que a aplicação se defenda sozinha. Coloque uma borda moderna na frente e boa parte do modelo de ameaças nunca chega ao seu código.

• Web application firewall. Conjuntos de regras gerenciados que absorvem o escaneamento genérico e o tráfego de injeção que toda loja pública recebe o tempo todo, mantidos por outra pessoa, na frente de uma aplicação que não é mais atualizada.
• Controle de bots e abuso. Credential stuffing contra os logins B2B, scraping de preços específicos por cliente e sondagem do checkout são os três que realmente importam em B2B. Todos são baratos de mitigar na borda e caros de tratar dentro de uma aplicação antiga.
• Rate limiting nos caminhos caros. Busca, consultas de preço e qualquer coisa que chegue até o ERP. Isso protege o ERP tanto quanto a loja, ou mais.
• TLS atual independentemente da origem. Terminar protocolos e cifras modernos na borda faz com que um scan de segurança ou um provedor de pagamento veja uma configuração atual mesmo enquanto a origem está sendo atualizada.
• Cache e disponibilidade. Servir conteúdo estático e semiestático a partir da borda tira carga de uma origem que você preferiria não ter que escalar, e mantém algo na tela durante um incidente.

Nada disso exige tocar no Sana. É a melhoria de segurança relevante mais barata disponível para uma loja 9.3, e normalmente é entregue em dias e não em meses.

Seus compradores não fazem ideia de qual versão você usa. Eles sabem se o site parece atual, se funciona no celular deles e se conseguem achar a peça que precisam. Uma loja com tema de 2019 costuma perder nas três, e nenhuma delas é limitação de plataforma.

Esse é o nosso ofício de verdade. Trabalhando dentro do modelo de theming suportado pela Sana, e não contornando ele, uma loja 9.3 ainda pode ter:

• Uma renovação visual. Tipografia, espaçamento, cor e imagens atualizados sem mudar uma única regra de negócio.
• Mobile realmente usável. Muitas lojas Sana 9 são tecnicamente responsivas e na prática sofríveis no celular, o que pesa mais a cada ano conforme os compradores refazem pedidos do chão do armazém e não de uma mesa.
• Páginas mais rápidas. Formatos de imagem, disciplina de peso e cache costumam dar um ganho medido maior do que se espera de uma stack antiga.
• Trabalho de acessibilidade. Marcação semântica, contraste, navegação por teclado e rotulagem. Virou requisito de compras em partes do B2B e é um motivo comum para ser desqualificado em silêncio, sem nunca saber por quê.
• Correções de conversão nos caminhos que faturam. Busca, página de produto, recompra e checkout.

Há um argumento estratégico para fazer isso agora em vez de guardar para a reconstrução: o trabalho de design e conteúdo é exatamente a parte que se aproveita. Estrutura, requisitos e um design system migram para uma plataforma nova com muito mais facilidade do que o código.

Algo mudou nos últimos dois anos e a maioria das lojas B2B não reagiu. Uma parcela real da pesquisa do comprador agora acontece dentro de um assistente e não numa página de resultados, e o que torna um catálogo legível para um assistente não é o que fazia ele ranquear em 2019.

A parte útil é que isso é sobretudo um problema de conteúdo e marcação, então uma loja 9.3 pode ficar totalmente em dia sem replataformar:

• Dados estruturados em todo o catálogo. Produto, oferta, preço, disponibilidade e identificadores renderizados no servidor. Isso alimenta resultados ricos e comparadores, e cada vez mais é o que um assistente lê ao decidir se consegue responder uma pergunta sobre o seu produto.
• Conteúdo de produto que dá para ler mesmo. Especificações como marcação real e não como imagem de uma tabela, para que um crawler e um modelo consigam interpretar.
• Resumos explícitos e legíveis por máquina. Uma declaração simples de quem você é, o que vende e para quem, num formato que assistentes consomem direto.
• O básico técnico que se degrada em silêncio. Canônicos, sitemaps e redirecionamentos que estavam certos no lançamento e foram se desviando ao longo de anos de mudanças de catálogo, mais o orçamento de rastreio gasto em URLs de facetas que ninguém quer indexadas.
• Uma política de crawlers de IA escolhida por você. Decidir de propósito quais assistentes podem ler seu catálogo, em vez de deixar num padrão que ninguém configurou.

Ser citado por um assistente depende muito mais de clareza e boa estrutura do que de autoridade de domínio, o que faz disso um dos poucos canais em que um distribuidor médio consegue superar um concorrente bem maior. E é trabalho que sobrevive intacto a uma replataforma.

Não auditamos uma. Não implementamos uma e seguimos em frente. Operamos uma loja Sana 9 profundamente customizada, com integração real ao ERP, continuamente, por anos: com os escalonamentos de plataforma, as surpresas de integração, o trabalho de performance e as falhas de uma terça-feira comum que nunca entram num case.

Isso importa mais aqui do que num projeto novo. Manutenção é um negócio de reconhecer coisas. Saber que um sintoma específico significa que o ERP mudou o tamanho de um campo, ou que uma falha no checkout é um provedor de pagamento trocando um requisito e não o seu código quebrando, não é algo que se leia na documentação.

A ProjectThunder é uma agência web certificada pela Sana, não um VAR de ERP. Construímos comércio desde 2004. Se você também tem um parceiro de ERP, trabalhamos ao lado dele e não no lugar dele.

Ninguém consegue orçar manutenção de uma loja que não olhou, e qualquer fornecedor que o faça está adivinhando suas customizações. Começamos estabelecendo quatro coisas:

1. Exatamente em qual release você está. Do 9.3.0 ao 9.3.4 o fim de vida chegou um ano inteiro antes do 9.3.5, e isso muda a urgência.
2. O que foi customizado, e por quê. Um inventário de add-ons, módulos, sobrescritas de view e trabalho de front-end, incluindo as regras de negócio enterradas neles que ninguém escreveu.
3. O estado da stack. Sistema operacional, versão do .NET Framework, configuração de IIS e TLS, tratamento de certificados, e o quanto cada um está atrasado.
4. A saúde da integração com o ERP. Os seis contratos dos quais a loja depende, e se algo já está falhando em silêncio e sendo contornado por uma pessoa.

Isso produz um retrato escrito do que você realmente tem. Escopo e condições saem daí. Se a avaliação disser que você precisa de menos do que esperava, também vamos dizer isso.

Manutenção não existe para te deixar no 9.3 para sempre. Existe para devolver o calendário às suas mãos, para que a mudança para o Sana Commerce Cloud aconteça numa data que você escolheu e orçou, e não correndo depois de um incidente.

Quando essa hora chegar, vale saber o que você está comprando. O Sana Commerce Cloud é um produto diferente e não a versão 10 do que você tem, e quase nada se aproveita automaticamente. Escrevemos isso por completo, incluindo o que de fato se aproveita e onde a IA realmente reduz o custo: O Sana 9.3 já passou do fim de vida: o que isso significa depende de quem faz a manutenção.

Manter a loja direito nesse meio-tempo também protege o que mais importa numa eventual reconstrução. Uma loja mantida conserva alguém fluente nas suas regras de negócio. Uma abandonada devolve tudo ao estado de arqueologia.