Un ejecutable que funciona no garantiza que pueda modificarse
Para mantener una aplicación hace falta conocer sus fuentes, herramientas de construcción y dependencias. Una copia del programa en uso puede no ser suficiente. Empezamos por separar lo disponible de lo que debe recuperarse o solicitarse a otro proveedor.
En proyectos para empresas cacereñas, ese inventario permite evitar un presupuesto basado en una aplicación que parece accesible pero no se puede reconstruir. Las carencias se registran con su efecto sobre el alcance.
Dependencias técnicas y decisiones comerciales
Una librería o una herramienta puede necesitar una versión concreta o una condición de licencia. No damos asesoramiento contractual sobre su uso, pero sí identificamos que esa dependencia debe aclararse con su titular antes de incluir una solución en el proyecto.
También revisamos los formatos de datos y las interfaces disponibles. Si existe una vía documentada de exportación, puede ofrecer un camino distinto al de modificar el programa. La alternativa se estudia por lo que permite demostrar y mantener.
Comparar continuidad, adaptación y migración
Mantener COBOL, crear un adaptador o trasladar una función a C# y .NET son opciones con costes y riesgos diferentes. El análisis describe qué problema resuelve cada una y qué dependencias conserva. No se presenta una reescritura como un remedio automático a toda dependencia de proveedor.
Un piloto puede centrarse en una función cuyo comportamiento y acceso estén claros. Los componentes no disponibles quedan fuera hasta resolver su relación con el proceso.
IA sobre materiales que se pueden utilizar
OpenAI o Claude, de Anthropic, pueden ayudar a revisar el código autorizado y preparar documentación. El permiso para mantener una aplicación no se interpreta automáticamente como autorización para enviar todo su contenido a un servicio externo. Esa decisión se acuerda antes del análisis asistido.
La IA tampoco puede confirmar una compatibilidad que depende de herramientas no disponibles. Sus propuestas se contrastan con documentación y con una construcción real cuando sea posible.
Una primera entrega para tomar decisiones
El resultado puede ser un inventario de componentes, una prueba de construcción y una lista de alternativas con sus condiciones. A veces esa fase descubre que conviene resolver primero un acceso o recuperar una versión de fuentes.
Un ejemplo sería una aplicación que se ejecuta correctamente, pero cuyo entorno de compilación ya no está preparado. El piloto intentaría reconstruir una versión de ensayo y documentar lo necesario. Es un escenario explicativo, no un trabajo realizado en Cáceres.