Como você planejaria a migração de uma aplicação on premises para a nuvem?

Faça inventário e avaliação primeiro, depois escolha um tratamento por componente em vez de uma estratégia única para tudo: rehost o que está estável, replataforme onde um serviço gerenciado remove trabalho braçal, refatore só onde há um retorno claro, e aposente o que ninguém usa. Sequencie por risco, começando por algo de baixa criticidade para provar o processo. Planeje a migração de dados e a virada com cuidado, já que é a parte com indisponibilidade real, e mantenha um caminho de rollback.

A primeira fase é a descoberta, e ela sempre leva mais tempo do que qualquer um orça. O que está rodando, o que fala com o quê, qual é a utilização real, quem é dono, e quais são as restrições de licenciamento e de conformidade. Disso sai uma decisão por componente em vez de uma estratégia para o parque inteiro. Coisas estáveis que funcionam são rehospedadas com mudança mínima, porque o valor está em sair do data center, não em reescrever. Coisas em que um serviço gerenciado remove uma pilha de trabalho operacional, normalmente bancos e filas, são replataformadas. Refatoração eu reservo para componentes com um caso de negócio genuíno, porque é a opção mais lenta e mais arriscada. E uma quantidade surpreendente é aposentada, já que todo parque tem servidores de que ninguém precisa há anos. Depois sequencie por risco: um serviço interno de baixo tráfego primeiro, para a gente exercitar a rede, o pipeline e o runbook onde os erros são baratos. Dado é a parte difícil, então replique continuamente com antecedência, rode em paralelo, e mantenha o sistema on premises vivo e pronto para rollback por umas duas semanas depois da virada.