Modernizar un sistema legacy sin detener la operación
Por qué el reemplazo de golpe casi siempre falla, cómo se sustituye un sistema por partes mientras sigue facturando, y qué hacer cuando las reglas de negocio solo viven en la cabeza de dos personas.
Lectura de 10 minutos
En esta guía
Respuesta corta
Un sistema legacy no se reemplaza de golpe: se sustituye por partes. Cada pieza nueva convive con la vieja y solo toma el control cuando demuestra, con datos reales, que hace exactamente lo mismo. El sistema anterior queda como respaldo hasta el final. Con este método el paro operativo objetivo es cero y los cortes se limitan a ventanas de minutos, programadas fuera del turno productivo.
Qué es un sistema legacy, y por qué no es cuestión de edad
Un sistema no es legacy porque tenga quince años. Es legacy cuando cambiarlo se volvió más riesgoso que aguantarlo. Esa es la definición práctica, y es la que importa para decidir.
Hay sistemas de veinte años perfectamente documentados, con pruebas automatizadas y tres personas que los conocen a fondo. Ese no es un problema legacy: es un sistema maduro. Y hay sistemas de seis años que nadie se atreve a tocar porque el único que entendía el módulo de precios renunció en 2023. Ese sí lo es.
Estas son las señales que de verdad predicen problemas:
| Señal | Qué significa en la práctica | Riesgo |
|---|---|---|
| No se puede actualizar de versión | Quedaste anclado a una versión sin parches de seguridad | Alto |
| Nadie sabe por qué hace algo | Hay reglas de negocio vivas que no están escritas en ningún lado | Crítico |
| Cada cambio rompe algo distinto | No hay pruebas: cada ajuste es una apuesta | Alto |
| Depende de una sola persona | Continuidad atada a que esa persona siga y esté disponible | Crítico |
| No conecta con nada nuevo | Todo lo que se integre alrededor requiere captura manual | Medio |
| Corre en un servidor que nadie apaga | Sin plan de recuperación probado ante una falla física | Crítico |
Dos señales críticas simultáneas justifican un diagnóstico formal antes de seguir invirtiendo en mantener el sistema.
Vale la pena separar dos cosas que suelen confundirse. Deuda técnica es lo que cuesta trabajar sobre el sistema: cada cambio toma más tiempo del que debería. Riesgo de continuidad es la probabilidad de que un día deje de operar y nadie pueda levantarlo. La primera duele en el presupuesto; la segunda cierra la planta.
Por qué el reemplazo de golpe casi siempre falla
La idea es tentadora: se construye el sistema nuevo completo, se elige un fin de semana largo, se migra todo y el lunes se arranca. En papel es limpio. En la práctica, esta es la razón por la que rara vez funciona.
El sistema nuevo tiene que replicar todo lo que hace el viejo antes de poder sustituirlo. Y "todo" incluye las excepciones que nadie recuerda: el descuento especial de un cliente que se aplica desde 2018, el formato que exige un solo proveedor, la validación que evita un error que ya nadie sabe qué era. Esas excepciones no aparecen en las juntas de levantamiento; aparecen el lunes de arranque, cuando alguien intenta facturar.
| Aspecto | Reemplazo de golpe | Sustitución por fases |
|---|---|---|
| Primer beneficio visible | Al final del proyecto | En semanas, con la primera pieza |
| Si algo sale mal | Se revierte el proyecto completo | Se revierte una sola pieza |
| Aprendizaje | Todo se decide con supuestos iniciales | Cada fase corrige la estimación de la siguiente |
| Exposición al riesgo | Concentrada en un día | Repartida y acotada |
| Costo de un error | Operación detenida | Vuelta al flujo anterior en minutos |
La pregunta que lo define
Antes de aprobar cualquier plan de modernización, pregunta una sola cosa: si esto falla el martes a las diez de la mañana, ¿qué hacemos? Si la respuesta es "revertimos y seguimos operando en el sistema anterior", el plan es sólido. Si es "lo arreglamos lo antes posible", no hay plan: hay optimismo.
Sustituir por partes: el patrón de estrangulamiento
El método se llama así por una imagen: la higuera estranguladora crece alrededor de un árbol, lo va rodeando y termina ocupando su lugar. El árbol original desaparece sin que el bosque note un hueco.
Aplicado a un sistema, funciona así. Se elige una función acotada —por ejemplo, la generación de órdenes de compra— y se construye esa pieza aparte. Mientras se prueba, el sistema viejo la sigue haciendo. Cuando la pieza nueva produce el mismo resultado durante un periodo suficiente, se le pasa el control. El sistema viejo pierde una función y sigue con las demás.
Se repite hasta que al sistema original no le queda nada que hacer. Ese día se apaga, y no pasa nada, porque hace meses que no sostiene la operación.
Lo importante de este orden es cuál pieza va primero. La elección no es técnica, es de negocio:
- Primero, lo que más riesgo concentra. Si hay un módulo que solo una persona entiende y que detiene la facturación, ese va primero, aunque no sea el más vistoso.
- Segundo, lo que más fricción diaria genera. Un proceso que obliga a recapturar datos consume horas todos los días y su mejora se nota de inmediato.
- Al final, lo estable. Lo que funciona bien, nadie toca y nadie extraña puede esperar. A veces ni siquiera se migra: se deja corriendo hasta que deje de ser necesario.
Si esto falla el martes a las diez, ¿qué hacemos? Esa pregunta separa un plan de modernización de una apuesta.
Brenda Infinite® · INCEPTIOLa capa que traduce entre lo viejo y lo nuevo
Durante la transición conviven dos sistemas que no hablan el mismo idioma. El viejo maneja códigos de cliente de ocho posiciones; el nuevo usa identificadores distintos. El viejo guarda las fechas en un formato propio. El viejo llama "artículo" a lo que el nuevo llama "producto".
La tentación es hacer que el sistema nuevo entienda el formato viejo, para ahorrarse el trabajo de traducir. Es un error caro: el sistema nuevo hereda los defectos del viejo y en dos años tienes un legacy más moderno pero igual de rígido.
La alternativa es una capa de traducción que se sienta en medio: recibe lo que manda el sistema viejo, lo convierte al modelo del nuevo, y viceversa. El sistema nuevo nunca ve el formato antiguo. Cuando el viejo se apaga, la capa se apaga con él y no queda rastro.
La señal de que algo va mal
Si el equipo empieza a decir "es que el sistema nuevo también tiene que manejar este caso raro porque así lo hacía el anterior", la traducción se está filtrando. Es el momento de detenerse y revisar dónde debe vivir esa regla, porque cada filtración de estas se paga durante los siguientes diez años.
Las cuatro fases de un proyecto real
Cada fase termina con algo en producción. No hay etapas que solo produzcan documentos.
| Fase | Qué se hace | Con qué termina |
|---|---|---|
| 1. Diagnóstico | Levantamiento de procesos reales, mapa de integraciones, inventario de reglas de negocio y evaluación de riesgo por módulo | Ruta priorizada y estimación por fases |
| 2. Primera pieza | Se construye y libera el módulo de mayor riesgo, corriendo en paralelo con el viejo | Una función operando en el sistema nuevo |
| 3. Sustitución progresiva | Se repite el ciclo módulo por módulo, con la capa de traducción manteniendo la convivencia | La mayoría de la operación migrada |
| 4. Apagado | Se migra el histórico, se valida que nada dependa del sistema anterior y se retira | Sistema viejo fuera, documentación entregada |
La duración de cada fase depende del número de módulos y de cuánta lógica esté sin documentar. El diagnóstico es lo que convierte un rango en un compromiso: es exactamente lo que hace Audit.Tech™.
Las reglas que nadie documentó
Esta es la parte que rompe más presupuestos, y conviene decirlo sin rodeos: cuando un sistema lleva años sin documentación, parte del proyecto no es programar, es investigar.
Hay reglas que solo existen dentro del código. Alguien las escribió hace ocho años para resolver un problema puntual, funcionaron, y se quedaron. Nadie las anotó. La persona que las escribió ya no está. Y sin embargo, si el sistema nuevo no las replica, alguien va a notar que su reporte cambió.
Hay tres formas de recuperarlas, y en un proyecto real se usan las tres:
- Leer el código. Lento pero exacto. Es la única fuente que no miente sobre lo que el sistema hace hoy.
- Comparar salidas. Se corre el proceso viejo y el nuevo con los mismos datos y se comparan resultados. Cada diferencia revela una regla que faltaba.
- Preguntar a quien opera. La gente de piso conoce excepciones que ningún documento registra, aunque casi nunca sepa que son excepciones. Se descubren preguntando "¿y esto siempre sale así?".
Este trabajo se estima aparte del desarrollo, porque su duración depende de lo que se encuentre. Cotizarlo junto con la construcción es la forma más rápida de que un proyecto se salga del presupuesto.
Cómo se garantiza que la operación no se detenga
"Sin detener la operación" no es una promesa comercial: es un conjunto de prácticas concretas. Estas son las que sostienen esa afirmación.
- Operación en paralelo. Antes de que la pieza nueva tome el control, corre en silencio con datos reales. Produce resultados que nadie usa todavía, y esos resultados se comparan contra los del sistema viejo.
- Marcha en sombra. El módulo nuevo recibe la misma información que el viejo pero sin escribir en producción. Sirve para detectar diferencias sin arriesgar nada.
- Plan de reversa probado. No basta con poder revertir: hay que haberlo ensayado. Antes de cada liberación se practica la vuelta atrás y se cronometra.
- Ventanas de corte fuera del turno. Los momentos en que sí hay que detener algo se programan en el hueco de menor actividad y se limitan a minutos.
- Criterio de aceptación por escrito. Se define antes qué resultado significa que la pieza nueva está lista. Sin ese criterio, la decisión se toma por presión de calendario.
- Convivencia sin fecha forzada. Si la pieza nueva no cumple el criterio, se queda en paralelo más tiempo. La fecha se mueve; la operación no.
Cuándo no conviene modernizar
No todo sistema viejo necesita reemplazo. Estos son los casos en los que la recomendación honesta es no hacerlo, o no todavía:
- El sistema funciona y nadie depende de una sola persona. Si está documentado, se puede actualizar y no bloquea nada, el dinero rinde más en otro lado.
- El proceso va a cambiar pronto. Modernizar un flujo que la empresa está por rediseñar es pagar dos veces. Primero se define el proceso, después se construye.
- Un producto estándar ya cubre lo que hace. Si el sistema lleva una función común sin nada particular de tu operación, configurar un ERP puede ser más barato que reconstruirlo. Ese análisis está en nuestra guía sobre construir o configurar.
- No hay quién decida del lado del cliente. Sin un responsable interno con horas asignadas, cualquier proyecto de este tipo se alarga hasta perder el sentido. Vale más esperar a tenerlo.
Lo que sí conviene siempre, aunque decidas no modernizar todavía, es saber en qué estado estás. Un inventario de riesgo por módulo cuesta poco, se hace en semanas y te da algo que hoy probablemente no tienes: una respuesta clara cuando alguien pregunte qué pasa si ese sistema se cae.
Preguntas frecuentes sobre modernización legacy
Sí, sustituyendo el sistema por partes en lugar de reemplazarlo completo. Cada módulo nuevo convive con el anterior y solo toma el control cuando demuestra con datos reales que produce el mismo resultado. El paro operativo objetivo es cero, y los cortes que sí hacen falta se limitan a ventanas de minutos programadas fuera del turno productivo.
No depende de la edad sino del riesgo. Un sistema es legacy cuando cambiarlo se volvió más riesgoso que aguantarlo: no se puede actualizar de versión, nadie sabe por qué hace ciertas cosas, cada cambio rompe algo distinto, o su operación depende de una sola persona. Un sistema de veinte años bien documentado no es legacy; uno de seis sin documentar sí lo es.
Porque el sistema nuevo debe replicar todo lo que hace el viejo antes de poder sustituirlo, y "todo" incluye excepciones que nadie recuerda: descuentos especiales, formatos que exige un proveedor, validaciones cuyo motivo se perdió. Esas excepciones no salen en las juntas de levantamiento, salen el día del arranque. Además concentra todo el riesgo en una sola fecha, y si algo falla la única salida es revertir el proyecto completo.
Es un método para sustituir un sistema por partes. Se construye una función acotada aparte, se prueba mientras el sistema viejo la sigue haciendo, y cuando produce el mismo resultado se le pasa el control. Se repite módulo por módulo hasta que al sistema original no le queda nada que hacer, momento en que se apaga sin consecuencias porque hace meses que no sostiene la operación.
Se recuperan con tres métodos combinados: leer el código, que es la única fuente que no miente sobre lo que el sistema hace hoy; comparar salidas del proceso viejo y el nuevo con los mismos datos, donde cada diferencia revela una regla faltante; y preguntar a quien opera, porque la gente de piso conoce excepciones que ningún documento registra. Ese trabajo se estima aparte del desarrollo, porque su duración depende de lo que se encuentre.
Depende del número de módulos y de cuánta lógica esté sin documentar, que son las dos variables que más mueven el calendario. Lo que sí es constante es que la primera pieza sale a producción en semanas, no al final: el método está diseñado para que cada fase entregue algo en operación en lugar de acumular meses de trabajo invisible. El diagnóstico inicial es lo que convierte un rango en un compromiso con fechas.
A veces sí. Si el sistema legacy cubre funciones comunes sin nada particular de tu operación, configurar un ERP como Odoo suele salir más barato que reconstruirlo. La respuesta cambia cuando el sistema contiene reglas propias que son parte de tu ventaja competitiva: eso no se configura, se construye. El diagnóstico separa una cosa de la otra antes de comprometer inversión.
Tres cosas concretas: un plan de reversa que ya se haya ensayado y cronometrado, criterios de aceptación por escrito que definan cuándo una pieza está lista antes de liberarla, y fases que terminen en producción y no en documentos. Si la propuesta no responde qué pasa si falla un martes a las diez de la mañana, no hay plan.
¿Sabes qué pasa si ese sistema se cae mañana?
El diagnóstico levanta tus procesos reales, mapea las integraciones y evalúa el riesgo módulo por módulo. Sale con una ruta priorizada, no con una recomendación genérica. Si lo mejor es no modernizar todavía, también te lo decimos.
Modernizar un sistema legacy sin detener la operación
Por qué el reemplazo de golpe casi siempre falla, cómo se sustituye un sistema por partes mientras sigue facturando, y qué hacer cuando las reglas de negocio solo viven en la cabeza de dos personas.
Lectura de 10 minutos
En esta guía
Respuesta corta
Un sistema legacy no se reemplaza de golpe: se sustituye por partes. Cada pieza nueva convive con la vieja y solo toma el control cuando demuestra, con datos reales, que hace exactamente lo mismo. El sistema anterior queda como respaldo hasta el final. Con este método el paro operativo objetivo es cero y los cortes se limitan a ventanas de minutos, programadas fuera del turno productivo.
Qué es un sistema legacy, y por qué no es cuestión de edad
Un sistema no es legacy porque tenga quince años. Es legacy cuando cambiarlo se volvió más riesgoso que aguantarlo. Esa es la definición práctica, y es la que importa para decidir.
Hay sistemas de veinte años perfectamente documentados, con pruebas automatizadas y tres personas que los conocen a fondo. Ese no es un problema legacy: es un sistema maduro. Y hay sistemas de seis años que nadie se atreve a tocar porque el único que entendía el módulo de precios renunció en 2023. Ese sí lo es.
Estas son las señales que de verdad predicen problemas:
| Señal | Qué significa en la práctica | Riesgo |
|---|---|---|
| No se puede actualizar de versión | Quedaste anclado a una versión sin parches de seguridad | Alto |
| Nadie sabe por qué hace algo | Hay reglas de negocio vivas que no están escritas en ningún lado | Crítico |
| Cada cambio rompe algo distinto | No hay pruebas: cada ajuste es una apuesta | Alto |
| Depende de una sola persona | Continuidad atada a que esa persona siga y esté disponible | Crítico |
| No conecta con nada nuevo | Todo lo que se integre alrededor requiere captura manual | Medio |
| Corre en un servidor que nadie apaga | Sin plan de recuperación probado ante una falla física | Crítico |
Dos señales críticas simultáneas justifican un diagnóstico formal antes de seguir invirtiendo en mantener el sistema.
Vale la pena separar dos cosas que suelen confundirse. Deuda técnica es lo que cuesta trabajar sobre el sistema: cada cambio toma más tiempo del que debería. Riesgo de continuidad es la probabilidad de que un día deje de operar y nadie pueda levantarlo. La primera duele en el presupuesto; la segunda cierra la planta.
Por qué el reemplazo de golpe casi siempre falla
La idea es tentadora: se construye el sistema nuevo completo, se elige un fin de semana largo, se migra todo y el lunes se arranca. En papel es limpio. En la práctica, esta es la razón por la que rara vez funciona.
El sistema nuevo tiene que replicar todo lo que hace el viejo antes de poder sustituirlo. Y "todo" incluye las excepciones que nadie recuerda: el descuento especial de un cliente que se aplica desde 2018, el formato que exige un solo proveedor, la validación que evita un error que ya nadie sabe qué era. Esas excepciones no aparecen en las juntas de levantamiento; aparecen el lunes de arranque, cuando alguien intenta facturar.
| Aspecto | Reemplazo de golpe | Sustitución por fases |
|---|---|---|
| Primer beneficio visible | Al final del proyecto | En semanas, con la primera pieza |
| Si algo sale mal | Se revierte el proyecto completo | Se revierte una sola pieza |
| Aprendizaje | Todo se decide con supuestos iniciales | Cada fase corrige la estimación de la siguiente |
| Exposición al riesgo | Concentrada en un día | Repartida y acotada |
| Costo de un error | Operación detenida | Vuelta al flujo anterior en minutos |
La pregunta que lo define
Antes de aprobar cualquier plan de modernización, pregunta una sola cosa: si esto falla el martes a las diez de la mañana, ¿qué hacemos? Si la respuesta es "revertimos y seguimos operando en el sistema anterior", el plan es sólido. Si es "lo arreglamos lo antes posible", no hay plan: hay optimismo.
Sustituir por partes: el patrón de estrangulamiento
El método se llama así por una imagen: la higuera estranguladora crece alrededor de un árbol, lo va rodeando y termina ocupando su lugar. El árbol original desaparece sin que el bosque note un hueco.
Aplicado a un sistema, funciona así. Se elige una función acotada —por ejemplo, la generación de órdenes de compra— y se construye esa pieza aparte. Mientras se prueba, el sistema viejo la sigue haciendo. Cuando la pieza nueva produce el mismo resultado durante un periodo suficiente, se le pasa el control. El sistema viejo pierde una función y sigue con las demás.
Se repite hasta que al sistema original no le queda nada que hacer. Ese día se apaga, y no pasa nada, porque hace meses que no sostiene la operación.
Lo importante de este orden es cuál pieza va primero. La elección no es técnica, es de negocio:
- Primero, lo que más riesgo concentra. Si hay un módulo que solo una persona entiende y que detiene la facturación, ese va primero, aunque no sea el más vistoso.
- Segundo, lo que más fricción diaria genera. Un proceso que obliga a recapturar datos consume horas todos los días y su mejora se nota de inmediato.
- Al final, lo estable. Lo que funciona bien, nadie toca y nadie extraña puede esperar. A veces ni siquiera se migra: se deja corriendo hasta que deje de ser necesario.
Si esto falla el martes a las diez, ¿qué hacemos? Esa pregunta separa un plan de modernización de una apuesta.
Brenda Infinite® · INCEPTIOLa capa que traduce entre lo viejo y lo nuevo
Durante la transición conviven dos sistemas que no hablan el mismo idioma. El viejo maneja códigos de cliente de ocho posiciones; el nuevo usa identificadores distintos. El viejo guarda las fechas en un formato propio. El viejo llama "artículo" a lo que el nuevo llama "producto".
La tentación es hacer que el sistema nuevo entienda el formato viejo, para ahorrarse el trabajo de traducir. Es un error caro: el sistema nuevo hereda los defectos del viejo y en dos años tienes un legacy más moderno pero igual de rígido.
La alternativa es una capa de traducción que se sienta en medio: recibe lo que manda el sistema viejo, lo convierte al modelo del nuevo, y viceversa. El sistema nuevo nunca ve el formato antiguo. Cuando el viejo se apaga, la capa se apaga con él y no queda rastro.
La señal de que algo va mal
Si el equipo empieza a decir "es que el sistema nuevo también tiene que manejar este caso raro porque así lo hacía el anterior", la traducción se está filtrando. Es el momento de detenerse y revisar dónde debe vivir esa regla, porque cada filtración de estas se paga durante los siguientes diez años.
Las cuatro fases de un proyecto real
Cada fase termina con algo en producción. No hay etapas que solo produzcan documentos.
| Fase | Qué se hace | Con qué termina |
|---|---|---|
| 1. Diagnóstico | Levantamiento de procesos reales, mapa de integraciones, inventario de reglas de negocio y evaluación de riesgo por módulo | Ruta priorizada y estimación por fases |
| 2. Primera pieza | Se construye y libera el módulo de mayor riesgo, corriendo en paralelo con el viejo | Una función operando en el sistema nuevo |
| 3. Sustitución progresiva | Se repite el ciclo módulo por módulo, con la capa de traducción manteniendo la convivencia | La mayoría de la operación migrada |
| 4. Apagado | Se migra el histórico, se valida que nada dependa del sistema anterior y se retira | Sistema viejo fuera, documentación entregada |
La duración de cada fase depende del número de módulos y de cuánta lógica esté sin documentar. El diagnóstico es lo que convierte un rango en un compromiso: es exactamente lo que hace Audit.Tech™.
Las reglas que nadie documentó
Esta es la parte que rompe más presupuestos, y conviene decirlo sin rodeos: cuando un sistema lleva años sin documentación, parte del proyecto no es programar, es investigar.
Hay reglas que solo existen dentro del código. Alguien las escribió hace ocho años para resolver un problema puntual, funcionaron, y se quedaron. Nadie las anotó. La persona que las escribió ya no está. Y sin embargo, si el sistema nuevo no las replica, alguien va a notar que su reporte cambió.
Hay tres formas de recuperarlas, y en un proyecto real se usan las tres:
- Leer el código. Lento pero exacto. Es la única fuente que no miente sobre lo que el sistema hace hoy.
- Comparar salidas. Se corre el proceso viejo y el nuevo con los mismos datos y se comparan resultados. Cada diferencia revela una regla que faltaba.
- Preguntar a quien opera. La gente de piso conoce excepciones que ningún documento registra, aunque casi nunca sepa que son excepciones. Se descubren preguntando "¿y esto siempre sale así?".
Este trabajo se estima aparte del desarrollo, porque su duración depende de lo que se encuentre. Cotizarlo junto con la construcción es la forma más rápida de que un proyecto se salga del presupuesto.
Cómo se garantiza que la operación no se detenga
"Sin detener la operación" no es una promesa comercial: es un conjunto de prácticas concretas. Estas son las que sostienen esa afirmación.
- Operación en paralelo. Antes de que la pieza nueva tome el control, corre en silencio con datos reales. Produce resultados que nadie usa todavía, y esos resultados se comparan contra los del sistema viejo.
- Marcha en sombra. El módulo nuevo recibe la misma información que el viejo pero sin escribir en producción. Sirve para detectar diferencias sin arriesgar nada.
- Plan de reversa probado. No basta con poder revertir: hay que haberlo ensayado. Antes de cada liberación se practica la vuelta atrás y se cronometra.
- Ventanas de corte fuera del turno. Los momentos en que sí hay que detener algo se programan en el hueco de menor actividad y se limitan a minutos.
- Criterio de aceptación por escrito. Se define antes qué resultado significa que la pieza nueva está lista. Sin ese criterio, la decisión se toma por presión de calendario.
- Convivencia sin fecha forzada. Si la pieza nueva no cumple el criterio, se queda en paralelo más tiempo. La fecha se mueve; la operación no.
Cuándo no conviene modernizar
No todo sistema viejo necesita reemplazo. Estos son los casos en los que la recomendación honesta es no hacerlo, o no todavía:
- El sistema funciona y nadie depende de una sola persona. Si está documentado, se puede actualizar y no bloquea nada, el dinero rinde más en otro lado.
- El proceso va a cambiar pronto. Modernizar un flujo que la empresa está por rediseñar es pagar dos veces. Primero se define el proceso, después se construye.
- Un producto estándar ya cubre lo que hace. Si el sistema lleva una función común sin nada particular de tu operación, configurar un ERP puede ser más barato que reconstruirlo. Ese análisis está en nuestra guía sobre construir o configurar.
- No hay quién decida del lado del cliente. Sin un responsable interno con horas asignadas, cualquier proyecto de este tipo se alarga hasta perder el sentido. Vale más esperar a tenerlo.
Lo que sí conviene siempre, aunque decidas no modernizar todavía, es saber en qué estado estás. Un inventario de riesgo por módulo cuesta poco, se hace en semanas y te da algo que hoy probablemente no tienes: una respuesta clara cuando alguien pregunte qué pasa si ese sistema se cae.
Preguntas frecuentes sobre modernización legacy
Sí, sustituyendo el sistema por partes en lugar de reemplazarlo completo. Cada módulo nuevo convive con el anterior y solo toma el control cuando demuestra con datos reales que produce el mismo resultado. El paro operativo objetivo es cero, y los cortes que sí hacen falta se limitan a ventanas de minutos programadas fuera del turno productivo.
No depende de la edad sino del riesgo. Un sistema es legacy cuando cambiarlo se volvió más riesgoso que aguantarlo: no se puede actualizar de versión, nadie sabe por qué hace ciertas cosas, cada cambio rompe algo distinto, o su operación depende de una sola persona. Un sistema de veinte años bien documentado no es legacy; uno de seis sin documentar sí lo es.
Porque el sistema nuevo debe replicar todo lo que hace el viejo antes de poder sustituirlo, y "todo" incluye excepciones que nadie recuerda: descuentos especiales, formatos que exige un proveedor, validaciones cuyo motivo se perdió. Esas excepciones no salen en las juntas de levantamiento, salen el día del arranque. Además concentra todo el riesgo en una sola fecha, y si algo falla la única salida es revertir el proyecto completo.
Es un método para sustituir un sistema por partes. Se construye una función acotada aparte, se prueba mientras el sistema viejo la sigue haciendo, y cuando produce el mismo resultado se le pasa el control. Se repite módulo por módulo hasta que al sistema original no le queda nada que hacer, momento en que se apaga sin consecuencias porque hace meses que no sostiene la operación.
Se recuperan con tres métodos combinados: leer el código, que es la única fuente que no miente sobre lo que el sistema hace hoy; comparar salidas del proceso viejo y el nuevo con los mismos datos, donde cada diferencia revela una regla faltante; y preguntar a quien opera, porque la gente de piso conoce excepciones que ningún documento registra. Ese trabajo se estima aparte del desarrollo, porque su duración depende de lo que se encuentre.
Depende del número de módulos y de cuánta lógica esté sin documentar, que son las dos variables que más mueven el calendario. Lo que sí es constante es que la primera pieza sale a producción en semanas, no al final: el método está diseñado para que cada fase entregue algo en operación en lugar de acumular meses de trabajo invisible. El diagnóstico inicial es lo que convierte un rango en un compromiso con fechas.
A veces sí. Si el sistema legacy cubre funciones comunes sin nada particular de tu operación, configurar un ERP como Odoo suele salir más barato que reconstruirlo. La respuesta cambia cuando el sistema contiene reglas propias que son parte de tu ventaja competitiva: eso no se configura, se construye. El diagnóstico separa una cosa de la otra antes de comprometer inversión.
Tres cosas concretas: un plan de reversa que ya se haya ensayado y cronometrado, criterios de aceptación por escrito que definan cuándo una pieza está lista antes de liberarla, y fases que terminen en producción y no en documentos. Si la propuesta no responde qué pasa si falla un martes a las diez de la mañana, no hay plan.
¿Sabes qué pasa si ese sistema se cae mañana?
El diagnóstico levanta tus procesos reales, mapea las integraciones y evalúa el riesgo módulo por módulo. Sale con una ruta priorizada, no con una recomendación genérica. Si lo mejor es no modernizar todavía, también te lo decimos.