Auditoría escrita del sistema
Mapa de módulos, dependencias, criticidad, obsolescencia y orden de ataque. El documento es tuyo aunque no continúes.
Ingeniería · Modernización
Modernización de software legacy sin parar producción
Sustituimos software legacy por fases, con el sistema antiguo funcionando todo el tiempo. Primero, una auditoría escrita de lo que hay: qué módulos, qué dependencias, qué es crítico y en qué orden conviene tocarlo. Después, módulo a módulo, verificando que lo nuevo hace exactamente lo que hacía lo viejo antes de darle el tráfico.
Actualizado:
Definiciones clave
- Strangler Fig
- Patrón de modernización en el que el sistema nuevo crece al lado del antiguo y le va quitando funcionalidades una a una, hasta que el antiguo se puede apagar sin riesgo.
- Deuda técnica
- Coste futuro de los atajos del pasado. Una auditoría seria la cuantifica en trabajo concreto por módulo, no en adjetivos.
- Paridad funcional
- Que el módulo nuevo devuelve lo mismo que el antiguo ante las mismas entradas, incluidos los comportamientos raros que nadie documentó nunca.
- Caracterización
- Escribir qué hace hoy el sistema de verdad, antes de sustituirlo. Sin este paso, la migración reproduce el código pero no el comportamiento.
Sustituir por partes, no reescribir de golpe
Modernizar un sistema legacy no es reescribirlo entero y cambiarlo un domingo por la noche. Es sustituirlo por partes, con el sistema antiguo en producción, verificando que cada pieza nueva hace exactamente lo que hacía la anterior antes de darle el tráfico. El patrón se llama Strangler Fig y tiene una propiedad que ningún otro tiene: se puede parar a mitad sin haber roto nada.
Antes de tocar una línea de código hay una auditoría escrita. Qué módulos existen y de qué dependen. Cuáles son críticos y cuáles no los usa nadie desde hace tres años. Qué dependencias están obsoletas o arrastran vulnerabilidades conocidas. Qué comportamiento del sistema no está cubierto por ningún test —que suele ser casi todo— y, por tanto, qué hay que caracterizar antes de sustituirlo. Y en qué orden conviene atacar. Ese documento es tuyo aunque decidas no seguir: es el mapa técnico de tu propio sistema, y en muchas empresas es la primera vez que existe.
Los sistemas que llegan a este punto se parecen bastante entre sí: PHP 5 que nadie se atreve a actualizar, ASP.NET WebForms, Java 6 o 7 con frameworks que ya no reciben parches, un Access o un VB6 que sostiene un proceso crítico, o un ERP propietario que escribió alguien que ya no está. El problema nunca es solo la tecnología: es que el conocimiento de por qué el sistema hace lo que hace se fue con las personas que lo escribieron.
El destino de la migración es TypeScript sobre Node, PostgreSQL y Next.js, en Google Cloud. No es una preferencia estética: es el stack con el que están construidas nuestras plataformas y donde corre Perizial, en producción y con clientes de pago. Lo que no hacemos es migrar manteniendo la tecnología obsoleta: cambiar PHP 5 por PHP 5 en otro servidor no es modernizar, es mudar el problema.
Conviene decir el límite antes que después. Sustituir por completo un ERP propietario grande es un programa de varios años y de varias personas: no es un encargo que se pueda aceptar sin vender humo, y no se acepta. La auditoría escrita, la sustitución de módulos concretos y la integración del sistema actual con software nuevo, sí.
Cómo se ejecuta la modernización
Sustitución por fases (Strangler Fig)
Lo nuevo crece al lado de lo viejo. El sistema antiguo se apaga cuando ya no queda nada dentro, no antes.
Caracterización del comportamiento actual
Antes de sustituir un módulo se escribe qué hace hoy de verdad, incluidos los comportamientos raros de los que nadie se acuerda.
Paridad funcional verificada
Un módulo nuevo no recibe tráfico hasta que se ha comprobado que devuelve lo mismo que el antiguo con las mismas entradas.
Cohabitación con el sistema antiguo
Un enrutador delante decide qué va a lo nuevo y qué sigue en lo viejo. Los dos conviven durante todo el proceso.
Migración del histórico
Carga de datos con validación, deduplicación y reconciliación contra el origen, con un informe de qué registros no cuadran.
Refactor cuando no hace falta reescribir
Si la tecnología aún es razonable, sale más barato y más seguro arreglar lo que hay que sustituirlo entero.
Documentación versionada con el código
Las decisiones de arquitectura se escriben y viven en el repositorio, no en una carpeta compartida que nadie vuelve a abrir.
Destino: el stack que operamos
TypeScript, Node, PostgreSQL y Next.js sobre Google Cloud. Es donde corre Perizial hoy, en producción.
Dónde se puede ver funcionando
El destino de la migración no es una recomendación de catálogo: es donde corre nuestro propio producto. Perizial es un SaaS B2B multi-tenant construido sobre TypeScript, Node, PostgreSQL y Next.js, desplegado en Google Cloud, en producción con clientes de pago y con planes públicos desde 69,99 € al mes. Cuando decimos que un sistema legacy se puede sustituir por este stack, hablamos del stack que mantenemos todos los días, no de uno que hemos leído que funciona bien.
Preguntas frecuentes
- ¿Qué es el patrón Strangler Fig?
- Una técnica para sustituir un sistema por partes en lugar de reescribirlo entero de una vez. Lo nuevo se construye al lado de lo viejo, un enrutador manda a la versión nueva solo el tráfico de lo que ya está migrado y verificado, y el sistema antiguo se apaga cuando ya no queda nada dentro. Se llama así por la higuera estranguladora, que crece alrededor del árbol que la sostiene hasta ocupar su sitio.
- ¿Hay que parar producción para modernizar?
- No, y ese es justamente el motivo de migrar por fases. El sistema antiguo sigue atendiendo todo lo que aún no se ha migrado, y cada módulo nuevo entra cuando se ha verificado que hace exactamente lo que hacía el anterior. La reescritura completa de golpe es el enfoque que obliga a parar y el que deja a la empresa sin salida si algo va mal a mitad.
- ¿Qué se entrega en la auditoría?
- Un documento escrito con el mapa del sistema actual: qué módulos hay, de qué dependen, cuáles son críticos, qué dependencias están obsoletas o tienen vulnerabilidades conocidas, qué comportamiento no está cubierto por tests y en qué orden conviene sustituir. El documento es tuyo aunque decidas no continuar, o continuar con otro proveedor: es un mapa técnico honesto de tu propio sistema.
- ¿Modernizar el sistema legacy o integrarse con él?
- Integrarse, si el sistema hace bien su trabajo. Sustituir un sistema que funciona es el proyecto más caro y más arriesgado que puede acometer una empresa. La modernización se justifica cuando el sistema ya no se puede mantener ni evolucionar: nadie entiende el código, la tecnología no recibe parches de seguridad o cada cambio pequeño rompe otra cosa. Si solo necesitas que hable con otro software, eso es integración.
- ¿Se puede modernizar un ERP propietario entero?
- No, y conviene decirlo antes que después. Sustituir por completo un ERP propietario grande es un programa de varios años y de varias personas; Cyber Vault SL tiene un único fundador técnico, así que aceptarlo sería vender algo que no se podría entregar. Lo que sí se hace: la auditoría escrita del sistema actual, la sustitución de módulos concretos y la integración del ERP existente con el software nuevo.
- ¿A qué stack se migra?
- A TypeScript sobre Node, con PostgreSQL y Next.js, corriendo en Google Cloud. No es una recomendación teórica: es el stack con el que están construidas nuestras propias plataformas, y es donde corre Perizial hoy, en producción y con clientes de pago. Lo que no hacemos es migrar manteniendo la tecnología obsoleta.
Servicios relacionados
Integración de ERP →
Cuando el sistema legacy no hay que sustituirlo, sino conectarlo con el resto del software.
Desarrollo de software a medida →
Cuando lo que sustituye al legacy hay que diseñarlo y construirlo desde cero.
Infraestructura cloud →
Dónde acaba corriendo el sistema nuevo, y por qué la región importa cuando el dominio está regulado.
¿Hablamos de tu proyecto?
Escribe a [email protected] y cuenta qué proceso quieres automatizar, qué datos toca y con qué sistemas tiene que hablar. Con eso se puede responder si tiene sentido, qué alcance tendría y en qué rango de precio cae.