He migrado más de una docena de sitios WordPress a Next.js en producción, y te diré algo que podría sorprenderte: la migración del código en sí no es la parte difícil. Lo difícil es el corte. Ese momento aterrador en que accionas el interruptor y rezas para que nada se rompa. ¿La buena noticia? Con el plan de acción correcto, puedes hacer que ese momento sea aburrido. Y en operaciones, aburrido es exactamente lo que quieres.

Este es el plan de acción que usamos en Social Animal para los cortes en producción. No es teórico — está construido a partir de migraciones reales donde había ingresos reales en juego. Hablamos de sitios de comercio electrónico que facturan $50K/día, editores de contenido con millones de páginas vistas mensuales, y sitios de marketing SaaS donde 5 minutos de inactividad significa que el CEO te llama al celular.

Tabla de Contenidos

Zero Downtime CMS Migration: WordPress to Next.js Cutover Playbook

Por Qué el Tiempo de Inactividad Cero Importa Más de lo que Crees

Pongamos algunos números sobre esto. La investigación de Google de 2024 muestra que un retraso de 1 segundo en la carga de la página cuesta aproximadamente un 7% en conversiones. Ahora imagina que tu sitio simplemente... desaparece. Aunque sea por 5 minutos.

Esto es lo que realmente está en juego:

Duración de Inactividad Impacto en Ingresos (para un sitio de $10K/día) Impacto SEO Impacto en Confianza del Usuario
5 minutos ~$35 perdidos Mínimo si es aislado Bajo
30 minutos ~$208 perdidos Googlebot puede notarlo Moderado
2 horas ~$833 perdidos Errores de rastreo en GSC Alto
24 horas $10,000+ perdidos Riesgo de desindexación Severo

Pero no son solo los ingresos. Los motores de búsqueda rastrean constantemente. Si Googlebot visita tu sitio durante una migración y recibe errores 500, esas URLs pueden caer del índice en cuestión de horas. He visto sitios perder el 40% de su tráfico orgánico porque alguien hizo una "migración rápida" a la hora del almuerzo.

El objetivo no es solo cero tiempo de inactividad. Es cero cambios visibles para usuarios y rastreadores durante la transición.

Visión General de la Arquitectura de Migración

Antes de entrar en las fases, veamos la arquitectura que buscamos. El patrón fundamental consiste en ejecutar ambos sistemas en paralelo y luego cambiar el tráfico de forma atómica.

                    ┌─────────────────┐
                    │   Cloudflare /   │
                    │   Load Balancer  │
                    └────────┬────────┘
                             │
                    ┌────────┴────────┐
                    │  Traffic Router  │
                    │  (weight-based)  │
                    └────┬───────┬────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  WordPress  │ │   Next.js   │
              │  (Blue)     │ │   (Green)   │
              │  Origin     │ │   on Vercel │
              └──────────┬──┘ └──┬──────────┘
                         │       │
              ┌──────────┴──┐ ┌──┴──────────┐
              │  MySQL DB   │ │ Headless CMS │
              │             │ │ (Sanity/etc) │
              └─────────────┘ └─────────────┘

La clave es que no solo estás migrando un frontend. Estás migrando la capa de contenido, la capa de renderizado y la capa de entrega — y cada una puede migrarse de forma independiente.

Fase 1: Migración de Contenido y Capa de API

Aquí es donde la mayoría de los equipos comienzan mal. Intentan construir el frontend de Next.js primero y luego se preocupan por el contenido. No hagas eso. Empieza con el contenido.

Elegir tu CMS Headless

El contenido de WordPress necesita un nuevo hogar. La elección importa mucho para la complejidad de la migración:

CMS Facilidad de Migración desde WP Sincronización en Tiempo Real Precios (2025) Ideal Para
Sanity Alta (el contenido estructurado se mapea bien) Sí, mediante webhooks Nivel gratuito, luego $99/mes Modelos de contenido complejos
Contentful Media (requiere mapeo de campos) Sí $300/mes para Team Equipos empresariales
Strapi Alta (modelo similar respaldado por BD) Sí Self-hosted gratis, Cloud desde $29/mes Control total
WordPress REST API N/A (mantener como headless) Ya sincronizado Costos de hosting existentes Victorias rápidas
Payload CMS Alta Sí Self-hosted gratis Equipos orientados a desarrolladores

Cubrimos la selección de CMS headless en profundidad en nuestra página de capacidades de desarrollo headless CMS, pero en resumen: para la mayoría de las migraciones de WordPress, Sanity o Payload CMS te ofrecen el mejor camino de migración.

Configurar la Sincronización de Contenido

Aquí está la parte crítica: durante la fase de ejecución en paralelo, el contenido debe existir en ambos sistemas. Tienes dos estrategias:

Estrategia A: Migración única + congelación Migra todo el contenido al nuevo CMS y luego congela la edición en WordPress. Esto funciona para sitios pequeños, pero falla cuando los editores necesitan seguir publicando.

Estrategia B: Sincronización continua (recomendada) Configura una canalización de sincronización que replique los cambios de WordPress en tu nuevo CMS casi en tiempo real.

// Ejemplo: Manejador de webhook de WordPress que sincroniza con Sanity
// Esto se ejecuta como una función serverless (Vercel/AWS Lambda)

import { createClient } from '@sanity/client';

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

export async function POST(request) {
  const payload = await request.json();
  const { post_id, post_title, post_content, post_status } = payload;

  if (post_status !== 'publish') return new Response('Skipped', { status: 200 });

  try {
    await sanity.createOrReplace({
      _id: `wp-${post_id}`,
      _type: 'post',
      title: post_title,
      body: convertGutenbergToPortableText(post_content),
      migratedFrom: 'wordpress',
      wpId: post_id,
      _updatedAt: new Date().toISOString(),
    });

    return new Response('Synced', { status: 200 });
  } catch (error) {
    console.error('Sync failed:', error);
    return new Response('Sync error', { status: 500 });
  }
}

También necesitarás el lado de WordPress. Usamos un plugin simple que se ejecuta en save_post:

// wp-content/plugins/headless-sync/headless-sync.php
add_action('save_post', function($post_id, $post) {
    if (wp_is_post_revision($post_id)) return;
    
    wp_remote_post(SYNC_ENDPOINT_URL, [
        'body' => json_encode([
            'post_id' => $post_id,
            'post_title' => $post->post_title,
            'post_content' => $post->post_content,
            'post_status' => $post->post_status,
        ]),
        'headers' => [
            'Content-Type' => 'application/json',
            'X-Sync-Secret' => SYNC_SECRET,
        ],
    ]);
}, 10, 2);

Ejecuta esta sincronización durante al menos 2 semanas antes del corte. Quieres detectar casos extremos — shortcodes raros, tipos de publicaciones personalizadas, campos ACF que no se mapean limpiamente.

Zero Downtime CMS Migration: WordPress to Next.js Cutover Playbook - architecture

Fase 2: Construcción de la Aplicación Next.js

No voy a cubrir el proceso completo de construcción de Next.js aquí — eso merece su propio artículo (y tenemos amplia experiencia en desarrollo Next.js). Pero hay aspectos específicos de la migración que importan para el tiempo de inactividad cero.

La Paridad de URLs es No Negociable

Cada URL que existe en tu sitio WordPress debe resolver al mismo contenido en tu sitio Next.js. Cada. Una.

Esto significa:

  • /blog/mi-slug-de-publicacion/ debe funcionar (incluida la barra diagonal final si WordPress la usaba)
  • /category/tecnologia/ debe funcionar o redirigir
  • /wp-content/uploads/2024/03/imagen.jpg debe redirigir a tu nuevo CDN de imágenes
  • /feed/ debe seguir devolviendo RSS/Atom válido
  • Las URLs de paginación como /blog/page/2/ deben funcionar

Construye un script de auditoría de URLs desde el principio:

# Exporta todas las URLs de WordPress usando WP-CLI
wp post list --post_type=post,page --post_status=publish \
  --fields=ID,post_name,post_type,guid --format=csv > urls.csv

# También obtén las redirecciones de cualquier plugin SEO
wp db query "SELECT * FROM wp_redirection_items" --format=csv > redirects.csv

Luego valídalas contra tu build de Next.js:

// validate-urls.mjs
import { readFileSync } from 'fs';
import { parse } from 'csv-parse/sync';

const urls = parse(readFileSync('./urls.csv'), { columns: true });
const NEXT_BASE = 'https://staging.yoursite.com';

for (const row of urls) {
  const res = await fetch(`${NEXT_BASE}/${row.post_name}/`, {
    redirect: 'manual'
  });
  
  if (res.status >= 400) {
    console.error(`BROKEN: /${row.post_name}/ → ${res.status}`);
  }
}

Línea de Base de Rendimiento

Antes del corte, tu sitio Next.js necesita ser al menos tan rápido como WordPress. Parece obvio, pero he visto equipos tan emocionados con el nuevo stack que se olvidan de hacer benchmarks.

Captura los Core Web Vitals de tu sitio WordPress usando datos de CrUX o Lighthouse CI, luego iguálalos o supéralos. Si tu sitio WordPress tiene un LCP de 2.1s y tu sitio Next.js está en 3.4s, no estás listo.

Fase 3: Configuración del Despliegue en Paralelo

Ahora llegamos a la infraestructura que hace posible el tiempo de inactividad cero.

La Ejecución en Paralelo

Ambos sistemas se ejecutan simultáneamente, sirviendo tráfico real. Pero solo uno es "primario" en cualquier momento dado.

Para Next.js en Vercel (nuestra configuración más común), desplegarás tu app Next.js en un dominio personalizado como next.yoursite.com o usarás la URL de vista previa de Vercel. Tu sitio WordPress sigue ejecutándose en yoursite.com.

# Si usas Nginx como proxy inverso
# Esta es la configuración de ejecución en paralelo

upstream wordpress {
    server wordpress-origin.internal:80;
}

upstream nextjs {
    server next-yoursite.vercel.app:443;
}

server {
    listen 443 ssl;
    server_name yoursite.com;

    # Durante la ejecución en paralelo: refleja el tráfico a ambos,
    # pero sirve las respuestas de WordPress
    location / {
        mirror /mirror;
        proxy_pass http://wordpress;
    }

    location = /mirror {
        internal;
        proxy_pass https://nextjs$request_uri;
    }
}

Esta configuración de espejo envía cada solicitud a ambos backends pero solo devuelve la respuesta de WordPress. Obtienes tráfico real llegando a tu app Next.js sin que los usuarios la vean. Revisa tus logs de Next.js en busca de errores, 404s y respuestas lentas.

Monitoreo Sintético

Configura un monitoreo que valide continuamente que ambos sistemas devuelvan contenido equivalente:

// canary-check.mjs — se ejecuta cada 5 minutos via cron
const CRITICAL_URLS = [
  '/',
  '/blog/',
  '/about/',
  '/contact/',
  '/blog/most-popular-post/',
];

for (const path of CRITICAL_URLS) {
  const [wpRes, nextRes] = await Promise.all([
    fetch(`https://yoursite.com${path}`),
    fetch(`https://next.yoursite.com${path}`),
  ]);

  if (wpRes.status !== nextRes.status) {
    alert(`Status mismatch on ${path}: WP=${wpRes.status} Next=${nextRes.status}`);
  }

  // Compara las etiquetas title como verificación de paridad de contenido
  const wpTitle = (await wpRes.text()).match(/<title>(.*?)<\/title>/)?.[1];
  const nextTitle = (await nextRes.text()).match(/<title>(.*?)<\/title>/)?.[1];

  if (wpTitle !== nextTitle) {
    alert(`Title mismatch on ${path}`);
  }
}

Ejecuta esto durante un mínimo de 1 semana sin alertas antes de proceder al corte.

Fase 4: Configuración del Despliegue Blue-Green

El despliegue blue-green significa tener dos entornos de producción idénticos — azul (WordPress actual) y verde (Next.js nuevo) — y cambiar entre ellos de forma atómica.

Uso de Cloudflare Workers para el Enrutamiento de Tráfico

Este es nuestro enfoque preferido porque te ofrece un cambio de tráfico instantáneo y global sin retraso de propagación de DNS.

// Cloudflare Worker para enrutamiento blue-green
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Lee el entorno activo del almacén KV
    const activeEnv = await env.CONFIG.get('active_environment') || 'blue';
    
    // Opcional: enrutamiento canary basado en porcentaje
    const canaryPercent = parseInt(await env.CONFIG.get('canary_percent') || '0');
    const useGreen = activeEnv === 'green' || 
                     (canaryPercent > 0 && Math.random() * 100 < canaryPercent);
    
    const origin = useGreen
      ? 'https://next-yoursite.vercel.app'
      : 'https://wp-origin.yoursite.com';
    
    const originUrl = new URL(url.pathname + url.search, origin);
    
    const response = await fetch(originUrl, {
      method: request.method,
      headers: {
        ...Object.fromEntries(request.headers),
        'Host': new URL(origin).hostname,
        'X-Forwarded-Host': url.hostname,
      },
      body: request.method !== 'GET' ? request.body : undefined,
    });
    
    const newResponse = new Response(response.body, response);
    newResponse.headers.set('X-Served-By', useGreen ? 'green-nextjs' : 'blue-wordpress');
    
    return newResponse;
  }
};

La belleza de este enfoque: cambiar de WordPress a Next.js es una sola escritura en el almacén KV. Sin cambios de DNS. Sin propagación. Instantáneo.

# Cambiar a green (Next.js)
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "green"

# Rollback a blue (WordPress) si algo sale mal
curl -X PUT "https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/active_environment" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  --data "blue"

Enrutamiento Canary

No cambies el 100% del tráfico de una vez. Empieza con un canary:

  1. 1% del tráfico a Next.js — Monitorea errores durante 1 hora
  2. 10% del tráfico — Monitorea durante 2 horas
  3. 50% del tráfico — Monitorea durante 4 horas
  4. 100% del tráfico — Monitorea durante 24 horas
  5. Descomisionar WordPress — Después de 1 semana al 100%

Fase 5: Estrategia de Cambio de DNS

Si no puedes usar Cloudflare Workers (o una solución de enrutamiento en el borde similar), necesitarás gestionar el cambio a nivel de DNS. Esto es más complicado debido a la propagación del TTL.

Preparación del DNS Antes del Corte

Al menos 48 horas antes del corte:

  1. Reduce el TTL de tu DNS a 60 segundos (desde el típico 3600 o 86400)
  2. Espera a que expire el TTL anterior
  3. Verifica que el TTL bajo esté activo: dig yoursite.com +short debe mostrar TTL ~60
# Verificar el TTL actual
dig yoursite.com A +noall +answer
# Debe mostrar algo como:
# yoursite.com.  60  IN  A  76.76.21.21

El Cambio de DNS

Con un TTL de 60 segundos, actualizar tu registro A/CNAME de DNS significa propagación global en aproximadamente 5-10 minutos (algunos resolvers ignoran los TTL bajos, pero la mayoría los respeta en 2025).

# Si te mueves a Vercel
# Actualiza CNAME para apuntar a cname.vercel-dns.com
# O actualiza los registros A a las direcciones IP de Vercel: 76.76.21.21

El Problema: El Tiempo del Certificado SSL

Aquí hay algo que afecta a la gente. Cuando cambias el DNS a Vercel (o cualquier nuevo host), el certificado SSL para tu dominio debe aprovisionarse en el nuevo host antes del cambio. De lo contrario, hay una ventana donde HTTPS no funciona.

En Vercel, agrega tu dominio personalizado en la configuración del proyecto antes del cambio de DNS. Vercel intentará aprovisionar el certificado mediante un desafío HTTP-01 o DNS-01. Si usas DNS con proxy de Cloudflare, es posible que necesites deshabilitar temporalmente el proxy (nube naranja → nube gris) para que el aprovisionamiento del certificado funcione.

Fase 6: La Lista de Verificación del Corte

Esta es la lista de verificación que usamos el día del corte. Imprímela. Marca cada casilla.

Pre-Corte (T-24 horas)

  • Todo el contenido sincronizado y verificado en el nuevo CMS
  • Validación de paridad de URLs pasando al 100%
  • Certificado SSL aprovisionado en el nuevo host
  • TTL de DNS confirmado en 60 segundos
  • Procedimiento de rollback documentado y probado
  • Todas las redirecciones del plugin SEO de WordPress migradas a next.config.js o middleware de borde
  • robots.txt y sitemap.xml generándose correctamente en Next.js
  • Seguimiento de analíticas verificado en Next.js (GA4, GTM, etc.)
  • Envíos de formularios probados de extremo a extremo
  • Feed RSS validado
  • Etiquetas OpenGraph verificadas en páginas clave
  • Página 404 probada

Corte (T-0)

  • Notificar a las partes interesadas: "Migración iniciando"
  • Establecer canary al 1% → monitorear 30 min
  • Aumentar al 10% → monitorear 1 hora
  • Verificar Google Search Console en busca de errores de rastreo
  • Aumentar al 50% → monitorear 2 horas
  • Aumentar al 100%
  • Enviar sitemap actualizado a Google Search Console
  • Verificar que Googlebot puede acceder a todas las páginas críticas (usa la herramienta de Inspección de URLs)
  • Probar todos los formularios, flujos de comercio electrónico, flujos de autenticación

Post-Corte (T+24 horas)

  • Monitorear Core Web Vitals en el dashboard de CrUX
  • Revisar Google Search Console en busca de problemas de cobertura
  • Verificar que todos los datos de analíticas fluyen correctamente
  • El origen de WordPress aún ejecutándose (mantener por un mínimo de 2 semanas)
  • Ejecutar un rastreo completo del sitio con Screaming Frog contra el nuevo sitio

Fase 7: Monitoreo Post-Corte y Rollback

Qué Monitorear

Configura dashboards en tu herramienta de monitoreo (usamos una combinación de Vercel Analytics, Datadog y Google Search Console) rastreando:

  • Tasas de error: ¿Alguna respuesta 5xx? ¿Algún aumento en 4xx?
  • Tiempos de respuesta: Latencia P50, P95, P99
  • Core Web Vitals: LCP, FID/INP, CLS
  • Search Console: Estadísticas de rastreo, informe de cobertura, estado de indexación
  • Métricas de negocio: Tasa de conversión, tasa de rebote, páginas/sesión

El Plan de Rollback

Tu rollback necesita ser un único comando. No un proceso de 15 pasos. Un comando.

Con el enfoque de Cloudflare Worker:

# Rollback con un comando
wrangler kv:key put --namespace-id=$NS_ID "active_environment" "blue"

Con cambio basado en DNS:

# Rollback de DNS pre-scriptado via API de Cloudflare
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/{record_id}" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"content": "old-wordpress-ip-address"}'

Mantén WordPress ejecutándose durante al menos 2 semanas después del corte. No seas un héroe. El momento en que apagues WordPress es cuando descubres una página que olvidaste migrar.

Modos de Fallo Comunes y Cómo Prevenirlos

Después de hacer esto decenas de veces, estos son los fallos que veo con más frecuencia:

1. Plugins de WordPress olvidados con rutas frontend Ese plugin de formulario de contacto crea endpoints /wp-json/contact-form-7/. Esa instalación de WooCommerce tiene /my-account/ y /cart/. Mapea el footprint de URLs de cada plugin.

2. URLs wp-content codificadas en el contenido Las imágenes en tu contenido hacen referencia a /wp-content/uploads/. Necesitas redirecciones o una regla de reescritura que las apunte a tu nuevo CDN de activos.

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/wp-content/uploads/:path*',
        destination: 'https://cdn.yoursite.com/uploads/:path*',
        permanent: true,
      },
    ];
  },
};

3. Olvidar los sitemaps XML Google Search Console apunta a /sitemap.xml. Tu app Next.js necesita generar uno. Usa next-sitemap o constrúyelo en los manejadores de rutas de tu app.

4. Problemas de autenticación y sesión Si tu sitio WordPress tiene usuarios con sesión iniciada, sus cookies no funcionarán en el nuevo stack. Planifica la migración de usuarios por separado.

5. Envenenamiento de caché del CDN durante la transición Si Cloudflare está almacenando en caché las respuestas, podrías servir páginas obsoletas de WordPress después de cambiar a Next.js. Purga la caché del CDN inmediatamente después del cambio.

# Purgar toda la caché de Cloudflare después del cambio
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache" \
  -H "Authorization: Bearer ${CF_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything": true}'

Si estás planeando una migración y quieres que expertos se encarguen del trabajo pesado, consulta nuestra página de precios o contáctanos directamente. Hemos hecho esto suficientes veces como para que nuestros planes de acción estén curtidos de la manera correcta.

Para sitios construidos con otros frameworks, también realizamos migraciones basadas en Astro que pueden ser incluso más rápidas para sitios con mucho contenido que no necesitan mucha interactividad.

Preguntas Frecuentes

¿Cuánto tiempo suele tardar una migración de WordPress a Next.js? Para un sitio de complejidad media (100-500 páginas, tipos de publicaciones personalizadas, algo de funcionalidad dinámica), planifica entre 8 y 12 semanas de principio a fin. La fase de migración de contenido y ejecución en paralelo toma de 3 a 4 semanas sola. El corte en sí, si has hecho el trabajo de preparación, requiere unas 4 horas de trabajo activo. No dejes que nadie te diga que esto se puede hacer en un fin de semana.

¿Puedo usar WordPress como CMS headless en lugar de migrar el contenido? Absolutamente, y para algunos equipos esta es la decisión correcta. Mantienes WordPress como tu CMS, usas la REST API o WPGraphQL para alimentar contenido a Next.js, y solo migras el frontend. Esto reduce significativamente el cronograma de migración porque omites completamente la fase de migración de contenido. La contrapartida es que sigues manteniendo una instalación de WordPress con toda su carga de actualizaciones y seguridad.

¿Qué pasa con mis posiciones SEO durante una migración? Con una migración adecuada de tiempo de inactividad cero, tus posiciones deberían mantenerse estables. John Mueller de Google ha confirmado que cambiar tu CMS no debería afectar las posiciones si el contenido, las URLs y los elementos de SEO técnico permanecen equivalentes. Los mayores riesgos son las URLs rotas (que generan 404s), las estructuras de enlaces internos modificadas y la velocidad de página degradada. Nuestro plan de acción aborda específicamente los tres.

¿Cómo manejo los formularios de WordPress en Next.js? Tienes varias opciones: usar un servicio de formularios como Formspree o Basin, construir rutas de API en Next.js que gestionen los envíos directamente, o usar las funciones de formulario de tu CMS headless (Sanity no tiene formularios nativos, pero Payload CMS sí). Para formularios complejos con lógica condicional, normalmente construimos rutas de API personalizadas y usamos React Hook Form en el frontend.

¿Debo usar Vercel, Netlify o self-hosting para el despliegue de Next.js? Para la mayoría de los equipos, Vercel es el camino de menor resistencia para Next.js. Está construido por el mismo equipo, y características como ISR, middleware y optimización de imágenes funcionan mejor allí. El plan Pro de Vercel a $20/usuario/mes cubre la mayoría de las necesidades de producción. Si tienes requisitos de cumplimiento específicos o necesitas quedarte en AWS, puedes hacer self-hosting con el modo de salida standalone. Netlify también funciona, pero históricamente ha ido por detrás en soporte de características de Next.js.

¿Cuál es la diferencia entre el despliegue blue-green y el despliegue canary? Blue-green es binario: todo el tráfico va al sistema antiguo (azul) o al nuevo (verde). El despliegue canary transfiere gradualmente un porcentaje del tráfico del antiguo al nuevo. En la práctica, combinamos ambos. Configuramos infraestructura blue-green (dos entornos completos) pero usamos enrutamiento basado en porcentajes al estilo canary durante el cambio real. Esto te da la seguridad de un despliegue gradual con la simplicidad de tener solo dos entornos que gestionar.

¿Cómo migro las redirecciones de WordPress a Next.js? Exporta tus redirecciones desde el plugin de WordPress que estés usando (Redirection, Yoast, RankMath). Conviértelas al formato de redirección de Next.js en next.config.js. Para sitios con cientos de redirecciones, usa middleware — es más eficiente y puede manejar coincidencias de patrones. Ten en cuenta que las redirecciones de next.config.js tienen un límite práctico de aproximadamente 1.000 entradas en Vercel antes de que los tiempos de build se vean afectados.

¿Puedo hacer rollback a WordPress si algo sale mal después del corte? Sí, y esto es innegociable. Mantén tu instancia de WordPress ejecutándose durante al menos 2 semanas después del corte. Con el enfoque de Cloudflare Worker descrito en este artículo, el rollback es una única llamada a la API que tiene efecto globalmente en segundos. Con el cambio basado en DNS, el rollback tarda entre 1 y 10 minutos dependiendo de la propagación del TTL. Nunca descomisiones el sistema antiguo hasta que estés seguro de que el nuevo es estable.