Migrar, reescribir o encapsular: cómo elegir la ruta de modernización
Casi todo el mundo salta directo a reescribir, que es la ruta más cara y más riesgosa de las cuatro. Aquí está el criterio para elegir, los riesgos de cada camino y por qué encapsular resuelve más casos de los que parece.
En esta guía
Respuesta corta
Hay cuatro rutas y elegir mal cuesta meses. Rehospedar mueve el sistema a infraestructura moderna sin tocar el código: sirve cuando el problema es el hardware. Encapsular lo expone con APIs sin modificarlo: sirve cuando el problema es el aislamiento, y resuelve el caso más frecuente en la industria mexicana. Refactorizar reescribe por partes conservando la lógica validada: sirve cuando el sistema es correcto pero imposible de mantener. Reconstruir empieza de cero: solo cuando la lógica actual ya no refleja cómo opera la empresa.
El problema no es técnico, es de diagnóstico
Cuando una empresa decide que su sistema ya no da más, la conversación salta casi siempre al mismo lugar: hay que hacer uno nuevo. Es la conclusión más intuitiva y la más cara de las cuatro posibles.
La razón por la que se llega ahí tan rápido es que el dolor se siente como una sola cosa —"el sistema ya no sirve"— cuando en realidad son varios problemas distintos que se manifiestan igual. Un sistema que no se integra con nada duele parecido a uno que nadie se atreve a tocar, y parecido a uno que corre sobre un servidor que ya no se fabrica. Pero cada uno de esos tres tiene una solución diferente, y dos de ellas no requieren reescribir una sola línea.
La pregunta que ordena todo
Antes de elegir ruta, complete esta frase con una sola causa: "si mañana se resolviera ____, el sistema dejaría de ser un problema". Si la respuesta es el servidor, es rehospedar. Si es que no habla con los demás sistemas, es encapsular. Si es que nadie se atreve a modificarlo, es refactorizar. Si es que ya no refleja cómo trabajamos, es reconstruir.
Ruta 1 · Rehospedar
Consiste en mover el sistema tal cual está a infraestructura moderna o a la nube, sin modificar el código. Es la ruta más rápida y la más barata, y también la más malentendida: no moderniza el software, moderniza dónde vive.
| Aspecto | Rehospedar |
|---|---|
| Qué resuelve | Hardware obsoleto, centro de datos propio, continuidad física, respaldo y recuperación |
| Qué no resuelve | Nada del software: si era imposible de mantener, lo sigue siendo |
| Riesgo principal | Creer que el proyecto terminó. El problema de fondo sigue ahí, ahora con renta mensual |
| Señal de que es la ruta | El sistema funciona bien y nadie se queja de él; lo que preocupa es el servidor |
Rehospedar es una decisión de infraestructura disfrazada de modernización. Es válida y muchas veces urgente, pero conviene llamarla por su nombre para no pausar el proyecto real durante dos años.
Ruta 2 · Encapsular con APIs
Consiste en dejar el sistema heredado intacto y construir encima una capa de servicios que permita a otros sistemas leer y escribir sus datos sin tocar el código original. Es la ruta que más casos resuelve y la que menos se propone.
El escenario típico en la industria mexicana es este: un sistema con veinte años encima cuya lógica de negocio sigue siendo correcta —factura bien, calcula bien, controla bien— pero que vive aislado. No se puede conectar con el comercio electrónico, ni con el sistema del cliente grande que exige integración, ni con una herramienta de reportes moderna. Ese sistema no necesita reescribirse: necesita puertas.
| Aspecto | Encapsular con APIs |
|---|---|
| Qué resuelve | Aislamiento, integración con terceros, acceso desde aplicaciones nuevas, reportes modernos |
| Qué no resuelve | La dificultad de mantener el sistema original ni su dependencia de una sola persona |
| Riesgo principal | Que la capa de APIs se vuelva otro sistema sin documentar si no se diseña con criterio |
| Señal de que es la ruta | La lógica sirve, pero mover un dato entre sistemas implica que alguien lo capture a mano |
Encapsular tiene además una ventaja estratégica que rara vez se menciona: desbloquea las otras rutas. Una vez que el sistema está expuesto con APIs, se puede construir lo nuevo alrededor y sustituir por partes sin que la operación se entere. Es el paso que convierte una reescritura de dos años en una secuencia de módulos de seis semanas.
Buena parte de lo que se plantea como una reescritura completa se resuelve encapsulando primero y sustituyendo después, por partes.
Brenda Infinite® · INCEPTIORuta 3 · Refactorizar por módulos
Consiste en reescribir el sistema por partes, conservando la lógica de negocio que ya está validada por años de operación. No es empezar de cero: es trasladar lo que funciona a una base que sí se puede mantener.
Lo que hace viable esta ruta es el patrón de estrangulamiento: el sistema nuevo va rodeando al viejo, tomando un proceso a la vez, hasta que el viejo queda sin uso. Durante toda la transición los dos conviven y comparten datos, y si un módulo nuevo falla se regresa al anterior el mismo día.
| Aspecto | Refactorizar por módulos |
|---|---|
| Qué resuelve | Mantenibilidad, velocidad de cambio, dependencia de una persona, tecnología sin soporte |
| Qué no resuelve | Procesos mal diseñados: si la lógica está mal, refactorizar la traslada tal cual |
| Riesgo principal | Empezar por el módulo más complejo en lugar del que más duele con menos riesgo |
| Señal de que es la ruta | El sistema hace lo correcto, pero nadie se atreve a modificarlo |
La secuencia importa más que la velocidad. El primer módulo debe elegirse por la combinación de dolor alto y riesgo bajo, porque su función real no es resolver el proceso: es demostrarle a la organización que el método funciona.
Ruta 4 · Reconstruir
Consiste en construir un sistema nuevo y migrar datos y procesos por etapas. Es la ruta más cara, la más larga y la única que se justifica cuando la lógica del sistema actual ya no refleja cómo opera la empresa.
El indicador más claro no es técnico: es que la operación ya trabaja por fuera del sistema. Cuando la gente arma hojas de cálculo paralelas, cuando el sistema se usa solo para facturar al final y todo lo demás se lleva en otro lado, la lógica que está adentro dejó de ser la lógica del negocio. Conservarla en una tecnología nueva sería pagar por preservar algo que ya nadie usa.
| Aspecto | Reconstruir |
|---|---|
| Qué resuelve | Todo lo anterior, más el desajuste entre el sistema y la operación real |
| Qué no resuelve | La falta de definición: si el proceso está en discusión, reconstruir lo congela mal |
| Riesgo principal | Reproducir el sistema viejo con tecnología nueva por no cuestionar los requisitos |
| Señal de que es la ruta | La operación ya trabaja por fuera del sistema y el sistema solo registra el final |
El criterio de decisión en tres preguntas
| Pregunta | Si la respuesta es sí | Si la respuesta es no |
|---|---|---|
| ¿La lógica del sistema todavía refleja cómo opera la empresa? | Rehospedar, encapsular o refactorizar | Reconstruir |
| ¿El problema principal es que no se comunica con otros sistemas? | Encapsular con APIs | Depende de las otras dos |
| ¿Se puede modificar sin miedo a romper algo? | Rehospedar alcanza | Refactorizar por módulos |
El caso más frecuente en México
Lógica correcta, sistema aislado y nadie se atreve a tocarlo. Es decir: sí a la primera, sí a la segunda, no a la tercera. Se resuelve encapsulando primero y refactorizando después, y es la combinación que más veces hemos aplicado en manufactura y distribución.
Casi siempre se combinan
Presentar las cuatro rutas como opciones excluyentes es útil para explicarlas, pero engañoso en la práctica. Un proyecto real suele verse así: se rehospeda para salir del servidor que ya es un riesgo, se encapsula para poder construir alrededor, se refactorizan los tres módulos que más duelen, y se reconstruye solo el proceso que cambió tanto que ya no se parece a lo que el sistema hace.
Lo que se decide al principio no es una ruta única para todo el sistema, sino una ruta por módulo. Ese cambio de encuadre es el que vuelve manejable un proyecto que de otro modo se ve enorme.
Los cuatro errores de elección más caros
- Reconstruir cuando bastaba encapsular. Es el error más caro y el más común. Se detecta porque nadie supo explicar qué tiene de malo la lógica actual, solo que el sistema "ya está viejo".
- Rehospedar creyendo que se resolvió el problema. El proyecto se cierra, el presupuesto se agota y dos años después el sistema sigue sin poder modificarse, ahora con costo mensual de nube.
- Refactorizar un proceso que estaba por rediseñarse. Se trasladó con cuidado a tecnología nueva algo que seis meses después se eliminó. Primero se define el proceso, después se automatiza.
- Empezar por el módulo más difícil. Elegir el proceso más complejo como primera fase para "salir de lo peor" es la forma más segura de que el proyecto pierda apoyo antes de mostrar un resultado.
El denominador común de los cuatro es el mismo: se eligió la ruta antes de tener el diagnóstico. Dos a cuatro semanas de levantamiento cuestan mucho menos que cualquiera de estos errores.
Preguntas frecuentes
Son tres rutas distintas de modernización. Migrar o rehospedar mueve el sistema a infraestructura moderna sin tocar el código y solo resuelve el hardware. Encapsular lo deja intacto y lo expone con APIs para que otros sistemas puedan usarlo, resolviendo el aislamiento. Reescribir o refactorizar sustituye el código por partes conservando la lógica validada, y resuelve la mantenibilidad.
Consiste en dejar el sistema heredado intacto y construir sobre él una capa de servicios que permita a otros sistemas leer y escribir sus datos sin tocar el código original. Resuelve el caso más frecuente en la industria mexicana: un sistema cuya lógica sigue siendo correcta pero que vive aislado. Además desbloquea las otras rutas, porque una vez expuesto se puede construir alrededor y sustituir por partes.
Es la técnica que hace viable reescribir un sistema sin detener la operación: el sistema nuevo va rodeando al viejo tomando un proceso a la vez, hasta que el viejo queda sin uso y se apaga. Durante toda la transición ambos conviven y comparten datos, y si un módulo nuevo falla se regresa al anterior el mismo día.
Solo cuando la lógica del sistema actual ya no refleja cómo opera la empresa. El indicador más claro no es técnico: es que la operación ya trabaja por fuera del sistema, con hojas de cálculo paralelas, y el sistema se usa solo para registrar el final del proceso. Conservar esa lógica en tecnología nueva sería pagar por preservar algo que ya nadie usa.
No por sí solo. Mover el sistema tal cual a la nube se llama rehospedar y resuelve el hardware obsoleto, el centro de datos y la continuidad física, pero no cambia nada del software. Si el sistema era imposible de mantener, lo sigue siendo en la nube y ahora con renta mensual. Es una decisión de infraestructura válida, pero conviene llamarla por su nombre.
Casi siempre se combinan, y de hecho lo que se decide al inicio no es una ruta única para todo el sistema sino una ruta por módulo. Un proyecto típico rehospeda para salir del servidor en riesgo, encapsula para poder construir alrededor, refactoriza los módulos que más duelen y reconstruye solo el proceso que ya no se parece a lo que el sistema hace.
Por el que combine dolor alto y riesgo bajo, no por el más complejo. La función real del primer módulo no es resolver ese proceso: es demostrarle a la organización que el método funciona. Empezar por el módulo más difícil para salir de lo peor es la forma más segura de que el proyecto pierda apoyo antes de mostrar un resultado.
Reconstruir cuando bastaba encapsular, rehospedar creyendo que se resolvió el problema de fondo, refactorizar un proceso que estaba por rediseñarse, y empezar por el módulo más difícil. El denominador común es que la ruta se eligió antes de tener el diagnóstico.
¿Ya sabe cuál de las cuatro rutas le toca?
En la sesión de diagnóstico revisamos su sistema, identificamos la ruta por módulo y entregamos la secuencia con el primer módulo definido. Si la ruta correcta resulta ser la más barata, se lo decimos igual.
Migrar, reescribir o encapsular: cómo elegir la ruta de modernización
Casi todo el mundo salta directo a reescribir, que es la ruta más cara y más riesgosa de las cuatro. Aquí está el criterio para elegir, los riesgos de cada camino y por qué encapsular resuelve más casos de los que parece.
En esta guía
Respuesta corta
Hay cuatro rutas y elegir mal cuesta meses. Rehospedar mueve el sistema a infraestructura moderna sin tocar el código: sirve cuando el problema es el hardware. Encapsular lo expone con APIs sin modificarlo: sirve cuando el problema es el aislamiento, y resuelve el caso más frecuente en la industria mexicana. Refactorizar reescribe por partes conservando la lógica validada: sirve cuando el sistema es correcto pero imposible de mantener. Reconstruir empieza de cero: solo cuando la lógica actual ya no refleja cómo opera la empresa.
El problema no es técnico, es de diagnóstico
Cuando una empresa decide que su sistema ya no da más, la conversación salta casi siempre al mismo lugar: hay que hacer uno nuevo. Es la conclusión más intuitiva y la más cara de las cuatro posibles.
La razón por la que se llega ahí tan rápido es que el dolor se siente como una sola cosa —"el sistema ya no sirve"— cuando en realidad son varios problemas distintos que se manifiestan igual. Un sistema que no se integra con nada duele parecido a uno que nadie se atreve a tocar, y parecido a uno que corre sobre un servidor que ya no se fabrica. Pero cada uno de esos tres tiene una solución diferente, y dos de ellas no requieren reescribir una sola línea.
La pregunta que ordena todo
Antes de elegir ruta, complete esta frase con una sola causa: "si mañana se resolviera ____, el sistema dejaría de ser un problema". Si la respuesta es el servidor, es rehospedar. Si es que no habla con los demás sistemas, es encapsular. Si es que nadie se atreve a modificarlo, es refactorizar. Si es que ya no refleja cómo trabajamos, es reconstruir.
Ruta 1 · Rehospedar
Consiste en mover el sistema tal cual está a infraestructura moderna o a la nube, sin modificar el código. Es la ruta más rápida y la más barata, y también la más malentendida: no moderniza el software, moderniza dónde vive.
| Aspecto | Rehospedar |
|---|---|
| Qué resuelve | Hardware obsoleto, centro de datos propio, continuidad física, respaldo y recuperación |
| Qué no resuelve | Nada del software: si era imposible de mantener, lo sigue siendo |
| Riesgo principal | Creer que el proyecto terminó. El problema de fondo sigue ahí, ahora con renta mensual |
| Señal de que es la ruta | El sistema funciona bien y nadie se queja de él; lo que preocupa es el servidor |
Rehospedar es una decisión de infraestructura disfrazada de modernización. Es válida y muchas veces urgente, pero conviene llamarla por su nombre para no pausar el proyecto real durante dos años.
Ruta 2 · Encapsular con APIs
Consiste en dejar el sistema heredado intacto y construir encima una capa de servicios que permita a otros sistemas leer y escribir sus datos sin tocar el código original. Es la ruta que más casos resuelve y la que menos se propone.
El escenario típico en la industria mexicana es este: un sistema con veinte años encima cuya lógica de negocio sigue siendo correcta —factura bien, calcula bien, controla bien— pero que vive aislado. No se puede conectar con el comercio electrónico, ni con el sistema del cliente grande que exige integración, ni con una herramienta de reportes moderna. Ese sistema no necesita reescribirse: necesita puertas.
| Aspecto | Encapsular con APIs |
|---|---|
| Qué resuelve | Aislamiento, integración con terceros, acceso desde aplicaciones nuevas, reportes modernos |
| Qué no resuelve | La dificultad de mantener el sistema original ni su dependencia de una sola persona |
| Riesgo principal | Que la capa de APIs se vuelva otro sistema sin documentar si no se diseña con criterio |
| Señal de que es la ruta | La lógica sirve, pero mover un dato entre sistemas implica que alguien lo capture a mano |
Encapsular tiene además una ventaja estratégica que rara vez se menciona: desbloquea las otras rutas. Una vez que el sistema está expuesto con APIs, se puede construir lo nuevo alrededor y sustituir por partes sin que la operación se entere. Es el paso que convierte una reescritura de dos años en una secuencia de módulos de seis semanas.
Buena parte de lo que se plantea como una reescritura completa se resuelve encapsulando primero y sustituyendo después, por partes.
Brenda Infinite® · INCEPTIORuta 3 · Refactorizar por módulos
Consiste en reescribir el sistema por partes, conservando la lógica de negocio que ya está validada por años de operación. No es empezar de cero: es trasladar lo que funciona a una base que sí se puede mantener.
Lo que hace viable esta ruta es el patrón de estrangulamiento: el sistema nuevo va rodeando al viejo, tomando un proceso a la vez, hasta que el viejo queda sin uso. Durante toda la transición los dos conviven y comparten datos, y si un módulo nuevo falla se regresa al anterior el mismo día.
| Aspecto | Refactorizar por módulos |
|---|---|
| Qué resuelve | Mantenibilidad, velocidad de cambio, dependencia de una persona, tecnología sin soporte |
| Qué no resuelve | Procesos mal diseñados: si la lógica está mal, refactorizar la traslada tal cual |
| Riesgo principal | Empezar por el módulo más complejo en lugar del que más duele con menos riesgo |
| Señal de que es la ruta | El sistema hace lo correcto, pero nadie se atreve a modificarlo |
La secuencia importa más que la velocidad. El primer módulo debe elegirse por la combinación de dolor alto y riesgo bajo, porque su función real no es resolver el proceso: es demostrarle a la organización que el método funciona.
Ruta 4 · Reconstruir
Consiste en construir un sistema nuevo y migrar datos y procesos por etapas. Es la ruta más cara, la más larga y la única que se justifica cuando la lógica del sistema actual ya no refleja cómo opera la empresa.
El indicador más claro no es técnico: es que la operación ya trabaja por fuera del sistema. Cuando la gente arma hojas de cálculo paralelas, cuando el sistema se usa solo para facturar al final y todo lo demás se lleva en otro lado, la lógica que está adentro dejó de ser la lógica del negocio. Conservarla en una tecnología nueva sería pagar por preservar algo que ya nadie usa.
| Aspecto | Reconstruir |
|---|---|
| Qué resuelve | Todo lo anterior, más el desajuste entre el sistema y la operación real |
| Qué no resuelve | La falta de definición: si el proceso está en discusión, reconstruir lo congela mal |
| Riesgo principal | Reproducir el sistema viejo con tecnología nueva por no cuestionar los requisitos |
| Señal de que es la ruta | La operación ya trabaja por fuera del sistema y el sistema solo registra el final |
El criterio de decisión en tres preguntas
| Pregunta | Si la respuesta es sí | Si la respuesta es no |
|---|---|---|
| ¿La lógica del sistema todavía refleja cómo opera la empresa? | Rehospedar, encapsular o refactorizar | Reconstruir |
| ¿El problema principal es que no se comunica con otros sistemas? | Encapsular con APIs | Depende de las otras dos |
| ¿Se puede modificar sin miedo a romper algo? | Rehospedar alcanza | Refactorizar por módulos |
El caso más frecuente en México
Lógica correcta, sistema aislado y nadie se atreve a tocarlo. Es decir: sí a la primera, sí a la segunda, no a la tercera. Se resuelve encapsulando primero y refactorizando después, y es la combinación que más veces hemos aplicado en manufactura y distribución.
Casi siempre se combinan
Presentar las cuatro rutas como opciones excluyentes es útil para explicarlas, pero engañoso en la práctica. Un proyecto real suele verse así: se rehospeda para salir del servidor que ya es un riesgo, se encapsula para poder construir alrededor, se refactorizan los tres módulos que más duelen, y se reconstruye solo el proceso que cambió tanto que ya no se parece a lo que el sistema hace.
Lo que se decide al principio no es una ruta única para todo el sistema, sino una ruta por módulo. Ese cambio de encuadre es el que vuelve manejable un proyecto que de otro modo se ve enorme.
Los cuatro errores de elección más caros
- Reconstruir cuando bastaba encapsular. Es el error más caro y el más común. Se detecta porque nadie supo explicar qué tiene de malo la lógica actual, solo que el sistema "ya está viejo".
- Rehospedar creyendo que se resolvió el problema. El proyecto se cierra, el presupuesto se agota y dos años después el sistema sigue sin poder modificarse, ahora con costo mensual de nube.
- Refactorizar un proceso que estaba por rediseñarse. Se trasladó con cuidado a tecnología nueva algo que seis meses después se eliminó. Primero se define el proceso, después se automatiza.
- Empezar por el módulo más difícil. Elegir el proceso más complejo como primera fase para "salir de lo peor" es la forma más segura de que el proyecto pierda apoyo antes de mostrar un resultado.
El denominador común de los cuatro es el mismo: se eligió la ruta antes de tener el diagnóstico. Dos a cuatro semanas de levantamiento cuestan mucho menos que cualquiera de estos errores.
Preguntas frecuentes
Son tres rutas distintas de modernización. Migrar o rehospedar mueve el sistema a infraestructura moderna sin tocar el código y solo resuelve el hardware. Encapsular lo deja intacto y lo expone con APIs para que otros sistemas puedan usarlo, resolviendo el aislamiento. Reescribir o refactorizar sustituye el código por partes conservando la lógica validada, y resuelve la mantenibilidad.
Consiste en dejar el sistema heredado intacto y construir sobre él una capa de servicios que permita a otros sistemas leer y escribir sus datos sin tocar el código original. Resuelve el caso más frecuente en la industria mexicana: un sistema cuya lógica sigue siendo correcta pero que vive aislado. Además desbloquea las otras rutas, porque una vez expuesto se puede construir alrededor y sustituir por partes.
Es la técnica que hace viable reescribir un sistema sin detener la operación: el sistema nuevo va rodeando al viejo tomando un proceso a la vez, hasta que el viejo queda sin uso y se apaga. Durante toda la transición ambos conviven y comparten datos, y si un módulo nuevo falla se regresa al anterior el mismo día.
Solo cuando la lógica del sistema actual ya no refleja cómo opera la empresa. El indicador más claro no es técnico: es que la operación ya trabaja por fuera del sistema, con hojas de cálculo paralelas, y el sistema se usa solo para registrar el final del proceso. Conservar esa lógica en tecnología nueva sería pagar por preservar algo que ya nadie usa.
No por sí solo. Mover el sistema tal cual a la nube se llama rehospedar y resuelve el hardware obsoleto, el centro de datos y la continuidad física, pero no cambia nada del software. Si el sistema era imposible de mantener, lo sigue siendo en la nube y ahora con renta mensual. Es una decisión de infraestructura válida, pero conviene llamarla por su nombre.
Casi siempre se combinan, y de hecho lo que se decide al inicio no es una ruta única para todo el sistema sino una ruta por módulo. Un proyecto típico rehospeda para salir del servidor en riesgo, encapsula para poder construir alrededor, refactoriza los módulos que más duelen y reconstruye solo el proceso que ya no se parece a lo que el sistema hace.
Por el que combine dolor alto y riesgo bajo, no por el más complejo. La función real del primer módulo no es resolver ese proceso: es demostrarle a la organización que el método funciona. Empezar por el módulo más difícil para salir de lo peor es la forma más segura de que el proyecto pierda apoyo antes de mostrar un resultado.
Reconstruir cuando bastaba encapsular, rehospedar creyendo que se resolvió el problema de fondo, refactorizar un proceso que estaba por rediseñarse, y empezar por el módulo más difícil. El denominador común es que la ruta se eligió antes de tener el diagnóstico.
¿Ya sabe cuál de las cuatro rutas le toca?
En la sesión de diagnóstico revisamos su sistema, identificamos la ruta por módulo y entregamos la secuencia con el primer módulo definido. Si la ruta correcta resulta ser la más barata, se lo decimos igual.