Un líder de desarrollo con el que trabajé, llamémoslo Diego porque ese no es su nombre real, me escribió un mensaje que empezaba con "creemos que estamos listos para arrancar la migración". Su equipo había pasado dos semanas mapeando su propio código: qué hacía cada pantalla, dónde vivía cada lógica de negocio, en qué orden abordar las cosas. Un trabajo prolijo y cuidadoso.
Después alguien abrió la pantalla de ingreso de pedidos para planificar su reescritura y descubrió que estaba construida casi por completo alrededor de un control de grilla comercial. Ordenamiento, edición en línea, exportación a Excel, navegación por teclado, todo manejado por un componente de un proveedor licenciado años atrás. El sitio del proveedor todavía existía. Su versión "para .NET moderno" no. El producto había sido discontinuado en silencio, y la versión más nueva que alguien pudo encontrar estaba hecha para .NET Framework y nada más.
Ese único control pasó a ser la razón por la que toda la pantalla no podía avanzar según el cronograma, y nadie lo había puesto en el mapa original de dos semanas, porque no es código que nadie haya escrito. Es fácil olvidarse de algo en lo que nunca tuvo que pensar.
Por qué este obstáculo se esconde tan bien
Cuando un equipo planifica una modernización, instintivamente audita lo que construyó. Lógica de negocio, acceso a datos, autenticación, la estructura de sus propias clases y servicios. Ese es el código que escribieron, el código que entienden, el código que se siente como "el sistema".
Los controles de terceros no se sienten así. Compraste una licencia una vez, colocaste el control en una pantalla, y lleva una década funcionando en silencio. No está en tu modelo mental de "nuestro código" porque nunca se sintió como algo que construyeron. Se siente más como una herramienta, más cercano a cómo pensarías en el sistema operativo debajo de todo, que como una pieza de la aplicación de la que sos responsable.
Por eso exactamente se pasa por alto en la planificación. No está escondido a propósito. Está escondido por la familiaridad, por haber funcionado sin quejas durante tanto tiempo que nadie tuvo motivo para abrir su carpeta y revisar qué es en realidad.
Las tres formas en que esto termina, y son costos muy distintos
Una vez que encuentra una de estas dependencias, en realidad hay tres resultados posibles, y la brecha entre el mejor y el peor es enorme.
El resultado bueno: el proveedor sigue existiendo, sigue manteniendo el producto, y tiene una versión compatible con .NET moderno. La conversión es en su mayoría mecánica: actualizar referencias, ajustar algunas llamadas a la API, volver a probar la pantalla. Una tarea real, pero acotada y predecible.
El resultado doloroso: el proveedor existe, pero nunca lanzó una versión para .NET moderno, y probablemente nunca lo haga. No hay un camino de actualización directo. Esa pantalla necesita reconstruirse usando una librería actual o un enfoque nativo del navegador, lo que suele significar re-derivar el comportamiento que el control original te daba gratis, como columnas ordenables o validaciones complejas, y a veces el alcance original de "actualizar" se convierte en silencio en "rediseñar".
El peor resultado: el proveedor desapareció por completo. Adquirido, cerrado, o simplemente se esfumó, y nadie en el equipo actual tiene el instalador, la clave de licencia, ni el código fuente. Vi esto con controles que eran centrales en una pantalla usada todos los días, donde la única copia restante de la DLL funcionando estaba en una carpeta bin de un servidor de producción, sin forma de confirmar siquiera qué versión era ni de conseguir un reemplazo si ese servidor alguna vez necesitara reconstruirse desde cero.
Por qué encontrar esto durante la Auditoría lo cambia todo
La diferencia entre estos resultados no es algo que se descubra adivinando. Es algo que se descubre abriendo de hecho cada referencia del proyecto y revisando, proveedor por proveedor, control por control: si todavía tiene soporte, si existe una versión para .NET moderno, y si la licencia sigue siendo válida.
Esa revisión es exactamente el tipo de trabajo que corresponde a una Auditoría, antes de tocar una sola línea de código. Descubrir en la primera semana que una pantalla necesita una reconstrucción completa cambia la hoja de ruta y la estimación, pero las cambia en el papel, donde el único costo es una conversación. Descubrirlo en el tercer mes, después de que un equipo ya comprometió un sprint a "solo convertir" esa pantalla, también cambia la hoja de ruta y el presupuesto, pero ahora además cuesta moral, una fecha interna incumplida, y una conversación incómoda con quien esté esperando el proyecto.
Un costo conocido de antemano es un ítem de la lista. Una sorpresa a mitad de camino es una crisis, sin importar cuán pequeño pareciera el control el día que alguien lo puso por primera vez en una pantalla.
Cómo se ve esto en la práctica
La revisión en sí no es exótica. Es un inventario deliberado: cada ensamblado de terceros referenciado en el proyecto, cada uno verificado contra el sitio actual de su proveedor, cada licencia revisada por validez, y cada pantalla que depende fuertemente de alguno marcada con una nota sobre cuál de los tres resultados aplica. Requiere atención real, pero es un trabajo finito y poco glamoroso, y por eso justamente vale la pena hacerlo a propósito en vez de esperar a encontrárselo por accidente.
Hago esta revisión en cada Auditoría ahora, como consecuencia directa de aquel mensaje que me escribió Diego. Es uno de los ejemplos más claros que conozco de una pequeña diligencia debida que compra una enorme cantidad de certeza más adelante.
El ancla que no se ve sigue siendo un ancla
El riesgo legacy no vive solo en código que alguien escribió mal hace diez años. A veces vive en un componente que alguien eligió bien hace diez años, que simplemente sobrevivió a la empresa que se lo vendió. De cualquier forma, ancla el proyecto al pasado hasta que alguien lo va a buscar a propósito.
Si estás planificando una modernización y todavía no inventariaste cada dependencia de terceros de la que realmente dependen tus pantallas, vale la pena hacerlo antes de escribir la hoja de ruta, no después.