Diseñar para el momento exigente, no para una muestra pequeña
Una aplicación puede responder bien con pocos registros y alargar su ejecución cuando crece la carga. Antes de modificarla pedimos mediciones y ejemplos del proceso completo. El tamaño del fichero es un dato útil, pero también importan las relaciones entre registros y las operaciones que cada uno provoca.
Para una empresa onubense con actividad variable proponemos identificar la carga que debe soportar el sistema. No presuponemos una campaña ni un sector concreto: se utiliza el calendario y el volumen que aporte el cliente.
Distinguir espera, cálculo y acceso a datos
El tiempo total puede incluir esperas de archivos, consultas o servicios externos. Trasladar una rutina a otro lenguaje no mejora necesariamente esas partes. Separamos las etapas para localizar dónde se concentra el trabajo y qué hipótesis merece comprobarse.
Las propuestas de paralelización requieren una revisión de dependencias. Ejecutar dos partes a la vez puede ser incorrecto si comparten contadores, ordenaciones o actualizaciones. La velocidad no se persigue a costa de producir resultados difíciles de reconciliar.
Un piloto .NET con criterios de capacidad
Si se plantea C#, definimos una prueba funcional y otra de volumen dentro de las condiciones acordadas. El objetivo es conocer cómo responde el componente y cómo se comporta cuando no puede terminar. Se registran los recursos y el entorno de ensayo para interpretar las mediciones.
No publicamos una mejora porcentual antes de medir. El resultado del piloto puede revelar que conviene optimizar el acceso a datos o mantener una parte en COBOL, en lugar de ampliar la migración.
IA para localizar hipótesis que después se miden
Claude de Anthropic o herramientas de OpenAI pueden apoyar la revisión de bucles, accesos y dependencias. Sus propuestas de optimización se contrastan con pruebas. Una reescritura más compacta no demuestra que vaya a consumir menos tiempo o memoria.
Las muestras de carga pueden prepararse con datos sintéticos siempre que reproduzcan las características relevantes. El cliente y el equipo acuerdan qué distribución de valores debe ensayarse; generar muchas filas por sí solo no crea una prueba representativa.
Publicar fuera de un periodo comprometido
El plan de cambio incluye el momento operativo, las comprobaciones iniciales y el criterio para detener o revertir. Si la aplicación necesita funcionar durante un periodo de alta carga, se valora si existe margen para experimentar o conviene esperar a una ventana acordada.
Un ejemplo sería mejorar una preparación masiva de documentos antes de ampliar su uso. Esta situación explica el enfoque del servicio y no describe un trabajo realizado en Huelva. El alcance se decide con mediciones y restricciones de la aplicación concreta.