Si has pasado una cantidad significativa de tiempo trabajando con TYPO3, sabes que es una bestia. No en mal sentido -- es increíblemente poderoso, especialmente para grandes sitios de empresas europeas con estructuras de contenido complejas, configuraciones multiidioma y permisos granulares. Pero existe una creciente conciencia entre los equipos que ejecutan instalaciones de TYPO3: la arquitectura monolítica los está frenando. Los desarrolladores frontend quieren usar React o Vue. Los equipos de marketing quieren entrega de contenido omnicanal. DevOps quiere implementaciones más simples. Y todos quieren mejor rendimiento.

Ahí es donde entra la migración a CMS headless. He pasado por este proceso varias veces -- llevando organizaciones de TYPO3 a arquitecturas headless -- y seré honesto: nunca es tan simple como sugieren las páginas de marketing de los proveedores. Pero vale absolutamente la pena hacerlo cuando las condiciones son las correctas. Esta guía cubre las decisiones reales, trampas y estrategias involucradas en la migración de TYPO3 a un CMS headless.

Tabla de Contenidos

TYPO3 to Headless CMS Migration: A Practical Developer Guide

Por qué los equipos dejan TYPO3

Déjame ser claro: TYPO3 no es software malo. Es maduro, bien mantenido y tiene una comunidad dedicada, particularmente en Alemania, Austria y Suiza. Pero lleva ciertas limitaciones arquitectónicas que se vuelven dolorosas a escala.

Fricción en la experiencia del desarrollador

El sistema de plantillas de TYPO3 (Fluid) es poderoso pero nicho. Encontrar desarrolladores que conozcan Fluid, TypoScript y el marco de extensiones Extbase/TYPO3 es cada vez más difícil. La curva de aprendizaje es pronunciada y los desarrolladores más jóvenes abrumadoramente prefieren trabajar con marcos JavaScript. He visto que los plazos de contratación se duplicaron porque los equipos no podían encontrar desarrolladores competentes en TYPO3.

Limitaciones de rendimiento

TYPO3 renderiza páginas del lado del servidor a través de PHP. Aunque el almacenamiento en caché ayuda, estás fundamentalmente limitado por el ciclo de solicitud monolítico. La generación de sitios estáticos y el renderizado en el borde -- las cosas que los marcos modernos hacen bien -- no son nativos de la arquitectura de TYPO3. La extensión TYPO3 Headless (EXT:headless) existe y convierte TYPO3 en una API, pero en ese punto estás manteniendo un backend PHP que está haciendo menos y menos del trabajo real.

Desafíos en la reutilización de contenido

El modelo de contenido de TYPO3 está centrado en la página. Los elementos de contenido viven en páginas. Si necesitas entregar contenido a una aplicación móvil, un quiosco digital, un sistema de correo electrónico y un sitio web simultáneamente, el modelo de TYPO3 se resiste en cada paso. Las plataformas CMS headless tratan el contenido como datos estructurados desde el inicio, haciendo que la entrega multicanal sea natural en lugar de agregada.

Costo total de propiedad

Ejecutar TYPO3 significa mantener servidores PHP, gestionar actualizaciones del núcleo de TYPO3 (que pueden ser no triviales entre versiones principales) y mantener la compatibilidad de extensiones. Un CMS SaaS headless elimina la mayoría de la sobrecarga de infraestructura. Incluso opciones headless auto-hospedadas como Strapi o Directus típicamente requieren menos esfuerzo operativo.

Cuándo la migración realmente tiene sentido

No todos los sitios TYPO3 necesitan migrar a headless. Aquí está mi evaluación honesta:

Escenario ¿Migrar? Por qué
Sitio de folleto simple, 50 páginas, un idioma Probablemente no Es excesivo. TYPO3 funciona bien aquí.
Sitio empresarial multiidioma con aplicaciones móviles Sí Headless brilla para entrega omnicanal
E-commerce con datos de productos complejos Sí Mejor flexibilidad frontend, integraciones API-first
Sitio con muchas extensiones de TYPO3 (noticias, eventos, formularios) Tal vez Audita las dependencias de extensión primero
Portal interno con flujos de trabajo backend de TYPO3 Cuidado Puedes perder características de flujo de trabajo que son difíciles de reemplazar
El equipo no puede contratar desarrolladores de TYPO3 Sí La sostenibilidad importa más que las características

La migración tiene más sentido cuando ya estás planeando un rediseño o actualización de plataforma. Migrar únicamente por razones técnicas -- sin un disparador comercial -- a menudo lucha por obtener aprobación presupuestaria.

Elegir tu CMS headless

Aquí es donde los equipos se atascan. Hay docenas de opciones de CMS headless y la opción correcta depende en gran medida de tu situación específica.

Opciones de grado empresarial

Contentful sigue siendo el líder del mercado para CMS headless empresarial. El precio comienza alrededor de $300/mes para el plan Team y escala a precios empresariales personalizados (típicamente $2,000-$10,000+/mes dependiendo del uso). Es maduro, bien documentado y tiene excelentes SDKs. El modelado de contenido es flexible y la característica Compose maneja casos de uso de construcción de páginas a los que los editores de TYPO3 están acostumbrados.

Sanity es mi favorita personal para la experiencia del desarrollador. El modelo de precios es generoso -- el nivel gratuito maneja muchos proyectos pequeños y el plan Team a $15/usuario/mes es razonable. Sanity Studio es completamente personalizable con React, por lo que puedes construir experiencias editoriales que coincidan o superen lo que ofrece el backend de TYPO3. El lenguaje de consulta GROQ requiere algo de acostumbramiento, pero es increíblemente poderoso una vez que lo dominas.

Storyblok merece atención especial para migraciones de TYPO3 porque ofrece un editor visual que se siente familiar para los usuarios del backend de TYPO3. El precio comienza en €99/mes para el plan Entry. Es particularmente popular en la región DACH, que se superpone mucho con la base de usuarios de TYPO3.

Alternativas de código abierto

Strapi (v5 lanzada en 2024) es la opción de código abierto líder. Puedes auto-hospedarlo o usar Strapi Cloud (comenzando a $29/mes por asiento). Está basado en Node.js, usa una base de datos PostgreSQL o MySQL y ofrece un ecosistema de complementos que está creciendo rápidamente.

Directus envuelve cualquier base de datos SQL con una API y panel de administración. Es una gran opción si quieres mantener tu estructura de base de datos existente e migrar gradualmente. La versión de código abierto está completamente equipada; la versión en la nube comienza a $99/mes.

Tabla de comparación: Opciones de CMS headless para migración de TYPO3

Característica Contentful Sanity Storyblok Strapi Directus
Modelo de hospedaje SaaS SaaS + Auto-hospedado SaaS Auto-hospedado + Nube Auto-hospedado + Nube
Editor visual Compose (complemento) Personalizable Integrado Complemento Limitado
Multiidioma Excelente Bueno Excelente Bueno Bueno
Precio inicial $300/mes Nivel gratuito €99/mes Gratuito (OSS) Gratuito (OSS)
Familiaridad con editor de TYPO3 Medio Bajo Alto Medio Medio
Modelado de contenido Flexible Muy flexible Basado en componentes Flexible Basado en base de datos
Webhooks/Flujos de trabajo Sí Sí Sí Sí Sí

Trabajamos con la mayoría de estas plataformas a través de nuestros servicios de desarrollo de CMS headless. La opción a menudo se reduce a si tus editores necesitan una experiencia de edición visual (Storyblok, Contentful Compose) u si la flexibilidad del desarrollador es la prioridad (Sanity, Strapi).

TYPO3 to Headless CMS Migration: A Practical Developer Guide - architecture

Modelado de contenido: la parte difícil

Aquí es donde la mayoría de las migraciones salen mal. El modelo de contenido de TYPO3 es fundamentalmente diferente del modelo de contenido del CMS headless y no puedes simplemente mapear uno al otro.

Entender la estructura de contenido de TYPO3

En TYPO3, el contenido se organiza como:

  • Páginas (el árbol de páginas) con propiedades y metadatos
  • Elementos de contenido (tt_content) posicionados en columnas en páginas
  • Extensiones que agregan tipos de registro personalizados (noticias, eventos, etc.)
  • Categorías y referencias de archivos vinculadas a través de la tabla sys_file_reference
  • Configuración de TypoScript que afecta el renderizado y el flujo de datos

Este es un modelo centrado en la página. El contenido existe en el contexto de una página.

Modelado de contenido headless

Las plataformas CMS headless utilizan un modelo centrado en contenido. Defines tipos de contenido (como Article, Author, Product) con campos y luego compones páginas a partir de referencias a esos elementos de contenido. La página misma a menudo es solo otro tipo de contenido.

El trabajo de traducción se ve algo así:

Árbol de páginas de TYPO3   →  Tipo de contenido de página con campos de slug/jerarquía
tt_content (texto)          →  Componente/bloque de texto enriquecido
tt_content (imagen)         →  Componente de medios con referencias de activos
tx_news_domain_model_news   →  Tipo de contenido Article/News
Categorías (sys_category)   →  Tipo de contenido de etiquetas/categorías
Referencias de archivos     →  Gestión de activos (DAM)

Consejo práctico

No intentes replicar el modelo de contenido de TYPO3 en tu CMS headless. Esta es una oportunidad para repensar y mejorar tu arquitectura de contenido. Comienza auditando:

  1. ¿Qué tipos de contenido existen? Exporta tus CTypes de tt_content y enumera todos los tipos de registro de extensión.
  2. ¿Qué campos se usan realmente? Las tablas de TYPO3 tienen docenas de campos. La mayoría del contenido solo usa un puñado.
  3. ¿Cuáles son las relaciones? Mapea cómo el contenido referencia otro contenido.
  4. ¿Cuál es la configuración de traducción? TYPO3 soporta modos de traducción conectados y libres -- tu CMS headless necesita manejar el que uses.
-- Consultas útiles de auditoría de TYPO3
-- Contar elementos de contenido por tipo
SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

-- Contar páginas por doktype
SELECT doktype, COUNT(*) as count 
FROM pages 
WHERE deleted = 0 AND hidden = 0 
GROUP BY doktype 
ORDER BY count DESC;

-- Encontrar todos los idiomas en uso
SELECT sys_language_uid, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 
GROUP BY sys_language_uid;

Estrategias de migración de datos

Una vez que tu modelo de contenido está definido en el CMS de destino, necesitas mover los datos. Hay tres enfoques principales.

Enfoque 1: Exportación/importación basada en scripts

Escribe scripts que consulten directamente la base de datos de TYPO3, transformen los datos e impúlsalos al CMS headless a través de su API de gestión. Este es el enfoque más común y te da el mayor control.

// Ejemplo: Migración de registros de noticias de TYPO3 a Contentful
const contentful = require('contentful-management');
const mysql = require('mysql2/promise');

async function migrateNews() {
  const db = await mysql.createConnection({
    host: 'localhost',
    database: 'typo3_db',
    user: 'root',
    password: 'password'
  });

  const client = contentful.createClient({
    accessToken: 'your-management-token'
  });

  const space = await client.getSpace('your-space-id');
  const env = await space.getEnvironment('master');

  const [rows] = await db.execute(`
    SELECT n.uid, n.title, n.teaser, n.bodytext, n.datetime,
           n.path_segment, p.slug as category_slug
    FROM tx_news_domain_model_news n
    LEFT JOIN sys_category_record_mm mm ON mm.uid_foreign = n.uid
    LEFT JOIN sys_category c ON c.uid = mm.uid_local
    WHERE n.deleted = 0 AND n.hidden = 0
  `);

  for (const row of rows) {
    const entry = await env.createEntry('article', {
      fields: {
        title: { 'en-US': row.title },
        teaser: { 'en-US': row.teaser },
        body: { 'en-US': convertRteToRichText(row.bodytext) },
        publishDate: { 'en-US': new Date(row.datetime * 1000).toISOString() },
        slug: { 'en-US': row.path_segment }
      }
    });
    await entry.publish();
    console.log(`Migrated: ${row.title}`);
  }
}

La función convertRteToRichText es donde las cosas se ponen confusas. La salida RTE de TYPO3 es HTML (a menudo con etiquetas personalizadas como <link> para enlaces internos). Convertir esto a formatos de texto enriquecido estructurados varía según el CMS -- Contentful usa su propio JSON de texto enriquecido, Sanity usa Portable Text, etc.

Enfoque 2: Extensión TYPO3 Headless como puente

Instala la extensión EXT:headless en tu instancia TYPO3 existente. Esto convierte TYPO3 en una API JSON, que puedes consumir desde scripts de migración o incluso usar temporalmente como tu backend headless mientras construyes el nuevo frontend.

Este enfoque tiene una ventaja agradable: puedes ejecutar el nuevo frontend contra la API headless de TYPO3 primero, luego cambiar el backend a un CMS headless apropiado más tarde. Divide la migración en dos fases.

Enfoque 3: Recreación manual

Para sitios más pequeños (menos de 100 páginas), a veces es más rápido simplemente recrear el contenido manualmente en el nuevo CMS. Especialmente si también estás reestructurando y reescribiendo contenido -- que probablemente deberías estar haciendo.

Decisiones de arquitectura frontend

Con un CMS headless, necesitas un frontend separado. Aquí es donde ocurren las ganancias reales de rendimiento.

Next.js

La opción más popular. Renderizado del lado del servidor, generación estática, regeneración estática incremental -- Next.js maneja todas las estrategias de renderizado que podrías necesitar. El App Router (estable desde Next.js 13.4) con React Server Components es particularmente adecuado para sitios con mucho contenido. Realizamos mucho de este trabajo a través de nuestro sitio de práctica de desarrollo de Next.js.

Astro

Para sitios con mucho contenido que no necesitan mucha interactividad, Astro es fenomenal. No envía JavaScript por defecto y soporta hidratación parcial a través de su Arquitectura de Islas. Hemos visto puntuaciones de Lighthouse consistentemente alcanzar 95+ con compilaciones de Astro, que es una mejora dramática sobre el rendimiento típico del frontend de TYPO3. Consulta nuestros servicios de desarrollo de Astro si esto te interesa.

Nuxt

Si tu equipo prefiere Vue sobre React, Nuxt 3 es el equivalente a Next.js. Buena opción, excelente DX, buen ecosistema.

Framework Mejor para JS enviado Curva de aprendizaje Integraciones CMS
Next.js Aplicaciones dinámicas, e-commerce, dashboards Medio-Alto Medio Excelente
Astro Sitios de contenido, blogs, marketing Mínimo Bajo Excelente
Nuxt 3 Equipos de Vue, contenido + aplicaciones Medio Medio Bueno
SvelteKit Equipos pequeños queriendo simplicidad Bajo Bajo-Medio En crecimiento

Manejo de características específicas de TYPO3

Algunas características de TYPO3 no tienen equivalentes directos en el mundo headless. Aquí está cómo manejar las comunes.

Espacios de trabajo y control de versiones

El sistema de espacios de trabajo de TYPO3 permite a los editores realizar cambios en etapas en varias páginas antes de publicar. La mayoría de las plataformas CMS headless ofrecen ambientes o publicación programada que parcialmente replican esto. Contentful tiene Environments y Scheduled Publishing. Sanity tiene Releases (lanzado recientemente). Ninguno es tan sofisticado como TYPO3 Workspaces de serie, así que si tus editores dependen mucho de espacios de trabajo, planifica ajustes de flujo de trabajo.

Permisos de usuario del backend

El sistema de permisos de TYPO3 es extremadamente granular -- controles de acceso a nivel de página, a nivel de elemento de contenido, a nivel de campo. Las plataformas CMS headless varían ampliamente aquí. El sistema de roles de Contentful es decente pero menos granular. El de Sanity es más flexible pero requiere configuración personalizada. El acceso basado en roles de Strapi es bueno. Audita tu matriz de permisos actual y valida que el CMS de destino pueda manejarlo antes de comprometerse.

Manejo de formularios

El marco de formularios de TYPO3 (EXT:form) genera formularios a partir de configuración YAML. En una configuración headless, necesitarás un servicio de formularios. Las opciones incluyen Formspree, Basin o construir tu propia con funciones serverless. Si usas Next.js, Server Actions hace que el manejo de formularios sea sencillo.

Multiidioma y localización

Esto es crítico y a menudo se subestima. El manejo de traducción de TYPO3 -- con su concepto de superposiciones de idioma, modo conectado/libre y cadenas de respaldo -- es sofisticado. Mapea tus requisitos exactos de traducción antes de elegir un CMS. Storyblok y Contentful manejan bien la gestión de locale. Sanity requiere más configuración personalizada para escenarios multiidioma complejos.

Preservación de SEO durante la migración

Esta sección podría ser la más importante. Una migración fallida puede hundir tu tráfico orgánico.

Mapeo de URL

Exporta cada URL de tu sitio TYPO3. Cada. Una. Sola. Usa un rastreador como Screaming Frog o wget --spider para construir una lista de URL completa. Luego crea un mapa de redirección:

/old-typo3-path/page.html → /new-clean-path
/index.php?id=42 → /about-us
/fileadmin/documents/report.pdf → /assets/report.pdf

Implementa redirecciones 301 para cada URL que cambie. En Next.js, esto va en next.config.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-path/:slug*',
        destination: '/new-path/:slug*',
        permanent: true,
      },
      // ... cientos más, cargados desde un archivo JSON idealmente
    ];
  },
};

Para listas de redirección grandes (500+), considera manejar redirecciones en el borde (Vercel Edge Middleware, Cloudflare Workers, o nginx) en lugar de en tu configuración de aplicación.

Migración de metadatos

TYPO3 almacena metadatos de SEO en la tabla de páginas (seo_title, description, og_image, etc.) y potencialmente en extensiones como EXT:cs_seo o EXT:seo_basics. Extrae todo esto y migra a tu modelo de contenido de CMS headless. No olvides:

  • Títulos de página y meta descripciones
  • Datos de Open Graph y Twitter Card
  • URLs canónicas
  • Etiquetas hreflang para sitios multilingües
  • Datos estructurados / esquemas JSON-LD
  • Generación de mapa de sitio XML

Monitoreo

Configura Google Search Console para el nuevo dominio/subdominio antes de la migración. Después del lanzamiento, monitorea el informe de Cobertura diariamente durante las primeras dos semanas. Vigila los errores de rastreo, páginas eliminadas y problemas de indexación. Ten un plan de reversión.

Estrategia de pruebas y lanzamiento

Recomiendo un enfoque por fases en lugar de un cambio integral.

Fase 1: Ejecución paralela (2-4 semanas)

Ejecuta el nuevo sitio headless en un dominio de ensayo. Compara la paridad de contenido con el sitio TYPO3. Haz que los editores prueben flujos de trabajo de contenido. Ejecuta pruebas automáticas de regresión visual con herramientas como Percy o Playwright.

Fase 2: Lanzamiento suave

Enruta un pequeño porcentaje de tráfico al nuevo sitio usando banderas de características o pruebas A/B a nivel de CDN. Monitorea Core Web Vitals, tasas de error y comportamiento del usuario.

Fase 3: Cambio completo

Cambia la configuración de DNS o proxy inverso. Activa todas las redirecciones. Monitorea agresivamente durante 48 horas. Mantén la instancia TYPO3 en ejecución (solo lectura) durante al menos 30 días como referencia.

Fase 4: Decomisionar

Una vez que estés seguro de que la migración es estable, apaga la infraestructura de TYPO3. Archiva la base de datos y el directorio fileadmin. Te agradecerás a ti mismo más tarde cuando alguien pregunte sobre contenido antiguo.

Cronograma y costos de migración del mundo real

Seamos honestos sobre lo que esto cuesta. He visto demasiados equipos subestimar proyectos de migración.

Tamaño del proyecto Páginas Cronograma Costo estimado
Pequeño 50-200 6-10 semanas $15,000-$35,000
Mediano 200-1,000 12-20 semanas $40,000-$90,000
Grande 1,000-5,000 20-36 semanas $80,000-$200,000
Empresa 5,000+ 6-12 meses $150,000-$500,000+

Estos números incluyen modelado de contenido, scripts de migración, desarrollo frontend, pruebas y soporte de lanzamiento. No incluyen costos de licencia de CMS, que varían según la plataforma.

Los mayores impulsores de costo son:

  1. Número de tipos de contenido y complejidad -- no recuento de páginas puro
  2. Extensiones TYPO3 personalizadas que necesitan funcionalidad equivalente construida
  3. Complejidad de configuración multiidioma
  4. Requisitos de integración (búsqueda, e-commerce, autenticación)
  5. Capacitación editorial y gestión del cambio

Si quieres discutir cómo podría parecer una migración para tu configuración específica, contáctanos o consulta nuestra página de precios para modelos de engagement.

Preguntas frecuentes

¿Puedo usar TYPO3 como un CMS headless en lugar de migrar a uno nuevo? Sí, la extensión EXT:headless (anteriormente "headless") convierte TYPO3 en una API JSON. Esta puede ser una buena estrategia intermedia. Sin embargo, todavía estás manteniendo un backend TYPO3 con toda su sobrecarga operativa. Tiene sentido como una estrategia de puente pero generalmente no es la respuesta a largo plazo si tu objetivo es reducir la dependencia de TYPO3.

¿Cuánto tiempo toma una migración típica de TYPO3 a CMS headless? Para un sitio de tamaño mediano (200-1,000 páginas), espera 3-5 meses desde el inicio hasta el lanzamiento. Las fases de modelado de contenido y scripts de migración típicamente toman más tiempo del que los equipos anticipan. El desarrollo frontend a menudo puede ejecutarse en paralelo una vez que el modelo de contenido está definido. Las migraciones empresariales con múltiples idiomas e integraciones complejas pueden tomar 6-12 meses.

¿Perderé rankings de SEO durante la migración? No deberías si lo haces correctamente. Los factores críticos son: implementar redirecciones 301 apropiadas para todas las URL cambiadas, migrar todos los metadatos, mantener tu estructura de sitio y enlaces internos y enviar mapas de sitio actualizados a Google. Una caída temporal en rankings de 2-4 semanas después de la migración es normal y usualmente se recupera. Las pérdidas permanentes típicamente indican redirecciones perdidas o contenido perdido.

¿Cuál es el mejor CMS headless para reemplazar TYPO3? Depende de tus prioridades. Storyblok a menudo es la transición más suave para editores de TYPO3 debido a sus capacidades de edición visual. Contentful es la opción empresarial más segura con el ecosistema más maduro. Sanity ofrece la mayor flexibilidad del desarrollador. Strapi es la mejor opción si necesitas código abierto y auto-hospedaje. No hay una respuesta única mejor -- depende de tu equipo, presupuesto y requisitos.

¿Qué sucede con mis extensiones de TYPO3 después de la migración? Cada extensión necesita ser evaluada individualmente. Las extensiones comunes como EXT:news, EXT:cal y EXT:powermail necesitan funcionalidad equivalente en tu nuevo stack. La funcionalidad de noticias/blog es sencilla de replicar con cualquier CMS headless. Las características de calendario y eventos podrían necesitar servicios de terceros. Los formularios requieren una nueva solución (constructores de formularios, funciones serverless o servicios como Formspree). Las extensiones personalizadas necesitan el análisis más.

¿Cómo manejo los activos de fileadmin de TYPO3 durante la migración? Necesitarás migrar todos los activos (imágenes, PDFs, videos) al sistema de gestión de activos de tu nuevo CMS o a un DAM/CDN separado. Escribe un script que descargue desde fileadmin, cargue en la nueva plataforma a través de su API y mapee referencias de archivo antiguas a IDs de activos nuevas. No olvides manejar imágenes procesadas/redimensionadas -- la mayoría de plataformas CMS headless manejan transformación de imagen automáticamente, así que típicamente solo necesitas migrar originales.

¿Puedo migrar incrementalmente o tiene que ser todo a la vez? La migración incremental es posible y a veces aconsejable para sitios grandes. Puedes usar un proxy inverso para enrutar ciertos caminos de URL al nuevo frontend headless mientras mantienes otros en TYPO3. Esto te permite migrar sección por sección. La compensación es mayor complejidad en gestionar dos sistemas simultáneamente y mantener navegación y diseño consistentes en ambos.

¿Qué debo hacer sobre usuarios del backend de TYPO3 que se resisten al cambio? La gestión del cambio es genuinamente la mitad de la batalla. Comienza involucrando a los editores temprano -- muéstrales el nuevo CMS durante la fase de modelado de contenido, no después de que todo esté construido. Elige un CMS con una buena experiencia de edición (Storyblok y Contentful tienden a obtener los mejores comentarios de editores). Crea documentación y materiales de capacitación específicos para tu configuración. Y sé honesto sobre qué está cambiando y por qué -- los editores usualmente se adaptan cuando ven la experiencia de vista previa mejorada y flujos de trabajo de publicación más rápidos.