A IBM já anunciou o preview do z/VM 7.5, com disponibilidade prevista para o 3Q26 (provavelmente no próximo Setembro). Veja neste link. Como alguém que acompanha a evolução do Mainframe desde 1984, vejo este lançamento não apenas como uma atualização, mas como um chamado à ação.

Entre outras coisas, o z/VM 7.5 traz o Host Secure Boot e uma escalabilidade de memória massiva (mínimo de 4 GB reais), além de suporte nativo para aceleração de IA com os adaptadores Spyre. Mas aqui está uma provocação: a tecnologia está avançando, mas e o seu capital humano? Com a exigência mínima de um hardware IBM z16, a complexidade da migração aumenta.

Sua equipe atual possui o know-how para configurar esses novos parâmetros de segurança e otimizar o gerenciamento de memória sem riscos de interrupção? O vácuo de especialistas no mercado é real. A Clovis Consulting nasceu justamente para ser o braço técnico que garante que essa inovação não se torne um gargalo operacional na sua empresa.

Muitos fatores envolvem uma mudança de cidades, quando se trata de TI. Cada Centro de Processamento de Dados possui fatores críticos e próprios, exigindo abordagens diferentes.
Para citar só os principais:

É uma atividade que exige muita experiência, aceitação de riscos, planejamento e dedicação.

Sobre o fator custo, é a solução mais simples e menos aceita. Mainframes significam equipamentos muito caros. A solução de montar outro Centro duplicando os equipamentos é simplesmente inviável.

A disponibilidade é outro complicador. Parar um CPD significa parar TODOS os sistemas, não apenas um aplicativo. Todos os equipamentos devem ser desativados, desmontados, transportados, remontados e reativados. Tudo isto consome tempo, o que leva ao proximo complicador.

Prazos no mundo corporativo são sempre curtos. Sistemas parados representam um enorme problema.

Em 1994 eu recebi um desafio neste nível.

Custo, deveria ser o menor possível. Disponibilidade, o mais próximo de 100%. Tempo, o menor, considerando a disponibilidade.

A meu favor: O site a ser movido se destinava a rodar serviços de Disaster Recovery. Ou seja, a produção se resumia a disponibilidade. Como desastres não são previsíveis, o DR-site deve estar vivo o tempo todo. Outra vantagem justificando meu envolvimento: rodava dois sistemas z/VM, um principal e um auxiliar, em dois mainframes distintos.

Minha estratégia foi muito simples: dividir para conquistar. Usei a principal característica do z/VM, a capacidade de rodar qualquer outro sistema em segundo nível, incluindo outro z/VM.

O plano:

Requisitei duas semanas, travando a agenda como "Atividade Interna". Esse era o prazo.

Na primeira semana dividi os equipamentos em duas metades. CPU, discos, fitas, terminais, equipamentos de network.
Garanti copias das duas imagens z/VM nos dois conjuntos de discos, o que ficaria ativo e o que seria transportado.
No primeiro fim de semana: desligamos o z/VM auxiliar. Foi religado em segundo nível dentro do z/VM principal. Desligamos e transportamos a primeira metade de equipamentos para o site destino, mantendo os dois sistemas rodando no site origem. Disponibilidade garantida.
Na segunda semana, os equipamentos foram remontados no site destino.
No segundo fim de semana: desligamos as duas imagens z/VM no site origem. O z/VM principal foi religado dentro do z/VM auxiliar na outra cidade. Desligamos e transportamos o restante dos equipamentos, mantendo os dois sistemas rodando no novo site. Disponibilidade garantida.
A terceira semana começou com todos os sistemas rodando na nova cidade. Sem nenhuma indisponibilidade durante a mudança. Custo, apenas a transportadora. Prazo, duas semanas.

Pela segunda vez em minha vida, estive na Convenção entre os Melhores do Ano, desta vez em 1994.