Checklist de migração

Use esta lista em uma sessão de planejamento com quem construiu o seu site atual. Um “não” não é, por si só, um impedimento. Ele mostra onde está o trabalho.

1. Tecnologia

• O site é Next.js App Router, ou a equipe aceita o esforço extra de outro framework de servidor. (Por quê)
• O conteúdo pode ser buscado em código de servidor, e o token de entrega pode ficar em uma variável de ambiente do servidor.
• O site pode manter um fallback embutido para cada página migrada, de modo que continue funcionando se o Atlas estiver inacessível.
• A equipe consegue adicionar uma rota para a pré-visualização, uma para webhooks e um relatório de build na inicialização.

2. Design e componentes

• As páginas são feitas de seções reutilizáveis (hero, cards, FAQ, call to action). Páginas únicas ainda podem ser um componente com campos.
• Você listou todos os tipos de página: página inicial, produto, artigo, landing page, jurídico e assim por diante.
• Para cada seção, você sabe quais partes os editores alteram (texto, imagens, links, listas) e quais ficam fixas no código.
• As partes interativas (calculadoras, configuradores, mapas, animações) continuam no seu código. Os editores só preenchem os textos e as configurações delas.

3. Conteúdo no seu CMS atual

• Você consegue exportar páginas, entradas e imagens: um dump do banco de dados, uma API, CSV ou um agente de IA lendo o site antigo.
• O conteúdo repetitivo (produtos, notícias, equipe, unidades) corresponde a coleções.
• Você listou os campos personalizados e sabe os tipos deles: texto, rich text, número, data, link, imagem, referência, lista.
• Você sabe onde o CMS atual executa código dentro do conteúdo: shortcodes, embeds, blocos de HTML, scripts. Cada um precisa de um componente substituto. Veja Equivalências com o seu CMS atual.
• Você tem uma lista de URLs e redirecionamentos a preservar, para não perder posições nos buscadores.
• Os idiomas e as regras de fallback deles estão claros. Idiomas escritos da direita para a esquerda exigem suporte a dir="rtl" nos seus componentes.

4. Recursos dos quais o seu site depende

Confira cada um no status dos recursos antes de se comprometer:

• Formulários e e-mails de leads: Development e o site no ar (em revisão final antes do lançamento).
• Chatbot: Development e o site no ar (em revisão final antes do lançamento).
• Envio de leads a um CRM ou outro sistema: o envio ao CRM e a Leads API cobrem hoje apenas leads de Development; os leads do site no ar chegam a você por webhooks.
• Analytics: o Atlas conta as visualizações de página por rota, sem cookies, em Development e no site no ar. Mantenha o seu analytics atual.
• Busca no seu site: o Atlas não oferece busca no site. Mantenha a sua ou construa uma a partir da API de entradas.
• E-commerce, checkout, logins de membros: não fazem parte do Atlas. Continuam no seu código ou nos seus serviços atuais.
• Publicação agendada, traduções, redirecionamentos, campos de SEO: compatíveis.

5. Pessoas e aprovações

• Você sabe quem edita, quem revisa e quem aprova os releases de Production.
• Todos que fazem login podem usar o login do Atlas. O login único (SSO) com o seu próprio provedor de identidade não está disponível.
• As áreas jurídica e de segurança leram Segurança e os itens em aberto no FAQ.

Resultado

• Maioria de “sim”: siga a migração passo a passo.
• Vários “não” nas seções 1 a 3: comece com um piloto em um tipo de página.
• Seu site depende de itens da seção 4 que não estão disponíveis: espere, ou mantenha essas partes fora do Atlas por enquanto.