Migração passo a passo

A forma segura de migrar é gradual. Seu site público continua rodando sem alterações enquanto você conecta e confere cada parte em Development.

As regras que mantêm tudo seguro

• O design não pode mudar. Cada página deve ficar idêntica, quer o Atlas tenha conteúdo para ela ou não.
• O fallback é obrigatório. Se o Atlas estiver inacessível ou não tiver nada publicado para uma página, o site serve o conteúdo embutido nele.
• Texto, nunca HTML. Os valores do CMS são renderizados como texto ou por meio dos seus componentes.
• Development primeiro. Nada chega ao Production até que um release passe nas verificações e uma pessoa o aprove.

Etapa 1: conectar uma página (cerca de um dia)

1. Crie o site no Studio e escreva um rascunho de contrato mínimo com um tipo de página.
2. Siga Conectar um site Next.js.
3. Publique essa página em Development e compare-a com a página no ar.

Concluído quando a página é renderizada a partir do Atlas, fica igual e continua funcionando com o Atlas desligado.

Etapa 2: modelar o site inteiro

1. Liste todas as rotas que o site serve e associe cada uma a um tipo de página.
2. Escreva o bundle do contrato: componentes com campos tipados, tipos de página com suas regiões, coleções, perfis de mídia e os globais de cabeçalho e rodapé. Mantenha-o no seu repositório como atlas/contract.bundle.json.
3. Valide e proponha o bundle. Um administrador do site o ativa no Studio (Site setup).
4. Refatore cada componente de página para que as seções do Atlas definam a ordem e o conteúdo, com os dados embutidos como fallback.

Concluído quando o Studio mostra o site In sync with the active contract.

Etapa 3: migrar o conteúdo e as imagens

1. Envie as imagens com o perfil de mídia correto. Nunca estique nem amplie; liste as que não se encaixam.
2. Crie entradas para cada item repetitivo, referenciando as imagens pelo id do asset, com texto alternativo.
3. Preencha os globais de cabeçalho e rodapé com o conteúdo atual.
4. Crie uma página para cada rota a partir do tipo de página dela e ajuste as seções até que o rascunho fique igual à página atual.
5. Crie rascunhos das traduções e peça a um falante nativo que as revise.

Um agente de codificação com IA conectado por MCP pode fazer a maior parte disso como rascunhos. Uma pessoa confere cada página com Preview on website e a publica.

Etapa 4: atualização, SEO e redirecionamentos

• Adicione o receptor de webhook para que a publicação atualize o site em segundos.
• Leia os títulos de SEO, as descrições e o noindex da Delivery API e gere o sitemap a partir de /routes.
• Carregue /redirects e aplique-os, para que as URLs antigas mantenham suas posições.

Etapa 5: entrar no ar

1. Treine os editores no Studio, nos rascunhos, na pré-visualização e na publicação.
2. Gere um release. O Atlas verifica se o contrato está sincronizado, se não há problemas de publicação, se o site está saudável e se há um backup recente.
3. Uma pessoa com permissão de aprovação o aprova. Um administrador do site ativa o Production e você cria um token de entrega de Production.
4. Faça o deploy do seu site com o token de Production. Mantenha o fallback no lugar.

O que o Production serve

O Production serve o conteúdo, os formulários, os chatbots e as configurações de busca do seu release no ar. A pré-visualização continua exclusiva do Development. Siga Entrar no ar para os passos exatos.

Revertendo

• Um erro de conteúdo: reverta para uma revisão anterior ou para um release de Production anterior.
• Um erro de código: faça o redeploy do build anterior do seu site, como você faz hoje.
• Atlas indisponível: o fallback serve o conteúdo embutido até que o Atlas volte.