A maioria dos programas de migração para a nuvem começa com uma varredura da infraestrutura. O Azure Migrate descobre as máquinas virtuais. O AWS Application Discovery Service mapeia os servidores. O Google Migration Center inventaria as cargas de trabalho. Em poucos dias, a equipe tem uma planilha com todos os servidores, sua utilização de CPU, seu consumo de memória e um custo estimado para executar a configuração equivalente na nuvem de destino. A avaliação da infraestrutura está concluída. O planejamento pode começar.
Mas não pode. Porque o inventário de infraestrutura informa qual hardware está executando seus aplicativos, não se esses aplicativos podem ser executados na nuvem, quanto custará adaptá-los para isso, quais têm dependências que serão afetadas pela migração, quais foram escritos com base em APIs obsoletas que a plataforma de nuvem não suporta ou quais contêm dez anos de lógica de negócios não documentada que precisarão ser compreendidas antes que qualquer conversão possa ser validada. A descoberta de infraestrutura é um pré-requisito para a avaliação da migração para a nuvem. Não é a avaliação em si.
Analise seu código antes de movê-lo.
SMART TS XL Mapeia todas as dependências, bloqueios e oportunidades de refatoração em todo o seu portfólio de aplicações.
Mais informaçõesO que é uma avaliação de migração para a nuvem?
Uma avaliação de migração para a nuvem é a análise estruturada que determina se, como e a que custo um conjunto de cargas de trabalho pode ser migrado para a nuvem. Ela fornece a base de evidências para três decisões: qual estratégia de migração aplicar a cada carga de trabalho, qual será o custo real da migração em termos de esforço e gastos com a nuvem, e em que sequência as cargas de trabalho devem ser migradas para gerenciar o risco de dependência.
Uma avaliação completa de migração para a nuvem abrange cinco dimensões distintas. As ferramentas de descoberta de infraestrutura abordam uma delas. As outras quatro exigem ferramentas, técnicas e conhecimentos especializados diferentes.
| Dimensão de avaliação | O que ele responde | Ferramentas Primárias |
|---|---|---|
| Infraestrutura | Quais servidores, máquinas virtuais e serviços existem? Quais são seus perfis de utilização? | Azure Migrate, AWS Application Discovery, Google Migration Center |
| Código de aplicação | O código é compatível com destinos na nuvem? O que precisa ser alterado? | Destaque do elenco, SMART TS XL, CloudPilot, Modernização de Aplicativos do GitHub Copilot |
| Dados | Quais são os volumes de dados existentes? Onde os dados estão armazenados? Quais são a complexidade da migração e as restrições de conformidade? | Serviço de Migração de Banco de Dados da AWS, Serviço de Migração de Banco de Dados do Azure, Striim |
| Segurança e compliance | Quais são os requisitos regulamentares aplicáveis? Quais são as lacunas de segurança existentes? Quais alterações de IAM e criptografia são necessárias? | AWS Security Hub, Microsoft Defender para Nuvem, Prisma Cloud |
| Custo e TCO | Qual é o custo total da migração e o custo total de propriedade após a migração? | Calculadora de preços da AWS, Calculadora de Custo Total de Propriedade (TCO) do Azure, Infracost, Capacidade de uso da nuvem da Apptio |
Organizações que gerenciam apenas a dimensão da infraestrutura elaboram planos de migração com escopo desconhecido. Elas descobrem surpresas relacionadas a aplicativos, dados, segurança e custos durante a migração, quando o custo para resolvê-las é mais alto.
As cinco dimensões da avaliação da migração para a nuvem
Avaliação de infraestrutura
A avaliação da infraestrutura é o ponto de partida. Ela inventaria o ambiente de origem: cada servidor, máquina virtual, contêiner e serviço, com sua configuração, dados de utilização e conexões de dependência com outros componentes da infraestrutura.
Ferramentas como o Azure Migrate ou outros produtos automatizam a descoberta de componentes e configurações de cargas de trabalho. Essas ferramentas reduzem o esforço manual e fornecem coleta de dados consistente em todo o seu ambiente, embora possam não detectar dependências não documentadas.
O Azure Migrate é o padrão para organizações que migram para o Azure. Ele realiza a descoberta sem agente de ambientes VMware vSphere, Hyper-V e servidores físicos, produzindo avaliações de prontidão, recomendações de dimensionamento adequadas com base no desempenho e estimativas de custos antes mesmo da migração de uma única carga de trabalho.
O AWS Application Migration Service (MGN) e o AWS Application Discovery Service desempenham funções equivalentes para destinos na AWS. O Discovery Service coleta dados de configuração e desempenho locais por meio de coleta sem agente ou com um agente instalado localmente.
O Google Migration Center oferece descoberta e avaliação unificadas para migrações do Google Cloud, combinando inventário de ativos, análise de dependências e modelagem de custo total de propriedade (TCO) em um único console.
O que as ferramentas de infraestrutura produzem: inventário de servidores, linhas de base de utilização, mapas de dependência de rede entre componentes de infraestrutura e recomendações de dimensionamento adequado para a camada de nuvem de destino. O que elas não produzem: qualquer informação sobre se os aplicativos em execução nesses servidores são compatíveis com a nuvem, quanto custará alterar o código ou como os dados desses aplicativos serão migrados.
Avaliação do código de aplicação
Uma avaliação do código do aplicativo identifica problemas de compatibilidade e oportunidades de modernização que podem afetar o sucesso da migração. Essa avaliação é essencial para garantir que os aplicativos sejam executados de forma confiável no Azure e para planejar as ondas de migração de forma eficaz. É necessário avaliar o código do aplicativo para detectar bloqueios precocemente, reduzir o risco de falha na migração e embasar as decisões sobre a arquitetura de destino.
A avaliação do código da aplicação identifica quatro categorias de problemas que a análise da infraestrutura não consegue detectar:
Bloqueadores de compatibilidade , APIs, frameworks ou recursos de tempo de execução que não existem ou se comportam de maneira diferente no ambiente de nuvem de destino. Um aplicativo Java desenvolvido para um servidor de aplicativos Java EE que não está disponível no serviço PaaS de destino precisa de alterações no código antes de ser implantado. Um aplicativo que usa uma convenção de caminho de arquivo específica do Windows não pode ser executado em uma instância de nuvem baseada em Linux sem modificações.
Suposições de infraestrutura codificadas , endereços IP, caminhos do sistema de arquivos, nomes de servidores ou números de portas incorporados no código que não serão mais válidos no ambiente de nuvem. Esses são bloqueios de migração que nenhuma varredura de infraestrutura encontrará, pois estão dentro do código do aplicativo, e não na configuração da infraestrutura.
Uso de APIs obsoletas , chamadas a APIs, bibliotecas ou recursos da plataforma que o ambiente de nuvem de destino não suporta ou que foram substituídos. Os provedores de plataformas de nuvem costumam descontinuar versões antigas de APIs, e os aplicativos que as utilizam falharão na nova plataforma, mesmo que funcionem corretamente hoje.
Complexidade de dependência , a estrutura interna da aplicação, que determina a dificuldade de migração e se ela pode ser dividida em serviços implantáveis independentemente. Uma aplicação monolítica com alto acoplamento interno é mais difícil e cara de migrar do que uma aplicação com baixo acoplamento, independentemente do que o inventário de infraestrutura indique.
O CAST Highlight realiza avaliações automatizadas de código de aplicativos em nível de portfólio, analisando o código-fonte em várias linguagens para gerar pontuações de prontidão para a nuvem, identificar bloqueios e realizar análises de risco de código aberto. Ele é referenciado no Azure Cloud Adoption Framework da Microsoft como uma ferramenta recomendada para cargas de trabalho que não utilizam .NET nem Java.
A CloudPilot é especializada em avaliações detalhadas de prontidão para a nuvem, com pontuação de compatibilidade e geração de roteiros de migração para JavaScript, Python, Node.js e Go.
O GitHub Copilot App Modernization combina os recursos de avaliação do AppCAT da CAST com a correção de código assistida por IA, especificamente para cargas de trabalho .NET e Java.
Para ambientes corporativos que abrangem COBOL, JCL, PL/I, RPG e outras linguagens de mainframe, além de sistemas modernos, essas ferramentas não oferecem cobertura. A avaliação de código de aplicativos para sistemas legados exige uma categoria de ferramenta completamente diferente.
Avaliação de Dados
A avaliação de dados determina a complexidade, o volume, os requisitos de conformidade e o método de migração para cada repositório de dados em escopo. Frequentemente, essa avaliação é subestimada, pois parece simples — basta mover o banco de dados, depois os dados —, até que a complexidade real se revele.
As principais questões que a avaliação de dados deve responder:
Volume e capacidade de transferência : Qual a quantidade de dados existentes? Qual a taxa de alteração? A migração pode ser feita sem tempo de inatividade ou é necessário usar replicação contínua para alcançar uma transição com tempo de inatividade próximo de zero?
Compatibilidade de esquema : O serviço de banco de dados de destino oferece suporte aos mesmos recursos de esquema, tipos de dados e procedimentos armazenados que a origem? Construções PL/SQL específicas do Oracle exigem conversão antes da migração para o PostgreSQL ou uma alternativa nativa da nuvem.
Soberania e conformidade de dados : Onde os dados devem residir legalmente? GDPR, HIPAA, PCI-DSS e regulamentações específicas do setor podem restringir quais regiões da nuvem podem hospedar categorias específicas de dados.
Acoplamento da aplicação : Quão fortemente o código da aplicação está acoplado ao esquema específico do banco de dados? Uma alteração de esquema que seja tecnicamente simples pode exigir extensas alterações no código da aplicação para ser adaptada.
O AWS Database Migration Service e o Azure Database Migration Service oferecem suporte à replicação contínua com tempo de inatividade mínimo para migrações homogêneas (Oracle para Oracle, SQL Server para SQL Server) e à conversão de esquema para migrações heterogêneas (Oracle para PostgreSQL, SQL Server para Aurora).
Striim e Attunity oferecem streaming e replicação de dados em tempo real para cenários de migração de alta disponibilidade, onde a indisponibilidade do banco de dados é inaceitável.
Avaliação de Segurança e Conformidade
A avaliação de segurança mapeia o estado atual de segurança de cada carga de trabalho e identifica as alterações necessárias para atender aos padrões de segurança em nuvem, estruturas de conformidade e princípios da arquitetura de confiança zero.
A avaliação de segurança dimensional deve abranger:
Gerenciamento de identidade e acesso (IAM) : Aplicativos locais geralmente usam contas de serviço com permissões amplas e autenticação baseada em senha. Ambientes em nuvem exigem controle de acesso baseado em funções, identidades de serviço com privilégios mínimos e autenticação baseada em certificado ou token. A lacuna entre o IAM atual e o necessário é um esforço de migração que não tem relação com o inventário de infraestrutura.
Criptografia : Os requisitos de criptografia de dados em repouso e em trânsito diferem entre ambientes locais e em nuvem. Aplicativos que gerenciam sua própria criptografia na camada de aplicação precisam se integrar a serviços de gerenciamento de chaves na nuvem. Armazenamentos de dados não criptografados que são aceitáveis em redes privadas exigem criptografia antes de serem migrados para serviços hospedados na nuvem.
Segurança de rede : as regras de firewall, a segmentação de rede e a inspeção de tráfego implementadas em hardware de rede local devem ser reconstruídas como grupos de segurança na nuvem, configurações de rede virtual e regras de firewall nativas da nuvem.
Alinhamento com a estrutura de conformidade : Cada setor regulamentado possui requisitos de conformidade específicos que se relacionam a configurações de nuvem específicas. As cargas de trabalho HIPAA exigem escolhas de configuração específicas em relação a armazenamento, registro de acesso e criptografia. O PCI-DSS exige segmentação de rede que deve ser implementada de forma diferente em uma VPC na nuvem do que em uma infraestrutura de rede física.
O Microsoft Defender para Nuvem fornece avaliação da postura de segurança e avaliação de conformidade com os padrões CIS, NIST, PCI-DSS e outras estruturas para cargas de trabalho do Azure.
O Prisma Cloud (Palo Alto Networks) e o AWS Security Hub oferecem avaliação de segurança e monitoramento de conformidade em múltiplas nuvens equivalentes.
Avaliação de custos e TCO
A avaliação de custos é o resultado mais visível da migração para as partes interessadas do negócio e também o que é mais frequentemente produzido incorretamente. O erro mais comum é comparar os custos atuais de hardware local com os custos de computação e armazenamento em nuvem, o que gera uma comparação incompleta e geralmente enganosa.
Uma avaliação completa do Custo Total de Propriedade (TCO) inclui:
Custos da infraestrutura em nuvem : custos de computação, armazenamento, rede e serviços gerenciados na configuração de nuvem desejada. O dimensionamento correto com base em dados reais de utilização (e não na capacidade provisionada) representa a diferença entre estimativas precisas e estimativas inflacionadas.
Custos do esforço de migração : As horas de engenharia necessárias para concluir as alterações no código do aplicativo, a migração de dados, a reconfiguração de segurança e os testes. Avaliações que consideram apenas a infraestrutura geralmente subestimam esse custo, pois não têm visibilidade da complexidade do aplicativo.
Alterações no licenciamento : A transição de licenças perpétuas locais para modelos de licenciamento baseados na nuvem, ou de software específico do fornecedor para alternativas nativas da nuvem, altera fundamentalmente a estrutura de custos de licenciamento.
Mudanças no modelo operacional : as equipes de operações locais, responsáveis pelo hardware físico, são substituídas por equipes de operações em nuvem, que gerenciam os serviços em nuvem. As habilidades, as ferramentas e o número de funcionários mudam.
Custos de treinamento e transição : Equipes que precisam aprender novas plataformas em nuvem, novos modelos de implantação e novos procedimentos operacionais incorrem em custos de produtividade durante a transição.
As calculadoras de preços da AWS , do Azure e do Google Cloud abordam a dimensão de custos da infraestrutura em nuvem. O Infracost fornece estimativas de custos integradas aos pipelines de IaC, gerando estimativas como parte do processo de CI/CD. O Apptio Cloudability e ferramentas similares de FinOps oferecem visibilidade contínua dos custos após a migração.
As sete estratégias de migração: como a avaliação determina qual se aplica.
A estrutura dos “7 Rs” descreve as estratégias disponíveis para cada migração de carga de trabalho. A avaliação determina qual estratégia é apropriada, e uma avaliação incorreta significa aplicar a estratégia errada, que é a causa principal da maioria dos estouros de orçamento em migrações.
| Estratégia | O que significa | Sinal de avaliação que o sugere |
|---|---|---|
| Rehospedar (elevar e deslocar) | Migre para a nuvem sem alterações de código. | Baixa complexidade de aplicação, sem bloqueios de compatibilidade, compatível com a infraestrutura. |
| Replataforma | Pequenas alterações para aproveitar os serviços em nuvem (por exemplo, migrar para um banco de dados gerenciado). | Acoplamento moderado, oportunidade específica de atualização da plataforma, escopo de alteração de código aceitável. |
| Refatorar | Reestruturar para padrões nativos da nuvem (microsserviços, contêineres) | Alto acoplamento monolítico, requisitos significativos de escalabilidade, justificados pelo crescimento esperado do tráfego. |
| Rearquitetar | Reformulação significativa da arquitetura do aplicativo. | Aplicação fundamentalmente incompatível com a nuvem; nova arquitetura proporciona grande benefício para os negócios. |
| Reconstruir | Reescrever do zero | O problema é irreparável do ponto de vista econômico; a substituição é mais barata que o reparo. |
| Substituir | Desative o aplicativo personalizado e adote uma alternativa SaaS. | O aplicativo oferece funcionalidades básicas que seriam melhor atendidas por um serviço de nuvem já existente. |
| Se aposentar | Desativar, o aplicativo não é mais necessário. | Aplicativo identificado como inativo, redundante ou substituído durante a avaliação. |
O inventário de infraestrutura não consegue distinguir entre candidatos a Rehost, Replatform, Refactor e Rebuild, pois todos parecem idênticos na camada de infraestrutura. A avaliação do código do aplicativo é o que faz essa distinção.
Avaliação da migração para a nuvem de sistemas legados e mainframe
As ferramentas padrão de avaliação de migração para a nuvem são projetadas para infraestruturas modernas: máquinas virtuais, contêineres, microsserviços e aplicações nativas da nuvem. Elas apresentam desempenho ruim ou nenhum desempenho para cargas de trabalho de mainframe, programas COBOL executados em IBM z/OS, fluxos de tarefas JCL que gerenciam processamento em lote, aplicações PL/I que lidam com transações financeiras e programas RPG incorporados em sistemas AS/400.
A avaliação da migração de mainframe para a nuvem exige uma abordagem fundamentalmente diferente, pois a camada de infraestrutura não é o fator limitante. O fator limitante é o código da aplicação, décadas de lógica de negócios acumulada, dependências implícitas por meio de conjuntos de dados e copybooks compartilhados, e comportamentos em tempo de execução que nenhuma análise de infraestrutura consegue revelar.
As oito análises necessárias antes que qualquer migração de mainframe possa ser planejada de forma responsável — inventário de programas, mapeamento de dependências, extração da lógica de negócios, identificação de código morto, classificação de complexidade, análise de agendamento de lotes, avaliação da qualidade dos dados e mapeamento de integração — são descritas em detalhes no contexto da mitigação de riscos da migração de mainframe . Cada uma delas é uma atividade de avaliação em nível de código, e não de infraestrutura.
Comparação de ferramentas de avaliação de migração para a nuvem
A tabela abaixo relaciona as principais ferramentas de avaliação de migração para a nuvem com a dimensão de avaliação que elas abordam e o cenário mais adequado para cada uma.
| ferramenta | Camada de avaliação | Alvo na nuvem | Mais Adequada Para |
|---|---|---|---|
| Migração do Azure | Infraestrutura | Azul | Descoberta de VMs e servidores, dimensionamento adequado, estimativa de custos do Azure |
| Serviço de descoberta de aplicativos da AWS | Infraestrutura | AWS | Descoberta de servidores locais para migrações da AWS |
| Central de Migração do Google | Infraestrutura | GCP | Inventário de ativos e custo total de propriedade (TCO) para migrações do GCP |
| Destaque do ELENCO | Código de aplicação | Multi-nuvem | Avaliação da prontidão de código em escala de portfólio em diversas linguagens |
| CloudPilot | Código de aplicação | Multi-nuvem | Análise detalhada de compatibilidade para Python, JS, Node.js e Go. |
| SMART TS XL | Mapeamento de código e dependências da aplicação | Multi-nuvem | Análise de portfólio em COBOL, JCL, mainframe e multilíngue |
| AWS DMS | Dados | AWS | Migração de banco de dados com conversão de esquema |
| Serviço de Migração de Banco de Dados do Azure | Dados | Azul | Migração de SQL Server, MySQL e PostgreSQL para o Azure |
| Estripar | Dados | Multi-nuvem | Replicação em tempo real para migração de dados sem interrupções. |
| Microsoft Defender para Nuvem | Total | Azure / Multi-nuvem | Avaliação da postura de segurança e conformidade |
| Nuvem Prisma | Total | Multi-nuvem | CSPM e conformidade em AWS, Azure e GCP. |
| Infracusto | Custo | Multi-nuvem | Estimativa de custos integrada à infraestrutura como código (IaC) em pipelines de CI/CD |
| Cloudabilidade do Apptio | Custo | Multi-nuvem | FinOps e gestão contínua de custos na nuvem |
| Corent SurPaaS | Infraestrutura + aplicação | Multi-nuvem | Orquestração de descoberta, avaliação e migração orientada por IA |
Como SMART TS XL Realiza avaliação do código da aplicação para migração para a nuvem.
SMART TS XL Aborda a camada de avaliação do código da aplicação que as ferramentas de infraestrutura não conseguem alcançar, especificamente para ambientes empresariais e legados onde o portfólio de aplicações abrange múltiplas linguagens, plataformas e gerações de tecnologia.
Para um programa de migração que inclui programas COBOL, fluxos de trabalho JCL, serviços Java, pipelines Python e esquemas SQL, SMART TS XL Constrói um modelo de dependência unificado para todos eles simultaneamente. Antes que a equipe de migração decida o que hospedar novamente, o que refatorar e o que desativar, SMART TS XL fornece:
Inventário completo do programa : Todos os programas-fonte, copybooks, procedimentos e esquemas em todas as linguagens do ambiente; o inventário real, não o documentado, que em ambientes legados normalmente diverge em 20 a 30%.
Mapeamento de dependências entre linguagens : O recurso de mapeamento de dependências da aplicação rastreia como um programa COBOL se conecta a um esquema DB2 consultado por um serviço Java, que alimenta um pipeline Python que produz a saída consumida por um frontend React moderno. Essa cadeia de dependências entre linguagens determina a sequência de migração; componentes com muitas dependências devem migrar somente depois que suas dependências estiverem prontas.
Identificação de código morto : Programas e procedimentos que nunca são chamados por nenhum caminho de execução de produção podem ser completamente excluídos do escopo da migração. Em grandes ambientes legados, isso normalmente representa de 10 a 25% do inventário total, resultando em uma redução significativa de custos já na fase de avaliação.
Classificação de complexidade : A funcionalidade de análise estática de código classifica cada programa por complexidade ciclomática, número de dependências de copybook, número de chamadas e outras métricas que determinam a dificuldade de migração. Programas de alta complexidade com muitas chamadas são candidatos a refatoração ou reconstrução. Programas de baixa complexidade e com poucas dependências são candidatos a rehospedagem.
Análise de impacto antes de qualquer mudança : A funcionalidade de análise de impacto responde à pergunta “o que será afetado se este programa mudar?” antes do início de qualquer atividade de migração, convertendo riscos desconhecidos em um escopo estruturado e enumerado.
Para organizações que planejam programas de migração de mainframe para a nuvem, SMART TS XL'S modernização legada A análise gera a avaliação pré-migração que os fornecedores de migração exigem antes do início do trabalho de conversão: inventário estrutural completo, gráfico de dependências, classificação de complexidade e relatório de exclusão de código morto.
O que uma avaliação completa de migração para a nuvem deve produzir
Uma avaliação só é valiosa se possibilitar decisões assertivas. Uma avaliação completa de migração para a nuvem deve gerar cinco entregáveis que, juntos, definem o programa de migração:
Inventário do portfólio de aplicações com atribuição de estratégia de migração : Todas as aplicações em escopo classificadas como Rehospedagem, Replataformação, Refatoração, Rearquitetura, Reconstrução, Substituição ou Desativação, com as evidências de avaliação que sustentam cada classificação.
Plano de migração baseado em dependências : a sequência na qual os aplicativos devem migrar, derivada do grafo de dependências em vez de agrupamentos arbitrários. Aplicativos sem dependências de entrada de outros aplicativos no escopo podem migrar nas primeiras ondas. Aplicativos dos quais muitos outros dependem migram em ondas posteriores, depois que seus dependentes estiverem prontos.
Estimativa do custo total da migração : esforço de engenharia, custos das ferramentas de migração, custos de execução paralela temporária e custos de treinamento, e não apenas diferenças nos custos de infraestrutura.
Modelo de Custo Total de Propriedade (TCO) pós-migração : Projeção de gastos com a nuvem com base em configurações dimensionadas corretamente e dados reais de utilização, comparada aos custos operacionais atuais em infraestrutura local, com premissas realistas sobre mudanças de licenciamento e transições de modelos operacionais.
Registro de riscos : Os riscos identificados, os bloqueios de compatibilidade, as migrações de dados complexas, as dependências não documentadas, as restrições de conformidade, com sua probabilidade, impacto e mitigação proposta para cada um.
Organizações que entregam todos os cinco itens antes do início da migração possuem as informações necessárias para o sucesso do programa. Já as organizações que ignoram a avaliação do código do aplicativo, a avaliação dos dados ou a avaliação de segurança entregam versões incompletas desses itens e descobrem as lacunas durante a migração, quando cada descoberta gera custos adicionais para sua resolução.
