Modernización de aplicaciones: de Access a una aplicación web preparada para crecer

Una empresa española de suministros agrícolas sustituyó su proceso de repartos basado en Microsoft Access y hojas de cálculo por una aplicación web empresarial conectada con SQL Server, conservando la flexibilidad de trabajo que tenía el equipo. Este proyecto de modernización de aplicaciones es un ejemplo de cómo trasladar lógica operativa acumulada durante años a una arquitectura actual, sin perder lo que hace funcionar el negocio.

Resumen ejecutivo
Cliente	DELAGRO
Sector	Agroalimentario · distribución de suministros y servicios para el sector agrario
País	España
Servicio	Modernización de aplicaciones y automatización de procesos
Tecnologías	Angular · Node.js/NestJS · SQL Server
Proceso intervenido	Cálculo, validación y ejecución de repartos
Estado	Implantada en producción, en evolución

Qué es la modernización de aplicaciones

La modernización de aplicaciones consiste en trasladar una herramienta interna que ya no da más de sí —normalmente una base de datos de Access, un conjunto de hojas de cálculo o un desarrollo antiguo— a una arquitectura actual, sin perder las reglas de negocio que esa herramienta acumuló durante años.

No es una migración de datos. Es un traslado de lógica operativa: los cálculos, las validaciones y los criterios que el equipo aplica todos los días y que rara vez están documentados en otro sitio que no sea la propia aplicación.

El punto de partida

DELAGRO gestionaba su operativa de repartos con una combinación de Microsoft Access, hojas de cálculo y lógica repartida entre distintos sistemas internos. Parte de esas transformaciones vivían en un componente que el equipo llamaba internamente «la hormigonera de estadísticas».

La solución funcionaba. Ese es justamente el matiz que hace difíciles estos proyectos: nadie sustituye una herramienta que funciona a menos que el coste de mantenerla supere al de sustituirla.

Los límites que se habían alcanzado:

• Dependencia de instalaciones locales. Cada usuario necesitaba Access en su ordenador para completar tareas del proceso de reparto.
• Dependencia de una única persona. Una sola persona del equipo dominaba realmente el Access: lo había ido desarrollando y refinando durante años, y era quien sabía dónde intervenir cuando algo fallaba.
• Reglas de negocio dispersas. Las transformaciones estaban repartidas entre consultas, ficheros y procedimientos operativos, sin un punto único de verdad.
• Trazabilidad limitada. Resultaba difícil reconstruir qué se había modificado, cuándo y con qué parámetros.
• Techo de escalabilidad. Añadir una funcionalidad nueva implicaba tocar varias piezas a la vez.
• Riesgo de obsolescencia técnica. La versión de Access que utilizaban ya no recibía actualizaciones, con el riesgo de que dejara de funcionar en cualquier momento.

Ninguno de estos límites es un fallo de Access: son las especificaciones del propio producto, que Microsoft documenta con detalle. Un proyecto de modernización de aplicaciones no arranca porque la herramienta sea mala, sino porque la operativa ha crecido por encima de aquello para lo que fue diseñada.

Al mismo tiempo había un requisito que no era negociable: los usuarios necesitaban seguir trabajando con la información de forma flexible, al estilo de una hoja de cálculo. Editar en bloque, filtrar, agrupar, reordenar columnas. Sin eso, la aplicación nueva sería técnicamente mejor y operativamente peor.

El enfoque: un motor configurable, no una copia de formularios

La vía evidente habría sido reproducir formulario por formulario lo que existía en Access. Se descartó.

En su lugar, Tecnología bi planteó un motor web común y configurable: una única base sobre la que las distintas vistas de trabajo se definen por configuración en lugar de programarse una a una. Este enfoque conserva la flexibilidad que el negocio necesitaba y reduce a la vez el coste de mantenimiento y el de añadir procesos nuevos.

La consecuencia práctica: cuando el usuario necesita una vista distinta, no hay que abrir un petición de desarrollo.

La solución desarrollada

Arquitectura de tres capas: Angular en la interfaz, Node.js/NestJS en la capa de servicios y SQL Server como plataforma de datos. Microsoft documenta el camino de Access a SQL Server para la parte de datos; lo que ninguna herramienta de migración resuelve es la lógica de negocio, y ahí es donde se concentra el trabajo real de una modernización de aplicaciones.

• Aplicación web accesible sin instalaciones individuales.
• Cuadrícula avanzada con edición de valores y actualizaciones múltiples.
• Selección, ocultación y reordenación de columnas por usuario.
• Filtros y vistas personalizadas guardadas.
• Agrupaciones y jerarquías dinámicas con consolidación automática.
• Ejecución de procesos de reparto conectados con los datos de SQL Server.
• Gestión de parámetros y trazabilidad de modificaciones y ejecuciones.

Cómo se abordó el proyecto

Etapa	Contenido
1. Análisis funcional	Revisión de la operativa existente, reglas de negocio, consultas y necesidades de los usuarios.
2. Diseño de solución	Definición de la arquitectura web y de la experiencia de trabajo con datos.
3. Desarrollo iterativo	Construcción de la aplicación y de los procesos de reparto mediante entregas sucesivas.
4. Validación	Contraste con casos reales y revisión conjunta de cálculos, flujos y resultados.
5. Evolución	Incorporación de procesos nuevos y ajustes detectados durante el uso.

Sobre esa base se abordaron después la evaluación y distribución de importes negativos, el análisis del ciclo completo de reparto, los controles previos al cierre por familia y una herramienta parametrizable para repartos especiales.

Este modelo de entregas sucesivas con validación conjunta es el que aplicamos en todos los proyectos: puedes revisarlo en detalle en nuestra metodología de trabajo.

Resultados

• Aplicación web en producción para el proceso de repartos, conectada con SQL Server.
• Experiencia de usuario configurable: edición, filtros, vistas y agrupaciones dinámicas.
• Menor dependencia de aplicaciones locales y de trasvases manuales entre Access y hojas de cálculo.
• Mayor trazabilidad sobre datos, parámetros, modificaciones y ejecución de procesos.
• Arquitectura modular que permite incorporar reglas y módulos nuevos sin rehacer la solución.
• Base común para completar el ciclo operativo y abordar repartos especiales.

Lo que gana el negocio, más allá de lo técnico: autonomía del usuario. Preparar una vista o explorar la información dejó de requerir una petición de desarrollo. Y las reglas de negocio pasaron a estar centralizadas, comprensibles y mantenibles, en lugar de repartidas entre consultas y ficheros.

Cuando los datos operativos quedan centralizados y son fiables, el paso siguiente deja de ser un salto: es el punto natural desde el que se construye una capa analítica. Es el mismo recorrido que planteamos en integración de datos y en automatización de informes.

Qué hizo que funcionara

• Análisis conjunto con usuarios que conocían una operativa acumulada durante años.
• Equilibrio entre flexibilidad de uso y control sobre las reglas del proceso.
• Desarrollo iterativo contrastado con casos reales.
• Gestión explícita de las ampliaciones de alcance.
• Arquitectura alineada con el entorno de datos existente, no con una moda tecnológica.

Continuidad

La colaboración evolucionó desde la sustitución de Access hacia la optimización integral del proceso de repartos. Las necesidades identificadas después —control previo al cierre, repartos especiales y la lógica que aún reside en la «hormigonera» histórica— constituyen la hoja de ruta para completar el circuito dentro de la aplicación.

Preguntas frecuentes

¿Qué es la modernización de aplicaciones?

La modernización de aplicaciones es el proceso de trasladar una herramienta interna obsoleta —una base de datos de Access, un conjunto de hojas de cálculo o un desarrollo antiguo— a una arquitectura actual, conservando las reglas de negocio que esa herramienta acumuló. Se diferencia de una simple migración de datos en que traslada también la lógica operativa: cálculos, validaciones y criterios de trabajo.

¿Cómo se migra una aplicación de Microsoft Access a la web?

Se migra en cinco fases: análisis funcional de la operativa y las reglas existentes, diseño de la arquitectura web, desarrollo iterativo por entregas, validación contra casos reales y evolución posterior. El error más común es reproducir la aplicación formulario por formulario; es más eficaz construir un motor configurable en el que las vistas se definan por configuración.

¿Se puede mantener una experiencia tipo hoja de cálculo en una aplicación web?

Sí. Una cuadrícula web avanzada permite editar valores en bloque, filtrar, agrupar, reordenar columnas y guardar vistas personalizadas por usuario. Es un requisito habitual cuando se sustituye Access o Excel, porque la flexibilidad de trabajo suele ser la razón por la que el equipo se resistía al cambio.

¿Qué ventajas tiene una aplicación web frente a Microsoft Access?

Cuatro principales: acceso sin instalación local en cada ordenador, reglas de negocio centralizadas en lugar de dispersas, trazabilidad de modificaciones y ejecuciones, y una arquitectura modular que permite añadir procesos sin rehacer la solución. Access sigue siendo válido para necesidades pequeñas y locales; el límite aparece cuando el proceso es crítico y multiusuario.

¿Cuánto dura un proyecto de modernización de aplicaciones?

Depende de la complejidad de las reglas de negocio acumuladas, no del volumen de datos. En proyectos con lógica repartida entre varias herramientas, el análisis funcional suele ser la fase más larga. El desarrollo iterativo permite poner en producción el primer módulo antes de tener el circuito completo cerrado.

¿Qué pasa con las reglas de negocio que solo existen dentro de Access?

Se recuperan mediante análisis conjunto con los usuarios que operan el proceso a diario. Es la parte crítica del proyecto: buena parte de esa lógica no está documentada en ningún otro sitio, y perderla en la migración es el riesgo real de estos proyectos, muy por encima del riesgo técnico.

¿Es necesario sustituir el ERP para modernizar un proceso interno?

No. La modernización de aplicaciones actúa sobre procesos que viven fuera del ERP —normalmente en Access, hojas de cálculo o desarrollos antiguos— y se conecta con los datos existentes. En este caso, la aplicación se conectó con SQL Server sin tocar los sistemas transaccionales.