Una aplicación puede seguir funcionando cuando termina el soporte de su plataforma. Los clientes entran, se generan facturas y el alojamiento continúa disponible. Esa continuidad visible puede esconder un cambio importante: la versión que sostiene la aplicación ya no dispone de la misma vía de actualizaciones y asistencia.
Para una empresa, estas fechas forman parte de la planificación operativa. Influyen en cuándo reservar presupuesto, quién debe aprobar las pruebas y cuánto tiempo tienen los proveedores para resolver incompatibilidades. Esperar a una caída para hacer visible el problema puede dejar menos alternativas que revisar el calendario mientras el sistema funciona.
Las fechas concretas de .NET
Microsoft fija el 10 de noviembre de 2026 como fecha de fin de soporte de .NET 8 y .NET 9. Su aviso explica que después terminan las actualizaciones de mantenimiento, correcciones de seguridad y asistencia para esas versiones. La política oficial sitúa el final del soporte LTS de .NET 10 el 14 de noviembre de 2028. Son fechas de plataforma, no una garantía de migración sin cambios. Consulta el aviso oficial y la política de soporte.
Utiliza esas fechas para revisar tu aplicación concreta. Si depende de un componente externo sin soporte, quizá haga falta algo más que cambiar la versión de .NET. Un producto empaquetado puede depender del calendario de su fabricante. Registra esas condiciones; el ciclo de la plataforma no describe por sí solo todo el sistema.
Inventaría lo que realmente se ejecuta
Pide al equipo que identifique aplicación desplegada, versión utilizada e infraestructura. Incluye tareas programadas, procesos en segundo plano y pequeñas integraciones. Pueden ser menos visibles que la web y resultar imprescindibles para facturación, existencias o avisos a clientes.
Comprueba producción en lugar de depender únicamente del proyecto o del ordenador del desarrollador. Un servidor puede tener varias versiones instaladas, y un contenedor o una aplicación autocontenida puede incorporar su propio entorno. Lo importante es saber cuál utiliza cada servicio y cómo se actualiza ese despliegue.
Asigna responsable y finalidad de negocio a cada elemento. Una hoja llena de versiones no es un plan si nadie sabe quién aprueba el trabajo. Relaciona cada servicio con la tarea del cliente o del equipo que permite realizar, para discutir prioridades en términos comprensibles.
Separa la fecha límite del alcance de la migración
El calendario de soporte indica cuándo cambia una condición de mantenimiento. No determina cuántos días necesita tu migración. Estima el trabajo a partir de dependencias, pruebas, despliegues y comportamiento que debe conservarse.
Una herramienta interna sencilla, con compilaciones reproducibles y pocas conexiones, puede necesitar una investigación acotada. Una integración de ERP muy personalizada y sin reglas documentadas puede exigir sobre todo entender su funcionamiento actual. Son proyectos distintos aunque ambos utilicen la misma versión de .NET.
Pide una revisión inicial antes de aceptar un calendario detallado. Debe identificar incompatibilidades, pruebas ausentes y decisiones que requieren al proveedor o al responsable de negocio. Así la empresa puede elegir un alcance realizable, en lugar de aprobar una fecha basada únicamente en expectativas optimistas.
Durante esa revisión conviene distinguir lo confirmado de lo pendiente. Una dependencia instalada no equivale a una dependencia probada; una copia del proyecto no demuestra que se pueda desplegar. Señalar esas diferencias ayuda a preparar el trabajo que falta y evita presentar incertidumbre como si fuera esfuerzo ya resuelto.
Prueba las operaciones de las que depende el equipo
Elige ejemplos capaces de revelar una regresión importante: calcular un presupuesto, importar un pedido, emitir una factura o generar un informe de expedición. Documenta resultados esperados a partir de entradas conocidas y acuerda quién puede validarlos.
Compilar correctamente es necesario, pero no demuestra que esas operaciones sigan siendo válidas. Una dependencia actualizada puede cambiar formato, autenticación, acceso a datos o comunicación externa. Incluye las integraciones relevantes en las pruebas exigidas para publicar.
Prepara datos y accesos con antelación. Una migración puede retrasarse porque nadie sabe reproducir una configuración o aportar un ejemplo seguro de un registro complicado. El negocio ayuda identificando excepciones importantes; el equipo técnico prepara un entorno y un tratamiento de datos adecuados.
Incluye despliegue y recuperación en la propuesta
Acuerda cómo llegará la nueva versión a producción y qué demostrará que funciona. En una aplicación de clientes, esto incluye comprobar una operación completa después del despliegue. Asigna quién observará el resultado y quién actuará si difiere de lo esperado.
Habla de los límites de volver atrás. Recuperar la aplicación anterior puede ser sencillo si los datos siguen siendo compatibles. Un cambio de base de datos puede necesitar otro procedimiento. Pide que se explique qué es reversible, qué exige conciliación y en qué condiciones se detendría la entrega.
Evita unir mejoras ajenas a una actualización urgente sin una razón clara. Una funcionalidad nueva, un rediseño y un cambio de plataforma pueden ser útiles, pero combinarlos aumenta el comportamiento que hay que comprender y verificar. Decide qué cambios deben viajar juntos y cuáles conviene entregar después.
Define la responsabilidad de los proveedores
Si otra empresa suministra un componente o aplicación, solicita sus versiones admitidas y su ruta de actualización. Comprueba que la propuesta contempla tus extensiones e integraciones. Un anuncio general no demuestra que incluya una instalación personalizada.
Aclarad quién investigará un fallo que aparece entre dos productos. El equipo de aplicación puede necesitar al proveedor del ERP para resolver un cambio de autenticación. Reserva tiempo para coordinar y señala quién puede tomar decisiones comerciales si hace falta una actualización de pago.
Después de publicar, actualiza la documentación operativa. Soporte necesita conocer versión desplegada, procedimiento de construcción y entrega, excepciones pendientes y siguiente revisión. De lo contrario, la empresa puede completar bien una migración y preparar la misma incertidumbre para la siguiente fecha límite.
Incorpora el ciclo de soporte al mantenimiento habitual
Mantén un calendario breve con fechas importantes de plataformas y dependencias. Revísalo junto con entregas previstas y momentos del negocio, como campañas o cierres contables. El objetivo es dejar espacio para investigar y probar sin convertir cada tarea de mantenimiento en una emergencia.
En Worktechlabs podemos evaluar una aplicación .NET existente, concretar el alcance de actualización y relacionarlo con el soporte continuado. Trae inventario, proveedores, información de despliegue y ejemplos de operaciones críticas. Un primer resultado útil es un plan priorizado con responsables y condiciones verificables de entrega, para convertir una fecha pública de soporte en trabajo gestionable dentro de tu empresa.
Información de ciclo de vida contrastada el 7 de octubre de 2026 con la política publicada por Microsoft. Revisa la política vigente y las dependencias concretas al planificar la implementación.
