El manual de migración de sistemas heredados: oleadas, ejecución en paralelo y recuentos y checksums idénticos

Toda empresa tiene un sistema que nadie quiere tocar: una base de datos antigua, un monolito, dos herramientas que deben seguir sincronizadas. Las migraciones de golpe de esos sistemas son donde se pierden fines de semana y reputaciones. Lo que funciona es aburrido a propósito: primero mapear, mover por oleadas, ejecutar lo viejo y lo nuevo en paralelo y cambiar solo cuando los números son idénticos. Este es el manual que uso, con los proyectos en los que funcionó.

Dominik Heinrich

8 de noviembre de 202611 min de lectura

1. Por qué fallan las migraciones de golpe

Una migración de golpe lo apuesta todo a una noche: todos los datos, todas las funciones y todos los usuarios cambian a la vez. Si algo está mal, lo descubres en producción y sin vuelta atrás que no pierda el trabajo hecho desde entonces. Además, el sistema viejo deja de recibir cambios durante meses mientras se construye el nuevo, y el negocio espera.

Los proyectos de esta web que salieron bien evitaron esa apuesta. Un ERP y un CRM siguieron en uso diario con los mismos datos mientras se conectaban en ambos sentidos. Registros sanitarios muy sensibles pasaron entre dos sistemas públicos sin perder ninguno. Bases de datos de clientes se movieron a un clúster de Kubernetes con recuentos y checksums idénticos. Sistemas distintos, el mismo patrón.

2. Primero mapea el sistema viejo, con IA leyendo el código

Antes de cualquier plan, haz un mapa: qué componentes hay, qué datos posee cada uno, qué interfaces los conectan con el exterior, qué procesos corren de noche y qué personas y equipos dependen de qué. Los sistemas viejos esconden su comportamiento real en sitios que nadie recuerda: un procedimiento almacenado, un cron, una exportación CSV que alguien abre cada lunes.

Aquí es donde la IA más ha cambiado el trabajo. Un agente de código puede leer una base de código antigua y grande, listar puntos de entrada y flujos de datos y redactar el mapa, y lo que hace falta son días de revisión en lugar de semanas de lectura. Sigo verificando cada hallazgo importante contra el sistema en marcha, pero el primer borrador ya no es lo que más tarda. Pregunta también a los usuarios: la exportación que nadie documentó es la que para las nóminas.

3. Elige una estrategia por componente, no una para todo

No todas las piezas merecen reescribirse. La guía de migración de AWS recoge las estrategias habituales: retirar, mantener, rehospedar, reubicar, replataformar, recomprar y refactorizar. Úsalas por componente: el módulo de informes que nadie usa se retira, el proceso por lotes estable se rehospeda tal cual, la base de datos pasa a un servicio gestionado y solo se refactoriza la parte que frena al negocio.

Así el trabajo caro se queda donde compensa. En un proyecto de automoción, una aplicación regulada pasó a Azure Kubernetes Service, todo en Terraform, sin aflojar ni un solo control, y los costes cloud quedaron en torno a un 25 % más bajos. El ahorro vino de elegir con cuidado qué cambiar, no de cambiarlo todo.

4. Oleadas por capacidad de negocio, detrás de una fachada

Divide la migración en oleadas que tengan sentido para el negocio: primero la facturación, luego las cuentas de cliente, luego los informes. Cada oleada es lo bastante pequeña para probarla bien y deshacerla por separado. Evita cortar por capas técnicas («primero la base de datos, luego el backend»): una función a medio mover es el estado más difícil de operar.

Pon una fachada delante, el patrón strangler fig del Azure Architecture Center: usuarios y otros sistemas hablan con la fachada, y esta envía cada función al sistema viejo o al nuevo. Mover una función se convierte en un cambio de enrutamiento que puedes revertir en minutos. Oleada tras oleada, el sistema viejo encoge hasta que ya no le llega nada.

5. Mover datos sin perder ni un registro

Los datos se mueven en dos fases: una copia masiva de todo y después captura de cambios (CDC), que mantiene al día el lado nuevo hasta el cambio. Servicios gestionados como Azure Database Migration Service y AWS DMS hacen ambas cosas para las bases de datos habituales. Donde dos sistemas deben ir a la par durante más tiempo, pon una cola entre ellos.

Así funcionaba el middleware de los datos sanitarios: funciones serverless en Azure con Azure Queue Storage entre los dos sistemas públicos. Si un lado no estaba disponible, los registros esperaban en la cola en lugar de perderse, y se entregaban cuando volvía. Reintentos, procesamiento idempotente y una cola de mensajes fallidos que alguien vigila de verdad convierten «esperamos que no se haya perdido nada» en «podemos demostrar que no se perdió nada».

Migración por oleadas: un análisis asistido por IA lee la aplicación antigua; usuarios y otros sistemas pasan por una fachada que envía las funciones aún no movidas a la aplicación antigua y las ya movidas a los servicios nuevos; los datos salen de la base de datos antigua mediante copia masiva más captura de cambios, se comprueban con recuentos y checksums por tabla y oleada y llegan a la base de datos nueva solo si son idénticos. — Una oleada de migración: mapear, enrutar por una fachada, mover los datos, comparar y cambiar. Haz clic para verlo a tamaño completo.

6. Ejecución en paralelo, recuentos y checksums

Antes de cambiar una oleada para siempre, ambos sistemas procesan la misma entrada y comparas los resultados: totales, facturas, informes, los números que la gente usa de verdad. Para los datos, compara por tabla y por oleada: el número de filas y un checksum del contenido en un orden fijo. AWS DMS trae una validación que compara origen y destino fila a fila; para lo demás, basta una consulta como la de abajo en ambos lados.

Acuerda la regla antes: si los recuentos o los checksums no coinciden, la oleada no cambia, por cerca que esté la fecha. Cuando en el proyecto FinOps las bases de datos de clientes se movieron a un clúster de Kubernetes con CloudNativePG, recuentos y checksums eran idénticos antes de cambiar un solo cliente.

sql

-- Run on the old and the new database, per table and per wave (PostgreSQL)
SELECT 'invoices'                                            AS table_name,
       count(*)                                              AS row_count,
       md5(string_agg(md5(t::text), '' ORDER BY t.id))       AS checksum
FROM invoices t;
-- Same result on both sides, or the wave does not switch.

7. El cambio, con una vuelta atrás probada

El cambio de una oleada es una rutina corta y ensayada: congelar las escrituras de los datos de la oleada, dejar que lleguen los últimos cambios, comparar recuentos y checksums una última vez, cambiar la fachada y vigilar las métricas de negocio. Deja el lado viejo funcionando en solo lectura un tiempo, para poder consultar y para que la vuelta atrás siga siendo posible.

Un plan de vuelta atrás que nunca se ejecutó no es un plan. Ensáyalo con una copia: devolver la fachada, reaplicar los cambios hechos en el lado nuevo y volver a comprobar los números. Cuando todos lo han visto funcionar una vez, el día del cambio es tranquilo en lugar de heroico.

8. Termina el trabajo: apaga lo viejo y déjalo como código

Una migración termina cuando el sistema viejo ha desaparecido, no cuando el nuevo está en marcha. Archiva lo que debas guardar por motivos legales, apaga el lado viejo, cancela sus licencias y contratos y borra lo que no hace falta. Si no, pagas dos sistemas y el viejo mantiene vivo un riesgo de seguridad.

Y construye el lado nuevo como código desde el primer día, para que el próximo cambio sea un pull request y no otra migración. En el proyecto de automoción todo entró como Terraform, con políticas que se aplican a todos los equipos: la plataforma a la que migras debería ser más fácil de cambiar que la que dejas.

Conclusión
Migra como un contable, no como un héroe: primero el mapa, oleadas detrás de una fachada, ambos lados en paralelo y el cambio solo con recuentos y checksums idénticos.

Proyectos reales relacionados

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos