Servicios de modernización de sistemas legados: cómo evaluar un socio

Los servicios de modernización de sistemas legados abarcan todo lo necesario para llevar un sistema envejecido a un estado más seguro y más fácil de cambiar mientras el negocio sigue funcionando: auditar el código, asegurar los accesos y los datos, actualizar o reemplazar partes de la stack y migrar usuarios poco a poco. Un buen socio empieza por entender tu sistema y los flujos de dinero que no se pueden romper. Uno malo empieza cotizando una reescritura.

Soy un ingeniero sénior brasileño y lideré la migración de una plataforma en producción de una stack legada a una nueva mientras los usuarios seguían usándola todos los días. Eso me da una inclinación hacia el trabajo incremental, así que diré dónde pesa. Esta guía busca ayudarte a evaluar a cualquier socio, ya sea una agencia, un freelancer o tu propio equipo.

¿Qué incluyen realmente los servicios de modernización de sistemas legados?

La etiqueta abarca trabajos muy distintos. Pregúntale a cualquier proveedor a cuáles de estos se refiere:

• Diagnóstico o auditoría de código: leer el código, la infraestructura, las dependencias y los datos para encontrar lo que es frágil, inseguro o no está documentado.
• Estabilización: lograr que el build funcione desde una máquina limpia y agregar monitoreo, backups y pruebas básicas en torno a los flujos críticos.
• Refactorización y actualizaciones: cambiar el código o las versiones del framework sin cambiar lo que hace el producto.
• Replatforming: pasar a un nuevo hosting o un nuevo runtime con pocos cambios en el código.
• Migración incremental: reemplazar el sistema parte por parte detrás de un mecanismo de enrutamiento, para que el antiguo y el nuevo funcionen lado a lado.
• Migración de datos: mover y sincronizar bases de datos mientras los usuarios siguen trabajando.
• Transferencia de conocimiento: documentación, runbooks y capacitación para que tu equipo se haga cargo del resultado.

Muchas propuestas agrupan todo esto bajo un solo precio. Insiste en verlos como fases separadas con entregables separados. Así puedes detenerte después del diagnóstico si no te gusta lo que descubres.

¿Qué debería preguntarte un buen socio antes de cotizar?

La calidad de las preguntas es la mejor señal temprana. En mi experiencia, un socio que entiende de sistemas legados preguntará cosas como:

• ¿Quién tiene hoy acceso a los repositorios, servidores, dominios, cuentas en la nube y servicios de terceros? ¿Quién tiene las credenciales de administrador?
• ¿El sistema se puede compilar y desplegar desde cero, y quién hizo el último despliegue?
• ¿Por dónde fluyen los ingresos? ¿Qué pantallas, jobs o APIs manejan pagos, registros o acciones centrales de los usuarios?
• ¿Qué rompe el negocio si se cae durante una hora? ¿Y durante un día?
• ¿Hay una suite de pruebas, un entorno de staging o documentación, y se puede confiar en ellos?
• ¿Quién conoce la historia del sistema, y todavía se puede contactar a esas personas?
• ¿Cuál es el motivo real: costo, dificultad para contratar, seguridad, velocidad de cambio, o una venta o revisión de inversionistas?

Cuando analizo un sistema heredado, la pregunta sobre los accesos es siempre la primera que hago, porque todas las demás respuestas dependen de ella. Pero la última pregunta es la que más importa. “Queremos que sea moderno” no es un objetivo. “No podemos lanzar una funcionalidad en menos de un mes” sí lo es, y cambia lo que deberías contratar.

¿Qué señales de alerta indican una venta centrada en la reescritura?

A veces la reescritura es lo correcto, por ejemplo cuando la plataforma es diminuta o cuando es imposible razonar sobre el sistema antiguo. Pero también es la opción por defecto más cara, así que toma estas señales como advertencias:

• Un precio cerrado antes de cualquier acceso al código. No pueden conocer el tamaño del problema.
• “Todo está mal” desde la primera llamada. El código antiguo que genera dinero tiene valor. Contiene años de reglas de negocio, casos extremos y correcciones.
• Ningún plan para operar ambos sistemas. Una reescritura implica que el sistema antiguo debe seguir operando en paralelo, y de ahí vienen los costos y retrasos ocultos.
• Una fecha de corte big-bang. Un único fin de semana de cambio, sin liberación gradual y sin rollback, es una apuesta a que todo salga bien.
• Ninguna mención de los datos. Mover la base de datos suele ser más difícil que mover el código.
• Una stack nueva elegida antes de entender el problema. La herramienta debe venir después del diagnóstico.
• Propiedad poco clara. No queda claro quién se queda al final con los repositorios, las cuentas en la nube y la documentación.

La alternativa que debes buscar es un plan que ponga un mecanismo de enrutamiento delante de todo antes de escribir código nuevo y luego mueva el tráfico poco a poco.

¿Cómo estructurar los primeros 30 días de una transición?

Entregar un sistema a una nueva agencia sin un plan es una forma común de perder meses. El orden que sigo es: primero los accesos, luego el build, luego los flujos de dinero y luego los riesgos. Los rangos de días de abajo son una regla general mía, no un calendario fijo; en un sistema más grande, cada fase se alarga.

Días 1–7: accesos

Reúne y verifica cada credencial y cuenta: control de versiones, hosting, DNS, bases de datos, proveedores de pago, correo, analítica, monitoreo. Transfiere la propiedad a cuentas controladas por la empresa, no por personas. Rota los secretos que conocían los desarrolladores anteriores. Confirma que existen backups y que se puede restaurar uno.

Días 8–15: el build

Logra que el sistema funcione en una máquina limpia y que pueda desplegarlo alguien distinto del desarrollador anterior. Anota lo que tuviste que averiguar. Si no puedes reproducir un despliegue, no puedes cambiar nada de forma segura.

Días 16–23: los flujos de dinero

Rastrea de punta a punta el checkout, la facturación, el registro y los flujos centrales de los usuarios. Agrega monitoreo y algunas pruebas en torno a ellos. Son los flujos que proteges primero y cambias al final. Trabajar en el equipo de carrito y checkout de Total Wine & More convirtió esto en un hábito permanente para mí: un error pequeño en el checkout cuesta más que uno grande casi en cualquier otro lugar.

Días 24–30: los riesgos

Ahora ordena los problemas: dependencias desactualizadas, brechas de seguridad, puntos únicos de falla, pruebas faltantes y problemas de datos. Conviértelos en un plan secuenciado con la primera porción de la migración definida. Un buen socio termina este periodo con un plan escrito que puedes mostrarle a cualquiera, incluso a otro proveedor.

Agencia, freelancer o equipo interno: ¿qué modelo se ajusta a tu sistema?

Ningún modelo gana siempre. Así es como los comparo, a partir de mi propia experiencia y no de un estudio publicado. Ten en cuenta que he trabajado con clientes extranjeros como contratista a través de mi propia empresa brasileña, así que pondera mi opinión sobre la fila del contratista en consecuencia:

Un patrón que he visto funcionar es que un ingeniero sénior externo lidere el diagnóstico y las primeras porciones de la migración, mientras tu equipo interno lo acompaña y luego toma el relevo. Para sistemas grandes con muchos frentes de trabajo en paralelo, una agencia o un equipo mixto puede tener sentido. En cualquier modelo, pregunta quién exactamente va a tocar tu código.

Liderar a más de 15 personas en web, mobile y e-commerce me enseñó que el cuello de botella rara vez es la velocidad de tecleo. Es la revisión, las decisiones y mantener a todos trabajando con el mismo plan.

¿Qué preguntas debes hacer antes de firmar?

1. ¿Qué tendré por escrito al final de los primeros 30 días?
2. ¿Cómo funcionarán lado a lado el sistema antiguo y el nuevo, y cómo cambian el tráfico?
3. ¿Cuál es el plan de rollback si una parte migrada se comporta mal?
4. ¿Cómo mueven y verifican los datos mientras los usuarios siguen trabajando?
5. ¿Quién hará el trabajo y qué experiencia tiene con sistemas legados?
6. ¿De quién son el código, las cuentas y la documentación, y cómo se devuelven?
7. ¿Cómo se divide el trabajo en fases que pueda pausar o detener?
8. ¿Qué supuestos de su estimación podrían cambiar el precio?
9. ¿Puedo hablar con alguien cuyo sistema en producción hayan migrado?

Presta atención a los detalles. Las respuestas sólidas mencionan pasos concretos, trade-offs y cosas que podrían salir mal. Las débiles repiten que todo será “sin fricciones”. Si un contrato involucra propiedad intelectual, protección de datos o pagos internacionales, pide a un abogado que lo revise. Este artículo no es asesoría legal ni fiscal.

¿Quieres una segunda opinión?

Si estás comparando propuestas de modernización o heredando un sistema, escríbeme a me@filipeeduardo.dev con el contexto y te diré qué revisaría primero.