Como Mover o Bitrix24 Self-Hosted para um Novo Servidor: Guia Completo

Quando Você Precisa Mover o Servidor

Há três cenários clássicos que justificam a migração do Bitrix24 (Alaio) self-hosted: upgrade de hardware (mais CPU, RAM ou SSD), troca de data center ou provedor de hospedagem, e atualização de sistema operacional - especialmente a saída do CentOS 7 em direção ao CentOS Stream 9.

Em projetos típicos atendidos pela ACP Group, a troca de servidor costuma coincidir com um desses momentos:

• O portal cresceu além da capacidade do hardware atual (lentidão, filas de tarefa represadas).
• A empresa decide sair de um servidor físico próprio e ir para uma VM em nuvem privada - ou o contrário.
• O SO do servidor antigo chegou ao fim do suporte, e subir um novo ambiente limpo é mais seguro do que atualizar no lugar.
• Mudança de provedor por questões de custo, latência ou conformidade com leis locais de residência de dados.

Migrar de servidor não é o mesmo que migrar da nuvem para o self-hosted. Se você está nessa segunda situação, o processo é diferente - veja o guia específico em Migrando do Bitrix24 Nuvem para Self-Hosted: Plano Passo a Passo.

O Que Não É Migração de Servidor

Migrar o Bitrix24 self-hosted de um servidor para outro é uma operação de infraestrutura - não é uma migração de dados de CRM, nem uma troca de plano/edição, nem uma atualização de versão do produto.

Confusões comuns que geram retrabalho:

• Exportar/importar CSV do CRM - serve para trocar de portal (nuvem → nuvem), não para mover toda a instalação self-hosted. O backup de servidor move tudo: CRM, tarefas, disco, histórico, configurações, módulos customizados.
• Atualizar versão do Bitrix24 - pode ser feito no servidor atual antes ou depois da migração; são operações independentes.
• Upgrade de SO no mesmo servidor - se você está saindo do CentOS 7 para o CentOS Stream 9 sem trocar de máquina, confira o artigo Migração do Bitrix24 On-Premise: do CentOS 7 para o CentOS Stream 9.

Pré-Requisitos e Checklist Antes de Começar

Antes de qualquer trabalho de migração, o novo servidor precisa estar provisionado, com OS suportado (CentOS Stream 9 ou imagem VM oficial), portas 80, 443 e 22 liberadas, IP externo fixo e domínio apontado - sem isso, o cutover não funciona.

Checklist de pré-migração

• Licença Bitrix24 self-hosted ativa (sem licença ativa, o portal bloqueia após o cutover)
• Backup completo gerado e validado - arquivos do portal + dump do banco de dados (MySQL/Percona)
• Backup armazenado fora dos servidores de aplicação (storage externo, S3, NAS)
• Novo servidor provisionado: SO suportado (CentOS Stream 9 recomendado a partir de 2026) ou imagem VM oficial compatível com VMware/VirtualBox
• Portas abertas no novo servidor: 80 (HTTP), 443 (HTTPS), 22 (SSH)
• IP externo fixo disponível no novo servidor
• Domínio do portal pronto para ser redirecionado ao novo IP (TTL baixo configurado com antecedência)
• Configurações salvas: /etc/nginx, /etc/httpd, /etc/php.ini, /etc/mysql/conf.d do servidor antigo
• Contato do registrador de domínio disponível para alteração de DNS
• Janela de manutenção comunicada aos usuários

Dimensionamento mínimo do novo servidor (com base em projetos reais):

Para portais com volume alto de arquivos (documentos, gravações de chamadas), adicione discos HDD separados para armazenamento de mídia e backups. Mais detalhes em Bitrix24 Self-Hosted: Guia de Dimensionamento de Hardware para 50 a 1.000 Usuários.

Passo a Passo da Migração

A migração segura do Bitrix24 self-hosted segue dois grandes blocos: (1) preparação e backup no servidor antigo, e (2) restauração e reconfiguração no novo - com o portal antigo ainda no ar até o cutover validado.

O fluxo completo do processo pode ser visualizado abaixo. O texto descreve cada etapa em sequência para garantir rastreabilidade mesmo sem renderização do diagrama.

Etapa 1 - Preparação (servidor antigo): gera-se o backup completo (arquivos do portal + dump do banco de dados). Os arquivos de configuração do web server, PHP e banco são salvos separadamente. O backup é transferido para storage externo.

Etapa 2 - Provisão do novo servidor: instala-se o SO suportado, o ambiente web (Nginx, Apache, PHP, Percona/MySQL nas versões compatíveis) e abre-se as portas necessárias.

Etapa 3 - Restauração: o backup é transferido para o novo servidor e restaurado. O portal sobe internamente para validação.

Etapa 4 - Reconfiguração: domínio redirecionado ao novo IP, SSL instalado (Let's Encrypt ou certificado próprio), e-mail do sistema reconfigurado, Push & Pull ajustado para o novo servidor, cron jobs validados, webhooks e integrações atualizados com a nova URL/IP.

Etapa 5 - Validação e cutover: testes funcionais completos, reativação da chave de licença no novo servidor, abertura de acesso aos usuários, encerramento do servidor antigo.

flowchart TD
    A([Servidor Antigo em Produção]) --> B[Gerar Backup Completo\nArquivos + Banco de Dados]
    B --> C[Salvar Configs\nnginx / php / mysql]
    C --> D[Transferir Backup\npara Storage Externo]
    D --> E[Provisionar Novo Servidor\nCentOS Stream 9 + Web Stack]
    E --> F[Restaurar Backup\nno Novo Servidor]
    F --> G[Validação Interna\nsem DNS público]
    G --> H{OK?}
    H -- Não --> F
    H -- Sim --> I[Bloquear Acesso\nno Servidor Antigo]
    I --> J[Alterar DNS\nApontar Domínio para Novo IP]
    J --> K[Instalar SSL\nLet's Encrypt ou Cert. Próprio]
    K --> L[Reconfigurar Email,\nPush & Pull, Cron, Integrações]
    L --> M[Reativar Licença\nno Novo Servidor]
    M --> N[Testes Finais com Usuários]
    N --> O([Servidor Antigo Desligado])

O Que Costuma Quebrar e Como Resolver

Em migrações de Bitrix24 self-hosted, os quatro pontos que mais causam problemas são: caminhos de arquivo incorretos após restauração, falha na reativação da licença no novo host, URLs hardcoded em integrações e webhooks, e o Push & Pull ainda apontando para o servidor antigo.

Problemas mais frequentes

1. Caminhos de arquivo quebrados O Bitrix24 armazena caminhos absolutos em configurações e no banco de dados. Se o diretório raiz do portal mudou entre os servidores, links internos e uploads podem quebrar. Solução: garantir que o path de instalação seja idêntico, ou executar busca-e-substituição no banco antes de subir o portal.

2. Licença não reconhecida no novo servidor A chave de licença do Bitrix24 self-hosted registra informações do ambiente no momento da ativação. Ao mover para um novo servidor, é necessário reativar a chave - o que normalmente é feito pela interface administrativa. Atenção: em licenças não-Enterprise, o Bitrix24 permite no máximo 2 instalações ativas simultaneamente (produção + teste). Com a licença expirada, REST API, Marketplace e telefonia param de funcionar, entre outros módulos críticos.

3. Webhooks e integrações com URL antiga Qualquer integração externa (formulários de site, ERP, sistemas de telefonia) que use a URL ou IP do portal precisa ser atualizada. Isso inclui webhooks de entrada, conectores de Open Channels e aplicativos do Marketplace instalados.

4. Push & Pull não configurado no novo servidor O Push & Pull é o serviço responsável pelos chats em tempo real, notificações e sincronização de documentos. Por padrão, após a restauração, ele pode continuar tentando usar a configuração de nuvem ou o endereço antigo. Em ambientes fechados (contorno privado), o serviço deve ser explicitamente redirecionado para o servidor local (Node.js/WebSocket via Nginx).

5. Propagação de DNS mais lenta que o esperado Reduza o TTL do domínio para 300 segundos (5 minutos) pelo menos 24 horas antes do cutover. Isso minimiza o tempo em que parte dos usuários ainda resolve o nome para o IP antigo.

Para uma visão mais ampla de segurança pós-migração, veja o Hardening de Segurança para Bitrix24 Self-Hosted: Checklist de 25 Pontos.

Tabela de Etapas com Responsáveis e Duração Típica

Em um projeto típico de migração de servidor, o tempo total de indisponibilidade do portal pode ser reduzido a 1-3 horas se o backup for preparado com antecedência e o novo servidor estiver pré-configurado antes da janela de manutenção.

Reativação de Licença no Novo Servidor

A licença Bitrix24 self-hosted (a partir de 2022, todas as edições são anuais com renovação obrigatória a cada 12 meses) precisa ser reativada no novo host - sem isso, REST API, Marketplace, Push & Pull em nuvem e telefonia ficam bloqueados.

Pontos críticos sobre licenciamento durante a migração:

• A chave de licença é vinculada ao domínio registrado. Se o domínio não mudar, a reativação é simples via painel administrativo.
• Se o domínio mudar junto com o servidor, todos os domínios precisam estar registrados na licença - caso contrário, o Push & Pull em nuvem não funciona.
• Em licenças não-Enterprise: máximo de 2 cópias ativas (produção + teste/homologação). Durante o período de execução paralela, ambas as instâncias consomem essa cota.
• Licença vencida durante a migração: o portal continua funcionando por um período de carência, mas sem atualizações, sem Marketplace e sem REST API - o que torna integrações inoperantes.

Renove a licença antes de iniciar a migração se ela vencer dentro de 30 dias. Mais sobre edições e licenciamento em Edições e Licenciamento do Bitrix24 Self-Hosted: Guia Completo para 2026.

Execução Paralela e Cutover

A estratégia mais segura é manter o servidor antigo acessível (somente leitura ou bloqueado para edições) enquanto o novo é validado - isso elimina o risco de perda de dados em caso de problema na restauração.

Recomendações para o período de execução paralela:

1. Bloquear gravações no portal antigo antes de alterar o DNS - usuários que ainda acessam o servidor antigo não devem conseguir salvar novos dados, evitando divergência entre os ambientes.
2. Manter o servidor antigo ligado por pelo menos 48 horas após o cutover para suporte a rollback rápido.
3. Monitorar logs do novo servidor nas primeiras horas: erros 500, timeouts de banco, falhas de Push & Pull.
4. Comunicar usuários sobre a janela de manutenção e o procedimento de reporte de problemas.
5. Validar integrações críticas - telefonia, formulários de captação, automações de CRM - antes de liberar acesso geral.

Para portais com alta disponibilidade ou múltiplos nós, o processo de cutover é mais complexo. Consulte Bitrix24 Self-Hosted em Alta Disponibilidade: Cluster Master-Replica para os cenários correspondentes.

A ACP Group, parceiro Gold Bitrix24 com mais de 1.300 projetos entregues, realiza migrações de servidor com janela de indisponibilidade mínima - tipicamente dentro da mesma noite - incluindo reativação de licença, reconfiguração de integrações e validação completa antes da entrega.

Trabalhar com um parceiro no self-hosting. Quer o controle do Bitrix24 self-hosted sem gerenciar o servidor? A ACP Group implanta e opera para voce - veja Bitrix24 self-hosted gerenciado, planos de suporte e manutencao ou peca um orcamento chave na mao.