Tu equipo aprueba el cambio a Sanity. Exportas 80,000 posts de WordPress, activas una instancia de Studio, y descubres que la mitad de tus campos meta siguen tres esquemas diferentes—y nadie documentó la lógica de taxonomía personalizada que impulsaba toda tu navegación del sitio. He realizado más de 40 migraciones a Sanity en tres años. Algunas se cerraron en dos semanas. Otras se extendieron a tres meses y me hicieron reconsiderar cada decisión que me llevó al trabajo independiente. La diferencia nunca dependió de si estabas dejando WordPress, Contentful o Drupal. Dependió de tres cosas: qué tan honestamente definiste tu modelo de contenido por adelantado, si trataste el mapeo de campos como arquitectura o trabajo ocupado, y si alguien en tu equipo admitió que no entendía cómo funcionaba realmente tu CMS antiguo. Esta guía te lleva a través de cada decisión que determina si tu migración es un sprint limpio o un desmoronamiento en cámara lenta—y te muestra las listas de verificación exactas, scripts y modelos mentales que separan los dos.

Esta es la guía que desearía haber tenido cuando comencé a hacer migraciones de CMS. Cubre el movimiento desde WordPress, Contentful y Drupal hacia el mundo impulsado por GROQ de Sanity. Seré directo sobre dónde Sanity brilla, dónde te frustará, y qué se ven los cronogramas reales.

Tabla de Contenidos

Guía de Migración a Sanity: Migración desde WordPress, Contentful o Drupal

Por Qué Los Equipos Se Están Moviendo a Sanity en 2026

Aclaremos lo obvio primero. La edición colaborativa en tiempo real de Sanity, el Studio personalizable, y el enfoque de contenido estructurado son genuinamente buenos. Pero la razón por la que la mayoría de los equipos se comunican con nosotros sobre migración no es porque hayan leído un artículo de blog sobre las características de Sanity. Es porque algo se rompió.

Los sitios de WordPress alcanzan límites de escalabilidad alrededor de 50,000+ piezas de contenido con tipos de posts personalizados complejos. El modelo de precios de Contentful comienza a presionar en el nivel empresarial — hemos visto equipos enfrentándose a facturas de $3,500+/mes por lo que es básicamente una API de contenido. Los equipos de Drupal no pueden encontrar desarrolladores, al menos no que quieran trabajar con el templating de PHP en 2026.

El modelo de precios de Sanity es genuinamente más predecible para la mayoría de los equipos. El nivel gratuito cubre hasta 100K solicitudes API/mes y 500K activos. El plan Growth a $99/mes/proyecto te da 2.5M solicitudes API y 1M activos. Para comparar, el plan Team de Contentful corre $300/mes y el nivel Premium de Contentful puede fácilmente exceder $2,000/mes.

Pero aquí está mi opinión honesta: si tu CMS actual funciona bien y tu equipo es productivo, no migres solo porque Sanity es más nuevo o más genial. Las migraciones siempre cuestan más de lo que piensas.

Auditoría Previa a la Migración: El Paso Que Todos Omiten

Antes de escribir una sola línea de código de migración, necesitas una auditoría de contenido. No un escaneo rápido — una auditoría real. Esto se ve así:

Inventario de Contenido

Documenta cada tipo de contenido, cada campo, cada relación. Uso una hoja de cálculo con estas columnas:

  • Nombre del tipo de contenido
  • Elementos totales
  • Campos (con tipos)
  • Relaciones con otros tipos de contenido
  • Adjuntos de medios (cantidad y tamaño total)
  • Funcionalidad personalizada (shortcodes, widgets, embeds)
  • Fecha de última modificación
  • ¿Aún es relevante? (Sí/No/Tal vez)

Te sorprenderá cuánto contenido es peso muerto. En una migración de WordPress, un cliente tenía 12,000 posts. Después de la auditoría, solo 4,200 eran relevantes. Eso es 65% menos contenido para migrar, probar y validar.

Mapeo de Dependencia Técnica

Haz una lista de cada plugin, módulo o integración que tu CMS actual usa. Para cada uno, determina:

  1. ¿Sanity puede manejar esto de forma nativa?
  2. ¿Hay un plugin de Sanity para esto?
  3. ¿Necesitamos construir una solución personalizada?
  4. ¿Podemos eliminar esto completamente?

Este mapeo por sí solo te ahorrará semanas de sorpresas por el camino.

Evaluación de Preparación del Equipo

Sanity Studio se basa en React. Tus editores de contenido necesitarán capacitación. Tus desarrolladores necesitarán aprender GROQ (u usar GraphQL, aunque GROQ es donde Sanity realmente brilla). Presupuesta 1-2 semanas para la incorporación del equipo — no como algo nice-to-have, sino como un elemento de línea.

Migración de WordPress a Sanity

WordPress es la fuente CMS más común desde la que migramos. También es la más complicada, porque WordPress no es solo un CMS — es una plataforma de aplicación completa en la que las personas han añadido todo.

Lo Que Se Transfiere Limpiamente

  • Posts y páginas (contenido básico)
  • Categorías y etiquetas
  • Imágenes destacadas
  • Datos del autor
  • Campos personalizados básicos (ACF, Meta Box)

Lo Que Se Vuelve Complicado

  • Bloques de Gutenberg: Cada tipo de bloque necesita un bloque personalizado o tipo de objeto de Portable Text de Sanity correspondiente. Si tienes 15+ bloques de Gutenberg personalizados, presupuesta tiempo significativo aquí.
  • Shortcodes: Estos necesitan ser analizados, interpretados y convertidos a anotaciones de Portable Text o bloques personalizados. Los shortcodes de WPBakery y Elementor son particularmente dolorosos.
  • Contenido generado por plugins: Productos de WooCommerce, datos de Yoast SEO, campos repetidores ACF — cada uno requiere lógica de migración personalizada.
  • Librería de medios: WordPress almacena múltiples tamaños de imagen. Sanity maneja transformaciones de imagen sobre la marcha, así que solo necesitas los originales. ¿Pero encontrar los originales en una carpeta wp-uploads desordenada? Momentos divertidos.

Enfoque de Script de Migración

Generalmente uso un script de Node.js que accede a la API REST de WordPress y escribe a la API de mutación de Sanity:

import { createClient } from '@sanity/client'
import fetch from 'node-fetch'

const sanity = createClient({
  projectId: 'your-project-id',
  dataset: 'production',
  token: process.env.SANITY_WRITE_TOKEN,
  apiVersion: '2025-01-01',
  useCdn: false,
})

const WP_API = 'https://yoursite.com/wp-json/wp/v2'

async function migratePosts(page = 1) {
  const res = await fetch(`${WP_API}/posts?per_page=100&page=${page}`)
  const posts = await res.json()
  const totalPages = res.headers.get('x-wp-totalpages')

  const transaction = sanity.transaction()

  for (const post of posts) {
    transaction.createOrReplace({
      _id: `wp-post-${post.id}`,
      _type: 'post',
      title: post.title.rendered,
      slug: { current: post.slug },
      publishedAt: post.date,
      // Body requires HTML-to-Portable-Text conversion
      body: await convertToPortableText(post.content.rendered),
    })
  }

  await transaction.commit()
  console.log(`Migrated page ${page} of ${totalPages}`)

  if (page < totalPages) {
    await migratePosts(page + 1)
  }
}

La función convertToPortableText es donde vive el 80% de la complejidad. Uso el paquete @sanity/block-tools combinado con jsdom para el análisis HTML. Maneja HTML básico bien, pero elementos personalizados y shortcodes necesitan manejadores individuales.

Cronograma Realista

Para un sitio de WordPress típico con 500-2,000 posts, campos personalizados estándar, y un puñado de tipos de posts personalizados: 4-8 semanas incluyendo modelado de contenido, scripting de migración, validación de datos y capacitación de editores.

Guía de Migración a Sanity: Migración desde WordPress, Contentful o Drupal - arquitectura

Migración de Contentful a Sanity

Contentful-a-Sanity es en realidad la ruta de migración más suave de las tres. ¿Por qué? Porque ambas son plataformas de contenido estructurado con modelos mentales similares. Tu contenido ya está en un CMS headless con tipos de contenido y campos definidos.

Diferencias Clave a Considerar

Característica Contentful Sanity
Texto enriquecido Rich Text (basado en JSON) Portable Text (basado en JSON)
Modelado de contenido IU web Esquemas definidos en código
Lenguaje de consulta GraphQL / REST GROQ (+ GraphQL)
Localización Built-in a nivel de campo Plugin o personalizado
Referencias Links (Entry/Asset) Referencias con tipos
Webhooks Sí Sí
Manejo de activos CDN integrado Sanity CDN + hotspot/crop
Precios (nivel medio) ~$300/mo (Team) $99/mo (Growth)

Conversión de Texto Enriquecido

El Rich Text de Contentful y el Portable Text de Sanity son ambos basados en JSON, lo cual es excelente. Pero tienen estructuras diferentes. Necesitarás escribir un transformador:

function contentfulRichTextToPortableText(richTextField) {
  return richTextField.content.map(node => {
    switch (node.nodeType) {
      case 'paragraph':
        return {
          _type: 'block',
          style: 'normal',
          children: node.content.map(mapInlineContent),
        }
      case 'heading-2':
        return {
          _type: 'block',
          style: 'h2',
          children: node.content.map(mapInlineContent),
        }
      case 'embedded-entry-block':
        // Map to your custom Portable Text type
        return mapEmbeddedEntry(node)
      // ... handle all node types
    }
  }).filter(Boolean)
}

Mapeo de Tipo de Contenido a Esquema

Los tipos de contenido de Contentful se mapean bastante directamente a tipos de documento y objeto de Sanity. El cambio más grande es que los esquemas de Sanity se definen en código (JavaScript/TypeScript), no en una IU web. Esto es en realidad una enorme ventaja — tu modelo de contenido vive en control de versiones.

Usa la API de Gestión de Contentful para exportar tu modelo de contenido, luego escribe un script que genere archivos de esquema de Sanity:

contentful space export --space-id YOUR_SPACE_ID --export-dir ./export

Cronograma Realista

Para un espacio de Contentful con 10-20 tipos de contenido y 5,000-10,000 entradas: 3-5 semanas. Es más rápido porque ya estás pensando en contenido estructurado.

Migración de Drupal a Sanity

Las migraciones de Drupal son las que me hacen servir un segundo café. No porque Drupal sea malo — es un sistema poderoso. Pero los sitios de Drupal tienden a ser antiguos, personalizados hasta el máximo, y funcionando en infraestructura que nadie entiende completamente.

Los Desafíos Específicos de Drupal

  • Tipos de contenido con 50+ campos: Drupal hace fácil agregar campos. Demasiado fácil. He visto tipos de contenido con 80 campos, la mitad de los cuales están sin usar.
  • Referencias de término de taxonomía: El sistema de taxonomía de Drupal es flexible pero puede crear jerarquías profundamente anidadas que necesitan aplanarse para Sanity.
  • Módulo de párrafos: Si el sitio usa Drupal Paragraphs (y la mayoría de los sitios modernos de Drupal lo hacen), cada tipo de párrafo se convierte en un tipo de bloque de Portable Text u objeto de Sanity. Esta es la tarea individual más grande.
  • Entidades de medios: El sistema de medios de Drupal 9/10 es más complejo que el de WordPress. Múltiples tipos de medios, entidades de medios reutilizables, y configuraciones de campos de archivo todo necesita mapeo.
  • Contenido multilingüe: El sistema de traducción de Drupal es sofisticado. Sanity no tiene localización integrada al mismo nivel — necesitarás el plugin @sanity/document-internationalization o un enfoque a nivel de campo.

Enfoque de Migración

Prefiero usar el módulo JSON:API de Drupal (incluido en Drupal core desde 9.x) como la capa de extracción:

async function fetchDrupalContent(type, page = 0) {
  const limit = 50
  const offset = page * limit
  const url = `${DRUPAL_URL}/jsonapi/node/${type}?page[limit]=${limit}&page[offset]=${offset}&include=field_image,field_paragraphs`

  const res = await fetch(url, {
    headers: { Authorization: `Basic ${DRUPAL_AUTH}` },
  })
  return res.json()
}

Para sitios Drupal 7 más antiguos sin JSON:API, es posible que necesites consultar la base de datos directamente. El esquema de base de datos de Drupal 7 es... una experiencia. Las tablas field_data_* perseguirán tus sueños.

Cronograma Realista

Las migraciones de Drupal varían enormemente. Un sitio Drupal 10 directo con 5-10 tipos de contenido: 5-8 semanas. Un sitio heredado de Drupal 7 con 30+ tipos de contenido, Paragraphs y contenido multilingüe: 8-16 semanas. No estoy exagerando.

Modelado de Contenido: Obtener Tus Esquemas Correctos

Aquí está la cosa que la mayoría de guías de migración no te dirán: no repliques tu modelo de contenido antiguo en Sanity. Esta es tu oportunidad para arreglar años de deuda de contenido acumulada.

Errores Comunes de Modelado

  1. Crear un mapeo de campo 1:1: Solo porque WordPress tenía un campo personalizado "subtitle" no significa que Sanity necesite uno. Tal vez debería ser parte de un objeto "hero" estructurado.
  2. Objetos sobre-anidados: Sanity te permite anidar objetos profundamente. Resiste la tentación. Los esquemas planos-ish son más fáciles de consultar con GROQ y más fáciles para que los editores trabajen.
  3. Ignorar el poder de Portable Text: No solo viertas HTML en un único campo de texto. Diseña tipos de bloques personalizados que coincidan con tus patrones de contenido. Un bloque "callout", un bloque "code snippet", un bloque "image with caption" — estos hacen la vida de los editores mejor.

Proceso de Diseño de Esquema

Sigo este orden:

  1. Auditoría de contenido existente (hecho en pre-migración)
  2. Identificar los patrones de contenido reales (no lo que el CMS impuso)
  3. Diseñar esquemas en papel/pizarra primero
  4. Construir esquemas en código
  5. Importar un lote de prueba pequeño (50-100 elementos)
  6. Hacer que los editores prueben la experiencia de Studio
  7. Iterar en esquemas antes de la migración completa

Los pasos 5-7 son críticos y a menudo se omiten. Hemos escrito más sobre enfoques de modelado de contenido en nuestro trabajo de desarrollo de CMS headless.

Estrategias y Herramientas de Migración de Datos

Herramientas Esenciales

  • @sanity/client: El cliente oficial de JavaScript para leer/escribir datos de Sanity
  • @sanity/block-tools: Convierte HTML a Portable Text
  • sanity dataset import/export: Herramientas CLI para operaciones de dataset completas
  • ndjson: Sanity usa JSON delimitado por saltos de línea para importaciones — familiarízate con él
  • jsdom o htmlparser2: Para el análisis HTML durante la conversión de texto enriquecido

Arquitectura de Migración

Estructuro cada migración como un pipeline con cuatro etapas:

Extract → Transform → Load → Validate

Cada etapa es un script separado. Esto importa porque ejecutarás la migración varias veces — típicamente 5-10 veces antes de la ejecución final de producción. Tener etapas separadas significa que puedes re-ejecutar solo las partes que necesitan corrección.

# Extract
node scripts/extract-wordpress.js > data/raw-posts.ndjson

# Transform
node scripts/transform-posts.js < data/raw-posts.ndjson > data/sanity-posts.ndjson

# Load
sanity dataset import data/sanity-posts.ndjson production --replace

# Validate
node scripts/validate-migration.js

Manejo de Activos

Las imágenes y archivos siempre son la parte más lenta. El pipeline de activos de Sanity es bueno, pero subir 10,000 imágenes toma tiempo. Consejos:

  • Sube activos primero, mantén un mapeo de URLs antiguas a IDs de activos de Sanity nuevos
  • Usa cargas concurrentes (pero respeta límites de velocidad — 25 req/seg para el plan Growth)
  • Verifica dimensiones e formato de imagen antes de subir
  • No migres tamaños de miniatura — Sanity los genera sobre la marcha a través de su CDN de imagen

Los Costos Ocultos de Los Que Nadie Habla

Permíteme ser directo contigo sobre costos que no aparecen en la estimación típica de migración.

Redirecciones de URL

Si estás cambiando tu frontend (que probablemente lo estés si te estás moviendo a un CMS headless), necesitas mapeo de redireccionamiento. Cada. URL. Única. Para SEO, esto es innegociable. Un sitio con 5,000 páginas necesita 5,000 reglas de redireccionamiento. Herramientas como redirecciones next.config.js o el archivo _redirects de Vercel pueden manejar esto, pero alguien tiene que construir el mapeo.

Migración de Metadatos de SEO

Datos de Yoast SEO de WordPress. Datos del módulo Metatag de Drupal. Campos de SEO de Contentful. Todo esto necesita venir. Títulos meta personalizados, descripciones, imágenes Open Graph, URLs canónicas, datos estructurados — es un proyecto dentro del proyecto.

Capacitación y Documentación de Editores

Presupuesta 2-4 días mínimo. Sanity Studio es intuitivo, pero es diferente de lo que tus editores conocen. Generalmente creamos documentación personalizada de Studio con capturas de pantalla y grabamos 3-5 videos de explicación.

Desarrollo Frontend

Este es el elefante en la sala. Migrar contenido a Sanity es solo la mitad del proyecto. También necesitas un frontend que consuma el contenido. Ya sea que estés usando Next.js, Astro u otro framework, la construcción del frontend es a menudo 50-70% del costo total del proyecto. Consulta nuestro trabajo con Next.js y Astro si estás evaluando opciones de frontend.

Comparación de Cronograma y Presupuesto

Basado en proyectos que hemos completado en años recientes:

Ruta de Migración Volumen de Contenido Complejidad Cronograma Rango de Presupuesto
WordPress → Sanity < 1,000 páginas Baja 3-5 semanas $8K-$15K
WordPress → Sanity 1,000-10,000 páginas Media 6-10 semanas $15K-$35K
WordPress → Sanity 10,000+ páginas Alta 10-16 semanas $35K-$75K
Contentful → Sanity < 5,000 entradas Baja-Media 3-5 semanas $7K-$18K
Contentful → Sanity 5,000-20,000 entradas Media 5-8 semanas $18K-$40K
Drupal → Sanity < 2,000 nodos Media 5-8 semanas $12K-$25K
Drupal → Sanity 2,000-15,000 nodos Alta 8-14 semanas $25K-$60K
Drupal 7 → Sanity Cualquiera Muy Alta 10-20 semanas $35K-$90K

Nota: Estos rangos incluyen solo migración de contenido. El desarrollo frontend es adicional. Contáctanos en /pricing para estimaciones específicas del proyecto.

Estas cifras incluyen modelado de contenido, scripting de migración, validación de datos y capacitación básica de editores. No incluyen desarrollo frontend, diseño o mantenimiento continuo.

Lista de Verificación Posterior a la Migración

Aquí está la lista de verificación que uso en cada migración:

  • Todos los tipos de contenido migrados y verificados
  • Todas las referencias/relaciones intactas
  • Todas las imágenes y archivos subidos y vinculados correctamente
  • Contenido de texto enriquecido se renderiza correctamente (verifica el formato roto)
  • Redirecciones de URL en su lugar y probadas
  • Metadatos de SEO migrados (títulos, descripciones, datos OG)
  • Mapa del sitio XML regenerado
  • Search console actualizada con nuevo mapa del sitio
  • Seguimiento de análisis preservado
  • Cuentas de editor creadas y permisos establecidos
  • Capacitación de editor completada
  • Vista previa de contenido (modo borrador) funcionando
  • Webhooks configurados para activadores de construcción
  • Copia de seguridad de datos del CMS de origen archivada
  • Cambios de DNS planeados (si aplica)
  • Línea de base de rendimiento medida
  • Monitoreo de 404 establecido para los primeros 30 días

Ese último punto es importante. No importa cuán minucioso sea tu mapeo de redireccionamiento, algunas URLs se escaparán. Monitorea tus 404s agresivamente durante el primer mes.

Preguntas Frecuentes

¿Cuánto tiempo toma una migración típica de WordPress a Sanity? Para un sitio estándar de WordPress con menos de 2,000 posts y campos personalizados directos, espera 4-8 semanas. Eso incluye modelado de contenido, scripting de migración, validación de datos y capacitación de editores. Los sitios con bloques de Gutenberg complejos, WooCommerce o contenido multilingüe pueden tomar 10-16 semanas. El volumen de contenido importa menos que la complejidad de tus tipos de contenido.

¿Puedo migrar de Contentful a Sanity sin perder datos? Sí, y es en realidad la ruta de migración más limpia entre las tres que cubro aquí. Ambas plataformas usan contenido estructurado basado en JSON, así que el mapeo es relativamente directo. El texto enriquecido necesita conversión del formato de Contentful a Portable Text, y las referencias necesitan remapeo, pero no deberías perder ningún dato. Recomiendo ejecutar la migración contra un dataset de staging primero y hacer una comparación de contenido minuciosa antes de cambiar.

¿Qué sucede con mis clasificaciones de SEO durante una migración de CMS? Esta es la pregunta que mantiene despiertos a los directores de marketing. Si manejas redireccionamientos correctamente, mantienes tu estructura de URL donde sea posible, y migras todos los metadatos de SEO, deberías ver un impacto mínimo. La documentación propia de Google dice que las migraciones adecuadamente redireccionadas pueden ver un dip temporal de 2-4 semanas antes de recuperarse. La palabra clave es "apropiadamente". Omite el mapeo de redireccionamiento y hundirás tus clasificaciones. Lo hemos visto suceder.

¿Es Sanity más barato que Contentful para uso empresarial? En la mayoría de los casos, sí — a veces significativamente. El plan Growth de Sanity a $99/mes cubre lo que necesitarías el plan Team de Contentful de $300/mes para. A escala empresarial, la diferencia se hace más grande. Los precios Premium de Contentful no están listados públicamente pero típicamente corren $2,000-$4,000+/mes. Los precios Enterprise de Sanity también son personalizados pero generalmente salen más bajos para uso equivalente. La verdadera diferencia de costo está en las llamadas API — los límites incluidos de Sanity son más generosos.

¿Debería migrar mi sitio Drupal 7 a Sanity o actualizar a Drupal 10 primero? Ve directamente a Sanity. Migrar de Drupal 7 a Drupal 10 es casi tanto trabajo como migrar a un CMS diferente completamente — la arquitectura cambió tan dramáticamente entre versiones. Si ya estás invirtiendo en una migración importante, podrías también moverte a la plataforma en la que realmente quieres estar a largo plazo. La una excepción: si tu equipo está profundamente invertido en el ecosistema de Drupal y solo quiere modernizar, Drupal 10 con un frontend headless es un camino válido.

¿Necesito reconstruir mi frontend al migrar a Sanity? Si vienes de un CMS monolítico como WordPress o Drupal, sí — necesitarás un frontend nuevo ya que Sanity es headless. Esto es generalmente la parte más grande del proyecto. Si vienes de Contentful, a menudo puedes reutilizar tu frontend existente con llamadas API modificadas, especialmente si ya estás usando Next.js o un framework similar. Manejamos tanto la migración de CMS como las construcciones de frontend como proyectos integrados.

¿Puedo ejecutar mi CMS antiguo y Sanity en paralelo durante la migración? Absolutamente, y lo recomiendo. Ejecuta ambos sistemas durante 2-4 semanas después de tu migración inicial. Los editores pueden continuar trabajando en el CMS antiguo mientras validas datos en Sanity. Solo congela contenido en el sistema antiguo antes de tu ejecución de migración final — no quieres perseguir un objetivo móvil. Algunos equipos establecen una fecha de "congelación de contenido" 48 horas antes del cambio final.

¿Cuál es el mayor error que los equipos cometen durante una migración de Sanity? Intentando replicar su estructura de CMS antigua exactamente en Sanity. Lo veo constantemente. Los equipos vienen de WordPress e intentan construir esquemas en forma de WordPress en Sanity — tipos de "página" genéricos con layouts flexibles en lugar de tipos de contenido propósito-construidos. La fortaleza de Sanity es contenido estructurado. Usa la migración como una oportunidad para modelar tu contenido apropiadamente. Pasa una semana extra en modelado de contenido. Te ahorrará meses de dolor después. Si quieres orientación en esto, contáctanos — el modelado de contenido es una de las cosas en las que más tiempo gastamos en proyectos de migración.