Del monolito a los microservicios: guía de migración empresarial

YuSMP Group Editorial Team Equipo editorial, YuSMP Group

¿Cómo se migra un monolito empresarial a microservicios?

Migrar un monolito empresarial a microservicios no es, ante todo, un ejercicio de programación. La mayor parte del trabajo es organizativa, y el resto tiene que ver con los datos y las operaciones. Piense en ello como el tipo de programa de ingeniería de software empresarial que dura 18–36 meses en un sistema grande, no como una refactorización que se cierra en un trimestre. Esto es lo que realmente asume:

• Extracción de servicios: identifica los bounded contexts y los extrae uno a uno con el patrón strangler fig
• Descomposición de datos: divide la base de datos monolítica compartida en bases de datos propiedad de cada servicio. Es el problema técnico más difícil de cualquier migración y el que los equipos subestiman con más frecuencia.
• Alineación organizativa: reorganiza los equipos en torno a los servicios (ley de Conway). Si se lo salta, su código vuelve poco a poco a la forma de su organigrama.
• Madurez operativa: trazabilidad distribuida, una service mesh, pipelines de CI/CD independientes y runbooks de guardia. Trátelos como requisitos previos, no como algo para después.
• Coste: normalmente entre el 15 y el 25 % del coste de desarrollo del sistema original por cada año de migración en un gran monolito empresarial

Cuándo migrar (y cuándo no)

La pregunta de arquitectura más importante no es cómo migrar, sino si hay que hacerlo. Muchos monolitos empresariales deberían quedarse como están, al menos por ahora, y a menudo en parte para siempre. No es una preocupación minoritaria: los estudios comparativos del sector de IDC han constatado una y otra vez que la mayoría de las grandes empresas señala la arquitectura monolítica como su principal limitación en los programas de transformación digital — que es exactamente el problema de acoplamiento de despliegues y de escalado que describen las señales siguientes.

Señales claras de que la migración está justificada

• El acoplamiento de despliegues frena la velocidad: los equipos se esperan unos a otros para publicar porque todo se entrega como un único artefacto. Un error de un equipo bloquea las funcionalidades de otros cinco.
• El escalado es de todo o nada: un pico en un subsistema, por ejemplo el procesamiento de pagos o el motor de recomendaciones, obliga a escalar toda la aplicación y consume un presupuesto de infraestructura que no hacía falta gastar.
• Se exige aislamiento normativo: la residencia de datos del RGPD, el aislamiento de los datos de titulares de tarjetas de PCI-DSS o la reducción del alcance de SOC 2 exigen que ciertos flujos de datos estén físicamente separados.
• La dependencia tecnológica bloquea capacidades: una funcionalidad nueva crítica necesita un runtime o un lenguaje que el stack del monolito no puede alojar, y hacer re-platform de toda la aplicación sería completamente desproporcionado.

Señales claras de que la migración debe esperar

• Su equipo tiene menos de 30 ingenieros. Con ese tamaño, los costes de coordinación de los microservicios suelen superar las ventajas en el despliegue.
• Le faltan pipelines de CI/CD maduros, pruebas automatizadas con más del 60 % de cobertura u observabilidad centralizada. Si sigue adelante igualmente, construirá un caos distribuido, no una plataforma de microservicios.
• Nadie es responsable del mapa de bounded contexts. Sin un modelo de dominio claro, trazará mal las fronteras y pasará años volviendo a fusionar lo que separó por error.
• El monolito funciona y el problema para el negocio es moderado. Si el ritmo de entrega actual es aceptable, una modernización de sistemas heredados incremental suele aportar más valor por dólar que una descomposición completa.

La trampa del espagueti distribuido

El fallo más habitual en las migraciones empresariales a microservicios es el monolito distribuido. Divide el sistema en unidades desplegables independientes y, sin embargo, conserva todo el acoplamiento que tenía el monolito original. Además, hereda toda la complejidad operativa de los sistemas distribuidos. Lo peor de ambos mundos.

Entre los síntomas de un monolito distribuido están:

• Los servicios comparten una base de datos o un esquema, de modo que cambiar una sola tabla obliga a coordinar versiones entre cinco equipos
• Las cadenas REST síncronas abarcan 4–8 servicios por petición de usuario, y un timeout en el servicio D se propaga en cascada hasta el servicio A
• Una única biblioteca compartida contiene el modelo de dominio, la lógica de negocio o la configuración, lo que obliga a todos los servicios a publicar a la vez cada vez que cambia
• Los servicios se despliegan juntos con un único calendario de versiones, lo que anula por completo el sentido del despliegue independiente

Otros tres antipatrones hunden migraciones con la misma frecuencia que el monolito distribuido:

• Nanoservicios: dividir tan finamente que una sola capacidad de negocio queda repartida entre una docena de servicios diminutos. Cada petición se ramifica ahora en una cadena de llamadas de red, y los costes operativos de ejecutar y monitorizar tantos desplegables superan cualquier beneficio. Si un servicio no justifica su propia rotación de guardia, probablemente es demasiado pequeño.
• Saltarse la plataforma operativa: extraer el primer servicio antes de que existan la trazabilidad distribuida, el logging centralizado y una plantilla de CI/CD. Los equipos depuran entonces los incidentes de producción a ciegas, y la segunda y la tercera extracción se estancan porque nadie confía en la plataforma.
• Ignorar el diseño organizativo: tratar la migración como un proyecto puramente técnico mientras la estructura de los equipos sigue intacta. Seis meses después, los «nuevos» servicios vuelven a desplegarlos y revisarlos el mismo grupo fuertemente acoplado que era dueño del monolito, y el despliegue independiente nunca llega a producirse.

El patrón strangler fig: extracción incremental

El patrón strangler fig de Martin Fowler toma su nombre de la enredadera tropical que crece alrededor de un árbol huésped y lo va sustituyendo poco a poco. Es el enfoque estándar del sector para migrar sin tiempo de inactividad grandes sistemas en producción. La idea clave es sencilla: nunca se reescribe todo el sistema a la vez. En su lugar, se redirigen rutas de petición concretas a servicios nuevos, una ruta cada vez.

Tres elementos hacen que la mecánica funcione:

1. Fachada: un API gateway, un proxy inverso (Nginx, Envoy) o una capa BFF se sitúa delante tanto del monolito como de los servicios emergentes. Enruta cada petición por ruta, cabeceras o feature flags.
2. Extraer: se traslada un bounded context a un servicio autónomo con su propia base de código, su propio pipeline de despliegue y, con el tiempo, su propia base de datos. El código del monolito para ese contexto sigue en su sitio, pero la fachada redirige el tráfico.
3. Verificar y estrangular: cuando el nuevo servicio gestiona el 100 % del tráfico de ese contexto sin regresiones, se elimina el código correspondiente del monolito. El «estrangulamiento» de ese contexto ha terminado.

Algunas reglas prácticas para el orden de extracción:

• Empiece por servicios con muchas lecturas y pocas escrituras, como los informes, la navegación por el catálogo o las preferencias de notificación. Tienen menos dependencias transaccionales, así que es más seguro extraerlos primero.
• Extraiga primero los contextos hoja — los servicios que no llaman a otros servicios internos. Avanzar hacia el núcleo mantiene reducido el radio de impacto de las primeras extracciones.
• No extraiga primero el contexto de pagos ni el de autenticación. Son dominios muy críticos y muy acoplados. Déjelos para más adelante, cuando su equipo haya ganado confianza con contextos más sencillos.
• Mantenga la fachada ligera. En cuanto la lógica de negocio se cuela en el enrutador, ha construido un nuevo monolito.

Descomponer la base de datos compartida

El patrón strangler fig acapara la atención, pero lo que de verdad hace fracasar a los equipos en la práctica es la descomposición de datos. La mayoría de los monolitos empresariales se apoya en una única base de datos relacional: cientos de tablas, claves foráneas que cruzan las fronteras de dominio y procedimientos almacenados con la lógica de negocio incrustada.

La descomposición avanza por etapas:

1. Identificar la propiedad: asigne un único servicio propietario a cada tabla y columna. Es un ejercicio de modelado de dominio, no técnico. Organice sesiones de event storming con las partes interesadas del negocio para descubrir quién es realmente dueño de qué.
2. Abstraer el acceso: antes de dividir físicamente las bases de datos, encamine lecturas y escrituras a través de la API del nuevo servicio. Los demás servicios dejan de consultar directamente la tabla compartida y llaman al servicio propietario. Solo ese paso ya saca a la luz acoplamientos que no sabía que tenía.
3. Transición con doble escritura: durante la ventana de cutover, escriba a la vez en la tabla compartida del monolito y en el esquema privado del nuevo servicio. Compruebe que ambos se mantienen coherentes antes de considerar canónico el nuevo esquema.
4. Migrar y hacer el cutover: cuando la doble escritura sea estable y las lecturas pasen por el nuevo servicio, convierta el esquema privado en canónico y elimine la doble escritura. La tabla compartida pasa primero a solo lectura y después desaparece.

Estructura organizativa y ley de Conway

La ley de Conway dice que las organizaciones diseñan sistemas que reflejan su propia estructura de comunicación. Esto es lo que significa para una migración: si extrae microservicios sin cambiar la organización de sus equipos, los servicios vuelven poco a poco a la forma de su organigrama. Acaba reconstruyendo el monolito en forma distribuida.

Una migración eficaz necesita la maniobra inversa de Conway: se remodelan deliberadamente los equipos para que coincidan con las fronteras de servicio que se quieren, de modo que la propiedad de los equipos, los patrones de comunicación y la propiedad de los servicios queden alineados.

En la práctica, eso significa:

• Cada servicio tiene un único equipo propietario, no un «equipo de plataforma» dueño de todo
• Los equipos se dimensionan para ser dueños de 1–3 servicios de extremo a extremo, desde el desarrollo hasta el despliegue y la guardia
• La comunicación entre servicios se convierte en un contrato de API formal propiedad del equipo productor, no en un join informal de base de datos
• Los equipos de plataforma son dueños de las primitivas de infraestructura (service mesh, plantillas de CI, observabilidad), pero se mantienen al margen de los servicios de dominio

Aquí es donde la estrategia de integración de sistemas empresariales demuestra su valor: a partir de ahora, la superficie de integración a largo plazo son los contratos entre servicios, no el esquema de la base de datos.

Stack de herramientas para la migración

Ninguno de los patrones anteriores se sostiene sin las herramientas operativas adecuadas por debajo. Son ejemplos de herramientas representativas y de uso habitual por categoría, no recomendaciones ni una lista exhaustiva — elija las que encajen con su proveedor cloud y con las competencias que ya tiene.

Referencias de coste y plazos

Las referencias de coste de las migraciones de monolitos empresariales varían mucho según el tamaño y el acoplamiento del sistema. Aun así, los rangos siguientes coinciden tanto con los datos del sector como con lo que hemos visto en nuestros propios proyectos:

Estas cifras suponen que la migración se dota en parte con su equipo actual, que aporta el conocimiento del dominio, y en parte con un partner especializado externo que aporta los patrones de arquitectura y las herramientas. Y la «descomposición completa» rara vez es el objetivo real. La mayoría de las empresas descompone solo los bounded contexts de alto valor y deja indefinidamente en el monolito los subsistemas estables y con pocos cambios.

Los costes de infraestructura también aumentan notablemente durante la transición. Ejecuta en paralelo el monolito y los nuevos servicios, y paga por nuevas herramientas de service mesh, trazabilidad distribuida y gestión de secretos. En conjunto, eso suele añadir un 30–50 % al gasto en infraestructura operativa hasta que la migración se estabiliza.

Un ejemplo real de extracción

Para concretar las fases abstractas, este es un patrón compuesto extraído de proyectos empresariales con un perfil similar: una plataforma de e-commerce a gran escala en la que todo el monolito — catálogo, checkout, gestión de pedidos y notificaciones — se entregaba como un único artefacto desplegable, una vez cada tres o cuatro semanas, porque los cambios de todos los equipos tenían que pasar por un único conjunto de pruebas de regresión.

El equipo aplicó la hoja de ruta por fases que se describe más abajo, empezando por el servicio de notificaciones:

• Por qué primero las notificaciones: muchas lecturas, pocas escrituras, un contexto hoja sin dependencias de servicios internos — exactamente el perfil «seguro para extraer primero» descrito más arriba.
• Enrutamiento por la fachada: una regla del API gateway enviaba todo el tráfico /notifications/* al nuevo servicio, mientras el monolito seguía sirviendo todo lo demás sin cambios.
• Cutover de datos: las preferencias de notificación y los registros de envío pasaron a un esquema propiedad del servicio mediante una ventana de doble escritura de cuatro semanas, antes de que la tabla compartida pasara a solo lectura.
• Resultado tras la primera extracción: solo el servicio de notificaciones pasó de versiones mensuales a varios despliegues por semana, porque ya no esperaba al conjunto de pruebas de regresión compartido. Sus incidentes de guardia también quedaron aislados en su propio equipo, en lugar de avisar a todo el grupo de plataforma.

Esa primera extracción no resolvió el ritmo de versiones general del monolito — los demás bounded contexts seguían entregándose juntos. Pero demostró de principio a fin el playbook de extracción (fachada, doble escritura, reversión, observabilidad) con un radio de impacto reducido, que es justo el objetivo de la fase 2 de la hoja de ruta que sigue: un ensayo del proceso antes de comprometerse con los contextos de mayor riesgo.

Observabilidad y estrategia de reversión

No se puede operar con seguridad un sistema distribuido en cuyo interior no se ve. Antes de extraer el primer servicio, tenga esto en marcha:

• Trazabilidad distribuida: OpenTelemetry con un backend (Jaeger, Tempo, Datadog APM) para poder seguir una sola petición de usuario a través de las fronteras entre servicios. Esto no es negociable.
• Agregación centralizada de logs: cada servicio envía logs JSON estructurados a un único almacén consultable, ya sea Loki, Elasticsearch o CloudWatch Logs.
• SLI/SLO por servicio: fije objetivos de tasa de errores, latencia p95 y disponibilidad para cada servicio antes de que reciba tráfico de producción. Las alertas se disparan por la tasa de consumo del SLO, no por métricas en bruto.
• Feature flags en la fachada: conserve la capacidad de devolver al instante el tráfico al monolito para cualquier contexto extraído. El patrón strangler fig solo se sostiene si se puede revertir rápido.

Detalle la estrategia de reversión para cada fase de extracción. Para cada servicio que extraiga, deje por escrito:

• La regla exacta de enrutamiento de la fachada que hay que revertir, idealmente un cambio de una línea en la configuración del API gateway
• El estado de la doble escritura: si ha escrito datos en ambos esquemas, cuál es el canónico
• La ventana de desactualización de datos que puede tolerar si la base de datos del nuevo servicio se ha desviado
• El ingeniero de guardia que decide la reversión, además del umbral de tiempo que activa una reversión automática

Hoja de ruta de migración por fases

Una hoja de ruta en cuatro fases mantiene bajo el riesgo y garantiza que cada fase aporte un valor medible antes de empezar la siguiente.

1. Fase 1 — Base (meses 1–3): todavía no se extrae nada. Primero se ponen en marcha los requisitos previos: observabilidad centralizada (trazabilidad, logging, alertas), plantillas de pipelines de CI/CD independientes, una plataforma de contenedores (Kubernetes o ECS), un catálogo de eventos de dominio y talleres de mapeo de fronteras con las partes interesadas de negocio e ingeniería. Entregable: un backlog de extracción priorizado con un mapa de bounded contexts.
2. Fase 2 — Primera extracción (meses 3–6): se extrae un bounded context de bajo riesgo y alto impacto con el patrón strangler fig. Sirve para demostrar de principio a fin el playbook de extracción: enrutamiento por la fachada, doble escritura, migración de datos, monitorización de SLO y reversión. Esta fase es tanto un ensayo del proceso como una entrega técnica. Entregable: un servicio desplegado de forma independiente en producción y un runbook de extracción documentado.
3. Fase 3 — Descomposición sistemática (meses 6–24+): ahora se aplica ese playbook probado al resto de contextos prioritarios, con cada equipo siguiendo el mismo patrón que el anterior. La descomposición de datos se acelera a medida que se aclara la propiedad de la base de datos compartida. La reestructuración organizativa (maniobra inversa de Conway) avanza en paralelo. Entregable: el 60–80 % de la lógica de negocio con muchos cambios funcionando como servicios independientes.
4. Fase 4 — Monolito residual: lo que queda es la parte estable y con pocos cambios que casi nadie toca. Decida, contexto por contexto, si merece la pena el coste de extraerla. Para la mayoría de las empresas, la respuesta sincera es que no: dejar el 20–30 % del sistema original como «monolito residual» es sencillamente lo más rentable. Entregable: una política documentada para el monolito residual y un plan de retirada de las tablas de la base de datos compartida que ya no se usan.

Preguntas frecuentes

¿Deberíamos migrar nuestro monolito a microservicios?

No de forma automática. Migre cuando sienta un problema organizativo concreto: equipos bloqueados por el acoplamiento de despliegues, servicios que necesitan escalar por su cuenta o un aislamiento normativo que está obligado a aplicar. Si su equipo tiene menos de 30 ingenieros, su CI/CD es inmaduro o el monolito funciona bien y el problema es moderado, la migración costará más de lo que ahorra. Empiece con una auditoría sincera de los bounded contexts y una lista clara de los problemas concretos que quiere resolver de verdad.

¿Qué es el patrón strangler fig?

Se coloca una fachada de enrutamiento delante del monolito y se redirigen rutas de petición concretas a nuevos microservicios, unas pocas cada vez, mientras el monolito sigue gestionando todo lo demás. Contexto a contexto, se va estrangulando hasta que el sistema antiguo recibe tan poco tráfico que se puede retirar. Como cada paso es incremental y reversible, es la forma más segura de migrar un sistema en producción.

¿Qué es un monolito distribuido?

Es el peor resultado posible de una migración mal planificada. Tiene varios servicios, pero siguen compartiendo una base de datos, o cadenas de llamadas síncronas que recorren todo el sistema, o una biblioteca compartida que obliga a desplegarlos todos juntos. Así que soporta toda la complejidad operativa de los sistemas distribuidos sin obtener nada de la independencia de despliegue. La causa de fondo es casi siempre una descomposición de datos que se omitió o se aplazó indefinidamente.

¿Cuánto dura una migración?

Con el patrón strangler fig puede entregar valor real, un servicio desplegado y escalable de forma independiente, en 3–6 meses. La descomposición completa de un gran monolito empresarial dura 18–36 meses. Lo que determina ese plazo es el acoplamiento de los datos y el cambio organizativo, mucho más que la programación en sí. Cuente con que el cambio organizativo dure aproximadamente lo mismo que el trabajo técnico.

¿Cómo evitar el tiempo de inactividad durante la migración?

La fachada de enrutamiento es su palanca principal: si un servicio nuevo falla, devuelve el tráfico al monolito en segundos. Refuércela con doble escritura durante las fases de cutover de la base de datos, despliegues blue-green a nivel de servicio, feature flags en la fachada y una trazabilidad distribuida exhaustiva para detectar regresiones antes de que lleguen a todos los usuarios. No haga nunca un cutover de base de datos de golpe en un sistema en producción. Ejecute siempre antes la doble escritura con una ventana de validación.

¿Qué herramientas necesita antes de empezar la migración de un monolito?

Seis categorías, listas antes de la primera extracción: una fachada o un API gateway para enrutar el tráfico; una plataforma de contenedores (Kubernetes, ECS) para que los servicios se desplieguen de forma independiente; una service mesh cuando tenga más de unos pocos servicios; una plantilla de pipeline de CI/CD que cada equipo pueda reutilizar; un stack de observabilidad para la trazabilidad distribuida entre servicios; y un broker de eventos si algún servicio necesita coordinación basada en sagas. Consulte la sección del stack de herramientas más arriba para ver productos representativos de cada categoría.

¿Qué es la maniobra inversa de Conway?

Es remodelar deliberadamente la estructura de los equipos para que coincida con la arquitectura de servicios que se quiere, en lugar de dejar que los servicios vuelvan a la forma del organigrama existente. Cada servicio tiene un único equipo propietario dimensionado para operar 1–3 servicios de extremo a extremo — del desarrollo a la guardia —, y esa reestructuración se hace a la vez que la extracción técnica, no después.

Última actualización: 3 de julio de 2026. Las referencias de coste reflejan datos de proyectos de YuSMP Group e informes del sector disponibles públicamente (Gartner, CNCF, ThoughtWorks Technology Radar). El coste de cada migración varía según el tamaño del monolito, el acoplamiento, la estructura de los equipos y la madurez de la observabilidad.