Modernización de sistemas legados: guía práctica para fundadores

En la práctica, la modernización de sistemas legados es el trabajo de llevar un sistema antiguo pero valioso a un stack, una arquitectura o una infraestructura más nueva sin perder lo que lo hace valioso: los usuarios, los datos y los ingresos. Bien hecha, ocurre pieza por pieza mientras el producto sigue funcionando, no como una reescritura big-bang que congela el negocio durante un año.

Soy Filipe, ingeniero full-stack sénior radicado en Brasil. Esta guía sale de siete años construyendo productos web y móviles, incluido liderar la migración de una plataforma en producción mientras la gente seguía usándola todos los días. Está escrita para fundadores y CTOs que heredaron una base de código, están dejando una agencia o están atascados en un stack que frena al equipo.

¿Qué es la modernización de sistemas legados y cuándo un sistema cuenta como legado?

Un sistema es legado cuando todavía hace un trabajo importante pero es difícil de cambiar con seguridad. La edad es una señal débil. He visto apps bastante jóvenes que en la práctica eran legadas porque nadie las entendía, y sistemas mucho más antiguos que estaban sanos porque tenían pruebas, documentación y límites claros.

Estas son las señales que busco:

• Miedo a desplegar. Los releases son raros, manuales o se hacen de madrugada porque algo podría romperse.
• El conocimiento está en una sola cabeza. El desarrollador original o la agencia se fue, y nadie puede explicar por qué existe cierto código.
• Dependencias sin soporte. La versión del lenguaje, el framework o las librerías ya no reciben correcciones de seguridad.
• Sin red de seguridad. Hay pocas o ninguna prueba automatizada, así que cada cambio es una apuesta.
• Fricción para contratar. Los ingenieros no quieren trabajar con el stack, o los pocos que lo conocen son caros y difíciles de encontrar.
• Entrega lenta de funcionalidades. Un cambio pequeño tarda semanas porque todo está enredado.

Modernización es el término paraguas para las opciones que tienes: refactorizar el código, moverlo a una nueva infraestructura, reemplazar partes o reconstruirlo. Son estrategias distintas con riesgos distintos, y las comparo más abajo.

Legado no es lo mismo que deuda técnica

La deuda técnica es la acumulación de atajos en una base de código. Legado es la situación en la que esa deuda, sumada a tecnología desactualizada y conocimiento perdido, hace que el sistema sea difícil de evolucionar. Puedes tener deuda sin ser legado, y puedes pagar deuda sin modernizar toda la plataforma.

¿Cómo sabes que es momento de modernizar en lugar de parchar?

Parchar es lo correcto cuando los problemas son locales y la base es sólida. Modernizar es lo correcto cuando la base misma es el problema. La prueba que uso es simple: ¿el costo de cada cambio está subiendo con el tiempo, y la causa es estructural?

Señales que apuntan a modernizar

• No se pueden aplicar correcciones de seguridad porque el runtime o el framework llegó al fin de su vida útil.
• Cada funcionalidad nueva rompe algo que no tiene relación.
• No puedes contratar ni incorporar ingenieros a un ritmo razonable.
• El producto necesita capacidades que la arquitectura no soporta, como funciones en tiempo real, una app móvil sobre la misma API o múltiples tenants.
• Los costos de infraestructura o las caídas crecen más rápido que el uso.
• Un comprador, inversionista o cliente enterprise está haciendo preguntas difíciles sobre seguridad o mantenibilidad.

Señales que apuntan a parchar

• Un módulo es el problema y el resto es estable.
• El dolor es una funcionalidad que falta, no una estructura rota.
• El equipo es productivo y el stack todavía tiene soporte.
• No tienes un resultado de negocio claro que la modernización desbloquearía.

Una advertencia: a los ingenieros nos encantan los stacks nuevos, a mí también. No modernices porque una tecnología está de moda. Escribe primero la razón de negocio, como releases más rápidos, menos incidentes, capacidad de contratar o un requisito de un cliente. Si no puedes, probablemente estás ante un problema de refactorización, no ante un proyecto de modernización.

Cuando sí modernices, ayuda tener una línea base. Anota cuánto tarda un cambio típico desde la idea hasta producción, con qué frecuencia fallan los despliegues y cuántos incidentes tienes por mes. Sin esos números no podrás saber después si el trabajo valió la pena.

¿Qué deberías hacer primero cuando heredas una base de código legada?

No empieces cambiando código. Empieza tomando el control. El orden que sigo en los primeros 30 días es: primero los accesos, luego el build, luego los flujos de dinero, luego los riesgos. El orden importa porque cada paso depende del anterior.

1. Accesos

Cuando tomo una base de código, lo primero que hago es inventariar todo lo que toca el sistema y asegurarme de que la empresa sea dueña de ello. Eso incluye repositorios de código, cuentas de hosting y de nube, el dominio y el DNS, la base de datos, servicios de terceros (pagos, email, analítica, autenticación), cuentas en las tiendas de apps y secretos. Si la agencia o el desarrollador anterior es el único dueño de cualquiera de estos, transfiere la titularidad ahora, mientras la relación todavía es cooperativa.

Luego rota las credenciales que antiguos contratistas todavía podrían conocer. Es rutina, no una acusación.

2. El build

¿Puedes compilar y desplegar el sistema desde cero en una máquina limpia? Muchas bases de código heredadas solo funcionan en la laptop del desarrollador original. Consigue un build reproducible, documenta los pasos y haz tú mismo un despliegue antes de cambiar cualquier cosa. Si no puedes desplegar, no puedes arreglar nada con seguridad.

3. Los flujos de dinero

Identifica los flujos en los que el negocio gana o pierde dinero: checkout, suscripciones, facturación, registro, la acción principal por la que pagan los usuarios. Rastrea cada uno de punta a punta, agrégale monitoreo y alertas, y escribe al menos una prueba automatizada básica o un checklist para él. Son las partes que nunca debes romper. Aprendí a tratar estos flujos con especial cuidado en el equipo de carrito y checkout de Total Wine & More, un minorista estadounidense con 190 millones de visitas al año en su sitio, donde el checkout es justo el lugar en el que un error pequeño se vuelve caro rápido.

4. Los riesgos

Solo ahora haz una revisión de riesgos más amplia: dependencias desactualizadas, secretos expuestos, backups faltantes, restauraciones nunca probadas, manejo de datos poco claro, puntos únicos de falla. Ordénalos por probabilidad e impacto, y corrige primero los baratos y graves. Una auditoría de código es una versión más profunda de este paso, y vale la pena hacerla por sí sola.

Al final de los 30 días deberías tener un mapa del sistema, un despliegue repetible, los flujos de dinero monitoreados y una lista corta y priorizada de riesgos. Ese es el verdadero punto de partida para cualquier decisión de modernización.

Reescribir, refactorizar, replatforming o strangler: ¿qué enfoque encaja?

Estas cuatro palabras suelen confundirse, así que aquí están lado a lado.

Por qué mi opción por defecto es lo incremental

Mi opción por defecto es la migración incremental, normalmente el enfoque strangler: poner un interruptor delante de todo antes de escribir código nuevo. Las solicitudes pasan por una capa de enrutamiento, y esa capa decide si el sistema antiguo o el nuevo atiende cada una. Luego mueves una porción a la vez, la verificas en producción y conservas la posibilidad de volver atrás. Ese es el patrón que nos permitió mover una plataforma en producción en avanzzada sin pedirles a los usuarios que dejaran de usarla.

Las reescrituras big-bang fallan por razones predecibles. El sistema antiguo sigue cambiando mientras lo reconstruyes, así que el objetivo se mueve. El comportamiento no documentado, como los casos límite de los que dependen los clientes, desaparece en la versión nueva. Y no entregas ningún valor hasta el final, que es justo cuando la presión es más alta.

Una reescritura todavía puede ser la decisión correcta. Si el sistema es pequeño, si la lógica de negocio se entiende bien o si el código antiguo está tan roto que envolverlo es más difícil que reemplazarlo, reconstruir todo puede ser más rápido. Solo toma esa decisión con evidencia, no por frustración.

¿Cómo migras una plataforma en producción sin detener el producto?

En avanzzada lideré la migración completa de una plataforma que postula automáticamente a ofertas de empleo por sus usuarios. Movimos toda su arquitectura de un stack legado a uno nuevo mientras la gente seguía usándola todos los días. Las lecciones de abajo vienen de ese trabajo y de situaciones similares.

Paso 1: pon el interruptor primero

Antes de cualquier código nuevo, agrega una capa de enrutamiento o feature flags para poder enviar tráfico a la implementación antigua o a la nueva, por ruta, por grupo de usuarios o por porcentaje. Esta es la decisión más importante del proyecto, porque hace reversible cada paso posterior.

Paso 2: elige la primera porción con cuidado

Empieza con algo real pero de bajo riesgo: una página de solo lectura, una herramienta interna, una funcionalidad pequeña con entradas y salidas claras. El objetivo es probar el pipeline, el despliegue, el monitoreo y el rollback, no mover primero la parte más difícil.

Paso 3: documenta el comportamiento actual

Antes de reemplazar una funcionalidad, registra lo que hace hoy, incluidos los casos raros. Las pruebas que corren contra el sistema antiguo y luego contra el nuevo son la forma más barata de encontrar comportamiento faltante. Cuando los dos no coincidan, decide cuál tiene razón.

Paso 4: libera primero para pocos usuarios

Envía una pequeña parte del tráfico a la ruta nueva, observa los errores y las métricas de negocio, y luego amplíala. Si algo se rompe, vuelve a mover el interruptor. Esa es la idea detrás de los releases canario, y funciona porque los errores se quedan pequeños.

Paso 5: maneja los datos de forma deliberada

Los datos suelen ser la parte más difícil. Las opciones incluyen compartir la base de datos antigua durante la transición, sincronizar dos bases de datos o migrar por fases. Elijas lo que elijas, define qué sistema es la fuente de verdad en cada etapa y ensaya la migración en una copia de los datos de producción antes de ejecutarla de verdad.

Paso 6: retira el código antiguo

Termina cada porción borrando la implementación antigua. Una migración que nunca elimina nada te deja manteniendo dos sistemas indefinidamente, que es el peor resultado.

Espera que la mitad del proyecto se sienta lenta. Estás operando dos sistemas, y ese es el precio de no detener el negocio.

¿Cuánto cuesta la modernización de sistemas legados y por qué las reescrituras cuestan más?

No te voy a dar una cifra, porque cualquier número sin conocer tu sistema sería inventado. Lo que sí puedo darte es qué impulsa el costo y cómo comparar opciones.

Qué impulsa el costo

• Tamaño y complejidad del sistema. Cantidad de funcionalidades, integraciones y roles de usuario.
• Calidad de lo que ya existe. Las pruebas, la documentación y los límites limpios abaratan todo.
• Volumen y forma de los datos. Los datos desordenados o inconsistentes agregan trabajo de migración.
• Requisitos de disponibilidad. Cuanto menos tiempo de inactividad toleres, más cuidadoso y lento será el cambio.
• Seniority del equipo. Los ingenieros sénior cuestan más por hora, pero tienden a evitar desvíos costosos.
• Disciplina de alcance. Agregar funcionalidades durante una migración es el clásico destructor de presupuestos.

Por qué una reescritura suele costar más

Una reescritura suele costar más y tardar más que una migración incremental, porque el sistema antiguo debe seguir funcionando en paralelo. Pagas por mantener el producto antiguo, pagas por construir el nuevo y vuelves a pagar para alcanzar la paridad de funcionalidades antes de poder hacer el cambio. Con un enfoque incremental, cada porción entrega valor en cuanto sale, y puedes detenerte en cualquier momento con un producto que funciona.

Eso no hace que la migración incremental sea barata. La capa de enrutamiento, el período con ambos sistemas en marcha y la sincronización de datos requieren esfuerzo. Pero el gasto se reparte, el riesgo es menor y puedes corregir el rumbo.

Cómo mantener las estimaciones honestas

• Haz un descubrimiento con tiempo acotado (los 30 días de traspaso son uno bueno) antes de comprometerte con un presupuesto completo.
• Estima porción por porción, no el programa completo.
• Incluye pruebas, migración de datos, monitoreo y el costo de operar ambos sistemas.
• Agrega un margen para sorpresas. En bases de código heredadas siempre hay alguna.

Desconfía de las cotizaciones de precio fijo hechas sin ver el código. Las incógnitas son demasiado grandes para ponerles precio con honestidad.

¿Cómo mantienes seguros a los usuarios y los ingresos fluyendo durante el cambio?

Los usuarios apenas deberían notar la migración. Estas prácticas lo hacen realista.

Protege primero los flujos de dinero

El checkout, la facturación y el registro reciben las protecciones más fuertes: monitoreo, alertas, pruebas y un rollback documentado. Si migras uno de ellos, hazlo tarde, con una pequeña parte del tráfico, en un período en que tu equipo esté totalmente disponible para vigilarlo.

Ten siempre un camino de vuelta

Cada release debe poder revertirse rápido. Con una capa de enrutamiento, el rollback es un cambio de configuración, no un redespliegue de emergencia. Las configuraciones blue-green, en las que el entorno antiguo sigue arriba hasta que el nuevo demuestra que funciona, cumplen el mismo propósito para los cambios de infraestructura.

Monitorea métricas de negocio, no solo errores

Un flujo migrado puede no devolver ningún error y aun así perder dinero, por ejemplo al descartar un campo en silencio o cambiar una redirección. Mide la conversión, los pedidos completados o las postulaciones enviadas con éxito, sea cual sea la acción clave de tu producto, y compara la ruta antigua y la nueva mientras ambas corren.

Protege los datos

• Haz backups verificados antes de cada paso con datos, y prueba que puedes restaurarlos.
• Limita quién puede tocar los datos de producción durante la migración.
• Lleva un registro claro de qué se movió, cuándo y cómo.
• Si manejas datos personales o regulados, involucra a un abogado o asesor de cumplimiento. Este artículo no es asesoría legal.

Comunica

Cuéntale al equipo de soporte y a quienes atienden clientes qué está cambiando y cuándo. La mayor parte del dolor de los clientes durante una migración no es técnico, es la sorpresa. Una nota interna corta antes de cada release ahorra mucha confusión.

Congela lo que puedas

Limita el trabajo en funcionalidades nuevas en las áreas que se están migrando. Los cambios que llegan al código antiguo mientras lo reemplazas generan trabajo doble y diferencias sutiles. Un congelamiento corto por porción suele ser más fácil que uno largo para todo el sistema.

¿Deberías modernizar con tu equipo interno, con un contratista o con una agencia?

No hay una respuesta universal. Depende de la capacidad de tu equipo, de tus plazos y de cuánto conocimiento institucional necesitas conservar.

Equipo interno

Lo mejor para la responsabilidad a largo plazo y el conocimiento del dominio. La desventaja es que tus ingenieros probablemente también están operando el producto, así que la modernización compite con el trabajo diario, y quizá nunca hayan hecho una migración así.

Contratista sénior o equipo pequeño

Funciona bien cuando necesitas liderazgo con experiencia durante un período definido, para armar el plan, construir las primeras porciones y dejarle al equipo un patrón que funciona. Funciona mejor cuando tu propia gente sigue involucrada, para que el conocimiento no se vaya cuando termine el contrato. Aclaración completa: yo mismo soy un ingeniero brasileño, así que tengo un sesgo a favor del modelo nearshore. Tiene ventajas reales, como la superposición horaria con EE. UU., pero evalúalo frente a tu propio contexto.

Agencia

Útil cuando necesitas volumen, una mezcla de habilidades y gestión de proyecto en un solo paquete. El riesgo es uno que quizá ya conoces: si la agencia es dueña del conocimiento y de las cuentas, puedes terminar heredando una base de código otra vez. Si vas por este camino, exige documentación, repositorios y cuentas de nube a tu nombre, y traspasos regulares.

Qué revisar, elijas lo que elijas

• ¿Empiezan con un descubrimiento o saltan directo a una estimación de reescritura?
• ¿Proponen un plan incremental y reversible?
• ¿Serás dueño de todo el código, las cuentas y la documentación desde el primer día?
• ¿Quién es responsable de los flujos de dinero durante la migración?
• ¿Pueden mostrar una migración anterior de un sistema en producción y explicar qué salió mal en ella?

Entregar un sistema legado a un nuevo proveedor sin un plan es la forma habitual en que los traspasos salen mal. Los primeros 30 días de accesos, build y flujos de dinero deciden mucho, así que asegúrate de que alguien los haga bien, sea quien sea.

¿Quieres una segunda opinión sobre tu caso?

Si heredaste una base de código o estás planeando una migración, escríbeme a me@filipeeduardo.dev con una descripción breve de tu stack y del problema. Con gusto comparo notas contigo y te digo qué revisaría primero.