Soporte extendido de AngularJS: un puente y sus límites

El soporte pagado de AngularJS puede cerrar la brecha de seguridad mientras migras. No moderniza nada. Esto es lo que recibes, lo que no recibes y cuándo vale la pena pagarlo.

Qué es el soporte extendido

Después del fin de soporte oficial, varios proveedores comerciales empezaron a mantener su propia continuación de AngularJS 1.x. Pagas una suscripción y recibes builds parchados del framework. Cuando se reporta una vulnerabilidad nueva, el proveedor la corrige en su versión y publica una actualización. En la mayoría de los casos cambias el origen del paquete y tu código queda igual.

Es el mismo modelo que las empresas usan con sistemas operativos y runtimes antiguos: alguien distinto del autor original mantiene seguro el software a cambio de un pago.

Qué suele cubrir

Las ofertas varían entre proveedores, así que usa esto como una lista para verificar:

• Parches de seguridad para el núcleo del framework y los módulos oficiales angular-*, como rutas, sanitización y animaciones.
• Correcciones de fallas causadas por versiones nuevas de los navegadores.
• Un paquete de reemplazo directo, que sustituye al oficial sin cambios de código.
• Documentación para auditorías. Un contrato de soporte, notas de cada parche y una declaración que puedes entregar a un auditor o a un cliente.
• Un compromiso de respuesta ante vulnerabilidades nuevas, escrito en el contrato.

Algunos proveedores también cubren ciertas librerías de terceros del ecosistema AngularJS. Pide la lista exacta.

Qué no cubre

• Tu propio código. Los errores y debilidades de tus controladores, templates y servicios siguen siendo tuyos.
• Librerías fuera del catálogo del proveedor. Los plugins viejos de jQuery, grillas, editores y kits de UI que nadie mantiene siguen sin parches.
• La cadena de build. Las versiones viejas de Node, los task runners y los bundlers quedan fuera del alcance.
• La contratación. AngularJS con soporte sigue siendo AngularJS. Los candidatos reaccionan igual.
• La velocidad de entrega. El código es tan difícil de cambiar como antes.
• Capacidades nuevas. Recibes correcciones. No recibes funcionalidades, mejoras de rendimiento ni un camino hacia herramientas modernas.

Cuándo tiene sentido

• Hay una migración planificada que va a tomar varios trimestres. El soporte cubre la brecha hasta que desaparezca la última pantalla AngularJS.
• Una auditoría o un contrato con un cliente exige software con soporte ahora. Una suscripción puede estar activa mucho antes de que termine una migración.
• La app tiene fecha de retiro. Pagar soporte hasta esa fecha puede costar menos que migrar algo que vas a apagar.
• La app es estable y casi no cambia. Si nadie necesita funcionalidades nuevas, el argumento de velocidad para migrar es débil, y los builds parchados pueden alcanzar por mucho tiempo.

Cuándo no

• El dolor principal es la entrega lenta o la contratación. El soporte no arregla ninguna de las dos.
• La mayoría de los hallazgos del escáner viene de otras librerías. Revisa dónde están realmente tus hallazgos antes de comprar.
• Se convierte en el motivo para postergar otra vez la migración. Un puente sin otra orilla es un costo recurrente sin fin.

Preguntas para el proveedor

1. ¿Qué paquetes y versiones están cubiertos, exactamente?
2. ¿En cuánto tiempo se comprometen a parchar una vulnerabilidad recién publicada, y dónde está escrito?
3. ¿Corrigen problemas que ustedes mismos descubren, o solo los públicos?
4. ¿Cómo se entregan los parches: registro privado, archivo, CDN?
5. ¿Nuestro escáner de dependencias va a reconocer la versión parchada, o seguirá marcando el paquete? ¿Cómo lo manejan otros clientes con sus auditores?
6. ¿Qué pasa con el acceso a los parches anteriores si cancelamos?
7. ¿El precio es por aplicación, por desarrollador o por organización?
8. ¿Pueden entregar un documento para nuestro auditor que describa la cobertura?

La pregunta 5 importa más de lo que parece. Si tu escáner sigue levantando los mismos hallazgos, alguien de tu equipo tiene que documentar cada excepción.

Cómo comparar el costo

Pide cotización a por lo menos dos proveedores, con tu cantidad real de aplicaciones. Luego compara la tarifa anual con las primeras fases de una migración, usando el método de la guía de costos de migración. Hay dos patrones que conviene revisar. En una app pequeña, la tarifa acumulada durante el plazo planificado puede acercarse al costo de migrarla, y entonces conviene migrar. En una app grande con una migración larga por delante, el soporte durante la migración es una línea razonable del presupuesto.

Úsalo como un puente con fecha de término

1. Contrata por el plazo más corto que cubra tu plan de migración.
2. Pon el fin de la suscripción en la hoja de ruta de la migración, como un hito.
3. Dile a tu auditor las dos cosas juntas: builds parchados ahora y eliminación en una fecha definida. La guía de seguridad y cumplimiento explica cómo presentarlo.
4. Revisa el avance antes de cada renovación. Si la migración no se movió, la conversación de renovación es el momento de preguntar por qué.

El soporte extendido es uno de varios caminos. La comparación completa está en Fin de soporte de AngularJS: tus opciones.

Más en esta sección

• Cómo armar el caso de negocio para modernizar el frontend
• Una hoja de ruta por fases para modernizar el frontend
• Cómo elegir un partner para migrar tu frontend
• Riesgos de una migración de frontend y cómo reducirlos