Sin cambio de CMS, sin reescritura del storefront: en qué se diferencia una FMP de una migración de CMS

Si tu competidor te está lanzando una guía de migración justo ahora, no respondas con una contra-guía de migración. Responde con un enfoque de arquitectura.

Esto no es retórica. La diferencia entre una Frontend Management Platform y un cambio de CMS es arquitectónica, no una distinción de marketing. Un cambio de CMS sustituye un componente de infraestructura por otro. Una FMP cambia cómo la capa de frontend accede a los componentes de infraestructura. Suena sutil, pero tiene consecuencias fundamentalmente distintas: en esfuerzo de implementación, riesgo y opcionalidad.

Este artículo es para solution architects y CTOs que tienen una decisión concreta que tomar en los próximos 90 días: ¿respondemos a la adquisición de Contentful por Salesforce con un cambio de CMS o con una decisión de arquitectura?

Lo que realmente cuesta un cambio de CMS

El discurso del competidor promete una "migración sencilla". Y para la migración de datos, eso suele ser cierto: Contentful tiene APIs de exportación abiertas, y herramientas como `contentful-export` generan JSON válido que se puede importar a un CMS de destino con la lógica de conversión adecuada.

El problema de coste real no es la transferencia de datos. Son otras tres capas:

Capa 1: cambios en el código de frontend

Cada cambio de CMS implica que las llamadas al SDK en el código de frontend deben cambiar. Suena como una operación trivial de buscar y reemplazar. En la práctica significa:

// Antes: SDK de Contentful directamente
import { createClient } from 'contentful'

const client = createClient({ space: '...', accessToken: '...' })
const entries = await client.getEntries({ content_type: 'blogPost', 'fields.slug': slug })

// Después: cliente de Hygraph
import { GraphQLClient } from 'graphql-request'

const hygraph = new GraphQLClient('https://eu-west-2.cdn.hygraph.com/content/...', {
  headers: { authorization: `Bearer ${token}` }
})
const { blogPost } = await hygraph.request(`query { blogPost(where: { slug: "${slug}" }) { ... } }`)

Eso no es un solo cambio. Es un cambio por cada tipo de contenido y por cada página del storefront. Un frontend de mercado medio con de 15 a 30 tipos de contenido distintos y de 50 a 80 páginas supone varias semanas de esfuerzo de ingeniería.

Capa 2: mapeo del modelo de contenido

Los modelos de contenido nunca son compatibles uno a uno. Contentful tiene rich text como JSON embebido; Hygraph entrega un AST de Slate; Storyblok trabaja con componentes anidados en bloques; Sanity tiene GROQ. Cada CMS de destino tiene un modelo distinto para contenido anidado, referencias entre entradas, entrega de assets y localización.

Mapear estas diferencias es el esfuerzo invisible de toda migración. Rara vez se cuantifica en las guías de migración.

Capa 3: disrupción del flujo de trabajo del editor

Los equipos de marketing han construido flujos de trabajo de edición en Contentful: procesos de aprobación, reglas de publicación programada, convenciones de modelado de contenido, URLs de previsualización. Cada CMS nuevo tiene su propia UX de edición, su propia estructura de permisos, su propia lógica de previsualización. El tiempo de formación de los equipos de marketing no aparece como coste de migración en ninguna guía de migración.

El esfuerzo combinado (cambios de frontend, mapeo del modelo de contenido y disrupción del flujo de edición) en proyectos enterprise de la región DACH suele ser de 3 a 6 meses. Ese es el precio real de un cambio de CMS.

Qué hace una FMP en su lugar

Una Frontend Management Platform opera en otra capa. No sustituye la infraestructura del CMS. Abstrae el acceso a esa infraestructura, de forma que la capa de frontend se vuelve agnóstica respecto al CMS.

La diferencia crítica es el render boundary (el límite de renderizado). Con un CMS integrado directamente, cada página, cada componente, cada plantilla de página tiene conocimiento explícito de qué CMS es el origen del contenido. El render boundary se sitúa dentro del propio código del componente.

Con una FMP, el render boundary se sitúa en la capa de la plataforma. El componente no conoce ningún CMS: conoce una interfaz de contenido. El CMS es una implementación detrás de esa interfaz.

// Enfoque FMP: el componente no conoce ningún CMS
interface ContentEntry {
  id: string
  type: string
  fields: Record<string, unknown>
  assets: Asset[]
  locale: string
}

// Componente Hero: agnóstico respecto al CMS
const HeroComponent: React.FC<{ entry: ContentEntry }> = ({ entry }) => {
  const { headline, subtext, ctaUrl, ctaLabel, image } = entry.fields

  return (
    <section className="hero">
      <h1>{String(headline)}</h1>
      <p>{String(subtext)}</p>
      <a href={String(ctaUrl)}>{String(ctaLabel)}</a>
      {image && <Image asset={image as Asset} priority />}
    </section>
  )
}

// Capa de la plataforma: abstracción del handler
type CMSHandler = {
  fetchEntry(slug: string, type: string, locale: string): Promise<ContentEntry>
  fetchCollection(type: string, locale: string, filter?: Filter): Promise<ContentEntry[]>
}

// Implementación de Contentful
const contentfulHandler: CMSHandler = {
  async fetchEntry(slug, type, locale) {
    const response = await contentfulClient.getEntries({
      content_type: type, 'fields.slug': slug, locale
    })
    return mapContentfulEntry(response.items[0])
  },
  // ...
}

// Implementación de Hygraph, misma interfaz
const hygraphHandler: CMSHandler = {
  async fetchEntry(slug, type, locale) {
    const data = await hygraphClient.request(FETCH_ENTRY_QUERY, { slug, type, locale })
    return mapHygraphEntry(data.entry)
  },
  // ...
}

Cambiar de Contentful a Hygraph en esta arquitectura consiste en: `setCMSHandler(hygraphHandler)`. Sin cambios en componentes. Sin actualizaciones de plantillas. Sin disrupción del flujo de edición cuando el editor vive en la capa de frontend (no en el CMS).

Semántica del render boundary: por qué esa línea es decisiva

El render boundary es la línea en la que el código de frontend deja de tener conocimiento del CMS. Cuanto más profundo se sitúa este límite en el árbol de componentes, más caro resulta un cambio de CMS.

Tres posiciones posibles del render boundary, de la más cara a la más barata:

Posición 1, en el componente (la más cara): Cada componente contiene llamadas al SDK. Los IDs de tipo de contenido están hardcodeados. Un cambio de CMS exige modificaciones en cientos de archivos.

Posición 2, en la plantilla de página: Las llamadas al SDK se agrupan en las plantillas de página, no en componentes individuales. Un cambio de CMS exige modificaciones en de 20 a 40 archivos de plantilla. Mejor, pero sigue siendo un esfuerzo considerable.

Posición 3, en el handler de la plataforma (la más barata): Un único handler encapsula todas las interacciones con el CMS. Los componentes y las plantillas solo conocen `ContentEntry`. Un cambio de CMS es un cambio de implementación en un único módulo. La Agentic Frontend Management Platform sitúa el render boundary de forma sistemática en la Posición 3.

Esto no es solo un objetivo de refactorización. Es una decisión de arquitectura estratégica que determina lo altos que son tus costes de cambio: para el CMS, pero también para los backends de búsqueda, los motores de personalización y las APIs de comercio. El Composable Headless Frontend es la capa sobre la que se sostiene esta abstracción.

El árbol de decisión concreto para solution architects

Si eres un solution architect que necesita hacer una recomendación para los próximos 90 días:

Si el frontend está hoy directamente acoplado a Contentful (Posición 1 o 2):

• Recomendación a corto plazo: refactoriza hacia una abstracción por handler antes de plantear ningún cambio de CMS. Un cambio de CMS en el estado actual es un proyecto de 3 a 6 meses. Refactorizar hacia la abstracción por handler son de 4 a 8 semanas.
• A medio plazo: tras la refactorización, un cambio de CMS es un proyecto de 2 a 4 semanas si llega a ser necesario.

Si el frontend ya tiene una capa de contenido abstracta (Posición 3 o similar):

• A corto plazo: la decisión sobre el CMS es estratégica (precio, roadmap, soberanía de los datos), no está impulsada por lo técnico. Tienes tiempo para una evaluación bien fundamentada, sin presión de tiempo.
• A medio plazo: comparación de proveedores con condiciones reales (precio de renovación, compromisos de roadmap, residencia de los datos), sin que los costes de implementación sean el factor dominante.

Si el frontend está construido sobre una FMP:

• La pregunta no es "a qué CMS cambio", sino "qué CMS ofrece la mejor combinación de precio, roadmap y cumplimiento a corto y medio plazo", porque el cambio es viable en cualquier momento sin reescribir el storefront.

Lo que una FMP no es

Para que quede claro, porque el término hoy carga con muchos significados:

Una FMP no es un CMS headless. No almacena contenido. No tiene un sistema de modelado de contenido propio. No es un DAM. No es un PIM.

Una FMP es la capa entre el código de frontend y los backends de contenido, comercio y datos. Es la capa de renderizado, la capa de handlers, la capa del editor visual, la capa de la librería de componentes. Hace que los backends sean intercambiables: CMS, comercio, búsqueda, personalización.

La diferencia es conceptual, pero tiene consecuencias concretas: quien compra una FMP no compra una alternativa de CMS. Compra la capacidad de tener alternativas de CMS sin pagar por ello.

Conclusión

Si la respuesta a una adquisición de CMS es un cambio de CMS, estás resolviendo un síntoma, no el problema. El problema es la dependencia arquitectónica. La solución es un render boundary que elimina esa dependencia.

Una Frontend Management Platform es la herramienta que establece ese límite de forma sistemática, y convierte un cambio de CMS en un paso de configuración en lugar de un proyecto.

Más sobre esta capacidad: Content Management

Relacionado: Cuando tu capa de CMS cambia de manos · Salesforce compra Contentful: la brecha en la capa de frontend · CMS headless para eCommerce con Next.js 2026