Una pantalla web no debe saltarse las reglas del sistema
Modernizar la presentación puede parecer sencillo si ya existe una base de datos. Sin embargo, escribir directamente en sus tablas podría omitir validaciones que realiza COBOL. El diagnóstico identifica la vía correcta para ejecutar cada operación y las condiciones que debe respetar el canal nuevo.
Para una empresa malagueña que necesite acceso web, proponemos comenzar por un recorrido concreto de usuario. Se define qué puede consultar, qué puede modificar y qué respuesta necesita cuando la operación no se completa.
Diseñar para esperas y respuestas incompletas
Un proceso que antes se ejecutaba de forma interna puede tardar más de lo que espera una pantalla. Se decide si la solicitud espera, queda registrada para su ejecución o permite consultar su estado posteriormente. Cada opción tiene consecuencias sobre los reintentos.
El usuario debe saber si ha enviado una petición o si el trabajo ha terminado. Una interfaz agradable no compensa una confirmación ambigua que provoque clics repetidos y operaciones duplicadas.
Qué puede asumir C# y .NET
La nueva capa puede gestionar presentación, acceso y coordinación, mientras COBOL conserva la lógica central. También se puede estudiar la extracción de una función concreta. La elección depende del objetivo y de la posibilidad de demostrar equivalencia.
Se evita crear una segunda versión de la misma regla en la web por comodidad. Si la regla se traslada al destino, se define qué componente pasa a ser la referencia durante la convivencia y cómo se impide que ambas versiones diverjan.
Asistencia de IA con controles sobre el alcance
Claude de Anthropic o herramientas de OpenAI pueden ayudar a preparar adaptadores, documentación y pruebas. Revisamos especialmente las suposiciones sobre autenticación, permisos y respuesta ante errores. La generación de código no autoriza a exponer una operación interna a cualquier visitante.
Antes de analizar un repositorio se acuerdan los accesos y la información permitida. El objetivo es trabajar sobre materiales suficientes para el proyecto, no enviar al modelo todo el sistema porque resulte más cómodo.
Ensayar el recorrido que utilizará la persona
Las pruebas incluyen el inicio de sesión cuando corresponda, la selección de datos, el envío y la consulta del resultado. También se revisa qué información aparece ante un error para evitar mostrar detalles internos o datos de otros usuarios.
Un ejemplo sería habilitar una consulta externa del estado de una solicitud, sin permitir todavía modificarla. Ese piloto ayuda a validar el acceso y la actualización. Es un escenario explicativo, no una implantación atribuida a una organización de Málaga.