Dá mesmo para migrar de servidor sem parar a operação?
Migração de servidor sem parar a operação não significa janela zero: significa janela curta, combinada e com caminho de volta pronto. O que encurta a parada é o trabalho feito antes — copiar os dados com antecedência, testar o ambiente novo em paralelo e deixar só a virada para o horário combinado.
Toda migração de servidor tem um momento em que o antigo para e o novo assume. A pergunta não é se vai existir esse momento, é quanto ele vai durar e o que acontece se der errado. Migração que 'não para nada' geralmente é migração que ninguém testou — e a parada aparece depois, mais longa e em horário pior.
Antes: o levantamento que define a janela
O tamanho da parada é decidido aqui, e não na noite da virada:
- O que o servidor atual faz, item por item: arquivos, banco de dados, diretório, impressão, licença de sistema, tarefa agendada, integração com terceiro.
- Quem depende de cada um desses itens, e o que acontece com a operação se cada um ficar fora por uma hora.
- Onde estão os pontos fixos: caminho de pasta que aparece dentro de sistema, endereço fixo configurado em equipamento, licença amarrada ao nome ou ao hardware da máquina.
- Qual é o volume real de dados e quanto tempo a cópia leva na rede que existe — não na que se imagina.
O quarto item é o que mais surpreende: copiar dados leva o tempo que leva, e descobrir isso na noite da migração é o que transforma duas horas em uma madrugada.
O método que encurta a parada
A ideia é simples: fazer quase tudo com a empresa funcionando.
- Ambiente novo montado e testado em paralelo, com o antigo ainda no ar. Nada de montar às pressas na hora da virada.
- Cópia inicial dos dados feita com antecedência, durante dias se necessário, sem tocar na operação.
- Cópias incrementais até o dia da virada, de modo que a última sincronização seja pequena e rápida.
- Teste real no ambiente novo, com o sistema abrindo, o usuário entrando e a impressão saindo — não só o servidor ligando.
- Virada em janela combinada, com a última sincronização, o ajuste dos apontamentos e a validação com a operação.
O que precisa estar pronto antes de virar a chave
A lista que não admite exceção:
- Backup do servidor antigo verificado por restauração, não por relatório.
- Caminho de volta escrito: o que exatamente se faz para voltar ao servidor antigo, em que ordem, e quem decide voltar.
- Servidor antigo preservado e desligado, não formatado, por um período combinado depois da virada.
- Lista de validação da operação: quem testa o quê, no dia seguinte, e a quem avisa se falhar.
- Fornecedores dos sistemas avisados, principalmente quando há licença amarrada à máquina.
O terceiro item é o que separa um susto de um desastre. Formatar o servidor antigo na mesma semana é o erro que impede qualquer volta atrás.
Depois: os dias que ninguém planeja
A migração não termina na virada. Os problemas típicos aparecem nos primeiros dias úteis:
- Atalho antigo na área de trabalho apontando para um caminho que não existe mais.
- Tarefa agendada que rodava no servidor antigo e ninguém tinha mapeado.
- Equipamento com endereço fixo antigo configurado — impressora, relógio de ponto, câmera.
- Integração com fornecedor externo que apontava para o endereço anterior.
- Permissão de pasta que veio diferente e só aparece quando alguém tenta salvar.
Por isso o acompanhamento próximo nos primeiros dias faz parte do trabalho, e não é cortesia: é quando o que passou despercebido aparece.
Como isso fica no contrato mensal
Migração é projeto, com escopo, janela e orçamento próprios — não entra na rotina mensal. O que o contrato faz é o antes e o depois: manter o inventário que permite planejar, o backup que permite arriscar a virada, e o acompanhamento que estabiliza o ambiente novo. Veja Migração para nuvem e os planos de suporte mensal.