Índice
- O que é migração de data center?
- Tipos de migração de data center
- Plano de migração do data center em 7 fases
- Lista de verificação para migração de data center
- Estratégia de migração de data center: escolhendo uma abordagem
- Minimizar o tempo de inatividade: replicação em tempo real versus migração a frio
- Fatores de cronograma e custo
- Desativação de data centers: descomissionamento e contratos
- Melhores práticas e erros comuns na migração de data centers
- Como a plataforma Hystax automatiza a migração de data centers
Principais conclusões
- Com a replicação em segundo plano, a única pausa real é a sincronização final e a reinicialização.
- Um plano de migração de data center passa por sete fases, desde a decisão sobre o que será transferido até o fechamento do site antigo.
- Os problemas surgem na transição, mas começam antes: um servidor desconhecido, um aplicativo separado de seu banco de dados ou um teste que nunca é executado.
- O site antigo continua cobrando até que você cancele os contratos de aluguel, suporte e circuitos, cada um com seu próprio prazo de aviso prévio.
O que é migração de data center?
A migração de data center consiste na transferência de aplicações, dados e infraestrutura de suporte de um ambiente de data center para outro. O destino pode ser uma nuvem pública, uma nuvem privada, um data center de colocation ou um site consolidado. Em uma migração baseada em rede, as cargas de trabalho são replicadas para a nova plataforma e iniciadas lá, sem a necessidade de transporte de hardware.
Grande parte desse movimento é agora impulsionado pela saída da Broadcom da VMware. Fim do suporte geral para vSphere 8.0 Em 11 de outubro de 2027, e as equipes que ainda estiverem usando essa plataforma precisarão migrar para uma nova até essa data.
Tipos de migração de data center
Poucos projetos se encaixam em um único tipo: pode-se consolidar dois locais, migrar a maior parte das cargas de trabalho para a nuvem e manter algumas poucas no local.
| Tipo | O que move | Motorista típico | Consideração principal |
|---|---|---|---|
| Do data center à nuvem | Migrar cargas de trabalho locais para uma nuvem pública. | Saída de hardware próprio, capacidade elástica | Largura de banda, custos de operação na nuvem, licenciamento |
| CC para CC | Cargas de trabalho para outro site, geralmente um hipervisor diferente. | Fim do contrato de locação, deixando um fornecedor de virtualização. | Os drivers, as configurações de rede e as configurações de inicialização diferem entre as plataformas. |
| Consolidação | Consolidar cargas de trabalho de vários locais em menos locais. | Redução de custos, integração de fusões | Planejamento de capacidade, sobreposição de faixas de IP |
| Híbrido | Parte da propriedade se muda, o restante permanece. | Residência de dados, latência, hardware especializado | Uma ligação estável entre locais durante meses ou anos. |
O tipo altera o que você verifica, não a ordem do trabalho.
Plano de migração do data center em 7 fases
Um plano de migração de data center transforma um grande projeto em uma sequência de etapas de verificação.
1. Defina o escopo e os critérios de sucesso.
O planejamento começa com uma lista do que será migrado, do que permanecerá e do que será desativado. Os critérios de sucesso incluem a janela de transição, a perda de dados aceitável (RPO), o tempo de recuperação (RTO) e um limite orçamentário.
2. Descobrir ativos e mapear dependências
3. Escolha uma estratégia para cada carga de trabalho.
Cada carga de trabalho recebe sua própria estratégia de migração de data center, e a seção abaixo descreve as opções.
4. Preparar o ambiente alvo
As redes, o armazenamento, os serviços de identidade, as políticas de segurança, a capacidade e as regras de firewall entre os sites precisam existir antes da chegada da primeira réplica. O tráfego de replicação precisa de um caminho de saída da rede de origem até o local onde a ferramenta de migração está sendo executada.
5. Replicar e testar
A replicação em segundo plano copia as cargas de trabalho para o destino enquanto a produção continua em execução. As migrações de teste iniciam cópias em uma rede isolada para verificar a inicialização, o comportamento do aplicativo e o desempenho.
6. Corte em ondas
As cargas de trabalho são movidas em grupos ordenados por dependência e risco para o negócio. Uma única migração executa uma réplica final, desliga a origem, inicia o destino, executa testes de aceitação e redireciona o tráfego para o novo site.
A fonte permanece intacta até que a aceitação seja aprovada, o que mantém um caminho de reversão aberto. Assim que as ondas começam, a replicação e a transição se sobrepõem: os grupos posteriores ainda estão copiando enquanto os primeiros fazem a transição.
7. Validar, otimizar e desativar
Após a aceitação, as equipes comparam o desempenho com as linhas de base, redimensionam os recursos, atualizam os trabalhos de monitoramento e backup e desativam o ambiente antigo. Os contratos e a higienização de dados têm sua própria seção abaixo.
Lista de verificação para migração de data center
A tabela abaixo transforma o plano de migração do data center em verificações que podem ser utilizadas em um sistema de tickets ou em uma planilha.
| Fase | Cheques | Feito quando |
|---|---|---|
| 1. Âmbito de aplicação | Lista de cargas de trabalho a serem movidas, retidas e desativadas; RPO, RTO, período de transição e orçamento definidos. | Inventário aprovado e metas por escrito |
| 2. Descoberta | Inventário de servidores, armazenamento e caminhos de rede; mapeamento de dependências por aplicação; configurações não suportadas sinalizadas. | Grupos de máquinas definidos por onda, lista de exceções com um responsável por item. |
| 3. Estratégia | Rehospedar, replataformar, desativar ou manter atribuído por carga de trabalho | Cada carga de trabalho tem uma estratégia. |
| 4. Alvo | Políticas de rede, firewall, plano de IP, computação, armazenamento, identidade e segurança implementadas; backups das cargas de trabalho de origem realizados e teste de restauração realizado. | Teste de conectividade aprovado, capacidade cobre a carga máxima, restaurar registro de testes |
| 5. Replicar e testar | Agentes ou dispositivos implantados, replicação inicial concluída, migração de teste executada por grupo de aplicativos | Todas as máquinas sincronizadas, relatório de teste com problemas resolvidos. |
| 6. Transição | Janela de manutenção aprovada e usuários informados, réplica final, inicialização no horário previsto, testes de aceitação, tráfego redirecionado para o novo site. | Aprovação dos proprietários do aplicativo |
| 7. Valide e saia | Monitoramento, backup e recuperação de desastres em execução no novo local; contratos encerrados, discos formatados. | Alertas e trabalhos ativos, registro de desativação |
Estratégia de migração de data center: escolhendo uma abordagem
Diretrizes prescritivas da AWS para migrações de grande porte., significa movimentações de 300 ou mais servidores, define sete estratégias, conhecidas como os 7 Rs. Rehospedagem, replataformação, realocação e desativação são opções comuns em larga escala, e a recomendação é evitar a refatoração durante a migração por ser o caminho mais complexo.
| Estratégia | O que acontece | Serve quando |
|---|---|---|
| Aposentar | O aplicativo foi encerrado. | Sem valor comercial ou sem conexões de entrada por 90 dias. |
| Reter | O aplicativo permanece na origem. | Residência de dados, hardware especial, atualização recente |
| Rehospedagem | A aplicação é migrada tal como está (migração direta). | Grandes volumes e prazos apertados |
| Mudar de residência | Uma migração para a versão em nuvem da mesma plataforma. | A origem e o destino executam a mesma pilha de protocolos. |
| Replataforma | O aplicativo funciona com algumas otimizações. | Nova plataforma de banco de dados ou um sistema operacional mais recente está planejado. |
| Recompras | O aplicativo foi substituído por um produto SaaS. | Existe um fornecedor alternativo. |
| Refatorar | O aplicativo foi reconstruído para o alvo | Uma sólida justificativa comercial; geralmente após a mudança. |
A escolha da estratégia de migração do data center também determina o volume de trabalho que uma ferramenta pode assumir. Rehost e relocação executam a replicação de ponta a ponta. Replatform, recompra e refatoração exigem trabalho adicional na aplicação, portanto, geralmente são executados como projetos separados após a migração.
Minimizar o tempo de inatividade: replicação em tempo real versus migração a frio
O tempo de inatividade depende de como os dados chegam ao destino. Uma migração a frio interrompe o aplicativo, copia os dados e o inicia no novo local, portanto, a interrupção dura apenas o tempo da cópia. A replicação em tempo real é executada em segundo plano e a interrupção se limita ao switch final. A escolha é mais importante quando não há uma janela de manutenção longa o suficiente para copiar os dados offline.
| Aspecto | Transição a frio | Replicação ao vivo |
|---|---|---|
| Aplicação durante a cópia | Parou | Correndo |
| Duração da interrupção | Cresce com o volume de dados | Sincronização final e reinicialização |
| Testando antes da mudança | Limitado | Lançamentos de teste repetidos a partir de réplicas |
| Tente novamente após o rollback | A interrupção e a cópia completa acontecem novamente. | A replicação é retomada de onde parou, portanto, uma nova tentativa requer apenas outra pequena alteração. |
| Melhor ajuste | Sistemas pequenos e não críticos | Grandes propriedades ou propriedades essenciais para os negócios |
A duração dessa transição final depende da ferramenta utilizada. A plataforma Hystax funciona em cinco etapas: iniciar a replicação, armazenar os dados no destino, automatizar a orquestração, executar migrações de teste e realizar a transição final, que leva em média de 1 a 3 minutos. Os resultados dependem da carga de trabalho e do destino.
Fatores de cronograma e custo
Alguns fatores-chave determinam quanto tempo uma migração leva e quanto ela custa.
| Fator | Efeito na linha do tempo | Efeito sobre o custo |
|---|---|---|
| Número e tamanho das VMs | Replicação inicial mais longa | Mais espaço de armazenamento e largura de banda de destino. |
| Taxa de alteração de dados | Sincronização final maior | Execução paralela mais longa de ambos os sites |
| Largura de banda entre sites | Define a velocidade da primeira cópia. | Atualizações de links ou circuitos temporários |
| Complexidade de dependência | Mais ondas para coordenar | Mais horas de projeto |
| Licenciamento | Tempo de revisão por meta | Licenças que não são transferidas automaticamente: o RHEL rehospedado na AWS chega como BYOL (Bring Your Own License), portanto, requer assinaturas Red Hat elegíveis ou uma mudança para o modelo de preços com licença inclusa da AWS. |
| Ferramentas de migração | A ferramenta de migração precisa ser implantada antes do início da replicação. | O poder computacional é dimensionado de acordo com o número de máquinas que replicam simultaneamente. |
Desativação de data centers: descomissionamento e contratos
O encerramento do site antigo é a última fase, e grande parte dele envolve contratos: prazos de aviso prévio de aluguel ou colocation, suporte de hardware, circuitos de rede e licenças vinculadas ao hardware antigo. Os prazos de aviso prévio podem ser longos, portanto, verifique-os durante o planejamento, e não após a migração. Assim que as cargas de trabalho forem removidas, desative os aplicativos marcados para descontinuação durante a fase de descoberta, formate ou destrua os discos rígidos e arquive os certificados de sanitização e os registros de ativos.
Diga-nos qual é a sua corrida de hoje e nós traçaremos o percurso.
Obrigado pelo seu pedido!
Entraremos em contato em breve.
Melhores práticas e erros comuns na migração de data centers
As linhas abaixo mostram como as fases acima se apresentam quando uma delas é executada com pressa.
| Erro | O que acontece | Melhores práticas |
|---|---|---|
| Inventário incompleto | Servidores esquecidos vêm à tona após o fechamento do site antigo. | Os dados de descoberta foram comparados com o tráfego de rede e o monitoramento. |
| Dependências ausentes | Um aplicativo funciona sem seu banco de dados. | Grupos de dependência fixados antes do plano de ondas |
| Migrações de teste ignoradas | Problemas de inicialização e de drivers surgem na transição. | Lançamentos de teste repetidos em uma rede isolada |
| Uma grande mudança repentina | Uma única falha afeta toda a propriedade. | Ondas com um caminho de reversão definido |
| Licenciamento negligenciado | Cobranças inesperadas ou casos de não conformidade | Uma análise de licença por plataforma alvo |
| Capacidade da rede subestimada | A replicação atrasa e as janelas deslizam | Testes iniciais de largura de banda, com compressão e deduplicação. |
| Desativação antecipada | Não há alternativa quando um problema surge tardiamente. | Uma fonte somente leitura mantida por um período acordado. |
Como a plataforma Hystax automatiza a migração de data centers
A plataforma Hystax combina três produtos: Hystax Migration, Hystax Disaster Recovery e Hystax Backup. Migração Move cargas de trabalho entre centros de dados e nuvens em um padrão de "lift-and-shift": replicação inicial, réplicas incrementais, lançamentos de teste e uma migração final.
As fontes incluem VMware, OpenStack e oVirt no nível da plataforma, além de qualquer outra plataforma ou servidor físico ao nível da máquina.
Os alvos são divididos em dois grupos. As plataformas de nuvem privada e virtualização incluem OpenStack, Serviços Red Hat OpenStack no OpenShift, VMware, oVirt, Nebulosa Aberta, Virtuozzo, Apache CloudStack, KubeVirt, Red Hat OpenShift Virtualization, Oracle Linux KVM e Oracle Linux Virtualization Manager. As nuvens públicas incluem AWS, Microsoft Azure, Google Cloud, Alibaba Cloud, CloudSigma e STACKIT como uma opção europeia soberana.
A replicação pode ser executada de duas maneiras. Um agente interno é instalado dentro do sistema operacional convidado e abrange qualquer plataforma de virtualização ou servidor físico. Para sistemas VMware, oVirt e OpenStack, um dispositivo externo realiza a mesma função sem a necessidade de um agente em cada sistema operacional convidado. No VMware, a leitura dos discos é feita através da biblioteca VDDK da Broadcom. não está mais disponível para download público.. O agente interno não precisa disso.
UM Direto para alvo Essa opção envia dados replicados diretamente para os discos de destino por meio de um agente dedicado, sem qualquer chamada à API da plataforma de destino. Qualquer ambiente com acesso de gravação em nível de disco pode servir como destino, o que abrange plataformas com exposição limitada à API, infraestrutura isolada da internet e sites de borda.
Três casos de clientes demonstram a escalabilidade do software:
- UM empresa global de folha de pagamento Migramos do VMware para o Red Hat OpenStack Services no OpenShift: 500 VMs na primeira fase, e depois mais de 4.500 ao longo de um programa de dois anos. Em um Postagem no blog de setembro de 2026, A Red Hat relatou a presença de 9.000 VMs Windows e Linux no programa, incluindo cargas de trabalho de uma nuvem OpenStack legada. Posteriormente, surgiu a necessidade de uma alternativa ao VMware Site Recovery Manager, e o projeto evoluiu para uma prova de conceito de recuperação de desastres.
- CompuGroup Medical Migramos mais de 5.000 máquinas virtuais entre plataformas baseadas em OpenStack em poucos meses, usando uma implementação que é executada dentro do ambiente do cliente sem acesso à internet.
- UM provedor global de cibersegurança migrou milhares de máquinas virtuais do VMware para o RHOSO, de um total de mais de 10.000 planejadas, com as migrações finais concluídas em questão de minutos.
Assim que as cargas de trabalho estiverem em execução no novo centro de dados, recuperação de desastres e backup podem protegê-los lá, e o Regra de backup 3-2-1 descreve quantas cópias devem ser mantidas.
Deixe seu e-mail comercial e um engenheiro da Hystax irá orientá-lo(a) durante uma migração de teste.
Obrigado pelo seu pedido!
Entraremos em contato em breve.
Perguntas frequentes
Quanto tempo demora a migração de um data center?
A duração depende do volume de dados, da largura de banda, das dependências e da profundidade dos testes. Os projetos de clientes da Hystax variam de alguns meses a cerca de dois anos, dependendo do escopo.
Qual a diferença entre migração de data center e migração para a nuvem?
Os dois conceitos se sobrepõem: migrar de um data center local para uma nuvem pública é ambos. migração para nuvem Abrange também migrações entre nuvens. A migração de data center engloba mudanças entre locais diferentes, consolidação de data centers e configurações híbridas.
É possível realizar a migração de um data center com o mínimo de tempo de inatividade?
A replicação em tempo real mantém os aplicativos em execução durante a cópia, de modo que a interrupção se limita à troca final. Na plataforma Hystax, a transição leva em média de 1 a 3 minutos. Essa é uma média, não uma garantia.
O software de migração é compatível com servidores físicos?
Sim. Na plataforma Hystax, os servidores físicos são replicados por meio de agentes internos para Windows e Linux. Há duas limitações a serem consideradas: a migração P2V não converte BIOS para UEFI, portanto, uma máquina com BIOS precisa de um destino que suporte inicialização por BIOS. O agente Linux também não funciona em sistemas com Inicialização Segura (Secure Boot) ativada.
O que acontece com o antigo centro de dados após a migração?
Ele permanece intacto por um período acordado como medida de contingência, depois é desativado: os contratos são encerrados, os discos são formatados e os registros são arquivados, conforme descrito em Desativação do data center.
Qual o custo da migração de um data center?
Não existe um valor único que se aplique. Depende da quantidade de máquinas virtuais, da taxa de alteração de dados, da largura de banda, dos ambientes de teste, do licenciamento e de quanto tempo ambos os sites operam em paralelo.