Cosas que la IA no te dirá al migrar a NET 10

Con la llegada de la IA, quizás alguna tarea tediosa como es migrar de versión de Framework es algo tan trivial, que seguramente el numéro de busquedas, articulos, tutoriales este año se ha reducido bastante, sin embargo yo creo que este año es algo mucho más importante que en los anteriores. El motivo es que el subir una versión del framework puede ser algo tan sencillo como cambiar un csproj, y subir las versiones de los nuget correspondiente. Pero eso es realmente lo que se considera subir una versión? Yo no y me explico si tu subess tu proyecto a NET 10 pero aun tienes alguna dependencia de algún nuget que este en versiones anteriores te funcionará, sin embargo es algo que se penaliza en el rendimiento, seguridad de tu aplicación y luego cuando se muestra un gran problema de alguna plataforma nos pondremos manos a la cabeza que como puede pasar eso si esta todo a ahora a la última versión.

En este articulo además de mostrar el como vamos a abordar una migración, intentaré que pensemos de algunas decisiones que la IA seguro que no te propone y que igual es un buen momento de plantearte.

Lo que trae .NET 10 respecto a .NET 9/8

#

Si analizamos qué aspectos nos pueden llevar a abordar esta migración, el primero es obvio: finaliza el soporte para .NET 8 en noviembre de 2026 y .NET 9 en mayo de 2026. Eso implica que si se encuentra una vulnerabilidad no vas a tener soporte del fabricante y estarás solo ante el peligro. Esperemos que queden atrás los tiempos en los que las compañías no migraban de versión de framework porque implicaba un drama y se quedaban ahí hasta el fin de los días.

Pero más allá del soporte, .NET 10 es una versión LTS (Long-Term Support), lo que significa tres años de soporte garantizado, al igual que fue .NET 6 y .NET 8. Si tu proyecto está en .NET 9, estás en una versión STS (18 meses de soporte), así que el salto a .NET 10 tiene todavía más sentido para entornos productivos.

Desde el punto de vista técnico, las mejoras más relevantes que trae .NET 10 son:

• Rendimiento del JIT y el GC: cada versión de .NET mejora el compilador JIT y el recolector de basura. En .NET 10 hay optimizaciones especialmente notables para aplicaciones con alta concurrencia y escenarios de servidor.
• Native AOT más maduro: la compilación anticipada (Ahead-Of-Time) ha ganado compatibilidad con más escenarios, incluyendo mejor soporte en ASP.NET Core y gRPC.
• C# 14: nuevas características del lenguaje como field-backed properties, extensiones de tipos mejoradas y mejoras en los patrones.
• ASP.NET Core: mejoras en Blazor, en el pipeline de middleware y en OpenAPI/Swagger integrado de forma nativa.
• EF Core 10: mejoras en el mapeo de colecciones, soporte más completo de SQL generado y rendimiento en consultas complejas.
• Mejoras en System.Text.Json: mayor rendimiento y soporte para más escenarios de serialización sin configuración adicional.

Todo esto está muy bien, pero la pregunta es: ¿qué implica realmente subir la versión?

La migración que la IA sí hace (y la que no)

#

Si le pides a cualquier asistente de IA que te ayude a migrar tu proyecto a .NET 10, probablemente obtendrás algo como esto:

# Cambia el TargetFramework en tu .csproj
<TargetFramework>net10.0</TargetFramework>

# Actualiza los paquetes
dotnet outdated --upgrade

Y técnicamente no está mal. El proyecto compilará, los tests pasarán y todo aparentará funcionar. El problema es que eso no es una migración real, es un cambio de número de versión.

La IA no suele plantearte las preguntas incómodas. Esas son las que vamos a ver a continuación.

Lo que la IA no te pregunta

#

¿Tus dependencias transitivas son compatibles?

#

Este es el punto que más problemas genera y el que menos gente revisa. Cuando actualizas tus paquetes NuGet directos, no siempre ves qué traen por debajo.

Un paquete puede declarar compatibilidad con net10.0 pero tirar de una dependencia que internamente usa APIs deprecated o que tiene un comportamiento diferente en .NET 10. Para inspeccionar el árbol de dependencias real:

dotnet list package --include-transitive

Busca paquetes que no tengan soporte explícito para net10.0 y que estén usando el target netstandard2.0 o netstandard2.1. Funcionarán, pero no se beneficiarán de ninguna de las mejoras de rendimiento y pueden tener incompatibilidades silenciosas.

¿Tu Dockerfile y tu pipeline de CI están actualizados?

#

Es uno de los errores más frecuentes: el código migra a .NET 10, pero el Dockerfile sigue usando la imagen base de .NET 8 o .NET 9.

# ❌ Antes
FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base

# ✅ Después
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS base

Lo mismo aplica a tu global.json si lo tienes, y a las acciones de GitHub o pipelines de Azure DevOps que especifiquen la versión del SDK:

# GitHub Actions
- uses: actions/setup-dotnet@v4
  with:
    dotnet-version: '10.x'

¿Tienes APIs deprecadas que ahora sí rompen?

#

.NET tiene la costumbre de deprecar APIs con bastante antelación antes de eliminarlas. En .NET 10 hay varias que pasan de warnings a errores de compilación o cambios de comportamiento. El compilador te avisará con warnings de tipo SYSLIB, pero es fácil ignorarlos si tienes la política de warnings configurada de forma laxa.

Ejecuta la compilación con warnings elevados a errores para forzarte a revisarlos:

dotnet build /WarnAsError

No es necesario que lo dejes así en producción, pero es un buen ejercicio para saber exactamente qué tienes pendiente de revisar.

¿Es el momento de revisar tu arquitectura?

#

La IA te ayudará a migrar el código tal como está. No te dirá que igual tienes un HttpClient instanciado con new en lugar de usar IHttpClientFactory, o que tus DbContext no están configurados de la forma más eficiente posible para .NET moderno.

Una migración de versión de framework es uno de los mejores momentos para plantearse:

• ¿Estamos usando los patrones modernos de .NET (minimal APIs, generic host, options pattern)?
• ¿Hay código que fue escrito para .NET Framework y nunca se modernizó del todo?
• ¿Tenemos tests que cubran los flujos críticos antes de cambiar la base?

Este último punto es especialmente importante: si no tienes tests, la migración es un salto de fe. Con tests, es una operación controlada.

¿Tu configuración de seguridad sigue siendo adecuada?

#

.NET 10 actualiza las políticas de seguridad por defecto. Algunas configuraciones que antes eran opt-in ahora son el comportamiento por defecto. Esto afecta a:

• TLS: versiones mínimas de TLS aceptadas
• Criptografía: algoritmos considerados débiles que pueden quedar deshabilitados por defecto en algunas plataformas
• CORS y headers HTTP: cambios en los valores por defecto de ASP.NET Core

Revisa la guía de breaking changes de .NET 10 antes de asumir que todo funciona igual que antes.

¿Necesitas realmente todas tus dependencias?

#

En muchos artículos hablo de cuestionarse si añadir una dependencia externa es algo que realmente hace falta. Una buena migración es una excusa perfecta para hacerse esa pregunta con cada paquete del packages.lock.json.

Tomemos Polly como ejemplo: es una librería fantástica para gestionar reintentos, circuit breakers y políticas de resiliencia. Pero, ¿necesitas Polly, o necesitas reintentar tres veces una llamada HTTP con backoff exponencial? Porque eso segundo lo puedes implementar en veinte líneas de código, y con IA en menos tiempo del que tardas en buscar la documentación de Polly.

Mi criterio personal es este: antes de mantener una dependencia externa, hazte estas preguntas:

• ¿Podrías hacer un fork si mañana pasa a ser de pago o queda sin mantenimiento?
• ¿Un desarrollador senior del equipo podría reimplementar lo que usas de esta librería en una tarde?
• ¿Estás usando el 10% de lo que ofrece?

Si la respuesta a las dos últimas es sí, igual merece la pena valorar si la dependencia te aporta más del coste que tiene en términos de superficie de ataque, actualización y compatibilidad con cada nueva versión del framework.

Esto no significa reescribir todo desde cero. Significa ser más selectivo. Las librerías grandes y bien mantenidas como EF Core, Serilog o MediatR tienen sentido. Pero hay decenas de paquetes en muchos proyectos que están ahí por inercia, y una migración es el momento ideal para revisarlos.

El riesgo real del open source: cuando lo gratuito deja de serlo

#

En los últimos años hemos visto un patrón que se repite con más frecuencia de la que nos gustaría: proyectos open source muy populares que cambian su licencia o modelo de negocio. No son casos aislados.

• HashiCorp cambió Terraform de MPL a BSL en 2023, lo que forzó a muchas empresas a evaluar su exposición y llevó a la comunidad a crear OpenTofu como fork.
• Redis cambió su licencia a RSALv2 + SSPLv1 en 2024, dejando de ser open source en el sentido estricto. AWS respondió con Valkey.
• Elasticsearch ya había hecho lo mismo antes con SSPL, lo que llevó a Amazon a crear OpenSearch.
• ImageSharp (Six Labors), muy usada en proyectos .NET para procesado de imágenes, pasó a requerir licencia comercial para uso en productos no open source.
• Moq generó una crisis de confianza en 2023 cuando introdujo SponsorLink, que escaneaba datos de los desarrolladores sin aviso explícito. El paquete fue descargado millones de veces antes de que la comunidad reaccionara.

¿Qué tienen en común todos estos casos? Que las empresas afectadas no los vieron venir, y cuando ocurrieron tuvieron que decidir rápido: pagar la licencia, migrar a una alternativa, o congelar la versión y asumir el riesgo de seguridad.

El coste que nadie presupuesta

#

Cuando introduces una dependencia en tu proyecto, estás asumiendo un riesgo implícito que no aparece en ningún presupuesto. Si mañana esa librería cambia de licencia, los posibles escenarios son:

1. Pagar la licencia comercial, que puede ser desde razonable hasta prohibitiva dependiendo del tamaño de tu empresa y el modelo de precios del proveedor.
2. Migrar a una alternativa, con el coste de desarrollo, testing y el riesgo de regresiones que eso implica. Y que puede coincidir con un momento crítico del negocio.
3. Congelar la versión, lo que significa quedarte sin actualizaciones de seguridad y acumular deuda técnica. Precisamente lo contrario de lo que intentas conseguir con una migración a .NET 10.

Cómo anticiparte antes de que sea un problema

#

La buena noticia es que hay señales de alerta que puedes vigilar antes de que un proyecto cambie de licencia. La mala es que requiere criterio humano, no es algo que la IA te vaya a proactivar.

Revisa la salud del proyecto antes de adoptarlo:

• ¿Quién lo mantiene? ¿Es una empresa con necesidad de monetizar o una comunidad distribuida?
• ¿Tiene una fundación detrás (Apache, CNCF, .NET Foundation)? Eso reduce el riesgo de cambios de licencia unilaterales.
• ¿La empresa que lo mantiene ha levantado rondas de inversión? Las startups con inversores buscan rentabilidad, y el open source es una estrategia de adquisición, no un modelo de negocio sostenible en sí mismo.

Para las dependencias que ya tienes:

• Audita las licencias con dotnet-delice o nuget-license. Conoce exactamente bajo qué condiciones estás usando cada paquete.
• Identifica cuáles son críticas para tu negocio y cuáles son reemplazables. No todas merecen el mismo nivel de vigilancia.
• Para las críticas y difíciles de reemplazar, evalúa si tiene sentido hacer una abstracción sobre ellas (un adapter o wrapper) para aislar el impacto de un cambio futuro.

Establece un proceso de revisión periódica:

Una migración de versión de framework es el momento perfecto para hacer esta auditoría, pero no debería ser la única vez. Un inventario semestral de dependencias, sus licencias y su estado de mantenimiento es una práctica que pocos equipos tienen y que puede evitar una crisis en el peor momento posible.

El open source ha cambiado. Ya no es suficiente con que algo sea gratuito hoy. La pregunta que debes hacerte es: ¿seguirá siendo sostenible para mi proyecto dentro de tres años?

Un enfoque práctico para la migración

#

Si tuviera que proponer un orden de trabajo, sería este:

1. Inventario: lista todos los proyectos de la solución, sus dependencias directas y transitivas, y sus licencias.
2. Actualiza el SDK: instala el SDK de .NET 10 y actualiza global.json.
3. Cambia el TargetFramework en cada .csproj.
4. Actualiza los paquetes NuGet proyecto a proyecto, no todos de golpe.
5. Compila con warnings activados y revisa cada SYSLIB warning.
6. Ejecuta los tests y analiza cualquier diferencia de comportamiento.
7. Actualiza la infraestructura: Dockerfile, CI/CD, variables de entorno.
8. Despliega en un entorno de staging antes de ir a producción.

La IA puede ayudarte con cada uno de estos pasos, pero la decisión de cuándo avanzar al siguiente y qué implicaciones tiene cada cambio es tuya.

Conclusión

#

Migrar a .NET 10 en 2026 no es opcional si quieres mantener soporte, seguridad y rendimiento. Y la IA puede acelerar mucho el proceso mecánico de la migración. Pero hay decisiones que requieren contexto de negocio, de arquitectura y de riesgo que ningún modelo de lenguaje puede tomar por ti.

El valor del desarrollador hoy no está en saber cambiar un csproj, sino en saber qué preguntas hacer antes de hacerlo.