Una migración gradual separa dominios de negocio mientras mantiene un recorrido operativo reconocible para el equipo. El sistema existente y los servicios nuevos conviven durante una transición controlada. El éxito se demuestra cuando los consumidores utilizan el dominio nuevo, los datos conservan su significado y la dependencia anterior se retira con evidencia.
Dominios antes que servicios
El primer error común es dividir por tecnología o por conveniencia de equipo, en vez de dividir por dominio de negocio real: facturación, agenda, mensajería, catálogo. Cada dominio bien delimitado tiene sus propios datos, sus propias reglas y su propio ciclo de cambio, y esa delimitación -no la cantidad de servicios- es lo que determina si la migración reduce complejidad o solo la reparte en más piezas.
Un contrato antes que una implementación
Antes de escribir el primer servicio nuevo, define el contrato -qué datos entran, qué datos salen, qué garantías ofrece- entre ese servicio y todo lo que hoy depende del sistema anterior. Ese contrato es lo que permite construir el servicio nuevo sin coordinar cada cambio con el anterior en tiempo real.
Un puente anterior, no un big bang
Mientras el dominio nuevo se construye y se valida, una capa de compatibilidad hacia el sistema anterior permite que los consumidores actuales sigan funcionando exactamente igual. Esa capa no es elegante ni definitiva, pero es lo que hace posible migrar sin parar la operación mientras se prueba el sistema nuevo con tráfico real.
Corte por consumidor y criterio de riesgo
En vez de fijar una fecha de corte total, define criterios de corte por consumidor: qué proceso puede migrar primero porque su impacto de error es bajo, y cuál debe migrar al final porque un fallo ahí sí sería costoso. Migrar por criterio de riesgo, no por orden de facilidad técnica, reduce la exposición durante toda la transición.
Una capa que absorbe el cambio, no que lo esconde
Una capa intermedia orientada al consumidor -que traduce entre lo que el interfaz o el sistema externo espera y lo que cada servicio de dominio realmente ofrece- permite que los cambios internos de arquitectura no rompan a quien consume el sistema desde afuera. Sin esa capa, cada migración interna se convierte también en un cambio visible para todos los consumidores externos, lo que multiplica el riesgo sin necesidad.
Cuándo declarar terminada la migración
Una migración a microservicios no termina cuando el último servicio se despliega. Termina cuando el sistema anterior ya no tiene ningún consumidor activo y se puede apagar sin que nadie lo note. Ese criterio de cierre -no la fecha de lanzamiento del último microservicio- es el que define si la migración realmente redujo riesgo operativo o solo agregó una arquitectura nueva sobre la vieja.
Correr los dos mundos en paralelo exige observabilidad doble
Mientras dura la transición, hay que poder observar tanto el sistema anterior como los servicios nuevos con el mismo nivel de detalle, incluyendo qué consumidores todavía dependen de cada lado. Sin esa observabilidad doble, es fácil perder de vista un consumidor olvidado que sigue apuntando al sistema viejo mucho después de que el equipo asumió que ya nadie lo usaba.
Asigna autoridad sobre cada dato durante la transición
El dominio nuevo necesita un límite de escritura. Define qué sistema acepta cambios en cada etapa y cómo se propagan hacia los consumidores que siguen en el sistema anterior. Dos lugares que corrigen el mismo dato sin una regla de autoridad generan versiones competidoras. Un registro de correspondencias conserva la identidad anterior y la nueva para explicar qué entidad representa cada movimiento durante la coexistencia.
La carga inicial incluye registros y relaciones. Compara el conjunto migrado con la fuente y conserva las diferencias como pendientes concretos: referencias ausentes, estados incompatibles o valores que requieren decisión. Después incorpora los cambios que ocurren mientras se valida la carga. El momento del corte necesita una frontera verificable entre lo ya incorporado y lo pendiente; una comparación de totales por sí sola no demuestra equivalencia operativa.
Comprueba contratos desde el consumidor
Un contrato incluye significado, formato y comportamiento ante respuestas pendientes. Si un consumidor solicita disponibilidad, necesita saber cuándo el resultado está vigente y qué identifica una reserva aceptada. La implementación nueva conserva esas expectativas o introduce una transición explícita. Documenta los campos que cambian y ofrece una prueba reproducible para que cada consumidor confirme su recorrido sin coordinar cada despliegue con el equipo del dominio.
Las lecturas comparadas permiten revisar diferencias entre ambos sistemas sobre el mismo conjunto de datos. Las escrituras requieren otro tratamiento: una prueba no debe producir dos reservas reales ni dos comunicaciones al cliente. Usa un entorno de ensayo o una ejecución sin efectos externos para comprobar las decisiones. Identifica después un alcance controlado de operaciones reales cuyo resultado acepta el responsable del proceso antes de ampliar el tráfico.
Prepara una reversión que incluya los datos
Volver al punto de entrada anterior solo recupera el servicio si ese sistema reconoce los movimientos aceptados por el nuevo dominio. Define cómo se trasladan esos cambios o qué condiciones obligan a pausar escrituras mientras se concilian. La reversión registra quién decide, qué evidencia necesita y cuál es el estado de cada operación en curso. Una instrucción de cambiar la conexión resulta insuficiente cuando ya existen datos nuevos.
Acepta cada etapa mediante criterios observables: contratos compatibles, registros conciliados, permisos revisados y pendientes identificados. Incluye la experiencia de quienes trabajan con el proceso; una respuesta técnica válida no demuestra que la información alcance para cerrar una tarea. La lista de consumidores migrados conserva fecha, versión del contrato y responsable que validó el recorrido. Así el avance se mide por dependencias resueltas, no por servicios creados.
Retira la convivencia con un criterio de cierre
La capa temporal necesita dueño y condiciones de eliminación. Revisa consumidores de baja frecuencia, reportes administrativos y tareas de cierre antes de declarar vacío el sistema anterior. Conserva la información histórica que la operación necesita consultar y define su acceso posterior. Solo entonces se revocan permisos y se retiran conexiones. La migración termina cuando la arquitectura nueva sostiene el proceso sin utilizar recursos cuya sustitución se declaró completa.
La modernización de operaciones organiza este trabajo por dominios y riesgo. La estructuración de datos y contexto mantiene identidades y reglas durante el cambio. Un diagnóstico del recorrido crítico convierte la migración en etapas aceptables por el negocio, con una salida documentada de la coexistencia y un responsable por cada decisión de corte.
