Cuándo actualizar su software a la última versión disponible

La respuesta corta es lo antes posible, y la respuesta ejecutiva es que usted debe actualizar según un calendario que la empresa decide de antemano, no según la urgencia que imponga el próximo incidente. Un software se actualiza cuando el proveedor libera correcciones de seguridad, cuando su versión se acerca al fin del soporte o cuando la brecha con la última versión empieza a costar más que cerrarla.

Imagine el lunes de un comité de dirección en una empresa de distribución con tienda en línea. El director de tecnología menciona, casi al pasar, que la plataforma de comercio electrónico lleva dos años sin cambiar de versión porque nunca hubo un momento cómodo para detener las ventas. La directora financiera pregunta cuánto cuesta ponerse al día y la respuesta es una cifra mayor que la del año anterior. Nadie pregunta cuánto cuesta no hacerlo, y esa es justamente la pregunta que este artículo propone responder. Actualizar el software no es una tarea técnica de mantenimiento. Es una decisión sobre riesgo, continuidad de ventas y velocidad para adoptar lo que viene, y por eso corresponde a la alta dirección.

Casi toda organización tiene hoy una o varias plataformas con versiones atrasadas. Magento, Liferay, WordPress, el CRM, el ERP o cualquier otro sistema reciben versiones nuevas con frecuencia, y los equipos de tecnología rara vez logran aplicarlas todas. Cada versión que se omite se suma a la anterior, de modo que la distancia entre lo que usted tiene y lo que existe se hace más grande, más costosa de cerrar y más riesgosa de cruzar. Este artículo explica qué se gana al actualizar, qué debe revisarse antes, cómo leer los números de versión y cómo convertir todo ello en una rutina que no dependa del humor del equipo ni del calendario comercial.

¿Qué gana la empresa cuando actualiza su software?

La primera ganancia es seguridad. Las actualizaciones suelen incluir parches que corrigen vulnerabilidades conocidas, y esas vulnerabilidades dejan de ser un secreto en el momento en que el proveedor las publica. A partir de ese día, cualquier atacante dispone de la descripción de la falla y busca sitios que todavía no la hayan corregido. Por eso las actualizaciones de seguridad deben considerarse de acatamiento inmediato y conviene que alguien en la empresa esté atento a los avisos del proveedor, para evitar fugas de información del sitio y de quienes lo usan.

El caso de Equifax es el ejemplo que más se cita, y con razón. Según el informe del Senado de Estados Unidos sobre el caso, el 8 de marzo de 2017 se emitió la alerta sobre una vulnerabilidad en Apache Struts, y la compañía recibió el aviso ese mismo día. La política interna exigía aplicar el parche en 48 horas, pero la aplicación vulnerable no se corrigió a tiempo, los atacantes entraron en mayo y la falla no quedó resuelta hasta agosto. La compañía anunció el incidente en septiembre de 2017 y la cifra final de personas afectadas superó los 145 millones. El informe atribuye parte del retraso a que Equifax no contaba con un inventario completo de sus activos tecnológicos, de manera que no sabía con certeza dónde estaba la versión vulnerable. La lección ejecutiva es doble: el parche existía, y la organización no tenía el control necesario para aplicarlo.

El informe completo puede consultarse en el reporte del Senado de Estados Unidos sobre la brecha de Equifax.

La segunda ganancia es funcional. Las nuevas versiones corrigen errores y funcionalidades difíciles de usar, y con frecuencia incorporan capacidades que el negocio todavía no sabía que necesitaba. Una tienda en línea que pasa a una versión más reciente puede recibir mejoras de rendimiento en el escaparate, nuevas formas de pago o mejores herramientas de administración sin que nadie haya escrito una línea de código propio. Quien se queda atrás paga dos veces: financia los parches de una versión que envejece y renuncia a las mejoras que sus competidores ya aprovechan.

La tercera ganancia es menos visible y quizá la más valiosa. Actualizar de manera frecuente mantiene pequeña la diferencia entre versiones, y una diferencia pequeña se cruza con riesgo bajo. Lo que parece un ahorro cuando se posterga la actualización se convierte, con el tiempo, en un proyecto de migración con presupuesto, plan de contingencia y una ventana de mantenimiento que ninguna área comercial quiere ceder.

¿Qué debe revisarse antes de actualizar?

Ninguna actualización es igual a otra, y cada caso requiere su propia evaluación. Aun así, hay dos preguntas que se repiten y que conviene responder antes de abrir la ventana de mantenimiento.

La primera es la compatibilidad. La nueva versión debe funcionar con el sistema operativo, la base de datos, el servidor de aplicaciones y los demás programas con los que convive. Algunas actualizaciones exigen requisitos mínimos de hardware o la actualización de otros componentes de la infraestructura, y las extensiones o integraciones desarrolladas a la medida son las primeras que suelen romperse. Un director de operaciones de una cadena de farmacias lo vive cada vez que una versión nueva del comercio electrónico deja de hablar con el sistema de inventarios de las sucursales: las ventas en línea siguen entrando, pero los faltantes se descubren en el mostrador.

La segunda es la migración de datos. Según el tipo de sistema y el alcance de la actualización, los datos pueden tener que migrarse por separado, y hay que confirmar que toda la información seguirá siendo utilizable en la versión nueva y que no se perderá nada de importancia. Los clientes, los pedidos históricos, las reglas de precios y las configuraciones del catálogo son el patrimonio comercial de la empresa, y una migración que los daña cuesta más que cualquier ahorro que se haya buscado con la prisa.

Hay además una precaución que la experiencia respalda. Antes de actualizar, es sensato investigar las opiniones y experiencias de otros usuarios sobre la nueva versión. Puede ocurrir que una versión recién liberada genere problemas nuevos, y si ese es el caso lo prudente es esperar a que se considere estable y bien avalada. Esta espera, sin embargo, se mide en semanas y se justifica con evidencia. Cuando se convierte en una excusa permanente deja de ser prudencia y pasa a ser deuda.

¿Cómo se lee el número de una versión?

Entender cómo se identifica una versión permite a un directivo interpretar un aviso del proveedor sin depender de un traductor técnico. Existen dos formas principales de numerar una actualización, y la más extendida es la consecutiva.

En la numeración consecutiva, un identificador como 7.2.1 se compone de tres valores. El primero, el 7, representa la versión principal del software, y cuando sube indica cambios amplios en el aplicativo, en su visualización, en su funcionamiento y en la forma de utilizarlo. El segundo, el 2, señala una versión secundaria o una actualización menor, que suele traer mejoras adicionales, correcciones y optimizaciones sin cambios profundos respecto a la anterior. El tercero, el 1, corresponde por lo general a una revisión, es decir, a correcciones de errores, parches de seguridad o ajustes menores que no agregan características importantes. Cuando sube un valor de la izquierda, los contadores de la derecha se reinician, de modo que un cambio mayor desde la 7.2.1 llevaría a la 8.0.0.

Esta convención tiene un respaldo formal. La especificación de versionado semántico establece que el número mayor debe incrementarse cuando se introducen cambios incompatibles con la versión anterior, el menor cuando se agrega funcionalidad compatible, y el de revisión cuando se publican correcciones compatibles de errores. La consecuencia práctica es útil para quien decide. Una revisión de tercer nivel suele ser de bajo riesgo y alta urgencia, mientras que un salto de versión principal pide planificación, pruebas y presupuesto.

La segunda forma es la numeración por fecha. Algunos proveedores identifican sus versiones con el año y el mes de su liberación, de manera que una versión 2023-05 indica que fue publicada en mayo de 2023. Con este sistema el número no dice cuán profundo es el cambio, pero permite medir de inmediato la antigüedad de lo que se tiene instalado, algo que el comité de dirección entiende sin ayuda.

Quien quiera ver el efecto de los distintos niveles en una plataforma concreta puede revisar la guía para crear y usar bloques en Adobe Commerce, que muestra cómo la administración de contenido se apoya en componentes que evolucionan con cada versión.

El ejemplo de Adobe Commerce, o por qué el soporte también vence

Los proveedores no solo liberan versiones nuevas. También retiran el soporte de las anteriores, y es en ese momento cuando una versión atrasada deja de ser un inconveniente y pasa a ser una exposición. Adobe Commerce, la plataforma que respalda a muchas tiendas B2C y B2B, es un buen ejemplo porque publica su política de manera abierta.

Según la política de ciclo de vida de Adobe Commerce, cada versión tiene una etapa de soporte estándar de tres años desde su disponibilidad general, que incluye correcciones de calidad y parches de seguridad. A esa etapa puede seguir un año de soporte extendido para determinadas versiones y, para algunas líneas, un periodo transitorio de correcciones de seguridad limitadas, que Adobe describe como un tiempo para migrar y no como una opción de soporte a largo plazo. En la página de versiones publicadas puede verse el resultado a octubre de 2026: la versión 2.4.9 salió en mayo de 2026 con soporte regular hasta mayo de 2029, la 2.4.8 lo tiene hasta mayo de 2028, y las líneas 2.4.4 y 2.4.5 ya terminaron su soporte regular y su soporte extendido, de modo que solo conservan correcciones de seguridad limitadas hasta mayo de 2027.

Los riesgos de esperar no son teóricos. En junio de 2024, Adobe publicó el boletín de seguridad APSB24-40, que describe una vulnerabilidad crítica identificada como CVE-2024-34102, con una puntuación de 9,8 sobre 10, que no requería autenticación y que, según la propia Adobe, fue explotada en ataques limitados contra comerciantes de Adobe Commerce. El boletín de seguridad de Adobe enumera las versiones afectadas, y quien aplicó el parche a tiempo cerró esa puerta. Quien llevaba años sin actualizar tuvo que decidir bajo presión, en plena temporada comercial, y con un costo mucho mayor.

La trampa del soporte vencido tiene también una dimensión que a menudo se pasa por alto. Las plataformas garantizan su funcionamiento a una fecha específica y para versiones concretas de base de datos, servidor y lenguaje. Cuando se vence el soporte de la plataforma, es probable que el de los componentes que la rodean ya haya vencido también. Una empresa puede creer que tiene un problema, cuando en realidad tiene tres.

¿Cuándo es el momento correcto?

La pregunta se responde con tres criterios que la dirección puede evaluar sin conocimientos técnicos. El primero es la gravedad del contenido. Si la actualización corrige un problema de seguridad, el plazo se mide en días, no en trimestres. El segundo es el estado del soporte. Si la versión instalada está dentro del último año de soporte estándar, el proyecto debería estar ya en el plan de trabajo, con presupuesto aprobado. Si el soporte ya venció, la actualización dejó de ser opcional. El tercero es la distancia. Cuando la brecha con la última versión supera uno o dos saltos principales, el costo crece de forma desproporcionada, y es mejor dividir el recorrido en etapas que esperar a que se vuelva un proyecto de reconstrucción.

A estos criterios se suma una consideración comercial que el área de ventas valora. Las actualizaciones importantes conviene programarlas fuera de las campañas de mayor facturación. Un minorista que concentra una parte relevante de su año en noviembre y diciembre tiene su ventana natural entre febrero y septiembre, y debería llegar a octubre con la versión estable y las pruebas completas, no con una migración pendiente.

Qué significa para la alta dirección

En términos de la cadena de valor comercial de la empresa, la actualización de software toca varios frentes a la vez. Para retener clientes, una plataforma segura y estable evita las interrupciones y las filtraciones que destruyen la confianza de quienes ya compran. Para convertir, las mejoras de rendimiento y de experiencia de pago de las versiones nuevas reducen la fricción en los momentos donde se pierden ventas. Para operar con eficiencia, mantener las versiones al día evita proyectos de rescate costosos y libera al equipo técnico para trabajar en lo que diferencia al negocio.

El gobierno de estas decisiones suele ser el verdadero problema. En muchas compañías, nadie es dueño de la pregunta de cuándo actualizar. El área de tecnología la plantea cuando hay presupuesto, el área comercial se opone cuando hay campaña, y la dirección se entera cuando algo falla. Una buena práctica es nombrar un responsable por plataforma, exigirle un inventario actualizado de versiones, fechas de fin de soporte y dependencias, y revisarlo con la misma regularidad con que se revisa el pronóstico de ventas. El caso de Equifax muestra con crudeza lo que ocurre cuando ese inventario no existe.

Cómo empezar el lunes por la mañana

La forma más sensata de abordar el asunto es comenzar por conocer el punto de partida. Pida a su equipo, o a un asesor externo, una lista de todas las plataformas críticas con la versión instalada, la versión más reciente disponible y la fecha en que termina el soporte de cada una. Esa lista, que rara vez toma más de unos días, suele provocar la conversación más útil del trimestre, porque pone cifras a un riesgo que hasta entonces era una sensación.

Con esa información, clasifique las plataformas según su impacto en las ventas y su cercanía al fin del soporte, y decida cuáles van primero. Defina una frecuencia para revisar los avisos de seguridad de cada proveedor y quién tiene autoridad para aprobar una actualización urgente fuera del calendario. Reserve en el presupuesto anual una partida de mantenimiento evolutivo, de modo que actualizar no compita cada vez con proyectos nuevos, y acuerde con el área comercial las ventanas del año en las que no se tocará nada. Finalmente, pruebe cada actualización en un ambiente separado antes de llevarla a producción y conserve un respaldo que permita volver atrás.

Si el atraso ya es grande, no se desanime. Un factor muy positivo de actualizar el software es que nunca es tarde para hacerlo. Si bien cada nueva versión acumula dificultad, también acumula mejoras, y una plataforma puesta al día es más segura, más útil y, sobre todo, más fácil de seguir actualizando. La primera actualización es la más cara; las siguientes cuestan una fracción.

Cómo le ayuda ICX

ICX Consulting acompaña a las empresas en la decisión y en la ejecución. Desde la práctica de hoja de ruta de transformación digital, ayudamos a ordenar el inventario tecnológico, a priorizar las plataformas según su efecto en ingresos y riesgo, y a convertir las actualizaciones en un calendario que el negocio pueda sostener. En comercio electrónico, nuestro trabajo de consultoría en comercio electrónico B2C incluye evaluar el estado de la plataforma, planear migraciones de versión y coordinar con los equipos técnicos para que el cambio ocurra sin sorpresas para el cliente. Para el componente de protección, la práctica de seguridad en CRM y plataformas digitales revisa el nivel de exposición real de cada sistema.

Si desea un punto de partida concreto, el kit de Transformación Digital reúne plantillas y guías para evaluar dónde está su organización y cómo priorizar los cambios. También puede ampliar el contexto con nuestra reflexión sobre el error de abrir una pulpería online y con el artículo sobre qué se deja pasar cuando no se realizan las migraciones a tiempo.

Preguntas frecuentes

¿Cada cuánto debería actualizarse una plataforma de comercio electrónico?

Las revisiones de seguridad deben aplicarse en cuanto el proveedor las libera y se hayan probado. Las versiones secundarias conviene evaluarlas cada trimestre, y los saltos de versión principal se planifican con anticipación. El criterio rector es no quedar a más de una versión de distancia ni dentro del último año de soporte sin un plan aprobado.

¿Qué pasa si mi versión ya perdió el soporte del proveedor?

La plataforma sigue funcionando, pero deja de recibir correcciones regulares y las vulnerabilidades nuevas quedan sin parche oficial, lo cual aumenta el riesgo y puede afectar el cumplimiento de normas de pago. Además, los componentes del entorno suelen perder su soporte también. Lo recomendable es planear la migración de inmediato, por etapas si la distancia es grande.

¿Se puede actualizar sin detener las ventas?

En muchos casos sí, si se prueba primero en un ambiente de pruebas, se programa una ventana de baja demanda y se cuenta con respaldos y un plan de retroceso. La clave no es evitar toda interrupción, sino acotarla en el tiempo y comunicarla internamente. Las plataformas en la nube de los proveedores reducen aún más esta fricción.

¿Hay actualizaciones que conviene esperar?

Sí, pero con criterio. Una versión mayor recién liberada puede traer errores que se corrigen en las primeras revisiones, así que muchas organizaciones esperan unas semanas y consultan la experiencia de otros usuarios. Esta cautela no aplica a los parches de seguridad críticos, que deben instalarse cuanto antes.

Una plataforma al día es una promesa cumplida a sus clientes y a su equipo comercial. Si quiere saber en qué punto se encuentra su empresa y qué debería hacerse primero, solicite un diagnóstico con un consultor de ICX y convierta la próxima actualización en una decisión planeada y no en una urgencia.