Entender como funciona a migração para nuvem exige olhar para o projeto como uma sequência de descoberta, business case, estratégia por workload, landing zone, ondas, cutover e validação. A execução também precisa prever dependências, rollback, custos de coexistência e descomissionamento da infraestrutura de origem antes de considerar a migração concluída.
Entender como funciona a migração para nuvem começa pelo inventário dos workloads e das dependências que sustentam cada processo de negócio. Antes de mover servidores, a empresa precisa saber quais sistemas se comunicam, quais requisitos de disponibilidade devem ser preservados e quanto a infraestrutura atual realmente custa.
A partir desse diagnóstico, o projeto define a estratégia adequada para cada workload, prepara a landing zone, organiza as cargas em ondas e estabelece os critérios de cutover e rollback. A migração não termina quando a aplicação sobe na nuvem: ainda é necessário validar a operação, ajustar o dimensionamento e desligar os recursos de origem para eliminar a coexistência de custos.
Na prática, a execução se distribui em sete fases, com riscos e decisões próprias em cada uma. O método reduz improvisação na janela de virada e dá ao financeiro uma visão mais clara do investimento antes da primeira onda.
Entender o método: cinco etapas oficiais, sete fases na prática
O Cloud Adoption Framework organiza a migração em cinco passos: planejar, preparar os workloads, executar, ajustar e descomissionar a origem. O quinto some da maioria das propostas comerciais, e é onde a economia aparece.
Num projeto de empresa média, esses cinco passos se abrem em sete fases: descoberta e inventário, business case, estratégia por sistema, landing zone, ondas com piloto, cutover com rollback e validação com descomissionamento. Cada fase produz o insumo da seguinte.
Pular a primeira não acelera nada: empurra a descoberta para dentro da janela de virada, o pior lugar do projeto para descobrir qualquer coisa. Projeto que começa pela ferramenta refaz o inventário no meio da onda.
Fase 1: descobrir o parque e mapear dependências
Nada se move antes de existir no papel. A avaliação de workloads dá visibilidade total de componente, dependência e requisito antes de a primeira carga sair do lugar, e o Azure Migrate faz a descoberta automatizada.
Automatizar é o ponto de partida, não a linha de chegada. A ferramenta enxerga tráfego, processo e porta aberta; não enxerga o script que roda no desktop do financeiro toda sexta. O mapa precisa de três camadas: dependência direta, quando um sistema chama o outro; indireta, quando os dois usam o mesmo banco ou a mesma autenticação; e de negócio, quando o processo quebra se os dois não estiverem no ar juntos.
Aqui também se documentam SLA, RPO e RTO por workload, antes de qualquer desenho de arquitetura, e abre-se o registro de riscos com mitigação, responsável e prazo.
O erro mais caro desta fase
Dar o inventário por pronto sem entrevistar quem opera. A varredura devolve servidores, processos e portas; não devolve o fato de que o fechamento contábil depende de um serviço que ninguém reivindica como seu.
Sem esse mapa, prazo prometido é ficção e orçamento é chute com aparência de planilha.
Fase 2: montar o business case antes de mover qualquer coisa
O diagrama de arquitetura não é o documento que o CFO assina. O business case é.
De um lado entra o custo total do ambiente atual: hardware, licença, Software Assurance, Extended Security Updates, virtualização, armazenamento, rede, segurança, instalações, mão de obra e gestão. Do outro entram os mesmos itens sem instalações, com o Azure Hybrid Benefit e as ESU no Azure lançados como economia.
Duas exigências separam business case de planilha otimista. A primeira é fluxo de caixa ano a ano, não um número único no slide. A segunda é o estado futuro modelado por percentual migrado: enquanto a migração acontece, o ano soma o custo de nuvem proporcional ao que já foi movido com o custo remanescente da origem.
CAPEX que vira OPEX muda o formato da conta, não o tamanho dela no primeiro ano. Quem mostra economia sem mostrar a coexistência está vendendo, não modelando.
Fase 3: escolher a estratégia certa para cada sistema
Migração não é sinônimo de lift and shift. Rehost é uma das oito estratégias possíveis, e quem chama o projeto inteiro de lift and shift trata uma delas como se fosse o método.
| Estratégia | O que faz, e quando cabe |
|---|---|
| Retire | Desliga o que ninguém usa, e reduz escopo antes de mover. |
| Retain | Mantém o workload onde está, quando alguma restrição impede o movimento. |
| Rehost | Move como está, sem modernização prevista para dois anos. |
| Replatform | Troca componentes por serviços gerenciados quando o banco pesa. |
| Refactor | Ajusta o código à plataforma quando o ganho paga o esforço. |
| Rearchitect | Redesenha a aplicação quando o limite estrutural trava o crescimento. |
| Rebuild | Reescreve a aplicação que não sustenta mais o negócio. |
| Replace | Substitui por produto de mercado o processo sem diferencial. |
A regra dura vem da documentação: não rehospedar workload que já tem problema. Rehospedar não conserta performance nem arquitetura; modernizar conserta. O servidor lento vai junto, agora com fatura mensal.
Executar essa escolha, sistema a sistema, é o que a Qualiserve entrega como migração para nuvem como serviço gerenciado.
Retain e Retire: as duas letras que economizam mais
As duas primeiras decisões do projeto não movem nada. São as que mais reduzem a conta: o que se aposenta não custa migrar, licenciar nem operar depois.
O que fica em Retain por restrição regulatória, latência ou dependência física convive com o ambiente novo. Escopo que ninguém questiona é escopo que alguém paga por três anos.
Fase 4: desenhar a landing zone e a identidade antes da primeira carga
A landing zone é o ambiente que recebe as cargas. A documentação de landing zones do Azure separa duas camadas: a de plataforma, que concentra governança, segurança, rede e recursos compartilhados, e a de aplicação, onde os workloads vivem sob as regras da plataforma, com uma landing zone de plataforma por tenant do Microsoft Entra ID.
O que se decide aqui é estrutural: hierarquia de management groups, organização das assinaturas, política aplicada por herança, identidade, segregação de rede e onde o Defender for Cloud enxerga. Trocar isso na terceira onda significa remontar assinatura com produção dentro.
Para quem opera sob sigilo, e escritório jurídico com repositório documental é o caso mais evidente, identidade e política precisam estar de pé antes da primeira carga. Compliance é requisito de arquitetura, não item de checklist do go-live.
É aqui que se decide se a fatura será rastreável por área ou um número indefensável na reunião de resultado.
Fase 5: organizar ondas e rodar o piloto
Ninguém migra um parque inteiro num fim de semana. Onda é um lote de workloads agrupados por dependência e movidos juntos, e o agrupamento sai do mapa da Fase 1: sistemas que compartilham banco, API, autenticação ou rede vão juntos.
Em varejo com franquias, a dependência de negócio manda: se a loja depende da integração central, loja e central viajam na mesma onda. A Mania de Churrasco consolidou cinco sistemas em três no Azure, com 99,3% de sucesso nas integrações. Consolidar e migrar são projetos diferentes; a lógica do agrupamento é a mesma.
A precedência é conhecida: não-produção antes de produção, simples antes de crítico, com um ou dois workloads complexos já nas ondas iniciais, para o time descobrir cedo o que não sabia. Só a onda seguinte é detalhada.
O caminho dos dados também é decisão de onda: ExpressRoute, VPN, Azure Data Box ou internet, com trade-off entre velocidade, segurança e custo. No agronegócio, o volume histórico viaja em Data Box porque a banda do campo não sustenta a transferência.
Cada onda carrega buffer de contingência e checkpoints em 25%, 50% e 75% do progresso. Onda bem fechada barateia a próxima, porque o runbook deixa de ser hipótese.
Fase 6: executar o cutover com rollback pronto
O cutover é o único ponto do projeto que o negócio sente: tudo antes dele é preparação, tudo depois é validação.
Antes da janela: comunicação aos usuários, plantão com nome e telefone, congelamento de mudanças na origem e produção provisionada por código. Ambiente montado à mão não é reproduzível, e o que não é reproduzível não se reverte numa madrugada.
São dois métodos, escolhidos pela tolerância de cada workload. Parada planejada: janela de indisponibilidade, mover, testar, liberar. Downtime quase zero: replicação contínua por dias, lag de replicação em zero antes de virar, pausa de escrita na origem durante a sincronização final, integridade verificada por checksum e contagem de linhas, troca de DNS no fim.
A pausa de escrita não é formalidade. Escrita na origem durante a sincronização final é o caminho mais curto para perda de dados.
O rollback é entregável, não plano B verbal
Rollback existe quando três coisas foram definidas antes da janela: o que conta como falha, em número e não em sensação; a reversão automatizada; e o teste dessa reversão em staging.
A origem permanece de pé como fallback até a validação terminar. Rollback testado é o que faz o CEO aprovar a janela; rollback prometido é o que faz ele adiar por mais um trimestre.
Fase 7: validar, ajustar e desligar a origem
Migração declarada concluída no domingo à noite e chamado aberto na segunda de manhã é a sequência do projeto malfeito. Validação é teste ponta a ponta com os donos dos sistemas, não ping no servidor, somada a monitoramento de performance, erro e acesso nas primeiras 24 a 48 horas. Só depois disso se anuncia sucesso.
Vem então o rightsizing. Máquina migrada com o dimensionamento da física costuma estar superdimensionada, porque o hardware antigo foi comprado para o pico de três anos à frente. A analogia que circula na casa dá conta do vício: comprar a Ferrari e dirigir como Fusca.
E há o quinto passo do método, o que quase nunca entra na proposta: descomissionar a origem. Desligar servidor, encerrar hospedagem, cancelar renovação de suporte, liberar espaço. A economia aparece quando a origem é desligada; enquanto o ambiente antigo continua ligado, a empresa paga duas infraestruturas ao mesmo tempo.
Daí em diante o assunto vira rotina de otimização de custos em nuvem. Projeto que termina sem data de desligamento da origem não terminou: mudou de fatura.
Conter o risco de cada fase
Risco de migração não é evento único no dia da virada. Ele se distribui pelas sete fases, e cada um tem contenção conhecida.
| Fase | Risco | Contenção |
|---|---|---|
| Descoberta | Dependência oculta na virada. | Entrevista com os donos. |
| Business case | Premissa otimista de economia. | Fluxo de caixa por percentual migrado. |
| Estratégia | Rehost de sistema doente. | Critério dos dois anos. |
| Landing zone | Identidade improvisada. | Hierarquia antes da primeira carga. |
| Ondas | Onda grande demais. | Checkpoints em 25%, 50% e 75%. |
| Cutover | Escrita durante a sincronização. | Pausa de escrita e lag em zero. |
| Pós-migração | Sucesso declarado cedo. | Validação assinada pelo dono. |
O registro aberto na Fase 1 mantém a tabela viva, com responsável e prazo. Risco sem dono não é risco gerenciado; é risco documentado.
Somar o custo real: o que entra na fatura e o que fica de fora
Não existe preço de tabela para migração. Número citado antes do inventário é chute com aparência de proposta. O que existe é composição de custo, em duas metades: a que entra no orçamento e a que aparece depois dele.
O que entra no orçamento
Do lado recorrente, a conta soma computação, armazenamento, rede, segurança gerenciada, monitoramento e backup. Do lado do projeto, entram as horas de desenho, execução e validação. Esses itens quase sempre estão na proposta: qualquer fornecedor sabe estimá-los.
As quatro linhas que estouram o orçamento
Saída de dados. A entrada no Azure é gratuita e os primeiros 100 GB por mês de saída também são, em todas as regiões. O excedente e a transferência entre regiões são cobrados por GB, conforme a tabela de preços de banda. Backup para fora vira surpresa mensal.
Licenciamento. Sistema operacional e banco continuam pagos depois da migração, com ou sem Azure Hybrid Benefit. O benefício reduz a linha; não a elimina.
Ambiente duplo. Durante a coexistência, o ano soma o custo de nuvem proporcional ao que já migrou com o custo remanescente da origem. É a objeção mais honesta que um CFO faz, e a resposta não é negar: é encurtar o calendário.
Horas de equipe interna. O time que valida, testa e atende chamado durante a onda não para o resto do trabalho. Essa hora tem custo, mesmo sem nota fiscal.
Escolher quem executa: time interno, parceiro ou os dois
A documentação oficial não decide isso por ninguém, mas dá o critério: avaliar a experiência da equipe em Azure, em ferramentas de migração e em cutover, e trazer apoio externo onde faltar repertório. Time de TI de empresa média costuma ter competência técnica e não ter repetição.
A Qualiserve opera do lado da repetição: 20 anos de mercado, equipe de 40 pessoas, mais de 50.000 usuários atendidos e um NOC próprio que monitora mais de 20.000 dispositivos, com a virada de break-fix reativo para serviços gerenciados feita em 2019. A execução em Azure tem chancela pública da Microsoft no projeto da BM Tax: 45 TB vindos de 30 bases consolidados no OneLake em seis meses, prova de execução em plataforma e não de migração de datacenter.
O que a Qualiserve entrega é o projeto e a operação, nunca a licença. Migração é projeto com data para acabar; operação gerenciada é contrato que continua depois da última onda.
Perguntas frequentes sobre a execução do projeto
As dúvidas abaixo aparecem em toda reunião de escopo, quase sempre na mesma ordem e quase sempre feitas por quem assina.
Quanto tempo demora uma migração para a nuvem?
Não há fonte confiável para média de mercado, e prazo prometido antes do inventário escorrega. O que define a duração é mensurável: número de workloads, estratégia escolhida para cada um, volume de dados, caminho de rede disponível e tolerância a parada. Parque crítico com replicação contínua leva mais ondas que um parque homogêneo.
A empresa precisa parar de operar durante a migração?
Não necessariamente. Com replicação contínua, a parada fica restrita à sincronização final, quando a escrita na origem é pausada para garantir integridade. Só os sistemas que toleram indisponibilidade usam janela de parada planejada completa. A decisão sai workload a workload, a partir do RPO e do RTO documentados na descoberta.
Quanto custa migrar para a nuvem?
Custo se calcula, não se consulta em tabela. A conta recorrente reúne computação, armazenamento, rede, segurança gerenciada, monitoramento e backup, e a conta do projeto reúne horas de desenho, execução e validação. Fora do orçamento costumam ficar quatro linhas: saída de dados por GB, licenciamento, ambiente duplo na coexistência e horas da equipe interna.
Quais são os maiores riscos de uma migração?
Dependência não mapeada que aparece na virada, premissa otimista no business case, rehost de sistema que já tinha problema, identidade improvisada na landing zone, onda maior que a capacidade do time, escrita na origem durante a sincronização final e sucesso declarado antes da validação. Cada um tem contenção conhecida e responsável no registro de riscos.
É possível voltar atrás se a migração der errado?
Sim, desde que o rollback tenha sido tratado como entregável. Isso significa definir por escrito o que conta como falha, automatizar a reversão e testá-la em staging antes da janela. O ambiente de origem permanece de pé como fallback até a validação terminar. Rollback que existe só na ata não é rollback.
Dá para fazer a migração só com o time interno de TI?
Isso se decide por repetição, não por competência. A recomendação oficial é avaliar a experiência da equipe em Azure, em ferramentas de migração e em execução de cutover, e buscar apoio externo onde faltar repertório. Time que nunca conduziu uma janela de virada aprende dentro da produção da própria empresa.
Decidir a primeira onda com o inventário na mão
As sete fases têm nome e ordem: descoberta, business case, estratégia por sistema, landing zone, ondas com piloto, cutover com rollback, validação com descomissionamento. Planeja-se por workload e por onda, nunca por servidor solto.
Antes de mover qualquer máquina, quem decide o custo do projeto é o inventário. O assessment da Qualiserve entrega o mapa de dependências, a estratégia por sistema e o business case com fluxo de caixa ano a ano: o documento que o financeiro precisa ver antes de aprovar a primeira onda.
O escopo contratado está na página de migração para nuvem como serviço gerenciado. Prefere falar com quem executa a janela? WhatsApp (11) 4941-1500.
