A parte difícil de migrar um WordPress para um servidor próprio não é a migração.
Copiar arquivos e banco de dados é trabalhoso, mas é procedimento conhecido — e há ferramentas que fazem boa parte disso. O que pega as pessoas de surpresa vem depois: o ambiente deixa de ser gerenciado, e um conjunto de coisas que o plano de hospedagem resolvia sozinho passa a ser responsabilidade sua.
Este guia trata das duas partes, com ênfase na segunda. O procedimento geral de migração entre hospedagens está no artigo sobre migrar de hospedagem sem sair do ar — aqui, o que é específico de um WordPress indo para um servidor.
O que você deixa para trás
Vale começar por um inventário honesto do que o plano gerenciado fazia e ninguém percebia.
| O que o plano fazia | Quem passa a fazer |
|---|---|
| Atualizar o sistema operacional | Você |
| Manter versões de PHP e banco | Você |
| Renovar certificados | Você (ou automação que você configura) |
| Backup automático | Você |
| Disparar tarefas agendadas | Você |
| Configurar servidor web e cache | Você |
| Monitorar recursos | Você |
| Proteger contra ataques básicos | Você |
Isso não é argumento contra migrar — é o preço do controle que justifica a migração. Mas é uma lista que precisa estar visível antes da decisão, e não descoberta depois.
A pergunta que decide: quem vai fazer essas oito coisas? Se não houver resposta com nome, vale reconsiderar o modelo — o comparativo está no artigo sobre Cloud Server gerenciado ou autogerenciado.
Antes de migrar
Preparação que evita a maior parte dos problemas:
- Levante o que existe: versões em uso, tamanho do banco e dos arquivos, plugins ativos, tarefas agendadas, contas de e-mail no mesmo plano.
- Monte o ambiente novo antes de tocar no atual, com as mesmas versões ou superiores.
- Teste o site no ambiente novo antes da virada, acessando por um endereço temporário.
- Verifique as integrações que dependem do endereço do servidor — elas vão parar quando ele mudar.
- Reduza o tempo de propagação dos registros com antecedência, para que a virada seja rápida.
- Escolha a janela, fora de períodos críticos.
- Garanta um caminho de volta, mantendo o ambiente antigo ativo por alguns dias.
O item 1 tem um subitem que causa incidentes graves: contas de e-mail hospedadas no mesmo plano. É comum o e-mail corporativo estar junto do site em planos compartilhados. Migrar o site sem tratar o e-mail — ou pior, apontar todos os registros para o servidor novo — derruba a comunicação da empresa.
E o item 4 merece uma lista própria: meios de pagamento, sistemas de emissão, integrações com ERP e ferramentas que autorizam por endereço precisam ser atualizados. A falha é silenciosa, como registrado no artigo sobre integrações e o que exigem do servidor.
A migração em si
O procedimento, em linhas gerais:
- Copie arquivos e banco de dados para o ambiente novo.
- Ajuste a configuração de conexão com o banco.
- Corrija permissões de arquivos e pastas.
- Teste tudo pelo endereço temporário: páginas, painel, formulários, checkout se houver.
- Sincronize novamente o que mudou desde a cópia inicial — especialmente em sites com publicação frequente ou loja em operação.
- Vire os registros de DNS.
- Acompanhe por algumas horas.
- Faça uma sincronização final do que entrou no ambiente antigo durante a propagação.
Os passos 5 e 8 são os que evitam perda de dados e são frequentemente pulados. Durante a propagação, parte dos visitantes ainda chega ao servidor antigo — e em uma loja, isso significa pedidos entrando no lugar errado.
Para lojas em operação, a recomendação é mais rígida: coloque em modo de manutenção durante a virada. Alguns minutos de indisponibilidade controlada custam menos que pedidos divididos entre dois bancos de dados.
O que configurar depois — e ninguém avisa
A parte mais importante deste artigo, e a mais negligenciada.
Um WordPress recém-migrado para um servidor limpo funciona, mas funciona no modo mais básico possível. Os ganhos que justificaram a migração só aparecem depois de configurar o que o plano compartilhado já entregava pronto — e mais.
1. Tarefas agendadas de verdade
Por padrão, o WordPress dispara suas tarefas agendadas quando alguém visita o site. Isso significa duas coisas ruins: em sites com pouco tráfego, as tarefas atrasam ou não rodam; em sites com muito tráfego, elas são verificadas em cada visita, desperdiçando recursos.
Em um servidor próprio, dá para fazer o certo: desativar esse comportamento e configurar uma tarefa real do sistema operacional chamando o WordPress em intervalos regulares.
É uma das primeiras configurações a fazer, e resolve problemas que muita gente convive sem saber — agendamentos de publicação que não disparam, backups que não rodam, e-mails de plugin que não saem.
2. Cache em nível de servidor
O maior ganho de desempenho disponível, e o que mais diferencia o servidor do plano anterior.
Cache por plugin funciona, mas atua depois que o interpretador já foi acionado. Cache em nível de servidor entrega a página antes disso — e é possível justamente porque você controla a configuração. O mecanismo está no artigo sobre o que é cache.
3. Camadas de cache de aplicação
Cache de objeto e cache de código, que aliviam banco e interpretador nas partes que o cache de página não cobre. São recursos que ambientes compartilhados raramente oferecem e que passam a estar disponíveis.
4. Backup próprio
O item mais crítico da lista, porque a ausência dele só aparece quando é tarde.
O plano antigo fazia backup; o servidor novo não faz nada até você configurar. Isso precisa ser resolvido no primeiro dia, com destino externo ao servidor e restauração testada — como tratado no artigo sobre backup de site.
5. Certificado e renovação automática
Emitir o certificado é simples; garantir que ele se renove sozinho é o que evita um site fora do ar em noventa dias. Vale testar a renovação, e não apenas configurá-la.
6. Monitoramento
Ninguém mais está olhando o servidor por você. Disponibilidade, espaço em disco, memória e validade do certificado precisam ser acompanhados — o que acompanhar está no artigo sobre monitoramento de site.
7. Segurança básica
Acesso administrativo restrito, autenticação forte, atualizações do sistema e limites de tentativa de acesso. O ambiente compartilhado tinha proteções que você não via.
Erros comuns depois da migração
| Sintoma | Causa provável |
|---|---|
| Agendamentos não disparam | Tarefa do sistema não configurada |
| Site funciona mas está lento | Cache ainda não configurado |
| Imagens quebradas | Permissões ou caminho de uploads |
| E-mails do site não saem | Envio não configurado no servidor novo |
| Integrações pararam | Endereço do servidor mudou |
| Site fora do ar em três meses | Renovação de certificado não automatizada |
| Painel lento | Cache de objeto ausente |
A quarta linha merece destaque porque é frequente e mal diagnosticada: um servidor novo não envia e-mails por padrão de forma confiável. Formulários de contato, recuperação de senha e notificações de pedido param de funcionar, e o sintoma é a ausência — ninguém recebe um erro.
A solução correta não é configurar o servidor para enviar diretamente, e sim usar um serviço de envio, pelas razões tratadas no artigo sobre newsletter e comunicação em massa.
O primeiro mês
Uma rotina curta que consolida a migração:
- Semana 1: acompanhar disponibilidade e desempenho de perto; confirmar que o backup rodou e restaurar um arquivo como teste.
- Semana 2: revisar o que ficou pendente da lista de configuração; verificar se todas as integrações voltaram.
- Semana 3: comparar o desempenho com o ambiente anterior, para confirmar o ganho.
- Semana 4: encerrar o ambiente antigo, depois de confirmar que nada depende dele — inclusive e-mail e arquivos antigos.
O encerramento do ambiente anterior costuma ser adiado indefinidamente, gerando custo duplicado por meses. Definir a data no início do projeto evita isso — e a verificação da semana 4 é o que autoriza o desligamento com segurança.
Conclusão
Migrar um WordPress para servidor próprio é um projeto com duas metades, e a segunda é maior: copiar o site é procedimento conhecido; assumir o que o plano gerenciado fazia é o que muda a rotina.
Sete configurações separam um servidor recém-migrado de um ambiente que entrega o ganho esperado: tarefas agendadas reais, cache em nível de servidor, camadas de cache de aplicação, backup próprio, renovação automática de certificado, monitoramento e segurança básica. Nenhuma delas vem pronta.
E dois itens que falham em silêncio depois da virada e merecem verificação explícita: o envio de e-mails do site e as integrações que dependem do endereço do servidor. Conheça o Cloud Server para WordPress da TBF Host e avalie o ambiente adequado ao seu projeto.
Perguntas frequentes
O que muda ao migrar o WordPress para um servidor próprio?
O ambiente deixa de ser gerenciado. Atualizações do sistema, versões de PHP e banco, renovação de certificados, backup, tarefas agendadas, configuração de servidor e cache, monitoramento e proteções básicas passam a ser sua responsabilidade — ou de quem você contratar.
O que preciso configurar depois de migrar?
Tarefas agendadas reais do sistema operacional, cache em nível de servidor, cache de objeto e de código, backup com destino externo e restauração testada, renovação automática do certificado, monitoramento e segurança básica. Nenhum desses itens vem pronto em um servidor limpo.
Por que os agendamentos do WordPress não disparam depois da migração?
Porque por padrão o WordPress dispara suas tarefas quando alguém visita o site. Em sites com pouco tráfego, elas atrasam ou não rodam. Em um servidor próprio, o correto é desativar esse comportamento e configurar uma tarefa real do sistema chamando o WordPress em intervalos regulares.
Por que os e-mails do site pararam de funcionar?
Um servidor novo não envia e-mails de forma confiável por padrão. Formulários de contato, recuperação de senha e notificações param — e a falha é silenciosa, ninguém recebe erro. A solução não é configurar o servidor para enviar diretamente, e sim usar um serviço de envio dedicado.
Como migrar sem perder pedidos ou conteúdo?
Sincronizando novamente o que mudou desde a cópia inicial, antes da virada, e fazendo uma sincronização final depois — porque durante a propagação parte dos visitantes ainda chega ao servidor antigo. Para lojas, o mais seguro é colocar em modo de manutenção durante a virada.
O que verificar antes de migrar?
Versões em uso, tamanho de banco e arquivos, plugins ativos, tarefas agendadas e, principalmente, se há contas de e-mail no mesmo plano — apontar todos os registros para o servidor novo sem tratar o e-mail derruba a comunicação da empresa. Também as integrações que autorizam por endereço.
Por que o site continua lento depois de migrar?
Porque um servidor recém-migrado funciona no modo mais básico. Os ganhos que justificaram a migração só aparecem depois de configurar cache em nível de servidor e as camadas de cache de aplicação — recursos que o ambiente permite e que precisam ser ativados.
Quando posso desligar o ambiente antigo?
Depois de confirmar que nada depende dele: integrações atualizadas, e-mail tratado, arquivos antigos recuperados e algumas semanas de operação estável no novo. Vale definir essa data no início do projeto — o encerramento costuma ser adiado, gerando custo duplicado por meses.