Plan de migración por escrito
Inventario del contenido origen, diseño del esquema destino, mapa de redirecciones, plan de cutover con ruta de rollback. No empezamos la migración hasta que el plan está firmado.
// migración a cms headless
Movemos sitios desde WordPress, Contentful heredado, Drupal o CMS hechos a medida hacia Sanity, Storyblok o Contentful — con el mapa de redirecciones, el esquema de contenido estructurado y la formación a editores que hacen que el cambio cuaje. Alcance dimensionado por proyecto.
// por qué los equipos cambian de plataforma
// qué incluye
Inventario del contenido origen, diseño del esquema destino, mapa de redirecciones, plan de cutover con ruta de rollback. No empezamos la migración hasta que el plan está firmado.
Documentos, objetos y referencias modelados según LO QUE ES el contenido — no según dónde aparece ahora. Reutilizable en web, app, email y pantallas físicas. Sanity, Storyblok o Contentful, según encaje con el equipo.
Configuración de Studio ajustada al flujo real de las editoras. Inputs personalizados, structure builder, document actions, preview en tiempo real contra staging.
Script idempotente y re-ejecutable que extrae cada post, página, taxonomía, imagen y referencia del CMS antiguo y los escribe en el nuevo modelo. Incluye informe de paridad de contenido.
Mapa de redirecciones URL (uno-a-uno para cada URL indexada), sitemap.xml actualizado, continuidad de schema.org, seguimiento de lastmod, monitorización en GSC durante el cutover.
Vídeos grabados para el equipo de contenido, runbook escrito para operaciones, registro de decisiones con las razones de cada elección de arquitectura.
// cómo trabajamos
01 · Calibrar
Auditoría de contenido en el CMS antiguo. Diseño de esquema destino. Estrategia de redirecciones. Plan de cutover con rollback. Alcance por escrito antes de cualquier migración.
02 · Construir y migrar
CMS nuevo configurado en paralelo con el script de migración. Demo semanal en staging con contenido real migrado. El equipo de contenido se forma en el nuevo Studio mientras construimos.
03 · Cutover y soporte
Migración en producción dentro de una ventana de mantenimiento. Redirecciones activas. Monitorización SEO durante el periodo posterior al lanzamiento. La ventana de soporte post-launch arranca con el cutover.
// preguntas frecuentes
Sí — cuando se planifica así. Construimos un mapa de redirecciones uno-a-uno para cada URL indexada, mantenemos el JSON-LD de schema.org, conservamos canonicals y hreflang, y monitorizamos Google Search Console durante el cutover. Hemos movido sitios con tráfico orgánico de seis cifras al mes sin perder posiciones. El riesgo es alto si os saltáis el plan de redirecciones; cercano a cero si no.
Sanity para equipos editoriales que quieren un Studio a medida y se preocupan por Portable Text estructurado. Storyblok para equipos de marketing que quieren editor visual y autoría por componentes. Contentful para organizaciones grandes que necesitan flujos formales de revisión, control de roles y logs de auditoría. Elegimos según tamaño del equipo, perfil editorial y necesidades de reutilización — no según cuál nos guste más.
Dimensionada por proyecto. Factores que la marcan: número de tipos de contenido, complejidad de campos a medida en el CMS origen, profundidad de referencias, volumen de imágenes y cuánta limpieza de contenido hay que hacer (la mayoría de CMS heredados arrastran posts huérfanos, imágenes rotas y taxonomías sin uso que aparecen en la auditoría).
Reemplazamos la funcionalidad, no los plugins. Los formularios pasan a un endpoint API tipado o a un servicio como Web3Forms. Los plugins de SEO se convierten en metadatos estructurados del nuevo esquema. La optimización de imágenes pasa a Next.js o a un CDN dedicado. La caché se gestiona en el edge. El resultado son menos piezas móviles, no una reescritura de cada plugin.
Sí. El script de migración es idempotente — re-ejecutable hasta el cutover. Las editoras siguen publicando en el CMS antiguo; volvemos a tirar contenido justo antes de la ventana de mantenimiento. El contenido se congela en el CMS antiguo solo durante la ventana de cutover, no durante todo el proyecto.
Podemos hacer una migración por fases — mover tipos de contenido en orden de prioridad, con el CMS antiguo y el nuevo sirviendo rutas a través de un proxy. Aumenta el alcance pero reduce el riesgo del cutover. Patrón habitual en sitios con blog de mucho tráfico que necesita publicación continua.
Habitualmente sí — construimos el storefront o el sitio de marketing headless en Next.js como parte del engagement. Si tenéis un frontend Next.js, Nuxt o SvelteKit ya en marcha, integramos el nuevo CMS contra él. No migramos a un CMS headless sin un plan para el frontend que lo consume.
Sanity y Contentful traen historial de documentos integrado. Configuramos la ventana de retención y los atajos de document actions al flujo de vuestro equipo. El script de migración mantiene el CMS antiguo como copia de solo lectura tras el cutover.
Murcia, España. En remoto con clientes en España, la UE, el Reino Unido y Norteamérica. Visitas presenciales cuando el proyecto lo justifica. Entregado en castellano o inglés.
Respondemos en menos de 24 horas. Cuéntanos qué estás construyendo.
Hablemos →