O Sana 9.3 já passou do fim de vida. O que isso significa depende de quem faz a manutenção.

Publicado: 20 de agosto de 2026 · 12 min de leitura

Se você opera uma loja Sana 9.3 e ninguém faz manutenção nela, você está rodando software sem suporte hoje. Não em breve. Hoje. Vale entender isso com calma em vez de com urgência, porque a resposta honesta não é automaticamente “reconstrua agora”.

As datas, sem rodeios

• Sana 9.3.0 até 9.3.4: fim de vida no fechamento de 2024.
• Sana 9.3.5: fim de vida no fechamento de 2025.

As duas datas ficaram para trás. Se você está em qualquer release 9.3 enquanto lê isto, já passou do fim de vida, e os acordos de suporte estendido que cobriam a lacuna se esgotaram. Veja o anúncio de fim de vida da Sana para os termos deles.

O que o fim de vida realmente retira

Passar do fim de vida não significa que sua loja para de funcionar numa terça-feira. Nada é desligado. Nenhuma licença expira. A loja que você tinha semana passada é a loja que você tem hoje.

O que some é a rede de segurança por trás dela:

• Correções de segurança. Vulnerabilidades descobertas na plataforma ficam sem correção do fornecedor, permanentemente.
• Correções de bugs da plataforma. Defeitos no próprio código da Sana agora são seus para contornar.
• Um caminho de escalonamento. Quando algo quebra na plataforma e não nas suas customizações, não existe mais um chamado que você possa abrir e que termine numa correção.
• Trabalho de compatibilidade. Este é o que pega as pessoas de surpresa, então ganha o próprio parágrafo.

Sua loja não é estática, mesmo que seu código seja. Navegadores mudam. Provedores de pagamento descontinuam integrações e trocam requisitos. Práticas de TLS e certificados evoluem. Seu ERP é atualizado por outro time num calendário próprio, e o contrato entre ele e a loja se desloca silenciosamente debaixo de você. Numa plataforma com suporte, outra pessoa absorve a maior parte disso. Passado o fim de vida, ninguém absorve, a menos que você contrate.

Esse é o conteúdo real da data de fim de vida. Não um abismo, mas a retirada daquilo que vinha mantendo em silêncio uma integração de cinco anos funcionando enquanto o mundo se mexia em volta.

Se você vai ficar no 9.3, alguém precisa mantê-lo

Esta é a parte que a maioria dos donos de um 9.3 não precificou, porque durante anos vinha embutida na taxa da plataforma e portanto era invisível.

Ficar no 9.3 é uma decisão legítima. Para uma loja que funciona, que fatura e cujo negócio não mudou de formato, pode ser a decisão certa por um bom tempo ainda. Compradores B2B não estão pedindo um redesign, e uma replataforma é muito risco para assumir sem motivo. Dizemos isso com todas as letras mesmo com as outras duas opções desta página valendo mais para nós.

Mas só é uma decisão legítima se você substituir o que o fornecedor fazia. Isso significa um terceiro que realmente conheça o código e responda por ele, cobrindo:

• Segurança. Acompanhar problemas na plataforma e na stack abaixo dela, e corrigir ou mitigar, já que a Sana não vai mais fazer isso.
• O contrato com o ERP. Manter funcionando consulta de cliente, preço, estoque, colocação de pedido, remessas e faturas conforme SAP, Dynamics 365, Business Central ou NAV mudam no calendário deles.
• O mundo lá fora que se move. Navegadores, gateways de pagamento, certificados e a surpresa periódica de um terceiro que presumiu que todo mundo já tinha atualizado.
• Consertar o que quebra. Não escalar. Consertar, porque não existe mais ninguém acima de você.
• Conhecer o sistema antes de virar emergência. A diferença entre uma loja mantida e uma abandonada é medida quase sempre no pior dia, e a essa altura já é tarde para começar a aprender o código.

Rodar depois do fim de vida sem ninguém nesse papel não é bem uma decisão, é uma aposta de que nada vai acontecer. É uma aposta que você ganha na maioria dos meses. No mês em que perde, perde no meio do fluxo de pedidos, sem fornecedor para acionar.

Para o que vale, esse é um trabalho que fazemos e fazemos há muito tempo. Operamos uma loja Sana 9 profundamente customizada, com integração real ao ERP, continuamente desde 2020, com os escalonamentos de plataforma, as surpresas de integração e o trabalho de performance. É também por isso que o resto deste artigo é bem direto sobre o que uma migração custa de verdade.

Quando migrar, saiba o que está comprando

Quando você decidir que é a hora, existe uma expectativa que vale corrigir primeiro, porque é o mal-entendido mais caro desta transição.

O lançamento inicial do Sana Commerce Cloud é documentado como versão 10. Você está no 9.3. Todo instinto que um comprador de tecnologia treinou diz que de 9.3 para 10 é um incremento: uma atualização maior que de 9.2 para 9.3, mas do mesmo tipo.

Não é desse tipo, e essa é a posição da própria Sana, publicada na documentação de suporte deles numa página intitulada Why a New Sana Product, and Not a New Version?.

O Sana Commerce Cloud é uma arquitetura desacoplada com front-end em React, um admin novo e um sistema de conteúdo inteiramente novo construído em torno de um editor visual de páginas. O Sana 9.3 é ASP.NET MVC sobre .NET Framework, Razor renderizado no servidor, rodando IIS em pipeline clássico. Essas duas coisas compartilham família de produto e filosofia de ERP. Não compartilham código.

A consequência prática: um projeto dimensionado como atualização é redimensionado como replataforma, normalmente umas seis semanas depois e normalmente depois do orçamento fechado. Dimensionar certo no primeiro dia é quase toda a diferença entre uma boa e uma má versão deste projeto.

O que realmente se aproveita

Vale ser direto, porque a resposta é perto de nada.

Não se aproveita

• Seu tema e seus templates. Views Razor e a camada de theming do 9.3 não têm caminho para um front-end em React. Cada template de página é reconstruído.
• Seu conteúdo de CMS. As páginas Flexi foram feitas no modelo de conteúdo antigo. O Sana Commerce Cloud usa um designer visual novo, com outra estrutura de páginas e blocos. O conteúdo é reescrito, não importado.
• Suas customizações. Add-ons próprios, módulos HTTP, sobrescritas de view, qualquer coisa compilada contra o SDK do 9.3: nada carrega. Costuma ser a maior linha do orçamento e a que mais provavelmente falta na estimativa, porque customizações tendem a não estar documentadas e suas razões vivem na cabeça das pessoas.
• JavaScript e CSS acoplados ao DOM antigo. Seletores que miravam a marcação renderizada no servidor não têm onde se prender.
• Configuração do admin. As definições são recadastradas num admin diferente, com outro formato.

Se aproveita

• Seu ERP. O sistema de registro não se move. SAP, Business Central, NAV, F&O, o que você usar, fica onde está.
• Seus dados. Clientes, preços, estoque, pedidos e faturas vivem no ERP, não na loja. Essa é a melhor propriedade estrutural de uma implementação Sana e é por isso que tudo isso é sobrevivível.
• Seus contratos de integração. Consulta de cliente, de preço, de estoque, colocação de pedido devolvendo um número real, acompanhamento de remessa, busca de fatura. O conector muda por baixo; as seis coisas que a loja precisa do ERP não.
• Seus requisitos. Cada regra de negócio da qual seu back office realmente depende. Esse é o ativo de verdade, e é o que ninguém escreveu.

Os requisitos são o ativo, não o código

A constatação incômoda de operar uma loja Sana 9 por anos é que o código nunca foi a parte valiosa. A parte valiosa é o conjunto acumulado de decisões: que o número de ordem de compra é obrigatório e limitado a 25 caracteres porque o ERP manda, que uma ordem só com espaços precisa ser rejeitada em vez de aceita em silêncio, que subcontas acima de um teto de autorização vão para um administrador pai, que pedidos de amostra são um tipo de documento separado no ERP e não um desconto, que adicionar ao carrinho precisa ser desabilitado quando o ERP não tem preço para aquele cliente, em vez de permitir um pedido que vai falhar depois.

Nada disso está escrito em lugar nenhum além do comportamento de um código que você estaria jogando fora. Está espalhado por anos de chamados, threads de e-mail e correções cujas razões eram óbvias na época e não são mais.

Se você reconstruir a partir de um levantamento de requisitos do zero, vai redescobrir um subconjunto dessas regras do jeito difícil, em produção, pela boca de quem tem o pedido quebrado. Toda replataforma que dá errado dá errado aqui.

Esse é também o argumento mais forte para manter bem uma loja 9.3 mesmo que você pretenda deixá-la um dia. Uma loja mantida conserva alguém fluente nessas regras. Uma abandonada devolve tudo ao estado de arqueologia.

Onde a IA ajuda de verdade e onde não

A reconstrução é em boa parte um problema de tradução, e traduzir através de uma fronteira conhecida é justamente aquilo em que as ferramentas de IA atuais são boas. Usada com disciplina, muda a economia deste projeto de forma relevante. Usada como varinha mágica, produz bobagem com muita confiança.

Onde ajuda

• Extrair requisitos do código antigo. Ler cada customização, cada sobrescrita de view, cada chamado do histórico do projeto, e produzir um registro estruturado do que a loja realmente faz e por quê. Esta é, de longe, a aplicação de maior valor, porque converte o ativo que você destruiria em um que você mantém. Também é tedioso o bastante em velocidade humana para normalmente não acontecer.
• Traduzir templates. De view Razor para componente React é uma transformação mecânica de formato consistente. IA é boa com formatos consistentes em volume.
• Reescrever o conteúdo. Mapear estruturas antigas de páginas Flexi para blocos do novo editor, na escala de algumas centenas de páginas, é exatamente o trabalho grande demais para fazer à mão e estruturado demais para justificar uma ferramenta sob medida.
• Gerar os testes de regressão que você nunca teve. A loja antiga é uma especificação viva do próprio comportamento até o momento em que você a desliga. Caracterizar esse comportamento como testes, enquanto ela ainda roda, te dá contra o que conferir a construção nova.

Onde não ajuda

• Decidir quais regras manter. Parte do que sua loja 9.3 faz é regra de negócio deliberada. Parte é contorno de uma limitação de plataforma que não existe mais, e parte é bug ao qual todo mundo se adaptou em silêncio. Distinguir exige conversar com quem toca o negócio. Nenhum modelo sabe qual é qual.
• Semântica de ERP. O conector é outro. Tamanhos de campo, tipos de documento e comportamento de erro precisam ser reverificados contra a integração nova, não presumidos.
• Qualquer coisa que você não verificar. Um componente gerado que renderiza não é um componente correto. A carga de revisão é real e não desaparece.

O enquadramento honesto: a IA não elimina a reconstrução. Ela elimina quase toda a arqueologia, quase toda a tradução mecânica e a desculpa para não ter os requisitos escritos. Isso é uma fração grande do custo e quase todo o risco.

Uma sequência que funciona

Quando você decidir migrar:

1. Capture o as-built primeiro, enquanto o 9.3 ainda roda. Antes de qualquer trabalho na plataforma nova. Se fizer só uma coisa desta lista, faça esta, porque a janela fecha quando a loja antiga apaga.
2. Inventarie as customizações e classifique cada uma. Manter, descartar ou substituir por recurso nativo da plataforma. Uma parcela relevante das customizações do 9.3 existe para contornar lacunas que o Sana Commerce Cloud já fecha nativamente, e reconstruir isso é desperdício puro.
3. Confirme os seis contratos com o ERP contra o conector novo antes de fechar um plano de front-end. Surpresa de integração mata cronograma.
4. Reconstrua o front-end começando pelo template de maior tráfego. Páginas de categoria e de produto são as que mais faturam e as que mais expõem problemas de renderização.
5. Rode as duas em paralelo com um grupo real de revendedores na loja nova antes do corte. Compradores B2B toleram mal surpresas, e um grupo piloto pega as regras que ninguém documentou.

O que fazer antes de ligar para alguém

Duas coisas, ambas gratuitas, ambas úteis mesmo que você nunca contrate ninguém:

1. Descubra exatamente em qual release 9.3 você está e quem faz a manutenção. Do 9.3.0 ao 9.3.4 o fim de vida chegou um ano antes do 9.3.5. As duas perguntas mudam a urgência disso, e a segunda muda mais que a primeira.
2. Escreva cada regra de negócio que seu back office notaria se sumisse. Sente com quem trata as exceções de pedido e pergunte o que o site faz que essa pessoa usa. Você vai receber uma lista que ninguém esperava. Essa lista é a especificação real do que vier depois, e vale mais que qualquer proposta que você vá receber.

A conclusão

Existem três caminhos honestos a partir da data de fim de vida, e eles não estão ordenados pelo que valem para um fornecedor.

1. Ficar no 9.3, com manutenção de verdade. Viável por anos. Exige um terceiro que conheça o código e assuma a segurança, o contrato com o ERP e as correções que a Sana não vai mais fazer. É a opção mais barata e, para muitas lojas, a correta agora.
2. Migrar para o Sana Commerce Cloud. Plataforma melhor que o 9.3 em quase todo eixo que importa, e para onde a linha de produto está indo. Só orce como uma reconstrução vestida de número de versão, porque é isso que é.
3. Olhar mais longe. Se o negócio mudou de formato desde que você comprou a Sana, o modelo integrado ao ERP pode já não ser o enquadramento certo. Essa é uma conversa que vale ter em vez de evitar, e preferimos tê-la com você com honestidade a ver você reconstruir com capricho a coisa errada.

O caminho que dá errado é o quarto, aquele que ninguém escolhe de propósito: ficar no 9.3 sem ninguém fazendo manutenção, e chamar isso de decisão.

Tem um projeto real que este artigo toca?

Operamos uma loja Sana 9 com integração profunda ao ERP continuamente desde 2020, incluindo as customizações, os escalonamentos de plataforma e o trabalho de performance. Se você quer que sua loja 9.3 atual seja bem cuidada, uma leitura direta do que uma migração para o Sana Commerce Cloud custaria de verdade, ou uma conversa mais ampla sobre se a Sana ainda é o encaixe certo, conte para nós o que você opera. Sem compromisso, e vamos dizer se a resposta for que você deve ficar onde está por enquanto.