Migrei mais de uma dúzia de sites WordPress para Next.js em produção, e vou contar algo que talvez o surpreenda: a migração real do código não é a parte difícil. É o cutover. Aquele momento aterrorizante quando você muda a chave e reza para nada quebrar. A boa notícia? Com o roteiro certo, você pode tornar esse momento entediante. E em operações, entediante é exatamente o que você quer.

Este é o roteiro que usamos na Social Animal para cutovers em produção. Não é teórico — foi construído a partir de migrações reais onde receita real estava em jogo. Estamos falando de sites de e-commerce fazendo $50K/dia, editoras de conteúdo com milhões de visualizações mensais, e sites de marketing SaaS onde 5 minutos de downtime significa que o CEO está ligando no seu celular.

Índice

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

Por que Zero Downtime Importa Mais do que Você Pensa

Vamos colocar alguns números nisso. Pesquisa do Google de 2024 mostra que um atraso de 1 segundo no carregamento da página custa aproximadamente 7% em conversões. Agora imagine seu site está... desaparecido. Mesmo por apenas 5 minutos.

Aqui está o que realmente está em jogo:

Duração do Downtime Impacto de Receita (para site de $10K/dia) Impacto de SEO Impacto na Confiança do Usuário
5 minutos ~$35 perdidos Mínimo se isolado Baixo
30 minutos ~$208 perdidos Googlebot pode notar Moderado
2 horas ~$833 perdidos Erros de rastreamento no GSC Alto
24 horas $10.000+ perdidos Risco de desindexação Severo

Mas não é apenas receita. Mecanismos de busca estão constantemente rastreando. Se o Googlebot atinge seu site durante uma migração e recebe erros 500, essas URLs podem sair do índice em poucas horas. Já vi sites perderem 40% do tráfego orgânico porque alguém fez uma "migração rápida" durante o almoço.

O objetivo não é apenas zero downtime. É zero mudança visível para usuários e crawlers durante a transição.

Visão Geral da Arquitetura de Migração

Antes de entrarmos nas fases, vamos ver a arquitetura que estamos visando. O padrão fundamental é executar ambos os sistemas em paralelo, depois mudar o tráfego atomicamente.

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

A percepção chave: você não está apenas migrando um frontend. Você está migrando a camada de conteúdo, a camada de renderização e a camada de entrega — e cada uma pode ser migrada independentemente.

Fase 1: Migração de Conteúdo e Camada de API

É aqui que a maioria das equipes começa errado. Elas tentam construir o frontend Next.js primeiro e depois descobrir o conteúdo depois. Não faça isso. Comece com o conteúdo.

Escolhendo Seu CMS Headless

Seu conteúdo WordPress precisa de uma nova casa. A escolha importa muito para a complexidade da migração:

CMS Facilidade de Migração do WP Sincronização em Tempo Real Possível Preço (2025) Melhor Para
Sanity Alta (conteúdo estruturado mapeia bem) Sim, via webhooks Camada gratuita, depois $99/mês Modelos de conteúdo complexos
Contentful Média (mapeamento de campo obrigatório) Sim $300/mês para Equipe Equipes Enterprise
Strapi Alta (modelo baseado em DB similar) Sim Auto-hospedado gratuito, Cloud a partir de $29/mês Controle total
WordPress REST API N/A (manter como headless) Já sincronizado Custos de hospedagem existentes Vitórias rápidas
Payload CMS Alta Sim Auto-hospedado gratuito Equipes orientadas por desenvolvedor

Cobrimos a seleção de CMS headless em profundidade em nossa página de capacidades de desenvolvimento de CMS headless, mas em resumo: para a maioria das migrações WordPress, Sanity ou Payload CMS oferece o melhor caminho de migração.

Configurando Sincronização de Conteúdo

Aqui está a parte crítica: durante a fase de execução paralela, o conteúdo precisa existir em ambos os sistemas. Você tem duas estratégias:

Estratégia A: Migração única + congelamento Migre todo o conteúdo para o novo CMS, depois congele a edição do WordPress. Isso funciona para sites pequenos, mas falha quando os editores precisam continuar publicando.

Estratégia B: Sincronização contínua (recomendado) Configure um pipeline de sincronização que replica mudanças do WordPress para seu novo CMS em tempo quase real.

// Exemplo: manipulador de webhook do WordPress que sincroniza para Sanity
// Isso é executado como uma função 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 });
  }
}

Você também precisará do lado WordPress. Usamos um plugin simples que dispara em 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);

Execute essa sincronização por pelo menos 2 semanas antes do cutover. Você quer pegar casos extremos — shortcodes estranhos, tipos de post personalizados, campos ACF que não mapeiam perfeitamente.

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

Fase 2: Construindo a Aplicação Next.js

Não vou cobrir o processo completo de construção do Next.js aqui — isso merece seu próprio artigo (e temos experiência profunda em desenvolvimento Next.js). Mas existem preocupações específicas de migração que importam para zero downtime.

URL Parity É Não-Negociável

Toda e qualquer URL que existe no seu site WordPress deve resolver para o mesmo conteúdo no seu site Next.js. Cada. Uma.

Isso significa:

  • /blog/my-post-slug/ deve funcionar (incluindo a barra final se o WordPress usou uma)
  • /category/technology/ deve funcionar ou redirecionar
  • /wp-content/uploads/2024/03/image.jpg deve redirecionar para seu novo CDN de imagens
  • /feed/ ainda deve retornar RSS/Atom válido
  • URLs de paginação como /blog/page/2/ devem funcionar

Construa um script de auditoria de URL cedo:

# Exporte todas as URLs do 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

# Também pegue redirecionamentos de qualquer plugin SEO
wp db query "SELECT * FROM wp_redirection_items" --format=csv > redirects.csv

Depois valide-as contra sua construção 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}`);
  }
}

Baseline de Desempenho

Antes do cutover, seu site Next.js precisa ser pelo menos tão rápido quanto o WordPress. Parece óbvio, mas já vi equipes ficarem tão animadas com a nova stack que esquecem de comparar.

Capture Core Web Vitals do seu site WordPress usando dados CrUX ou Lighthouse CI, depois combine ou supere. Se seu site WordPress tem LCP de 2,1s e seu site Next.js está em 3,4s, você não está pronto.

Fase 3: Configuração de Implantação Paralela

Agora chegamos à infraestrutura que torna zero downtime possível.

A Execução Paralela

Ambos os sistemas são executados simultaneamente, servindo tráfego real. Mas apenas um é "primário" em qualquer momento.

Para Next.js no Vercel (nossa configuração mais comum), você implantará seu aplicativo Next.js para um domínio personalizado como next.yoursite.com ou use a URL de preview do Vercel. Seu site WordPress continua rodando em yoursite.com.

# Se você estiver usando Nginx como um proxy reverso
# Esta é a configuração de execução 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 execução paralela: espelhe tráfego para ambos,
    # mas sirva respostas do WordPress
    location / {
        mirror /mirror;
        proxy_pass http://wordpress;
    }

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

Essa configuração de espelho envia cada solicitação para ambos os backends, mas apenas retorna a resposta do WordPress. Você obtém tráfego real atingindo seu aplicativo Next.js sem os usuários verem. Verifique seus logs do Next.js para erros, 404s e respostas lentas.

Monitoramento Sintético

Configure monitoramento que valida continuamente que ambos os sistemas retornam conteúdo equivalente:

// canary-check.mjs — executa a 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}`);
  }

  // Compare title tags as a content parity check
  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}`);
  }
}

Execute isso por um mínimo de 1 semana com zero alertas antes de prosseguir para o cutover.

Fase 4: Configuração de Implantação Blue-Green

Implantação blue-green significa ter dois ambientes de produção idênticos — blue (WordPress atual) e green (novo Next.js) — e alternar entre eles atomicamente.

Usando Cloudflare Workers para Roteamento de Tráfego

Esta é nossa abordagem preferida porque oferece comutação de tráfego instantânea e global sem atraso de propagação de DNS.

// Cloudflare Worker para roteamento blue-green
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Leia o ambiente ativo do KV store
    const activeEnv = await env.CONFIG.get('active_environment') || 'blue';
    
    // Opcional: roteamento de canário baseado em percentual
    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;
  }
};

A beleza dessa abordagem: alternar de WordPress para Next.js é uma única escrita no KV store. Nenhuma mudança de DNS. Nenhuma propagação. Instantâneo.

# Mude para 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"

# Reverta para blue (WordPress) se algo der errado
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"

Roteamento de Canário

Não jogue 100% do tráfego de uma vez. Comece com um canário:

  1. 1% de tráfego para Next.js — Monitore erros por 1 hora
  2. 10% de tráfego — Monitore por 2 horas
  3. 50% de tráfego — Monitore por 4 horas
  4. 100% de tráfego — Monitore por 24 horas
  5. Descomissione WordPress — Após 1 semana em 100%

Fase 5: Estratégia de Switchover de DNS

Se você não pode usar Cloudflare Workers (ou uma solução de roteamento de borda similar), precisará lidar com o switchover em nível de DNS. Isso é mais complicado por causa da propagação de TTL.

Preparação de DNS Pré-Cutover

Pelo menos 48 horas antes do cutover:

  1. Baixe seu TTL de DNS para 60 segundos (do típico 3600 ou 86400)
  2. Aguarde o TTL antigo expirar
  3. Verifique se o TTL baixo está ativo: dig yoursite.com +short deve mostrar TTL ~60
# Verifique o TTL atual
dig yoursite.com A +noall +answer
# Deve mostrar algo como:
# yoursite.com.  60  IN  A  76.76.21.21

O Switch de DNS

Com um TTL de 60 segundos, atualizar seu registro DNS A/CNAME significa propagação global em cerca de 5-10 minutos (alguns resolvers ignoram TTLs baixos, mas a maioria respeita em 2025).

# Se movendo para Vercel
# Atualize CNAME para apontar para cname.vercel-dns.com
# Ou atualize registros A para IPs do Vercel: 76.76.21.21

A Pegadilha: Timing do Certificado SSL

Aqui está algo que pega as pessoas. Quando você muda o DNS para Vercel (ou qualquer novo host), o certificado SSL do seu domínio precisa ser provisionado no novo host antes do switch. Caso contrário, você obtém uma janela onde HTTPS não funciona.

No Vercel, adicione seu domínio personalizado nas configurações do projeto antes do switch de DNS. O Vercel tentará provisionar o cert via desafio HTTP-01 ou DNS-01. Se você estiver usando DNS proxied do Cloudflare, pode precisar desabilitar temporariamente o proxy (nuvem laranja → nuvem cinza) para que o provisionamento do cert funcione.

Fase 6: O Checklist de Cutover

Este é o checklist que usamos no dia do cutover. Imprima. Marque cada caixa.

Pré-Cutover (T-24 horas)

  • Todo conteúdo sincronizado e verificado no novo CMS
  • Validação de URL parity passando 100%
  • Certificado SSL provisionado no novo host
  • TTL de DNS confirmado em 60 segundos
  • Procedimento de rollback documentado e testado
  • Todos os redirecionamentos do plugin SEO do WordPress migrados para next.config.js ou middleware de borda
  • robots.txt e sitemap.xml gerando corretamente no Next.js
  • Rastreamento de análise verificado no Next.js (GA4, GTM, etc.)
  • Envios de formulário testados end-to-end
  • Feed RSS validado
  • Tags OpenGraph verificadas nas páginas-chave
  • Página 404 testada

Cutover (T-0)

  • Notifique stakeholders: "Migração iniciando"
  • Defina canário para 1% → monitore 30 min
  • Aumente para 10% → monitore 1 hora
  • Verifique Google Search Console para erros de rastreamento
  • Aumente para 50% → monitore 2 horas
  • Aumente para 100%
  • Envie sitemap atualizado para Google Search Console
  • Verifique se o Googlebot pode acessar todas as páginas críticas (use ferramenta de Inspeção de URL)
  • Teste todos os formulários, fluxos de e-commerce, fluxos de autenticação

Pós-Cutover (T+24 horas)

  • Monitore Core Web Vitals no painel de CrUX
  • Verifique Google Search Console para problemas de cobertura
  • Verifique se todos os dados de análise fluem corretamente
  • Origem WordPress ainda rodando (manter por mínimo 2 semanas)
  • Execute rastreamento de site completo com Screaming Frog contra novo site

Fase 7: Monitoramento Pós-Cutover e Rollback

O que Monitorar

Configure dashboards em sua ferramenta de monitoramento (usamos uma combinação de Vercel Analytics, Datadog e Google Search Console) rastreando:

  • Taxas de erro: Alguma resposta 5xx? Algum aumento em 4xx?
  • Tempos de resposta: Latência P50, P95, P99
  • Core Web Vitals: LCP, FID/INP, CLS
  • Search Console: Estatísticas de rastreamento, relatório de cobertura, status de indexação
  • Métricas de negócio: Taxa de conversão, taxa de rejeição, páginas/sessão

O Plano de Rollback

Seu rollback precisa ser um único comando. Não um processo de 15 passos. Um comando.

Com a abordagem Cloudflare Worker:

# Rollback de um único comando
wrangler kv:key put --namespace-id=$NS_ID "active_environment" "blue"

Com comutação baseada em DNS:

# Rollback de DNS pré-escrito via API do 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"}'

Mantenha WordPress rodando por pelo menos 2 semanas após o cutover. Não seja um herói. O momento em que você desligar WordPress é o momento em que descobre uma página que esqueceu de migrar.

Modos de Falha Comuns e Como Preveni-los

Depois de fazer isso dezenas de vezes, aqui estão as falhas que vejo com mais frequência:

1. Plugins WordPress esquecidos com rotas de frontend Esse plugin de formulário de contato cria endpoints /wp-json/contact-form-7/. Essa instalação WooCommerce tem /my-account/ e /cart/. Mapeie o footprint de URL de todo plugin.

2. URLs wp-content codificadas em conteúdo Imagens no seu conteúdo referenciam /wp-content/uploads/. Você precisa de redirecionamentos ou uma regra de reescrita apontando essas para seu novo CDN de ativos.

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

3. Esquecer de sitemaps XML Google Search Console está apontado para /sitemap.xml. Seu aplicativo Next.js precisa gerar um. Use next-sitemap ou construa-o nos manipuladores de rota do seu aplicativo.

4. Problemas de autenticação e sessão Se seu site WordPress tem usuários conectados, seus cookies não funcionarão na nova stack. Planeje a migração de usuário separadamente.

5. Envenenamento de cache de CDN durante transição Se o Cloudflare está armazenando em cache respostas, você pode servir páginas WordPress obsoletas após alternar para Next.js. Limpe o cache do CDN imediatamente após alternar.

# Limpe todo o cache do Cloudflare após alternar
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}'

Se você está planejando uma migração e quer especialistas para lidar com o pesado, verifique nossa página de preços ou entre em contato diretamente. Fizemos isso o suficiente para que nossos playbooks sejam cicatrizados de todas as maneiras certas.

Para sites construídos com outros frameworks, também fazemos migrações baseadas em Astro que podem ser ainda mais rápidas para sites pesados em conteúdo que não precisam de muita interatividade.

FAQ

Quanto tempo típicamente leva uma migração de WordPress para Next.js?

Para um site de complexidade média (100-500 páginas, tipos de post personalizados, alguma funcionalidade dinâmica), planeje 8-12 semanas end-to-end. A fase de migração de conteúdo e execução paralela leva 3-4 semanas sozinha. O cutover real, se você fez o trabalho de preparação, leva cerca de 4 horas de trabalho ativo. Não deixe ninguém contar que isso pode ser feito em um fim de semana.

Posso usar WordPress como um CMS headless em vez de migrar conteúdo?

Absolutamente, e para alguns times esta é a chamada correta. Você mantém WordPress como seu CMS, usa a REST API ou WPGraphQL para alimentar conteúdo para Next.js, e apenas migra o frontend. Isso reduz significativamente a linha do tempo de migração porque você pula a fase de migração de conteúdo completamente. O tradeoff é que você ainda está mantendo uma instalação WordPress com toda sua sobrecarga de atualização e segurança.

O que acontece com meus rankings de SEO durante uma migração?

Com uma migração apropriada de zero downtime, seus rankings devem permanecer estáveis. John Mueller do Google confirmou que mudar seu CMS não deve afetar rankings se o conteúdo, URLs e elementos de SEO técnico permanecerem equivalentes. Os maiores riscos são URLs quebradas (que causam 404s), estruturas de ligação interna alteradas e velocidade de página degradada. Nosso playbook especificamente aborda os três.

Como lidar com formulários WordPress no Next.js?

Você tem várias opções: use um serviço de formulário como Formspree ou Basin, construa rotas de API em Next.js que lidam com envios diretamente, ou use recursos de formulário do seu CMS headless (Sanity não tem formulários nativos, mas Payload CMS tem). Para formulários complexos com lógica condicional, tipicamente construímos rotas de API personalizadas e usamos React Hook Form no frontend.

Devo usar Vercel, Netlify ou auto-hospedagem para a implantação do Next.js?

Para a maioria das equipes, Vercel é o caminho de menor resistência para Next.js. É construído pela mesma equipe, e recursos como ISR, middleware e otimização de imagem funcionam melhor lá. O plano Pro do Vercel em $20/usuário/mês cobre a maioria das necessidades de produção. Se você tem requisitos de conformidade específicos ou precisa ficar no AWS, você pode auto-hospedar com o modo de saída standalone. Netlify também funciona, mas historicamente ficou para trás no suporte de recursos do Next.js.

Qual é a diferença entre implantação blue-green e implantação de canário?

Implantação blue-green é binária: todo tráfego vai para qualquer sistema antigo (blue) ou novo (green). Implantação de canário alterna gradualmente um percentual de tráfego de antigo para novo. Na prática, nós combinamos ambos. Configuramos infraestrutura blue-green (dois ambientes completos) mas usamos roteamento baseado em percentual estilo canário durante o switchover real. Isso oferece a segurança de rollout gradual com a simplicidade de ter apenas dois ambientes para gerenciar.

Como migro redirecionamentos do WordPress para Next.js?

Exporte seus redirecionamentos de qualquer plugin do WordPress que você esteja usando (Redirection, Yoast, RankMath). Converta-os para formato de redirecionamento Next.js em next.config.js. Para sites com centenas de redirecionamentos, use middleware — é mais performático e pode lidar com correspondência de padrão. Esteja ciente que redirecionamentos de next.config.js têm um limite prático de cerca de 1.000 entradas no Vercel antes que os tempos de construção sofram.

Posso voltar para WordPress se algo der errado após o cutover?

Sim, e isso é não-negociável. Mantenha sua instância WordPress rodando por pelo menos 2 semanas após o cutover. Com a abordagem Cloudflare Worker descrita neste artigo, rollback é uma única chamada de API que entra em efeito globalmente em segundos. Com comutação baseada em DNS, rollback leva 1-10 minutos dependendo da propagação de TTL. Nunca descomissione o sistema antigo até estar confiante que o novo está estável.