Tu sitio WordPress en producción sirve 80,000 vistas de página al día. Lo has reconstruido en Next.js—capa de datos más limpia, despliegues más rápidos, sin bloat de plugins. Ahora enfrentas el cutover. Esa ventana de cinco minutos cuando el DNS se propaga, las cachés de CDN se invalidan, y tu panel de monitoreo se mantiene verde o se ilumina como un árbol de Navidad. He ejecutado este procedimiento 12 veces en producción. La migración de código nunca es el riesgo. El cutover es. Pero si lo tratas como un despliegue blue-green—entorno antiguo ejecutándose, entorno nuevo caliente, tráfico desplazado gradualmente—transformas un evento de nudillos blancos en una tarea de martes por la tarde. Aquí está el playbook que hizo que nuestros últimos tres cutovers fueran tan sin eventos que el cliente no se dio cuenta de que habíamos ido en vivo hasta que envié la confirmación en Slack.

Este es el playbook que usamos en Social Animal para cutovers en producción. No es teórico—está construido a partir de migraciones reales donde el dinero real estaba en juego. Estamos hablando de sitios de e-commerce que hacen $50K/día, editores de contenido con millones de vistas mensuales, y sitios de marketing SaaS donde 5 minutos de tiempo de inactividad significa que el CEO está llamando a tu teléfono celular.

Tabla de Contenidos

Playbook de Migración WordPress a Next.js sin Tiempo de Inactividad

Por Qué el Tiempo Cero de Inactividad Es Más Importante de Lo Que Crees

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

Aquí está lo que realmente está en riesgo:

Duración del Tiempo de Inactividad Impacto en Ingresos (para sitio de $10K/día) Impacto en 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 es solo ingresos. Los motores de búsqueda están rastreando constantemente. Si Googlebot llega a tu sitio durante una migración y obtiene errores 500, esas URLs pueden desaparecer del índice en horas. He visto sitios perder el 40% de su tráfico orgánico porque alguien hizo una "migración rápida" durante el almuerzo.

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

Descripción General de la Arquitectura de Migración

Antes de entrar en las fases, veamos la arquitectura que estamos buscando. El patrón fundamental es ejecutar ambos sistemas en paralelo, luego desplazar el tráfico de manera atómica.

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

La perspectiva clave: 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 ser migrada independientemente.

Fase 1: Migración de Contenido y Capa API

Aquí es donde la mayoría de equipos comienzan mal. Intentan construir el frontend de Next.js primero y luego descubren el contenido después. No hagas esto. Comienza con el contenido.

Elegir tu CMS Headless

Tu 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 Posible Precios (2026) Mejor Para
Sanity Alta (mapeo de contenido estructurado funciona bien) Sí, vía webhooks Nivel gratuito, luego $99/mes Modelos de contenido complejos
Contentful Media (requiere mapeo de campos) Sí $300/mes para Equipo Equipos empresariales
Strapi Alta (modelo respaldado por BD similar) Sí Auto-hospedado gratuito, Cloud desde $29/mes Control total
API REST de WordPress N/A (mantener como headless) Ya sincronizado Costos de hospedaje existentes Ganancias rápidas
Payload CMS Alta Sí Auto-hospedado gratuito Equipos enfocados en desarrollador

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

Configurar Sincronización de Contenido

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

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

Estrategia B: Sincronización continua (recomendada) Configurar un pipeline de sincronización que replique los cambios de WordPress a tu nuevo CMS en tiempo casi real.

// Ejemplo: controlador de webhook de WordPress que sincroniza a Sanity
// Esto se ejecuta como una función sin servidor (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: '2026-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('Omitido', { 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('Sincronizado', { status: 200 });
  } catch (error) {
    console.error('Sincronización fallida:', error);
    return new Response('Error de sincronización', { status: 500 });
  }
}

También necesitarás el lado de WordPress. Usamos un plugin simple que se dispara 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 cutover. Quieres capturar casos excepcionales—shortcodes raros, tipos de publicación personalizados, campos de ACF que no se asignan limpiamente.

Playbook de Migración de WordPress a Next.js sin Tiempo de Inactividad - arquitectura

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 experiencia profunda en desarrollo de Next.js). Pero hay preocupaciones específicas de migración que importan para tiempo cero de inactividad.

Paridad de URL es No Negociable

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

Esto significa:

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

Construye un script de auditoría de URL temprano:

# Exportar 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 redirecciones de cualquier plugin de SEO
wp db query "SELECT * FROM wp_redirection_items" --format=csv > redirects.csv

Luego valídalas contra tu compilación 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(`ROTA: /${row.post_name}/ → ${res.status}`);
  }
}

Línea Base de Rendimiento

Antes del cutover, tu sitio de Next.js necesita ser al menos tan rápido como WordPress. Suena obvio, pero he visto equipos tan emocionados por el nuevo stack que olvidan hacer benchmark.

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

Fase 3: Configuración de Despliegue Paralelo

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

La Ejecución Paralela

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

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

# Si estás usando Nginx como reverse proxy
# Esta es la configuración de ejecución paralela

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

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

server {
    listen 443 ssl;
    server_name yoursite.com;

    # Durante ejecución paralela: enviar tráfico a ambos,
    # pero servir respuestas desde 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 golpeando tu aplicación de Next.js sin que los usuarios lo vean. Verifica tus registros de Next.js para errores, 404s, y respuestas lentas.

Monitoreo Sintético

Configurar monitoreo que valide continuamente que ambos sistemas devuelven contenido equivalente:

// canary-check.mjs — se ejecuta cada 5 minutos vía 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(`Desajuste de estado en ${path}: WP=${wpRes.status} Next=${nextRes.status}`);
  }

  // Comparar etiquetas de título 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(`Desajuste de título en ${path}`);
  }
}

Ejecuta esto durante un mínimo de 1 semana sin alertas antes de pasar al cutover.

Fase 4: Configuración de Despliegue Blue-Green

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

Usando Cloudflare Workers para Enrutamiento de Tráfico

Este es nuestro enfoque preferido porque te da 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);
    
    // Leer el entorno activo desde KV store
    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 única escritura de KV store. 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"

# Revertir 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 voltees el 100% del tráfico a la vez. Comienza con un canary:

  1. 1% de tráfico a Next.js — Monitorea errores durante 1 hora
  2. 10% de tráfico — Monitorea durante 2 horas
  3. 50% de tráfico — Monitorea durante 4 horas
  4. 100% de tráfico — Monitorea durante 24 horas
  5. Decommisionar 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 similar de enrutamiento en edge), necesitarás manejar el cambio a nivel de DNS. Esto es más complicado debido a la propagación de TTL.

Preparación de DNS Pre-Cutover

Al menos 48 horas antes del cutover:

  1. Bajar tu TTL de DNS a 60 segundos (desde los típicos 3600 o 86400)
  2. Esperar a que el TTL antiguo expire
  3. Verificar que el TTL bajo esté activo: dig yoursite.com +short debe mostrar TTL ~60
# Verificar 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 de DNS A/CNAME significa propagación global en aproximadamente 5-10 minutos (algunos resolvers ignoran TTLs bajos, pero la mayoría los respeta en 2026).

# Si te mueves a Vercel
# Actualizar CNAME para apuntar a cname.vercel-dns.com
# O actualizar registros A a direcciones IP de Vercel: 76.76.21.21

El Truco: Sincronización de Certificado SSL

Aquí hay algo que muerde a las personas. Cuando cambias el DNS a Vercel (o cualquier nuevo host), el certificado SSL para tu dominio necesita ser provisionado en el nuevo host antes del cambio. De lo contrario, obtienes una ventana donde HTTPS no funciona.

En Vercel, añade tu dominio personalizado en la configuración del proyecto antes del cambio de DNS. Vercel intentará provisionar el certificado vía desafío HTTP-01 o DNS-01. Si estás usando DNS de Cloudflare proxied, es posible que tengas que deshabilitar temporalmente el proxy (nube naranja → nube gris) para que el aprovisionamiento del certificado funcione.

Fase 6: Lista de Verificación del Cutover

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

Pre-Cutover (T-24 horas)

  • Todo el contenido sincronizado y verificado en el nuevo CMS
  • Validación de paridad de URL pasando 100%
  • Certificado SSL provisionado en el nuevo host
  • TTL de DNS confirmado en 60 segundos
  • Procedimiento de reversión documentado y probado
  • Todas las redirecciones del plugin de SEO de WordPress migradas a next.config.js o middleware edge
  • robots.txt y sitemap.xml generando correctamente en Next.js
  • Rastreo de análisis verificado en Next.js (GA4, GTM, etc.)
  • Envíos de formulario probados de punta a punta
  • Feed RSS validado
  • Etiquetas OpenGraph verificadas en páginas clave
  • Página 404 probada

Cutover (T-0)

  • Notificar a partes interesadas: "Migración iniciando"
  • Configurar canary a 1% → monitorear 30 min
  • Aumentar a 10% → monitorear 1 hora
  • Verificar Google Search Console para errores de rastreo
  • Aumentar a 50% → monitorear 2 horas
  • Aumentar a 100%
  • Enviar sitemap actualizado a Google Search Console
  • Verificar que Googlebot pueda acceder a todas las páginas críticas (usar herramienta de Inspección de URL)
  • Probar todos los formularios, flujos de e-commerce, flujos de autenticación

Post-Cutover (T+24 horas)

  • Monitorear Core Web Vitals en dashboard de CrUX
  • Verificar Google Search Console para problemas de cobertura
  • Verificar que todos los datos de análisis fluyen correctamente
  • Origen de WordPress aún ejecutándose (mantener durante 2 semanas mínimo)
  • Ejecutar rastreo completo del sitio con Screaming Frog contra sitio nuevo

Fase 7: Monitoreo Post-Cutover y Reversión

Qué Monitorear

Configurar 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 Reversión

Tu reversión necesita ser un único comando. No un proceso de 15 pasos. Un comando.

Con el enfoque de Cloudflare Worker:

# Reversión de un comando
wrangler kv:key put --namespace-id=$NS_ID "active_environment" "blue"

Con cambio basado en DNS:

# Reversión de DNS pre-programada vía 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 cutover. No seas un héroe. El momento en que apagas WordPress es el momento en que descubres una página que olvidaste migrar.

Modos de Fallo Comunes y Cómo Prevenirlos

Después de hacer esto docenas de veces, aquí están los fallos que veo más a menudo:

1. Plugins de WordPress olvidados con rutas de 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 cada huella de URL del plugin.

2. URLs wp-content hardcodeadas en contenido Las imágenes en tu contenido hacen referencia a /wp-content/uploads/. Necesitas redirecciones o una regla de reescritura apuntando estas 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 sobre sitemaps XML Google Search Console está apuntado a /sitemap.xml. Tu aplicación de Next.js necesita generar uno. Usa next-sitemap o constrúyelo en tus controladores de ruta de la app.

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

5. Envenenamiento de caché de CDN durante la transición Si Cloudflare está almacenando en caché respuestas, es posible que sirvas páginas de WordPress obsoletas después de cambiar a Next.js. Purga la caché de CDN inmediatamente después de cambiar.

# Purgar caché completa de Cloudflare después de cambiar
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 manejen el trabajo pesado, consulta nuestra página de precios o contacta directamente. Hemos hecho esto lo suficiente como para que nuestros playbooks estén cicatrizados de todas las maneras correctas.

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

Preguntas Frecuentes

¿Cuánto tiempo toma típicamente una migración de WordPress a Next.js? Para un sitio de complejidad media (100-500 páginas, tipos de publicación personalizados, algo de funcionalidad dinámica), plan para 8-12 semanas de punta a punta. La fase de migración de contenido y ejecución paralela toma 3-4 semanas sola. El cutover real, si has hecho el trabajo preparatorio, toma aproximadamente 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 contenido? Absolutamente, y para algunos equipos este es el camino correcto. Mantienes WordPress como tu CMS, usas la API REST o WPGraphQL para alimentar contenido a Next.js, y solo migras el frontend. Esto reduce significativamente la cronología de migración porque saltas la fase de migración de contenido por completo. El tradeoff es que aún estás manteniendo una instalación de WordPress con toda su actualización y sobrecarga de seguridad.

¿Qué sucede con mis clasificaciones de SEO durante una migración? Con una migración de tiempo cero de inactividad adecuada, tus clasificaciones deben permanecer estables. John Mueller de Google ha confirmado que cambiar tu CMS no debería afectar las clasificaciones si el contenido, las URLs, y los elementos de SEO técnico permanecen equivalentes. Los riesgos más grandes son URLs rotas (que causan 404s), estructuras de vinculación interna cambiadas, y velocidad de página degradada. Nuestro playbook específicamente aborda los tres.

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

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

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

¿Cómo migro redirecciones de WordPress a Next.js? Exporta tus redirecciones de cualquier 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 en su lugar—es más performante y puede manejar coincidencia 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 construcción sufran.

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