Migrar de hospedagem n\u00e3o exige tirar o site do ar. O princ\u00edpio t\u00e9cnico \u00e9 direto: o servidor antigo permanece ativo enquanto o novo ambiente \u00e9 montado e testado em paralelo, e s\u00f3 depois de tudo validado o DNS \u00e9 apontado para o novo destino.<\/p>\n\n\n\n
Migra\u00e7\u00f5es mal executadas j\u00e1 derrubaram o tr\u00e1fego org\u00e2nico em at\u00e9 30%, segundo levantamento da Swell<\/a> com dados do setor de e-commerce. Na pr\u00e1tica, isso raramente tem a ver com o novo provedor. Tem a ver com a ordem em que backup, staging, TTL e DNS s\u00e3o executados. \u00c9 esse fluxo que este guia detalha.<\/p>\n\n\n\n Um site atual raramente \u00e9 s\u00f3 arquivos est\u00e1ticos. Banco de dados, cache e integra\u00e7\u00f5es precisam chegar ao destino no mesmo estado em que sa\u00edram, e cada uma dessas pe\u00e7as tem uma depend\u00eancia de ordem: o banco precisa estar \u00edntegro antes do primeiro teste; o DNS s\u00f3 deve mudar depois do ambiente novo aprovado; os redirects precisam existir antes da troca, n\u00e3o depois.<\/p>\n\n\n\n Quando essa ordem \u00e9 quebrada, o efeito quase sempre aparece do mesmo jeito: erro 404 em p\u00e1gina que existia, formul\u00e1rio que n\u00e3o envia, ou parte dos visitantes vendo uma vers\u00e3o desatualizada por horas. Antes de seguir para o passo a passo, vale ter em m\u00e3os o tutorial de backup completo do site e do banco de dados<\/em><\/a>, porque o backup \u00e9 a base de tudo que vem a seguir.<\/p>\n\n\n\n Exporte o site (arquivos), o banco de dados e as configura\u00e7\u00f5es de e-mail antes de tocar em qualquer coisa. Guarde a c\u00f3pia fora do servidor atual: no seu computador e, se poss\u00edvel, tamb\u00e9m em nuvem.<\/p>\n\n\n\n Verifica\u00e7\u00e3o: <\/strong>abra o backup e confirme que o banco de dados exporta sem erro, e que o tamanho dos arquivos bate com o da hospedagem original.<\/p>\n\n\n\n Configure a nova hospedagem e acesse o site por um endere\u00e7o tempor\u00e1rio \u2014 IP direto ou dom\u00ednio alternativo \u2014 sem apontar o dom\u00ednio principal ainda. O site antigo continua recebendo 100% do tr\u00e1fego enquanto isso, e \u00e9 justamente esse per\u00edodo de sobreposi\u00e7\u00e3o que elimina o downtime.<\/p>\n\n\n\n Verifica\u00e7\u00e3o: <\/strong>acesse o endere\u00e7o tempor\u00e1rio e confirme que a p\u00e1gina inicial carrega sem erro 500.<\/p>\n\n\n\n Aproveite esta etapa para medir o TTFB do novo ambiente. Um site que carrega em 1 segundo converte 2,5 vezes mais que um que leva 5 segundos, de acordo com dados citados pela WP Engine<\/a>. Corrigir performance agora custa bem menos do que corrigir depois que o site j\u00e1 est\u00e1 no ar.<\/p>\n\n\n\n Verifica\u00e7\u00e3o: <\/strong>rode um teste de velocidade e confirme TTFB abaixo de 200ms antes de seguir para o pr\u00f3ximo passo.<\/p>\n\n\n\n Um registro DNS com TTL de 86.400 segundos pode levar at\u00e9 24 horas para atualizar em todo o mundo, porque cada resolvedor s\u00f3 busca o valor novo quando o cache local expira. Baixar o TTL dos registros A, CNAME e MX para 300-900 segundos antes da virada faz a diferen\u00e7a entre uma propaga\u00e7\u00e3o de minutos e uma de um dia inteiro.<\/p>\n\n\n\n Verifica\u00e7\u00e3o: <\/strong>confira o TTL atual com dig<\/em> ou outra ferramenta de consulta DNS antes de reduzir o valor. Se o conceito ainda n\u00e3o estiver claro, o guia completo sobre DNS e zona DNS<\/em><\/a> explica como cada tipo de registro se comporta.<\/p>\n\n\n\n Com o TTL baixo e o ambiente novo validado, altere os registros ou os nameservers. A partir daqui, a propaga\u00e7\u00e3o global costuma levar entre 30 minutos e algumas horas \u2014 muito abaixo das 24 horas do cen\u00e1rio sem TTL reduzido.<\/p>\n\n\n\n Mantenha os dois servidores ativos por 48-72h ap\u00f3s a troca. Desligar o antigo antes disso significa que parte dos visitantes, ainda com o DNS antigo em cache, simplesmente para de encontrar o site.<\/p>\n\n\n\n Verifica\u00e7\u00e3o: <\/strong>acompanhe os logs de acesso dos dois servidores. O tr\u00e1fego no antigo deve cair de forma gradual ao longo desse per\u00edodo, n\u00e3o parar de uma vez.<\/p>\n\n\n\n Redirect \u00e9 o ponto onde a maioria das migra\u00e7\u00f5es perde ranking, n\u00e3o a troca de servidor em si. O mapeamento precisa ser um a um \u2014 cada URL antiga apontando para sua equivalente exata na estrutura nova, sem passar por uma p\u00e1gina intermedi\u00e1ria.<\/p>\n\n\n\n Verifica\u00e7\u00e3o: <\/strong>rastreie o site antigo, exporte a lista de URLs indexadas e confirme, uma a uma, que cada redirect responde com c\u00f3digo 301 (n\u00e3o 302) e sem cadeia de mais de um salto.<\/p>\n\n\n\n
Resumo<\/strong><\/p>\n\n\n\n\n
<\/li>\n<\/ul>\n<\/div><\/div>\n\n\n\nPor que a Sequ\u00eancia Importa Mais que o Provedor?<\/strong><\/h2>\n\n\n\n
Como Migrar Sem Downtime em 6 Passos<\/strong><\/h2>\n\n\n\n
1. Backup completo e testado<\/strong><\/h3>\n\n\n\n
2. Suba o novo ambiente sem trocar o DNS<\/strong><\/h3>\n\n\n\n
3. Teste o ambiente novo por completo<\/strong><\/h3>\n\n\n\n
\n
4. Reduza o TTL do DNS 24-48h antes<\/strong><\/h3>\n\n\n\n
5. Troque o DNS e monitore os dois ambientes<\/strong><\/h3>\n\n\n\n
6. Mapeie e valide cada redirect 301<\/strong><\/h3>\n\n\n\n
\u2705 Fazer \/ \u274c N\u00e3o fazer<\/strong><\/h3>\n\n\n\n