Tu sistema lleva años sosteniendo el negocio. Precisamente por eso no puedes permitirte un “big bang”. En Arcosoft modernizamos sistemas legacy por partes: el sistema antiguo sigue en producción mientras el nuevo demuestra, con tus datos reales, que hace lo mismo o mejor. Solo entonces se retira lo viejo.
Arcosoft lleva desde 2013 trabajando sobre software en producción, incluida la evolución de Zenith, la plataforma de ASOPAGOS para cajas de compensación familiar: Java con un framework propietario, SQL Server y grandes volúmenes de datos regulados. Conocemos ese mundo por dentro, y por eso sabemos sacarte de él con seguridad hacia una base moderna: Python/FastAPI, TypeScript y PostgreSQL.
¿Te suena alguna de estas situaciones?
- Cada cambio tarda semanas y nadie se atreve a tocar ciertos módulos.
- El conocimiento está en dos o tres personas y la documentación no refleja lo que hace el código.
- La base o la plataforma están fuera de soporte: por ejemplo, SQL Server 2016 dejó de tener soporte extendido de Microsoft el 14 de julio de 2026 (Microsoft Lifecycle), y hay versiones antiguas de Java, Tomcat o frameworks propietarios sin actualizaciones.
- No puedes integrarlo con tu CRM, una app móvil, un proveedor o un asistente de IA porque no tiene API.
- Es una aplicación de escritorio y tus usuarios necesitan acceso web.
- Los procesos nocturnos ya no caben en la noche: las cargas, liquidaciones o cierres tardan cada vez más.
Si te reconoces en dos o más, modernizar ya no es una mejora: es gestión de riesgo.
Qué entendemos por modernizar (y qué no)
Modernizar no es reescribirlo todo con la tecnología de moda. Es reducir el riesgo y el coste de cambiar tu sistema, conservando las reglas de negocio que funcionan. Según el estado del sistema, recomendamos una de estas vías, o una combinación por módulos:
| Vía | Cuándo tiene sentido | Riesgo |
|---|---|---|
| Actualizar (rehost / replatform) | El código es razonable, pero la plataforma (versión de Java, servidor de aplicaciones, base de datos) está obsoleta | Bajo |
| Refactorizar | El sistema hace lo correcto, pero es difícil de cambiar: se reorganiza, se añaden pruebas y se separan responsabilidades | Medio |
| Extraer por partes (patrón strangler fig) | Módulos concretos frenan al negocio: se reconstruyen alrededor del sistema antiguo y se van sustituyendo uno a uno | Medio, controlado |
| Reemplazar | El proceso cambió tanto que el sistema ya no lo representa, o existe un producto estándar que lo cubre | Alto si se hace de golpe |
| Encapsular | El núcleo debe quedarse por ahora: se le pone una API delante para integrarlo con lo nuevo | Bajo |
La recomendación sale del diagnóstico, no de una preferencia nuestra.
Cómo migramos sin parar tu operación
1. Diagnóstico del sistema actual
Revisamos código, base de datos, integraciones, procesos batch, volúmenes y quién usa qué. Hablamos con las personas que conocen las reglas “no escritas”. Resultado: un mapa de módulos y dependencias, los riesgos priorizados y una recomendación argumentada por módulo (actualizar, refactorizar, extraer, reemplazar o encapsular).
2. Red de seguridad antes de tocar nada
Antes de cambiar código, construimos lo que el sistema casi nunca tiene: pruebas de caracterización que fijan el comportamiento actual, comparaciones de resultados con datos reales (anonimizados cuando hay datos personales), monitorización y un plan de vuelta atrás por fase.
3. Primer módulo en producción
Elegimos un módulo con impacto visible y riesgo acotado. Lo construimos, lo ponemos a convivir con el antiguo y comparamos resultados en paralelo hasta que coinciden. Así se valida el método con tu sistema real, no con una presentación.
4. Migración progresiva por módulos
Cada módulo sigue el mismo ciclo: análisis, desarrollo, pruebas, migración de datos, despliegue y validación. El sistema legacy va perdiendo funciones mientras el nuevo las asume. Tu operación no se detiene.
5. Migración de datos verificada
Los datos son lo que no puedes perder. Migramos con scripts versionados y repetibles, conciliamos conteos, sumas y saldos entre origen y destino, y guardamos evidencia de cada conciliación para tus auditores.
6. Retirada ordenada del sistema antiguo
Cuando todo está migrado y validado, se apaga lo viejo con copia completa, documentación y formación. Después, si lo necesitas, seguimos con mantenimiento evolutivo.
De dónde partimos y a dónde te llevamos
Lo que conocemos a fondo (origen):
- Java: aplicaciones monolíticas, frameworks propietarios, servidores de aplicaciones antiguos y aplicaciones de escritorio Java.
- SQL Server: procedimientos almacenados con lógica de negocio, procesos batch de alto volumen, versiones sin soporte.
- Frontales antiguos: escritorio o web de generaciones anteriores.
Nuestra base tecnológica (destino):
- Python + FastAPI para servicios y APIs: legible, con un ecosistema enorme en datos e IA y mucho mercado de profesionales.
- PostgreSQL como base de datos: abierta, sin coste de licencias y madura para cargas transaccionales y analíticas.
- TypeScript para aplicaciones web y móviles.
No siempre hay que cambiar de tecnología: a veces lo correcto es actualizar o encapsular el núcleo Java con una API y construir lo nuevo alrededor en Python. Lo decidimos módulo a módulo en el diagnóstico. Si tu prioridad es quedarte en Java o SQL Server, también podemos actualizarlos y estabilizarlos, y te diremos honestamente los costes de cada opción.
- PENDIENTE: confirmar otras tecnologías de origen con experiencia (.NET, PHP, Oracle, Visual Basic…). No listar las que no se hayan trabajado.
Si tu sistema está en una tecnología que no dominamos, te lo diremos en la primera llamada.
IA en la modernización, con revisión humana
Usamos asistentes de IA para acelerar tareas concretas: leer y documentar código heredado, proponer pruebas de caracterización o detectar dependencias. Todo cambio pasa por revisión de un ingeniero y por las pruebas; la IA no despliega nada por su cuenta. PENDIENTE: confirmar que este uso de IA forma parte del proceso actual Y cuando el sistema ya está modernizado, puede alimentar asistentes y agentes de IA sobre tus propios datos.
Qué recibes
- Diagnóstico escrito con mapa de módulos, riesgos y hoja de ruta por fases.
- Repositorio con el código nuevo, las pruebas y la documentación técnica PENDIENTE: confirmar política “repositorio del cliente desde el día 1”.
- Informes de conciliación de datos por fase.
- Plan de despliegue y de vuelta atrás por módulo.
- Formación a tu equipo técnico y traspaso de conocimiento.
Experiencia real: ASOPAGOS · Zenith
Hemos trabajado en Zenith, la plataforma con la que ASOPAGOS da soporte a la operación del FOSFEC (Mecanismo de Protección al Cesante) para cajas de compensación familiar en Colombia: un sistema Java con framework propietario y SQL Server, con grandes volúmenes de registros y normativa que cambia. Allí hemos hecho nuevos desarrollos y controles de cambio sobre un sistema que no puede pararse. Resultados: PENDIENTE: métricas y años. Leer el caso ASOPAGOS →
Para quién es
- Empresas medianas y grandes con un sistema core propio (gestión, facturación, liquidación, prestaciones) de más de 10 años.
- Entidades de sectores regulados: prestaciones, subsidios y previsión social, seguros, finanzas, administración.
- Equipos de IT que necesitan refuerzo con experiencia en legacy durante la migración.
No es para ti si buscas reescribir un sistema pequeño desde cero en dos semanas o cambiar de tecnología sin un motivo de negocio.
Preguntas frecuentes
¿Cuánto dura una modernización?
Depende del tamaño y del estado del sistema. El diagnóstico se hace en 2–3 semanas y el primer módulo en producción suele ser el hito que da el ritmo real del resto. No damos un plazo total serio sin haber visto el código.
¿Hay que parar el sistema durante la migración?
No como norma. El enfoque por módulos permite que el sistema antiguo y el nuevo convivan. Puede haber ventanas de corte cortas y planificadas para pasar datos o tráfico de un módulo, acordadas contigo.
¿Es mejor reescribir desde cero?
Rara vez de golpe. Reescribir todo a la vez retrasa el valor durante meses y concentra el riesgo en un único día de cambio. Preferimos sustituir por partes y reescribir solo los módulos donde el diagnóstico lo justifica.
¿Qué pasa con las reglas de negocio que solo están en el código?
Las hacemos visibles: pruebas de caracterización que fijan el comportamiento actual, entrevistas con quien opera el sistema y documentación de cada regla antes de migrarla. Si una regla resulta ser un error histórico, lo decides tú.
¿Podéis modernizar un sistema que no hicisteis vosotros?
Sí, es el caso habitual. Zenith, por ejemplo, es una plataforma de ASOPAGOS sobre la que Arcosoft ha trabajado en producción.
¿Cómo se protegen los datos personales durante el proyecto?
Acceso mínimo, entornos separados, datos anonimizados o seudonimizados para pruebas y contrato de encargo del tratamiento conforme al RGPD cuando trabajamos para empresas en España.
Empieza por un diagnóstico
En 30 minutos revisamos tu situación y te decimos si tiene sentido un diagnóstico completo y qué incluiría.
Para profundizar
- Qué es un sistema legacy y cuándo conviene modernizarlo
- Strangler fig: cómo migrar un monolito Java por partes (próximamente)
- SQL Server 2016 sin soporte: opciones y riesgos