Sana 9.3 ya pasó su fin de vida. Lo que eso significa depende de quién le da mantenimiento.

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

Si operas una tienda Sana 9.3 y nadie le da mantenimiento, hoy estás corriendo software sin soporte. No pronto. Hoy. Vale la pena entenderlo con calma en lugar de con urgencia, porque la respuesta honesta no es automáticamente “reconstruye ya”.

Las fechas, sin rodeos

• Sana 9.3.0 a 9.3.4: fin de vida al cierre de 2024.
• Sana 9.3.5: fin de vida al cierre de 2025.

Ambas fechas quedaron atrás. Si estás en cualquier versión 9.3 mientras lees esto, ya pasaste el fin de vida, y los acuerdos de soporte extendido que cubrían el hueco se agotaron. Consulta el anuncio de fin de vida de Sana para ver sus términos.

Qué quita en realidad el fin de vida

Pasar el fin de vida no significa que tu tienda deje de funcionar un martes. Nada se apaga. Ninguna licencia expira. La tienda que tenías la semana pasada es la tienda que tienes hoy.

Lo que desaparece es la red de seguridad detrás de ella:

• Parches de seguridad. Las vulnerabilidades que se descubran en la plataforma quedan sin parche del proveedor, de forma permanente.
• Correcciones de la plataforma. Los defectos en el propio código de Sana ahora son tuyos para rodearlos.
• Una ruta de escalamiento. Cuando algo se rompe en la plataforma y no en tus personalizaciones, ya no hay un ticket que puedas levantar y que termine en una corrección.
• Trabajo de compatibilidad. Este es el que agarra desprevenida a la gente, así que se lleva su propio párrafo.

Tu tienda no es estática, aunque tu código sí lo sea. Los navegadores cambian. Los proveedores de pago dan de baja integraciones y rotan requisitos. Las prácticas de TLS y certificados se mueven. Tu ERP lo actualiza otro equipo en otro calendario, y el contrato entre él y la tienda se desplaza en silencio debajo de ti. En una plataforma con soporte, alguien más absorbe la mayor parte de eso. Pasado el fin de vida, nadie lo hace a menos que tú lo arregles.

Ese es el contenido real de la fecha de fin de vida. No un precipicio, sino la retirada de aquello que mantenía funcionando en silencio una integración de cinco años mientras el mundo se movía a su alrededor.

Si te vas a quedar en 9.3, alguien tiene que mantenerlo

Esta es la parte que la mayoría de los dueños de un 9.3 no ha costeado, porque durante años venía incluida en la cuota de la plataforma y por lo tanto era invisible.

Quedarse en 9.3 es una decisión legítima. Para una tienda que funciona, que genera ingresos y cuyo negocio no ha cambiado de forma, puede ser la decisión correcta por un buen rato todavía. Los compradores B2B no están exigiendo un rediseño, y una replataforma es mucho riesgo para asumirlo porque sí. Lo decimos con claridad aunque las otras dos opciones de esta página valgan más para nosotros.

Pero solo es una decisión legítima si reemplazas lo que el proveedor solía hacer. Eso significa un tercero que de verdad conozca el código y responda por él, cubriendo:

• Seguridad. Vigilar los problemas de la plataforma y del stack debajo de ella, y parchar o mitigar, porque Sana ya no lo hará.
• El contrato con el ERP. Mantener funcionando la consulta de clientes, precios, existencias, colocación de pedidos, embarques y facturas conforme SAP, Dynamics 365, Business Central o NAV cambian en su propio calendario.
• El mundo que se mueve afuera. Navegadores, pasarelas de pago, certificados y la sorpresa periódica de un tercero que dio por hecho que todos ya habían actualizado.
• Arreglar lo que se rompe. No escalarlo. Arreglarlo, porque ya no hay nadie por encima de ti.
• Conocer el sistema antes de que sea una emergencia. La diferencia entre una tienda mantenida y una abandonada se mide casi siempre en el peor día, y para entonces ya es tarde para empezar a aprender el código.

Seguir operando después del fin de vida sin nadie en ese rol no es tanto una decisión como una apuesta a que no pasará nada. Es una apuesta que ganas la mayoría de los meses. El mes que la pierdes, la pierdes en pleno flujo de pedidos y sin proveedor a quién llamar.

Para lo que valga, este es un trabajo que hacemos y que llevamos haciendo mucho tiempo. Hemos operado una tienda Sana 9 profundamente personalizada, con integración real al ERP, de forma continua desde 2020, con sus escalamientos de plataforma, sus sorpresas de integración y su trabajo de rendimiento. Por eso mismo el resto de este artículo es bastante directo sobre lo que cuesta de verdad una mudanza.

Cuando te muevas, ten claro qué estás comprando

Cuando decidas que es el momento, hay una expectativa que conviene corregir primero, porque es el malentendido más caro de esta transición.

El lanzamiento inicial de Sana Commerce Cloud está documentado como versión 10. Tú estás en 9.3. Todo el instinto que se le ha enseñado a un comprador de tecnología dice que de 9.3 a 10 es un incremento: una actualización más grande que de 9.2 a 9.3, pero del mismo tipo.

No es de ese tipo, y esta es la propia postura de Sana, publicada en su documentación de soporte bajo una página titulada Why a New Sana Product, and Not a New Version?.

Sana Commerce Cloud es una arquitectura desacoplada con un front-end en React, un admin nuevo y un sistema de contenido completamente nuevo construido alrededor de un editor visual de páginas. Sana 9.3 es ASP.NET MVC sobre .NET Framework, Razor renderizado en el servidor, corriendo IIS en modo de canalización clásica. Esas dos cosas comparten familia de producto y filosofía de ERP. No comparten código.

La consecuencia práctica: un proyecto dimensionado como actualización se vuelve a dimensionar como replataforma, normalmente a las seis semanas y normalmente después de fijar el presupuesto. Dimensionarlo bien desde el día uno es casi toda la diferencia entre una buena y una mala versión de este proyecto.

Qué se conserva en realidad

Vale la pena ser directo, porque la respuesta se acerca a nada.

No se conserva

• Tu tema y tus plantillas. Las vistas Razor y la capa de theming de 9.3 no tienen camino hacia un front-end en React. Cada plantilla de página se reconstruye.
• Tu contenido del CMS. Las páginas Flexi se construyeron en el modelo de contenido viejo. Sana Commerce Cloud usa un diseñador visual nuevo con otra estructura de páginas y bloques. El contenido se vuelve a redactar, no se importa.
• Tus personalizaciones. Add-ons a medida, módulos HTTP, sobrescrituras de vistas, cualquier cosa compilada contra el SDK de 9.3: nada carga. Suele ser la partida más grande y la que más probablemente falte en la estimación, porque las personalizaciones tienden a no estar documentadas y sus razones viven en la cabeza de la gente.
• JavaScript y CSS acoplados al DOM viejo. Los selectores que apuntaban al marcado renderizado en servidor no tienen a qué engancharse.
• La configuración del admin. Los ajustes se vuelven a capturar contra un admin distinto con otra forma.

Sí se conserva

• Tu ERP. El sistema de registro no se mueve. SAP, Business Central, NAV, F&O, lo que uses, se queda donde está.
• Tus datos. Clientes, precios, existencias, pedidos y facturas viven en el ERP, no en la tienda. Esa es la mejor propiedad estructural de una implementación Sana y es la razón por la que todo esto es sobrevivible.
• Tus contratos de integración. Consulta de cliente, de precio, de existencias, colocación de pedido devolviendo un folio real, seguimiento de embarques, descarga de facturas. El conector cambia por debajo; las seis cosas que la tienda necesita del ERP no.
• Tus requerimientos. Cada regla de negocio de la que realmente depende tu back office. Ese es el activo de verdad, y es el que nadie ha escrito.

Los requerimientos son el activo, no el código

El hallazgo incómodo de operar una tienda Sana 9 durante años es que el código nunca fue la parte valiosa. La parte valiosa es el conjunto acumulado de decisiones: que el número de orden de compra es obligatorio y tiene tope de 25 caracteres porque el ERP lo dice, que una orden de compra con puros espacios debe rechazarse en lugar de aceptarse en silencio, que las subcuentas que rebasan un techo de autorización se enrutan a un administrador padre, que los pedidos de muestra son un tipo de documento distinto en el ERP y no un descuento, que agregar al carrito debe deshabilitarse cuando el ERP no tiene precio para ese cliente en lugar de permitir un pedido que fallará más adelante.

Nada de eso está escrito en ningún lado salvo en el comportamiento de un código que estarías tirando. Está disperso en años de tickets, hilos de correo y correcciones cuyas razones eran obvias en su momento y ya no lo son.

Si reconstruyes a partir de un levantamiento de requerimientos desde cero, vas a redescubrir un subconjunto de esas reglas por las malas, en producción, de boca de la gente a la que se le rompen los pedidos. Toda replataforma que sale mal, sale mal aquí.

Este es también el argumento más fuerte para mantener bien una tienda 9.3 aunque pienses dejarla algún día. Una tienda mantenida conserva a alguien con fluidez en esas reglas. Una abandonada las vuelve a convertir en arqueología.

Dónde ayuda de verdad la IA y dónde no

La reconstrucción es en buena medida un problema de traducción, y traducir a través de una frontera conocida es justo aquello en lo que las herramientas de IA actuales son buenas. Usada con disciplina, cambia la economía de este proyecto de forma significativa. Usada como varita mágica, produce disparates con mucha seguridad.

Dónde ayuda

• Extraer requerimientos del código viejo. Leer cada personalización, cada sobrescritura de vista, cada ticket del historial del proyecto, y producir un registro estructurado de lo que la tienda hace realmente y por qué. Esta es, con diferencia, la aplicación de mayor valor, porque convierte el activo que de otro modo destruirías en uno que conservas. También es lo bastante tedioso a velocidad humana como para que normalmente no ocurra.
• Traducir plantillas. De vista Razor a componente React es una transformación mecánica con una forma consistente. La IA es buena con formas consistentes a volumen.
• Volver a redactar el contenido. Mapear estructuras viejas de páginas Flexi a bloques del nuevo editor, a escala de unos cientos de páginas, es exactamente el trabajo demasiado grande para hacerlo a mano y demasiado estructurado para justificar una herramienta a medida.
• Generar las pruebas de regresión que nunca tuviste. La tienda vieja es una especificación funcional de su propio comportamiento hasta el momento en que la apagas. Caracterizar ese comportamiento como pruebas, mientras sigue corriendo, te da con qué contrastar la construcción nueva.

Dónde no ayuda

• Decidir qué reglas conservar. Parte de lo que hace tu tienda 9.3 es una regla de negocio deliberada. Parte es un rodeo a una limitación de plataforma que ya no existe, y parte es un bug al que todos se adaptaron en silencio. Distinguirlos exige hablar con la gente que opera el negocio. Ningún modelo sabe cuál es cuál.
• La semántica del ERP. El conector es distinto. Longitudes de campo, tipos de documento y comportamiento de errores hay que verificarlos contra la integración nueva en vez de darlos por heredados.
• Cualquier cosa que no verifiques. Un componente generado que renderiza no es un componente correcto. La carga de revisión es real y no desaparece.

El encuadre honesto: la IA no elimina la reconstrucción. Elimina casi toda la arqueología, casi toda la traducción mecánica y el pretexto para no tener los requerimientos por escrito. Eso es una fracción grande del costo y casi todo el riesgo.

Una secuencia que funciona

Cuando decidas moverte:

1. Captura el as-built primero, mientras 9.3 sigue corriendo. Antes de cualquier trabajo en la plataforma nueva. Si solo haces una cosa de esta lista, haz esta, porque la ventana se cierra cuando la tienda vieja se apaga.
2. Inventaría las personalizaciones y clasifica cada una. Conservar, descartar o reemplazar por una función nativa de la plataforma. Una parte importante de las personalizaciones de 9.3 existen para rodear huecos que Sana Commerce Cloud ya cubre de forma nativa, y reconstruir eso es desperdicio puro.
3. Confirma los seis contratos con el ERP contra el conector nuevo antes de comprometerte con un plan de front-end. Las sorpresas de integración matan calendarios.
4. Reconstruye el front-end empezando por la plantilla de mayor tráfico. Las páginas de categoría y de producto son las que más generan y las que más problemas de renderizado exponen.
5. Corre ambas en paralelo con un grupo real de distribuidores en la tienda nueva antes del cambio definitivo. Los compradores B2B toleran mal las sorpresas, y un grupo piloto detecta las reglas que nadie documentó.

Qué hacer antes de llamar a nadie

Dos cosas, ambas gratis, ambas útiles aunque nunca contrates a nadie:

1. Averigua exactamente en qué versión 9.3 estás y quién le da mantenimiento. De 9.3.0 a 9.3.4 llegaron al fin de vida un año antes que 9.3.5. Ambas preguntas cambian qué tan urgente es esto, y la segunda lo cambia más que la primera.
2. Escribe cada regla de negocio que tu back office notaría si desapareciera. Siéntate con quien maneja las excepciones de pedidos y pregúntale qué hace el sitio de lo que depende. Vas a obtener una lista que nadie esperaba. Esa lista es la especificación real de lo que venga después, y vale más que cualquier propuesta que vayas a recibir.

Las conclusiones

Hay tres caminos honestos a partir de la fecha de fin de vida, y no están ordenados por lo que le convienen a un proveedor.

1. Quedarte en 9.3, bien mantenido. Viable durante años. Requiere un tercero que conozca el código y cargue con la seguridad, el contrato con el ERP y las correcciones que Sana ya no hará. Es la opción más barata y, para muchas tiendas, la correcta ahora mismo.
2. Moverte a Sana Commerce Cloud. Mejor plataforma que 9.3 en casi cualquier eje que importe, y hacia donde va la línea de producto. Solo presupuéstalo como una reconstrucción disfrazada de número de versión, porque eso es lo que es.
3. Mirar más allá. Si el negocio cambió de forma desde que compraste Sana, puede que el modelo integrado al ERP ya no sea el marco correcto. Esa es una conversación que vale la pena tener en vez de evitarla, y preferimos tenerla contigo con honestidad a verte reconstruir con cuidado la cosa equivocada.

El camino que sale mal es el cuarto, el que nadie elige a propósito: quedarse en 9.3 sin nadie que le dé mantenimiento, y llamarle a eso una decisión.

¿Tienes un proyecto real que toque este artículo?

Hemos operado una tienda Sana 9 con integración profunda al ERP de forma continua desde 2020, incluyendo las personalizaciones, los escalamientos de plataforma y el trabajo de rendimiento. Ya sea que quieras que tu tienda 9.3 actual quede bien cuidada, una lectura directa de lo que costaría de verdad moverte a Sana Commerce Cloud, o una conversación más amplia sobre si Sana sigue siendo lo que te conviene, cuéntanos qué estás operando. Sin compromiso, y te diremos si la respuesta es que te quedes donde estás por ahora.