Migração de Servidores em Santa Catarina

Decisão de infraestrutura

Quando migrar de servidor

A hora de migrar aparece quando a infraestrutura atual deixa de atender um requisito mensurável. Lentidão isolada não basta: primeiro é preciso separar problema de aplicação, banco, rede e capacidade. Métricas de CPU, memória, I/O, latência, erros e filas mostram se o limite está no servidor ou em uma consulta, rotina ou integração específica.

• Saturação recorrente de recursos — CPU constantemente disputada, memória entrando em swap, disco com fila alta ou conexões de banco no limite indicam que picos normais já não cabem no ambiente. O sinal relevante é a recorrência correlacionada com degradação, não um pico curto e sem efeito para o usuário.
• Custo desproporcional à carga — O servidor pode ter folga e ainda ser inadequado. Compare computação, armazenamento, tráfego, licenças, backup e operação com a carga atendida e com alternativas equivalentes.
• Fim de suporte — Sistema operacional, runtime, painel ou banco fora do ciclo de correções cria risco que uma configuração de firewall não elimina. Quando a atualização no mesmo ambiente é inviável, construir um destino suportado permite atualizar com ensaio e rollback.
• Limite de escala vertical — Adicionar mais CPU e memória deixa de resolver quando o provedor atingiu o maior plano, quando a arquitetura precisa de redundância ou quando o tempo de recuperação de uma única máquina ficou incompatível com a operação. Nesse ponto, o destino pode exigir balanceamento, réplicas ou serviços gerenciados.
• Latência geográfica — Usuários e sistemas dependentes distantes do datacenter pagam o tempo de ida e volta em cada requisição. A decisão deve usar medições por região e considerar banco, armazenamento e APIs; mover apenas o frontend raramente corrige uma cadeia inteira de chamadas lentas.
• Requisito de segurança ou conformidade — Residência de dados, segregação de rede, trilhas de auditoria, criptografia ou políticas internas podem exigir controles que o ambiente atual não oferece. A migração precisa então provar onde cada dado fica, quem acessa e como o controle é registrado.
• Indisponibilidade recorrente — Falhas repetidas de host, storage, rede ou suporte justificam avaliar outro desenho. Antes do movimento, os incidentes devem ser classificados; caso contrário, uma falha da aplicação pode acompanhar a cópia e reaparecer no destino.

Cenários

Tipos de migração e o risco de cada movimento

O método muda conforme origem e destino. A quantidade de dados importa, mas as maiores diferenças costumam estar nos serviços equivalentes, na rede disponível e no quanto da configuração antiga estava implícito.

Quando URLs, CMS, framework ou arquitetura mudam junto, o escopo se aproxima de uma migração de plataformas com preservação de SEO. Separar os planos distingue riscos de infraestrutura e de produto.

Execução controlada

O runbook completo de uma migração de servidor

Runbook define ação, responsável, evidência esperada, ponto de decisão e retorno. Ele reduz improviso no corte e compara o destino com um estado conhecido.

1. Inventariar o ambiente de origem — Liste aplicações, domínios, bancos, volumes, serviços, portas, jobs, filas, certificados, firewall, integrações, backups e observabilidade. Registre versões, dependências, inicialização, configuração, destinos de escrita e sistemas externos vinculados ao IP atual.
2. Medir e dimensionar o destino — Colete consumo em períodos representativos e diferencie uso médio de pico. CPU virtual não equivale automaticamente a núcleo dedicado; desempenho de disco depende de latência e IOPS; banco precisa de memória, conexões e comportamento de consulta. A escolha deve reservar margem para picos, manutenção e crescimento sem reproduzir desperdício.
3. Definir arquitetura, rede e segurança — Antes de instalar a aplicação, desenhe sub-redes, endereços públicos, regras de entrada e saída, identidade, segredos, criptografia, backup e acesso administrativo. Portas devem ser abertas por necessidade documentada. O destino não deve herdar uma regra ampla apenas porque ela existia na origem.
4. Construir um ambiente espelho — Instale versões compatíveis de sistema, runtime, proxy, banco e agentes operacionais. Reproduza a configuração por automação quando possível e use dados sanitizados ou uma cópia protegida conforme a sensibilidade. O ambiente precisa iniciar de forma repetível; ajustes feitos manualmente devem voltar para a documentação ou para o código de infraestrutura.
5. Fazer a carga inicial de dados — Transfira arquivos e banco por método que preserve permissões, timestamps e consistência. Para banco ativo, um dump simples representa um ponto no tempo; se a cópia demorar, será necessário replicar mudanças posteriores. Valide contagens, checksums, tamanho, constraints e logs de importação em vez de confiar apenas no término do comando.
6. Sincronizar mudanças incrementais — Depois da carga inicial, mantenha origem e destino próximos. Bancos podem usar replicação nativa ou captura de mudanças; arquivos podem usar sincronização incremental; objetos podem ser copiados por versão. É indispensável saber a direção da escrita: permitir alterações nos dois lados sem estratégia de conflito cria divergência.
7. Ensaiar o corte — Execute o procedimento completo sem trocar o tráfego público: congelamento quando necessário, sincronização final, subida de serviços, testes e medição do tempo de cada etapa. O ensaio revela permissões ausentes, comandos lentos e dependências não inventariadas. Atualize o runbook com o que foi observado.
8. Definir critérios de go e rollback — Antes do cutover, escreva o que permite continuar e o que obriga voltar. Erro de autenticação, divergência de dados, fila sem consumo ou latência acima do limite acordado são exemplos de critérios. Rollback precisa indicar até quando é seguro reverter, como tratar escritas feitas no destino e quem toma a decisão.
9. Executar o cutover — Comunique o início, confirme backups e saúde dos dois ambientes, restrinja escrita se o desenho exigir, faça a última sincronização e direcione tráfego por balanceador, proxy ou DNS. Registre horários e mudanças. Durante o corte, alterações fora do runbook devem ser raras e documentadas.
10. Validar por camadas — Valide infraestrutura, banco, aplicação e jornadas externas. Verifique HTTP, TLS, login, leitura, escrita, uploads, e-mails, webhooks, filas, jobs e painéis enquanto observa os logs, pois uma tela correta pode esconder falhas assíncronas.
11. Encerrar com observação e desativação segura — Mantenha monitoramento reforçado e preserve a origem sem novas escritas enquanto o período de retorno estiver aberto. Só depois de confirmar backups restauráveis, integrações e estabilidade operacional começa a desativação. Revogue credenciais, remova dados conforme a política e atualize inventário, diagramas e rotinas de suporte.

Continuidade

Como evitar downtime de verdade

Reduza o TTL antes, não durante o corte

TTL determina por quanto tempo um resolvedor pode guardar uma resposta DNS. Se o registro ainda tem TTL alto quando ele é alterado, caches que consultaram antes continuam usando o IP antigo até expirar. Baixar o valor no momento do corte não encurta essas cópias já armazenadas; a redução precisa ser publicada e permanecer ativa por pelo menos um ciclo do TTL anterior.

Um TTL menor acelera a troca, mas não garante atualização instantânea em todos os clientes. Por isso origem e destino devem coexistir quando possível. Depois da estabilização, o TTL pode voltar a um valor adequado para reduzir consultas e evitar depender de uma configuração emergencial.

Blue-green, replicação e janela de corte

No modelo blue-green, o ambiente atual permanece atendendo enquanto o novo é construído e testado. O tráfego troca de um para o outro por uma camada controlável. A técnica reduz o tempo de indisponibilidade da aplicação, mas não resolve sozinha dados mutáveis: é preciso replicar, impedir escrita durante a sincronização final ou definir como conciliar alterações.

A janela de corte concentra a parte incompatível com operação paralela. Quanto mais dados forem pré-copiados e mais testes ocorrerem no ambiente verde, menor o trabalho nessa janela. Sistemas com sessão em memória, upload local ou jobs que alteram o banco exigem coordenação adicional para não processar duas vezes nem perder estado.

Dependências invisíveis

O que quebra numa migração e ninguém avisa

Os incidentes difíceis aparecem nas rotinas e relações ao redor da aplicação. O inventário precisa procurar explicitamente os itens abaixo.

• Cron jobs e timers — podem não ser copiados, executar com usuário diferente ou rodar simultaneamente nos dois ambientes. Confirme agendamento, timezone, diretório de trabalho, variáveis e trava contra duplicidade.
• Certificados TLS — dependem de chave privada, cadeia, nomes cobertos e renovação. Copiar apenas o certificado público não basta. Emissão automática também exige que desafio DNS ou HTTP alcance o destino correto.
• IPs em allowlists — gateways, bancos, ERPs, webhooks e parceiros podem aceitar somente o endereço antigo. Liste saídas e entradas, solicite a inclusão do novo IP e teste antes de retirar o anterior.
• SPF, DKIM e DMARC — mudanças no envio de e-mail podem exigir novo IP autorizado, chave DKIM disponível no serviço e alinhamento do domínio. DNS correto não compensa reputação ou reverse DNS ausente.
• Sessões ativas — sessões mantidas em memória desaparecem na troca e forçam novo login. Cookies também podem depender de domínio, chave de assinatura ou configuração de proxy. Centralizar sessão ou aceitar expiração controlada precisa ser decisão consciente.
• Uploads em disco local — arquivos gravados após a cópia inicial ficam na origem. É preciso sincronização incremental, armazenamento compartilhado ou uma pausa de escrita no corte. Caminho, proprietário e permissões devem ser equivalentes.
• Filas e workers — mensagens em trânsito podem ser abandonadas ou consumidas em duplicidade. Verifique confirmação, retry, dead-letter, idempotência e versão do payload antes de iniciar consumidores no destino.
• Variáveis e segredos — arquivos ocultos, serviços do sistema e painéis do provedor podem conter configuração que não está no repositório. Transfira por canal seguro, revise escopo e aproveite a troca para rotacionar o que foi exposto a operadores antigos.
• Timezone e locale do banco — alteram conversões de data, ordenação, comparação e formatação. Compare parâmetros do servidor, sessão e aplicação; teste datas próximas a mudanças de fuso e consultas sensíveis a collation.
• DNS reverso e reputação de IP — serviços de e-mail e integrações antifraude podem reagir ao endereço novo mesmo que a aplicação esteja íntegra. O comportamento deve ser validado como dependência externa, não apenas como conectividade.

Uma auditoria técnica de SEO, AEO e GEO ajuda a encontrar efeitos públicos da troca, enquanto a validação de infraestrutura cobre processos internos. Em lojas, a checagem deve incluir carrinho, estoque, pagamento e catálogo; o guia de SEO para e-commerce detalha esses pontos de indexação e arquitetura.

Busca orgânica

Impacto da migração de servidor em SEO

Uma troca apenas de servidor não deve alterar URLs, conteúdo, canônicos, headings, dados estruturados ou indexação. Se a aplicação mudar de caminho ou tecnologia, cada URL antiga precisa de destino equivalente e redirect permanente sem cadeia.

Antes do corte, guarde amostras de status HTTP, HTML renderizado, sitemap, robots.txt, canônicos e métricas de performance. Depois, rastreie o site como um robô e compare. No Search Console, acompanhe inspeção de URL, páginas indexadas, sitemap, Core Web Vitals, erros de servidor e desempenho orgânico. Logs do proxy mostram se Googlebot encontra respostas lentas ou códigos 5xx.

Não existe prazo universal de estabilização: o recrawl varia por URL e por condições técnicas. Use o retorno dos indicadores ao comportamento esperado, não uma promessa de calendário. Se a troca inclui frontend ou CMS, trate-a como migração de plataforma e valide performance com a abordagem de sites de alta performance.

Aceite técnico

Checklist de validação pós-migração

• DNS autoritativo e resoluções externas apontam para o destino previsto.
• Certificado TLS cobre os nomes usados, entrega a cadeia completa e tem renovação testada.
• Páginas e APIs críticas retornam o status e o conteúdo esperados.
• Login, permissões, sessão, leitura, escrita e logout funcionam.
• Banco passou por contagens, constraints, amostras e teste de nova gravação.
• Uploads novos persistem e podem ser recuperados pelo caminho público correto.
• Filas, workers e jobs processam uma vez, registram falhas e retomam após reinício.
• E-mails, webhooks, pagamentos e integrações externas completam o fluxo.
• Firewall, IAM, segredos e acesso administrativo seguem o desenho aprovado.
• Logs, métricas e alertas recebem dados do novo ambiente.
• Backup novo foi criado e o procedimento de restauração está documentado.
• Robots.txt, sitemap, canônicos, redirects e páginas indexáveis não regrediram.
• Plano de rollback continua executável até o encerramento formal da janela de retorno.
• Origem será desativada somente após validação e preservação exigida pela política de dados.