Planejar uma migração para o Azure em empresas de médio e grande porte raramente significa mover tudo de uma só vez. O desafio aparece quando é preciso decidir o que vai primeiro, o que pode esperar e como agrupar sistemas que compartilham dependências sem concentrar risco em um único corte. Este artigo apresenta o modelo de ondas de migração para Azure como ferramenta de decisão e mostra como aplicá-lo ao sequenciamento real das cargas de trabalho.
O que é o modelo de ondas de migração para Azure
O modelo de ondas de migração para Azure é uma abordagem de planejamento que divide a jornada para a nuvem em agrupamentos sequenciais de cargas de trabalho, chamados ondas. Cada onda reúne um conjunto de aplicações, bancos de dados e servidores que serão avaliados, migrados, testados e colocados em produção dentro de um mesmo ciclo. Em vez de tratar centenas de ativos de TI como um bloco único, o modelo reconhece que diferentes sistemas têm níveis distintos de criticidade, dependência e prontidão para a nuvem.
Na prática, uma onda funciona como uma unidade de entrega com escopo fechado: tem critérios de entrada, atividades de migração, validação de saída e um conjunto de lições aprendidas que alimenta a onda seguinte. Isso permite que uma empresa de médio ou grande porte — especialmente aquelas que lidam com dados sensíveis ou transações financeiras — reduza a exposição a falhas concentradas. O modelo não elimina riscos, mas os distribui em ciclos menores e mais controláveis.
Ondas como unidade de planejamento, não como cronograma rígido
Um erro frequente é confundir ondas com fases fixas de um cronograma. A onda não é simplesmente "mês 1, mês 2, mês 3". Ela é uma unidade de planejamento que combina escopo técnico, capacidade do time e critérios de negócio. Uma onda pode durar três semanas ou três meses, dependendo da complexidade das cargas de trabalho agrupadas, da maturidade da equipe e das janelas de mudança autorizadas pelo negócio.
O valor do modelo está justamente na flexibilidade: se uma onda revela um problema inesperado — uma dependência de dados não documentada, um componente legado sem dono claro —, o plano pode ser reajustado antes que o problema contamine todo o programa. O cronograma passa a ser consequência do agrupamento, e não o contrário. Isso é especialmente relevante em ambientes regulados, onde a indisponibilidade de um sistema transacional pode gerar impacto financeiro imediato.
Como o modelo de ondas se conecta ao Cloud Adoption Framework
O Cloud Adoption Framework (CAF) da Microsoft organiza a adoção de nuvem em metodologias como Estratégia, Planejar, Preparar, Adotar, Governar e Gerenciar. O modelo de ondas se encaixa principalmente na metodologia Adotar, que trata da migração e da inovação. Dentro do CAF, a migração é conduzida por meio de iterações — e cada iteração corresponde, na prática, a uma onda com escopo definido.
O CAF também fornece os artefatos que sustentam o modelo: avaliação de prontidão, racionalização do patrimônio digital, landing zones e planos de adoção. A onda é o mecanismo operacional que transforma esses artefatos em entregas sequenciais. Sem o CAF, o modelo de ondas vira apenas uma lista de tarefas; com o CAF, cada onda carrega consigo requisitos de governança, segurança e operação que precisam estar prontos antes da primeira migração.
Por que migrar em ondas em vez de tudo de uma vez
A migração monolítica — mover todo o ambiente de uma só vez — concentra risco em um único evento de corte. Qualquer falha não prevista atinge simultaneamente sistemas de folha de pagamento, portais de clientes, bancos de dados transacionais e infraestrutura de apoio. O modelo de ondas dilui esse risco ao permitir que cada ciclo seja validado isoladamente antes de comprometer o próximo conjunto de cargas de trabalho.
Além da segurança operacional, há um argumento econômico: migrar em ondas permite que a empresa comece a operar no Azure enquanto outras partes do ambiente ainda estão on-premise. Isso gera aprendizado real, reduz a necessidade de manter dois ambientes completos em paralelo por longos períodos e permite ajustar estimativas de custo com base em consumo observado, não apenas projetado.
Riscos de uma migração monolítica
Uma migração do tipo big bang concentra todas as dependências em um único ponto de falha. Se um sistema legado de integração não se comporta como esperado na nuvem, o impacto se propaga para todas as aplicações conectadas a ele. Em ambientes financeiros, isso pode significar interrupção de processamento de pagamentos, conciliação e canais digitais simultaneamente.
Outro risco é a perda de capacidade de correção de rota. Quando tudo migra de uma vez, não há oportunidade de testar hipóteses em pequena escala, como o desempenho de um banco de dados em discos gerenciados ou a latência de uma aplicação distribuída entre regiões. O modelo de ondas cria ciclos de feedback curtos: o que se aprende na primeira onda ajusta a segunda, e assim por diante.
- Falha única afeta todos os sistemas ao mesmo tempo
- Sem ciclos de feedback para corrigir a rota
- Pressão extrema sobre a equipe em um único evento de corte
- Dificuldade de isolar a causa de problemas pós-migração
- Maior exposição a dependências não documentadas
Ganhos de aprendizado e previsibilidade entre ondas
Cada onda concluída gera dados reais: tempo efetivo de migração por tipo de carga, consumo de rede, comportamento de licenciamento e custos de computação. Esses dados substituem estimativas iniciais por métricas observadas, aumentando a previsibilidade das ondas seguintes. Uma equipe que migra dez servidores na primeira onda sabe, com muito mais precisão, quanto esforço será necessário para os próximos cinquenta.
O aprendizado também é organizacional. Procedimentos de comunicação, planos de reversão e rotinas de validação são testados em escala reduzida antes de se tornarem padrão. Isso constrói confiança com as áreas de negócio, que passam a ver a migração como um processo incremental e gerenciável, e não como um salto no escuro.
Como definir os critérios de agrupamento das ondas
O agrupamento das ondas não deve ser feito por intuição ou por conveniência política. Ele exige critérios objetivos, documentados e pontuáveis, que permitam justificar por que uma carga de trabalho entra na onda 1 e outra na onda 4. Os critérios mais eficazes combinam dimensões técnicas, de negócio e de prontidão organizacional.
Uma prática comum é criar uma matriz de pontuação em que cada carga de trabalho recebe notas em diferentes eixos — dependência, criticidade, afinidade com o Azure, esforço estimado e maturidade do time. A soma ponderada dessas notas define a ordem de entrada nas ondas. O importante é que os pesos reflitam as prioridades reais da empresa, e não apenas a facilidade técnica.
Dependências técnicas e de dados entre cargas de trabalho
Cargas de trabalho que compartilham bancos de dados, filas de mensagens, APIs ou sistemas de autenticação precisam ser tratadas como um conjunto coeso. Migrar uma aplicação sem seu banco de dados de apoio — ou sem a camada de integração que a conecta a outros sistemas — cria um ambiente quebrado na nuvem. O mapeamento de dependências é, portanto, o primeiro filtro de agrupamento.
Dependências de dados merecem atenção especial. Sistemas que gravam em um mesmo banco ou que trocam arquivos em diretórios compartilhados não podem ser separados em ondas distintas sem um plano de sincronização. Ferramentas como o Azure Migrate ajudam a visualizar essas conexões, mas a validação final depende de entrevistas com os times que operam os sistemas no dia a dia.
Criticidade de negócio, janelas de mudança e tolerância a indisponibilidade
Sistemas com baixa tolerância a indisponibilidade — processamento de pagamentos, autorização de transações, conciliação financeira — normalmente não entram na primeira onda. Eles exigem que a equipe já tenha validado procedimentos de migração em cargas menos críticas. A primeira onda costuma ser composta por sistemas internos, de apoio administrativo ou ambientes de desenvolvimento e homologação.
As janelas de mudança também influenciam o agrupamento. Uma carga de trabalho que só pode ser migrada em fins de semana específicos, ou fora do horário comercial, precisa ser planejada com mais antecedência. Se duas cargas críticas disputam a mesma janela, uma delas precisa ser movida para uma onda posterior ou receber um plano de migração com replicação contínua para reduzir o tempo de corte.
Afinidade com serviços de destino no Azure
Algumas cargas de trabalho migram com pouco esforço porque já são compatíveis com os serviços de destino. Servidores Windows com SQL Server, por exemplo, têm caminho relativamente direto para máquinas virtuais no Azure ou para o Azure SQL Managed Instance. Aplicações web baseadas em .NET podem ser movidas para o Azure App Service com ajustes moderados.
Agrupar cargas de alta afinidade nas primeiras ondas acelera os ganhos iniciais e gera confiança. Cargas com baixa afinidade — sistemas legados com dependências de hardware específico, componentes de terceiros sem suporte ou arquiteturas monolíticas antigas — exigem mais análise e normalmente entram em ondas intermediárias ou finais, quando a equipe já domina as ferramentas de migração.
Esforço, risco e maturidade do time por carga de trabalho
O esforço estimado de migração varia conforme a complexidade da carga, o volume de dados e o número de dependências. Uma aplicação simples com banco pequeno pode ser migrada em dias; um ERP legado com centenas de tabelas e integrações pode levar semanas. Esse esforço precisa ser ponderado com o risco associado: uma carga de esforço médio mas risco alto pode ser adiada, enquanto uma carga de esforço baixo e risco baixo é candidata natural à primeira onda.
A maturidade do time também conta. Se a equipe nunca operou no Azure, as primeiras ondas devem priorizar cargas que exijam menos conhecimento profundo de serviços gerenciados. À medida que o time ganha fluência em redes virtuais, identidade, monitoramento e automação, ondas mais complexas se tornam viáveis sem depender exclusivamente de consultoria externa.
Etapas para montar o plano de ondas no Azure
Montar um plano de ondas é um processo estruturado que começa muito antes da primeira migração. Ele exige inventário completo, avaliação de dependências, pontuação de prioridades e validação com as áreas de negócio. Pular qualquer etapa resulta em ondas mal dimensionadas, surpresas durante a execução e retrabalho.
O plano de ondas é um documento vivo. Ele deve ser revisado após cada onda concluída, incorporando os dados reais de esforço, custo e desempenho observados. A primeira versão do plano é uma hipótese fundamentada; a versão após a terceira onda é uma projeção com base empírica.
Inventário e avaliação do ambiente atual
O ponto de partida é um inventário confiável de servidores, bancos de dados, aplicações, dispositivos de rede e contas de serviço. O Azure Migrate automatiza parte desse trabalho, coletando dados de desempenho e configuração de ambientes VMware, Hyper-V e servidores físicos. O inventário precisa responder a perguntas básicas: quantas cargas de trabalho existem, onde estão hospedadas, quem as utiliza e quais são seus requisitos de desempenho.
Além do inventário técnico, é necessário um inventário de negócio: dono de cada sistema, criticidade, requisitos de conformidade e janelas de manutenção. Sem esse mapeamento, a priorização vira um exercício puramente técnico e tende a ignorar restrições que só as áreas de negócio conhecem.
Priorização e pontuação das cargas de trabalho
Com o inventário em mãos, cada carga de trabalho recebe uma pontuação nos eixos definidos anteriormente. Uma abordagem simples usa escala de 1 a 5 para cada critério e pesos diferentes conforme a prioridade da empresa. O resultado é uma lista ordenada que indica a sequência natural de entrada nas ondas.
- Atribuir notas de dependência, criticidade, afinidade, esforço e risco
- Aplicar pesos conforme as prioridades do negócio
- Gerar uma lista ordenada de cargas de trabalho
- Agrupar cargas interdependentes no mesmo conjunto
- Revisar a lista com as áreas de negócio antes de congelar as ondas
Desenho da primeira onda e das ondas seguintes
A primeira onda deve ter escopo reduzido, risco baixo e valor de aprendizado alto. Candidatas típicas incluem ambientes de desenvolvimento, servidores de arquivos internos, aplicações departamentais e cargas de trabalho com pouca integração. O objetivo da primeira onda não é migrar o sistema mais importante da empresa, mas validar o processo de ponta a ponta: rede, identidade, backup, monitoramento e operação.
As ondas seguintes aumentam progressivamente em complexidade e criticidade. A segunda onda pode incluir aplicações de negócio com dependências moderadas; a terceira, sistemas transacionais com janelas de corte específicas; as ondas finais, cargas que exigem refatoração ou que dependem de serviços do Azure ainda não totalmente dominados pela equipe.
Validação com as partes interessadas e ajuste do plano
O plano de ondas precisa ser validado com donos de sistemas, áreas de negócio, segurança da informação e compliance. Cada área deve confirmar que as janelas propostas são viáveis, que os critérios de aceite fazem sentido e que os riscos foram adequadamente considerados. Essa validação reduz a chance de bloqueios durante a execução.
Após cada onda, o plano é revisitado. Se uma carga de trabalho se mostrou mais complexa do que o previsto, as ondas seguintes são rebalanceadas. Se o time ganhou velocidade, cargas podem ser antecipadas. O ajuste contínuo é parte do modelo, não um sinal de falha de planejamento.
Estratégias de migração aplicadas dentro de cada onda
Uma onda não precisa ser homogênea em termos de estratégia de migração. É perfeitamente possível — e comum — que uma mesma onda contenha cargas de trabalho migradas por rehost, outras por replatform e algumas por refactor. O que define a estratégia é a avaliação individual de cada carga, não a onda em que ela está inserida.
Os chamados 7Rs da migração — rehost, replatform, refactor, rearchitect, rebuild, replace e retain — são o vocabulário padrão para classificar essas decisões. Dentro do modelo de ondas, eles funcionam como opções disponíveis para cada carga, aplicadas conforme o objetivo de negócio e o retorno esperado.
Rehost, replatform e refactor na mesma onda
Rehost, ou lift-and-shift, é a migração de uma carga de trabalho sem alterações significativas de arquitetura. É a estratégia mais rápida e de menor risco, adequada para sistemas que funcionam bem e não se beneficiam de mudanças imediatas. Replatform envolve ajustes moderados — como mover um banco de dados para um serviço gerenciado ou trocar um servidor de aplicação por um PaaS — sem reescrever a lógica de negócio.
Refactor exige modificação do código ou da arquitetura para aproveitar capacidades nativas da nuvem, como escalabilidade automática, contêineres ou funções serverless. Uma onda pode combinar as três estratégias: um servidor de arquivos vai por rehost, um portal web por replatform e uma aplicação legada de integração por refactor. O que as une é o ciclo de migração compartilhado, não a técnica aplicada.
Quando reter ou desativar cargas de trabalho
Nem toda carga de trabalho precisa migrar. Algumas devem ser retidas on-premise por restrições regulatórias, dependência de hardware específico ou custo proibitivo de migração. Outras devem ser desativadas porque se tornaram redundantes, foram substituídas por sistemas mais novos ou têm uso residual que não justifica o esforço.
A decisão de reter ou desativar deve ser documentada com o mesmo rigor da decisão de migrar. Reter uma carga sem prazo de revisão cria um ambiente híbrido permanente sem governança. Desativar uma carga sem comunicação adequada pode interromper processos que ainda dependem dela. Ambas as decisões entram no plano de ondas como ações explícitas, com dono e data de revisão.
Ferramentas do Azure que apoiam a execução por ondas
O Azure oferece um conjunto de serviços que sustentam cada fase do modelo de ondas, desde a descoberta inicial até a operação pós-migração. Essas ferramentas não substituem o planejamento, mas reduzem o esforço manual e aumentam a consistência entre ondas.
A escolha das ferramentas deve acompanhar a estratégia definida para cada carga. Uma migração por rehost usa recursos diferentes de uma por refactor. O importante é que as ferramentas estejam integradas ao plano de ondas e gerem os dados necessários para as métricas de saída de cada ciclo.
Azure Migrate e avaliação de dependências
O Azure Migrate é o hub central para descoberta, avaliação e migração. Ele coleta dados de ambientes on-premise, identifica dependências entre servidores e aplicações, e gera recomendações de dimensionamento para máquinas virtuais e bancos de dados no Azure. A análise de dependências é particularmente útil para definir os agrupamentos das ondas, pois revela conexões que não estão documentadas em lugar nenhum.
O serviço também produz estimativas de custo baseadas no uso real observado, não em suposições. Isso permite que cada onda tenha uma projeção financeira mais realista antes da migração, alimentando as discussões de FinOps desde o início do programa.
Database Migration Service e migração de dados
O Azure Database Migration Service (DMS) automatiza a migração de bancos de dados SQL Server, PostgreSQL, MySQL e outros para serviços gerenciados no Azure. Ele suporta migração online com replicação contínua, o que reduz a janela de corte para bancos de dados grandes ou de alta transação. Essa capacidade é crítica para cargas de trabalho financeiras que não podem ficar horas indisponíveis.
Para bancos de dados que exigem cuidados adicionais, o DMS permite validar a compatibilidade antes da migração e executar migrações de teste. Integrar o DMS ao plano de ondas significa que cada banco de dados tem um caminho de migração definido, com tempo de corte estimado e plano de contingência caso a replicação falhe.
Azure Monitor, Backup e recuperação por onda
Cada onda precisa entrar em produção com monitoramento e backup configurados desde o primeiro dia. O Azure Monitor coleta métricas, logs e alertas das cargas de trabalho migradas, permitindo comparar o comportamento na nuvem com o baseline on-premise. O Azure Backup garante que cada carga migrada tenha proteção de dados equivalente ou superior à que tinha antes.
A recuperação de desastres também entra nessa equação. Cargas críticas migradas em ondas intermediárias ou finais podem exigir replicação para uma segunda região do Azure. Para entender como estruturar essa proteção em ambientes terceirizados, vale consultar recuperação de desastres terceirizada. E para cargas que ainda convivem com infraestrutura local, o backup em ambientes híbridos é um complemento essencial.
Governança, segurança e operação entre ondas
O modelo de ondas só funciona se a fundação de governança estiver pronta antes da primeira migração. Isso inclui assinaturas organizadas, grupos de gerenciamento, políticas de nomenclatura, controles de acesso e, principalmente, landing zones bem desenhadas. Migrar cargas de trabalho para um ambiente sem essa fundação gera retrabalho e dívida técnica.
Segurança e conformidade não são atividades que acontecem depois da migração. Elas precisam estar embutidas em cada onda, com requisitos claros de criptografia, gerenciamento de identidade, registro de auditoria e segregação de ambientes. Em setores regulados, a ausência desses controles pode inviabilizar a operação na nuvem.
Landing zones e políticas que precisam existir antes da primeira onda
Landing zones são ambientes pré-configurados no Azure que recebem as cargas de trabalho migradas. Elas definem a estrutura de rede, os limites de assinatura, as políticas de segurança e os padrões de identidade. O Azure Landing Zone Accelerator fornece implantações de referência que seguem as recomendações do CAF, acelerando a preparação do ambiente.
Políticas do Azure Policy, controles do Microsoft Defender for Cloud e padrões de tagging precisam estar definidos antes da primeira onda. Sem eles, cada onda migra cargas para um ambiente ligeiramente diferente, criando inconsistências que se acumulam e dificultam a operação e a auditoria. A padronização prévia é o que permite que ondas posteriores sejam executadas com velocidade crescente.
Plano de reversão e critérios de aceite por onda
Cada onda precisa ter um plano de reversão documentado. Se uma carga de trabalho migrada apresentar problemas graves após o corte, a equipe deve saber exatamente como retornar ao ambiente on-premise ou, quando isso não for possível, como ativar um ambiente de contingência. O plano de reversão define prazos, responsáveis e gatilhos para acionamento.
Os critérios de aceite são as métricas que determinam se uma onda foi concluída com sucesso. Eles incluem indicadores técnicos — desempenho, disponibilidade, integridade dos dados — e indicadores de negócio — validação das áreas usuárias, ausência de incidentes críticos em um período de observação. Uma onda só é considerada concluída quando todos os critérios são atendidos, não apenas quando a migração técnica termina.
O que define o custo e o esforço de uma migração em ondas
O custo de uma migração em ondas não é determinado apenas pelo número de servidores ou pelo volume de dados. Ele resulta de uma combinação de fatores que incluem a complexidade das dependências, a estratégia escolhida para cada carga, a maturidade da equipe e a qualidade da fundação de governança. Entender esses fatores permite estimar o esforço com mais precisão e evitar surpresas.
Também é importante distinguir o custo da migração em si do custo de operação na nuvem. O primeiro é um investimento pontual; o segundo é recorrente e precisa ser gerenciado continuamente. O modelo de ondas ajuda a separar esses dois momentos, porque cada onda tem seu próprio custo de migração e passa a contribuir para o custo operacional assim que entra em produção.
Fatores que mais impactam prazo e consumo de recursos
O volume de dados a ser transferido é um dos fatores mais diretos: quanto maior o banco de dados ou o conjunto de arquivos, maior o tempo de replicação e a necessidade de largura de banda. Cargas com dados na casa de terabytes exigem planejamento de transferência offline ou replicação contínua com corte curto. A distância entre o datacenter on-premise e a região do Azure também influencia a latência e o tempo total.
A complexidade das dependências é outro fator crítico. Uma carga de trabalho com dezenas de integrações exige muito mais esforço de análise e teste do que uma aplicação isolada. E a estratégia de migração tem impacto direto: rehost é mais rápido e barato; refactor exige desenvolvimento, testes e, muitas vezes, a participação de fornecedores ou equipes especializadas.
- Volume de dados e largura de banda disponível
- Número e complexidade das dependências entre sistemas
- Estratégia de migração escolhida para cada carga
- Maturidade da equipe em operação no Azure
- Qualidade da fundação de governança e das landing zones
- Número de janelas de mudança disponíveis por mês
Como acompanhar e otimizar o consumo ao longo das ondas
O acompanhamento de custo começa na primeira onda, com a definição de tags obrigatórias para todos os recursos criados. Tags de centro de custo, ambiente e carga de trabalho permitem que o Microsoft Cost Management gere relatórios por onda, por sistema e por área de negócio. Sem tags, o custo da nuvem vira uma caixa-preta impossível de atribuir.
A otimização é um processo contínuo. Recursos dimensionados com folga na migração podem ser reduzidos após algumas semanas de observação. Máquinas virtuais que ficam ociosas fora do horário comercial podem ser desligadas automaticamente. Reservas de capacidade podem ser adquiridas quando o consumo se estabiliza. Cada onda gera dados que alimentam a otimização das ondas seguintes e do ambiente como um todo.
Erros comuns ao aplicar o modelo de ondas no Azure
Mesmo com um bom planejamento, o modelo de ondas pode falhar se alguns erros clássicos não forem evitados. Esses erros geralmente decorrem de pressa, excesso de otimismo ou subestimação da complexidade organizacional envolvida na migração.
Reconhecer esses padrões com antecedência permite que o plano de ondas inclua salvaguardas específicas. A maioria dos erros não é técnica, mas de gestão: escopo mal dimensionado, dependências ignoradas e falta de visão de longo prazo.
Ondas grandes demais ou dependentes de uma única equipe
Uma onda com cinquenta cargas de trabalho deixa de ser uma unidade gerenciável e volta a se comportar como uma migração monolítica disfarçada. O tempo de execução se estende, os critérios de aceite se diluem e a capacidade de correção de rota desaparece. Uma boa regra prática é dimensionar a onda para que possa ser concluída em um ciclo curto o suficiente para gerar aprendizado, mas longo o suficiente para entregar valor perceptível.
Dependência excessiva de uma única equipe ou de poucas pessoas-chave é outro risco. Se todo o conhecimento de migração está concentrado em duas ou três pessoas, o programa inteiro fica vulnerável a férias, saídas ou sobrecarga. O modelo de ondas deve incluir a disseminação de conhecimento: documentação, pares trabalhando juntos e rotação de responsabilidades entre ondas.
Ignorar dependências ocultas e dados compartilhados
Dependências ocultas são a causa mais comum de falhas em migrações. Um sistema que parecia isolado descobre-se conectado a um banco de dados compartilhado, a uma fila de mensagens ou a um serviço de autenticação que não estava no inventário. Quando isso acontece no meio de uma onda, o cronograma estoura e a confiança das áreas de negócio é abalada.
Dados compartilhados merecem atenção redobrada. Se duas aplicações gravam no mesmo banco, migrar uma sem a outra exige sincronização ou replicação temporária. A análise de dependências do Azure Migrate ajuda, mas não substitui a validação com os times de operação. Entrevistas com quem opera os sistemas no dia a dia revelam conexões que nenhuma ferramenta consegue mapear sozinha.
Tratar a migração como projeto com fim, e não como capacidade contínua
Um erro estratégico é tratar o modelo de ondas como um projeto que termina quando a última carga de trabalho migra. Na prática, a capacidade de migrar — avaliar, planejar, executar, validar e operar cargas na nuvem — deve se tornar uma competência permanente da organização. Novos sistemas serão adquiridos, fusões e aquisições trarão novos ambientes, e a própria evolução da nuvem exigirá migrações adicionais.
Manter essa capacidade contínua significa preservar a documentação, os padrões, as automações e o conhecimento acumulado ao longo das ondas. Também significa manter as ferramentas de avaliação e os processos de governança ativos. A proteção de dados é parte dessa capacidade permanente: entender backup imutável ou backup anti ransomware faz parte da operação contínua de um ambiente que já está na nuvem. O modelo de ondas, nesse sentido, é o início de uma prática de gestão de portfólio de TI que não tem data para acabar.
