O Que Considerar ao Migrar para Outro Provedor de Hospedagem Web

Migrar um website para um novo fornecedor de alojamento é uma das operações de infraestrutura de maior risco que um proprietário de site pode realizar. Feita corretamente, resulta em zero perda de dados, tempo de inatividade insignificante e desempenho mensuravelmente melhor. Feita de forma descuidada, produz bases de dados corrompidas, falhas de DNS, quedas no ranking de SEO e horas de trabalho de recuperação de emergência.

Este guia abrange todas as fases críticas de uma migração de alojamento — desde a auditoria pré-migração e validação de compatibilidade, passando pela mecânica de transição de DNS, até à monitorização pós-migração — com a profundidade técnica necessária para a executar sem incidentes.

Fase 1: Audite o Seu Ambiente de Alojamento Atual Antes de Tocar em Qualquer Coisa

A falha de migração mais comum resulta de ignorar uma auditoria completa do ambiente existente. Antes de avaliar um novo fornecedor, precisa de um inventário preciso do que está realmente a executar.

Perfil de Tráfego e Recursos

Recolha pelo menos 90 dias de dados de recursos do servidor — não apenas contagens de visualizações de página. As métricas que importam são:

• Pico de ligações simultâneas — não o tráfego médio, mas o limite máximo de picos que o seu servidor deve suportar
• Consumo de memória por worker PHP ou processo de aplicação
• Padrões de I/O de disco — especialmente relevante se executar uma aplicação com uso intensivo de base de dados como WooCommerce ou um CRM personalizado
• Utilização de largura de banda — totais de transferência mensais versus o limite do seu plano atual

Se o seu alojamento atual fornece cPanel ou Plesk, estes dados estão acessíveis nas secções de utilização de recursos ou AWStats. Num Linux VPS, execute o seguinte para capturar um instantâneo de linha de base:

vmstat 1 10
iostat -x 1 5
free -m
df -h

Este resultado indica se o seu gargalo é CPU, RAM ou disco — o que determina diretamente se precisa de um plano partilhado maior, um VPS, ou um Servidor Dedicado.

Inventário da Stack de Software

Documente cada componente da sua stack com números de versão exatos:

• Versão PHP (ex.: 8.1, 8.2) e extensões ativas (mbstring, curl, gd, imagick, redis)
• Versão MySQL ou MariaDB e motor de armazenamento (InnoDB vs. MyISAM é importante para ferramentas de migração)
• Software de servidor web: Apache, Nginx, LiteSpeed, ou uma combinação de proxy reverso
• Quaisquer módulos compilados, regras .htaccess personalizadas, ou blocos de localização nginx.conf
• Tarefas Cron — exporte-as de crontab -l e documente-as separadamente
• Tipo de certificado SSL e emissor (Let’s Encrypt, CA comercial, wildcard)

Faltar mesmo uma extensão PHP no servidor de destino pode silenciosamente quebrar funcionalidades que só surgem em ações específicas do utilizador — um bug notoriamente difícil de rastrear após a migração.

Fase 2: Avalie e Selecione o Nível de Alojamento Correto

Escolher o nível de alojamento errado é um erro estrutural que força uma segunda migração em poucos meses. Mapeie os resultados da sua auditoria para a classe de infraestrutura correta.

Comparação de Níveis de Alojamento

Regra de decisão chave: Se a sua aplicação requer uma configuração específica de pool PHP-FPM, ligações de socket Redis, reescritas Nginx personalizadas, ou qualquer processo daemon, o alojamento partilhado é arquiteturalmente incompatível. Precisa no mínimo de um VPS com acesso root.

Para sites WordPress ou Joomla com tráfego moderado, um VPS com cPanel fornece a interface familiar do painel de controlo, mantendo o isolamento e desempenho de uma máquina virtual.

Critérios de Avaliação de Fornecedores

Além das afirmações de marketing, avalie os fornecedores com base nestes fatores técnicos verificáveis:

• SLA de uptime com cláusulas de penalização financeira — um SLA de 99,9% sem compensação não tem valor
• Classificação de nível do centro de dados (Tier III ou Tier IV para cargas de trabalho de produção)
• Redundância de rede — BGP multi-homing, múltiplos fornecedores upstream
• Tipo de armazenamento — NVMe SSD versus SATA SSD versus disco rotativo (as diferenças de latência são significativas)
• Política de backup — frequência, período de retenção, se os backups são armazenados fora do local
• SLA de tempo de resposta do suporte — distinguir entre tempo de primeira resposta e tempo de resolução

Fase 3: Criar e Verificar um Backup Completo

Nenhuma migração deve começar sem um backup verificado e restaurável. “Verificado” significa que testou efetivamente a restauração — não apenas confirmou que existe um ficheiro de backup.

O Que um Backup Completo Deve Incluir

• Ficheiros da raiz web — toda a raiz do documento, incluindo ficheiros ocultos como .htaccess e .env
• Todas as bases de dados — exportadas como dumps .sql, não apenas uma cópia dos ficheiros do diretório da base de dados
• Dados de email — se utilizar Alojamento de Email associado ao seu domínio, exporte as caixas de correio antes de qualquer alteração de DNS
• Tarefas Cron — crontab -l > crontab_backup.txt
• Certificados SSL e chaves privadas — se utilizar um certificado comercial, exporte a cadeia completa
• Ficheiros de configuração do servidor — /etc/nginx/, /etc/apache2/, /etc/php/, definições my.cnf personalizadas

Realizar uma Exportação de Base de Dados

Para MySQL/MariaDB, utilize mysqldump com opções que preservam total fidelidade:

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

O sinalizador --single-transaction é crítico para tabelas InnoDB — tira um instantâneo consistente sem bloquear tabelas, o que significa que o seu site em produção continua a servir pedidos durante o dump.

Verificar a Integridade do Backup

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

Um backup que não testou restaurar não é um backup — é uma falsa sensação de segurança.

Fase 4: Validar a Compatibilidade no Servidor de Destino

Antes de transferir dados de produção, configure o novo ambiente e valide a compatibilidade usando uma abordagem de staging.

Verificação de Versão PHP e Extensões

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

Compare este resultado com o seu inventário da Fase 1. Qualquer extensão em falta deve ser instalada antes da migração, não depois.

Verificação de Compatibilidade de Base de Dados

Se migrar do MySQL 5.7 para MySQL 8.0 (um cenário comum), esteja ciente destas alterações incompatíveis:

• O charset utf8mb3 está obsoleto; as colunas podem precisar de declarações explícitas de charset
• O comportamento de GROUP BY mudou — consultas que funcionavam em 5.7 podem falhar em 8.0 sem ajuste do modo ONLY_FULL_GROUP_BY
• NO_ZERO_DATE está ativado por padrão no modo strict, que rejeita campos de data contendo 0000-00-00

Teste o seu dump SQL contra a versão MySQL de destino antes de transferir o tráfego de produção.

Tradução de Configuração do Servidor Web

Se migrar de Apache para Nginx (um cenário frequente ao mover para um VPS otimizado para desempenho), as suas regras .htaccess não se traduzem automaticamente. Conversões comuns:

Redirecionamento .htaccess do Apache:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Equivalente Nginx no bloco server:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Falhar esta tradução é uma das causas mais comuns de erros 404 e loops de redirecionamento pós-migração.

Fase 5: Executar a Migração com Minimização do Tempo de Inatividade

Escolha a Janela de Migração Estrategicamente

Analise o seu Google Analytics ou registos do servidor para identificar a sua janela de menor tráfego — tipicamente entre as 02:00 e as 05:00 no fuso horário do público principal, numa terça ou quarta-feira. Evite sextas-feiras; se algo correr mal, as suas opções de suporte reduzem-se significativamente durante o fim de semana.

O Fluxo de Trabalho de Migração com Staging Primeiro

1. Aponte um subdomínio para o novo servidor (ex.: staging.example.com) usando um registo A, sem tocar no DNS de produção
2. Transfira todos os ficheiros e bases de dados para o novo servidor
3. Atualize a string de ligação à base de dados da aplicação para apontar para a nova base de dados
4. Modifique o seu ficheiro /etc/hosts local para resolver o domínio de produção para o IP do novo servidor — isto permite-lhe testar a configuração de produção completa sem afetar os utilizadores em produção:

# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com

1. Execute um teste funcional completo — cada formulário, fluxo de pagamento, sistema de login, endpoint de API e upload de média
2. Execute benchmarks de desempenho usando ab (Apache Benchmark) ou wrk:

ab -n 1000 -c 50 https://example.com/

1. Apenas após passar em todos os testes, prossiga para a transição de DNS

Configuração do Certificado SSL

Certifique-se de que o seu certificado SSL está instalado e validado no novo servidor antes da transição de DNS. Se utilizar Let’s Encrypt:

certbot --nginx -d example.com -d www.example.com

Se utilizar um certificado comercial de um fornecedor como os disponíveis através de Certificados SSL, instale a cadeia de certificados completa (certificado + CA intermediária + CA raiz) para evitar erros de validação de cadeia em clientes mais antigos.

Fase 6: Transição de DNS — O Passo Tecnicamente Mais Sensível

A propagação de DNS é amplamente mal compreendida. O valor de 48 horas é um limite máximo para o pior caso, não uma duração típica. Na prática, a maioria dos resolvers respeita o valor TTL do registo que está a ser alterado.

Redução de TTL Antes da Transição

Pelo menos 24–48 horas antes da janela de migração, reduza o TTL nos seus registos A e registos CNAME para 300 segundos (5 minutos):

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

Isto significa que após atualizar o registo para o novo IP, o valor em cache antigo expira em 5 minutos para a maioria dos resolvers — não em 48 horas. Esta é a técnica mais impactante para minimizar a janela de propagação de DNS.

Atualizações de Servidor de Nomes vs. Registo A

Existem duas abordagens distintas de transição de DNS:

• Alterar apenas registos A (mantendo os mesmos servidores de nomes autoritativos): A propagação segue o TTL do registo. Abordagem mais rápida se o seu registador de domínio permitir gestão direta de registos.
• Alterar servidores de nomes (apontar para o DNS do novo alojamento): Os TTLs dos servidores de nomes são tipicamente 24–48 horas e não estão sob o seu controlo direto. Esta abordagem demora mais.

Prefira atualizações de registos A quando possível. Gira o DNS do seu domínio através do seu painel de controlo de Registo de Domínios para controlo direto ao nível do registo.

Manter o Servidor Antigo Ativo Durante a Propagação

Não cancele nem desligue o plano de alojamento antigo imediatamente após a transição de DNS. Mantenha-o em funcionamento por um mínimo de 72 horas. Durante a propagação, uma parte dos seus utilizadores ainda resolverá para o IP antigo — esses pedidos devem continuar a ser servidos. Desligar o servidor antigo prematuramente cria uma interrupção real para esses utilizadores.

Fase 7: Monitorização e Validação Pós-Migração

Monitorização de Uptime e Desempenho

Configure monitorização externa de uptime imediatamente após a transição de DNS — não depois de achar que a propagação está completa. Ferramentas a implementar:

• UptimeRobot ou Better Uptime — verificações HTTP(S) a cada 1–5 minutos a partir de múltiplas localizações geográficas
• Google Search Console — observe os relatórios de Cobertura e Core Web Vitals para anomalias nos 7 dias pós-migração
• New Relic ou Datadog — monitorização de desempenho ao nível da aplicação, se a sua aplicação o justificar

Identificar e Resolver Erros Pós-Migração

Execute um rastreio do novo site imediatamente usando Screaming Frog ou um espelho wget:

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

Problemas comuns pós-migração e as suas causas:

Corrigir URLs Codificados em Bases de Dados WordPress

Um problema frequente e subtil: o WordPress armazena o URL do site na base de dados, e muitos temas e plugins armazenam URLs absolutos em dados serializados. Após migração para um novo domínio ou protocolo, execute:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

O sinalizador --precise trata corretamente os dados serializados PHP, que a substituição simples de strings corrompe.

Fase 8: Cancelar o Plano de Alojamento Antigo

Cancele o plano antigo apenas após confirmar todas as seguintes condições:

• A propagação de DNS está completa (verifique com dig +trace example.com a partir de múltiplas localizações)
• A monitorização de uptime mostra 100% de disponibilidade durante pelo menos 72 horas consecutivas
• Nenhum erro 404 ou link quebrado detetado nos registos de rastreio
• A entrega de email está a funcionar corretamente no novo servidor
• A análise mostra padrões de tráfego normais sem quedas anómalas
• Tem uma cópia local de todos os ficheiros de backup independente de qualquer fornecedor de alojamento

Lista de Verificação Técnica de Pontos-Chave

Use isto como a sua lista de verificação de execução de migração:

Pré-Migração

• [ ] Exportada linha de base de utilização de recursos de 90 dias (CPU, RAM, I/O, largura de banda)
• [ ] Documentada stack de software completa com números de versão exatos
• [ ] TTL de DNS reduzido para 300 segundos pelo menos 24 horas antes da transição
• [ ] Criado e testado backup completo (ficheiros + bases de dados + tarefas cron + email)
• [ ] Validada versão PHP e todas as extensões necessárias no servidor de destino
• [ ] Traduzidas regras .htaccess para formato Nginx se mudar de servidor web
• [ ] Certificado SSL instalado e validado no novo servidor antes da alteração de DNS

Durante a Migração

• [ ] Ficheiros transferidos usando rsync com verificação de checksum (rsync -avz --checksum)
• [ ] Base de dados importada e contagens de linhas verificadas correspondem à origem
• [ ] Funcionalidade completa do site testada via substituição /etc/hosts antes da alteração de DNS
• [ ] Ficheiros de configuração da aplicação atualizados (host da base de dados, credenciais, URL do site)

Pós-Migração

• [ ] Monitorização externa de uptime ativa dentro de 5 minutos após a transição de DNS
• [ ] Servidor antigo mantido em funcionamento por um mínimo de 72 horas após a transição
• [ ] Rastreio completo do site concluído; todos os erros 404 e links quebrados resolvidos
• [ ] URLs codificados corrigidos na base de dados (especialmente para WordPress)
• [ ] Google Search Console monitorizado durante 7 dias pós-migração
• [ ] Plano de alojamento antigo cancelado apenas após confirmação de todos os itens acima

Perguntas Frequentes

Quanto tempo demora realmente a propagação de DNS e posso acelerá-la?

A duração da propagação de DNS é determinada pelo valor TTL do registo que está a ser alterado, não por uma janela fixa de 48 horas. Se reduzir o TTL do seu registo A para 300 segundos pelo menos 24 horas antes da migração, a maioria dos resolvers irá obter o novo IP em 5–10 minutos após a alteração. O valor de 48 horas aplica-se a alterações de delegação de servidores de nomes, que têm TTLs fora do seu controlo.

Migrar para um novo alojamento irá prejudicar o meu ranking de pesquisa no Google?

Uma migração corretamente executada sem tempo de inatividade, estrutura de URL preservada e SSL válido não tem impacto negativo no SEO. Os rankings podem cair temporariamente se o novo servidor for mais lento, se os URLs mudarem sem redirecionamentos 301 adequados, ou se o site estiver inacessível durante o rastreio. Monitorize os relatórios de Cobertura e Core Web Vitals do Google Search Console durante 14 dias pós-migração.

Qual é a forma mais segura de transferir bases de dados grandes sem corromper dados?

Utilize mysqldump com o sinalizador --single-transaction para tabelas InnoDB para garantir um instantâneo consistente sem bloqueios de tabelas. Transfira o ficheiro dump via SSH usando scp ou rsync em vez de phpMyAdmin, que tem limites de tamanho de ficheiro e restrições de timeout que causam truncamento silencioso em bases de dados grandes.

Preciso de reinstalar o meu certificado SSL após migrar?

Sim. Os certificados SSL estão vinculados à chave privada do servidor, que reside no servidor original. Deve reemitir o certificado no novo servidor (gratuito para Let’s Encrypt) ou exportar a chave privada e a cadeia de certificados do servidor antigo e instalá-los no novo. Certifique-se de que o certificado está totalmente validado antes de atualizar o DNS, para que HTTPS funcione imediatamente após a transição.

Como verifico que a minha migração está completa antes de cancelar o plano antigo?

Execute dig +trace example.com @8.8.8.8 e dig +trace example.com @1.1.1.1 para confirmar que os resolvers do Google e Cloudflare retornam o IP do novo servidor. Verifique a monitorização de uptime durante 72 horas consecutivas de respostas limpas. Rastreie o site para erros 404 e verifique a entrega de email. Apenas após todos estes passos serem aprovados é seguro terminar a conta de alojamento antiga.