Software sin soporte en 2026: qué hacer si tu app todavía corre sobre él

Esto es lo que hace tan fácil ignorar el problema: el software que dejó de tener soporte no deja de funcionar. No tiene fecha de caducidad, ni luz de advertencia, ni un mensaje en pantalla. La mañana siguiente al último parche, tu aplicación abre exactamente igual que el día anterior, y va a seguir abriendo durante años.

Justo por eso hay tanto software así todavía en producción. Nada obliga a tener la conversación. La cuenta llega después, toda junta, y normalmente en el peor momento posible.

Varias herramientas de las que todavía depende mucho software en funcionamiento ya se quedaron en silencio de forma definitiva. Esto es lo que eso te cuesta realmente, cómo averiguar si te afecta sin ser técnico, y qué hacer si es tu caso.

Qué significa realmente “fin de vida”

Se usan tres términos de forma imprecisa y significan cosas bastante distintas, así que conviene ser preciso antes de ponerte a preguntar.

• Obsoleto o deprecado significa: todavía funciona, todavía tiene soporte, pero sus creadores ya avisaron que va de salida. Es una advertencia, no un problema. Tienes tiempo.
• Fin de vida significa: sus creadores se detuvieron. Sin parches de seguridad, sin corrección de errores, sin actualizaciones cuando cambia el entorno alrededor. Sigue funcionando.
• Apagado significa: era un servicio, y el servicio se apagó. Este sí se rompe, en una fecha concreta, y no hay forma de esperar que ayude.

Casi todo lo que sigue es la categoría del medio, que es la que se subestima, porque el día señalado no pasa nada visible.

Qué te cuesta que nadie mantenga tu software

No en abstracto. Estas son las cuatro formas en que aparece de verdad, más o menos en el orden en que las vas encontrando.

Los parches de seguridad se detienen, los atacantes no. Cuando se encuentra una vulnerabilidad en un framework con soporte, aparece un parche y lo instalas. Cuando se encuentra en uno sin soporte, se publica, se comenta, se agrega a las herramientas automáticas de escaneo, y nunca se corrige. El conocimiento se difunde y la defensa no. Este es el riesgo que más importa y el más difícil de ver, porque nada en tu aplicación se ve distinto.

Las tiendas suben el mínimo cada año. Apple y Google exigen que las aplicaciones apunten a un SDK reciente, y suben ese requisito todos los años. Una app que nadie ha tocado sigue funcionando para quien ya la tiene, y un día falla la revisión en una actualización pequeña de rutina. En ese momento no puedes publicar nada, incluida la corrección urgente que intentabas publicar, hasta que actualices todo. Escribimos más sobre cómo esto sorprende a la gente en cuando el software se lanza más rápido de lo que alguien alcanza a revisarlo.

Conseguir gente se vuelve más difícil y más caro cada año. Cada año que un framework está sin soporte, menos desarrolladores lo conocen y menos quieren trabajar en él. Los que quedan pueden cobrar más, y hacen bien. No solo pagas el trabajo, pagas que el grupo se está encogiendo.

Aquello a lo que se conecta avanza sin ti. Tu software habla con procesadores de pago, servicios de mapas, proveedores de identidad y herramientas de analítica. Todos ellos siguen cambiando. Los frameworks con soporte se actualizan para seguirles el paso. Los que no tienen soporte no, así que un día una integración simplemente deja de funcionar, y arreglarla ya no es algo pequeño.

Los que seguimos encontrando en producción

Estos aparecen con suficiente frecuencia en código real como para nombrarlos, con las fechas que anunciaron sus propios creadores.

Xamarin llegó al fin de soporte el 1 de mayo de 2024

Microsoft terminó por completo el soporte de Xamarin y Xamarin.Forms. Sin parches de seguridad, sin correcciones, nada. Muchas aplicaciones de negocio se construyeron sobre él, y la mayoría siguen funcionando.

El sucesor con soporte es .NET MAUI, y es un sucesor de verdad y no una reescritura desde cero: buena parte de la estructura y bastante del código C# se conserva. Si tu equipo es un equipo .NET, ese es casi seguro el camino. Si la app es pequeña, o si de todos modos no estabas contento con ella, este es un buen momento para preguntarte si Flutter o React Native te convendrían más. Esa pregunta trata sobre todo de quién mantiene la app después, no de cuál framework es mejor.

El soporte de AngularJS terminó en enero de 2022

Conviene ser claro, porque los nombres causan confusión real: AngularJS es la versión 1, y está terminada. Angular, sin el JS, es la moderna y está muy viva. Si tu equipo dice “usamos Angular”, eso puede significar cualquiera de las dos, y la diferencia son varios años de parches de seguridad.

Salir de AngularJS suele ser rehacer el front end más que actualizarlo, lo cual es una mala noticia que conviene conocer temprano. El destino es una elección normal entre Angular moderno, React y Vue, y lo que decide vuelve a ser tu equipo y no la tecnología.

Vue 2 llegó a su fin de vida el 31 de diciembre de 2023

Vue 2 todavía se instala y todavía funciona, y no recibe nada. El camino a Vue 3 es mejor que el de AngularJS, porque existe una ruta de migración real y una versión de compatibilidad, pero sigue siendo un proyecto y no un cambio de número de versión. Hay soporte extendido comercial de terceros si de verdad necesitas comprar tiempo, que es un puente razonable y una casa permanente cara.

Firebase Dynamic Links se apagó el 25 de agosto de 2025

Este es de la tercera categoría. Era un servicio, y Google lo apagó. Si tu aplicación usaba Dynamic Links para los enlaces que abren la app en el lugar correcto, o para saber qué campaña trajo a un usuario, esos enlaces dejaron de funcionar en vez de degradarse en silencio.

Los reemplazos son los Universal Links de Apple y los App Links de Android, que son las funciones de plataforma que están debajo, o un servicio comercial de deep linking si además quieres los reportes de atribución. Si no sabes si tu app lo usaba, es una pregunta de cinco minutos para quien la mantiene y vale la pena hacerla hoy.

InVision cerró a finales de 2024

La plataforma de colaboración en diseño cerró. En la práctica, la mayoría de los equipos ya se habían movido a Figma. Lo que sorprende a la gente no es la herramienta, es lo que había dentro: prototipos, comentarios y el registro de por qué una interfaz terminó siendo como es. Ese historial es fácil de perder sin darse cuenta e imposible de reconstruir después.

Adobe XD está en modo mantenimiento

Adobe no ha anunciado una fecha de fin de vida, así que este es menos urgente que los demás. Pero XD ya no se vende como aplicación independiente y no recibe funciones nuevas. Es una herramienta en declive lento, no una muerta, lo que significa que puedes planear con calma, y deberías.

Resumen: a dónde moverse

Cómo revisar tu propio software sin ser técnico

No necesitas leer nada de código. Envíale estas tres preguntas a quien mantiene tu software y lee las respuestas con atención.

1. ¿De qué frameworks y librerías depende nuestra app, y qué versión tiene cada una? Los números de versión son todo el punto. Una respuesta sin ellos no es una respuesta.
2. ¿Cuándo se actualizaron por última vez? No cuándo se cambió la app. Cuándo se actualizó lo que está debajo. Son fechas distintas y la distancia entre ellas es justo lo que estás midiendo.
3. ¿Algo de lo que dependemos pasó su fin de vida? Pregunta directa, respuesta directa. Es información pública y se comprueba en una tarde.

Un equipo que ha estado al día responde en un día, con detalle y sin ponerse a la defensiva. La vaguedad, la demora o una respuesta que habla de la app en vez de sus dependencias son en sí mismas el hallazgo. Si nadie puede responder, que pasa más seguido de lo que esperarías cuando el desarrollador original ya no está, una auditoría de software independiente te lo responde por escrito.

Qué hacer al respecto, y en qué orden

El instinto al leer una lista así es arreglarlo todo. No lo hagas. Migrar todo a la vez es la forma en que estos proyectos se convierten en el desastre que pretendían evitar. Ordénalo por riesgo.

Primero, todo lo que toca dinero, datos personales o inicios de sesión. Ahí es donde una vulnerabilidad sin parchear te cuesta algo de verdad, y es la única parte de esta lista que es genuinamente urgente.

Segundo, todo lo que bloquea una publicación. Si no puedes publicar una actualización de tu app, todo lo demás queda detenido detrás, incluido trabajo que no tiene nada que ver con esto.

Tercero, el declive lento. Herramientas de diseño, utilidades internas, cosas sin camino hacia un cliente. Reales, dignas de planear, no de una emergencia.

Y sé honesto sobre lo que no hay que hacer. El software que solo es viejo, pero tiene soporte, recibe parches y funciona bien, no es un problema, y reemplazarlo porque se siente anticuado es una forma de gastar mucho dinero en nada. Viejo y sin soporte son palabras distintas. Solo una de las dos es motivo para actuar.

La parte incómoda

Casi todo el que lee esto ya sospecha cuál es la respuesta para su propio software. La razón por la que no se revisa rara vez es ignorancia. Es que averiguarlo significa escuchar algo caro, y el software está funcionando ahora mismo, y siempre hay algo más urgente este trimestre.

Ese razonamiento aguanta durante sorprendentemente mucho tiempo, y después deja de aguantar de golpe, normalmente el día en que necesitas publicar un cambio urgente y descubres que no puedes. La versión barata de este problema es la que sales a buscar. La cara es la que te encuentra a ti.

Si quieres una respuesta directa sobre qué estás usando, hacemos auditorías de software independientes: tarifa fija, un informe escrito que te quedas, y una recomendación que puedes llevarte a donde quieras, incluso con otro equipo.