Durante anos, quando falávamos em migrar aplicações legadas baseadas em IIS para a nuvem, a decisão quase sempre terminava no mesmo lugar: Máquinas Virtuais!
Não porque fosse a melhor opção arquitetural.
Mas por que era a única opção viável sem quebrar tudo.
Se você já tentou mover uma aplicação clássica em ASP.NET / .NET Framework para Azure App Service, provavelmente já viveu esse momento:
- A aplicação precisa instalar um componente.
- Usa fontes específicas para gerar relatórios.
- Depende de DLLs nativas ou componentes COM.
- Lê configuração do Registry.
- Escreve em caminhos fixos como
C:\ouL:\Logs. - Pressupõe que você pode “entrar no servidor e ajustar algo”.
E aí o App Service tradicional simplesmente não atende.
Resultado? Voltávamos para VMs. Ou VM Scale Sets.
Mas isso começa a mudar com o Managed Instance on Azure App Service.
E, na minha opinião, isso muda a conversa sobre migração!
A falsa dicotomia que tivemos por anos
Por muito tempo, a decisão era binária:
Opção 1 – Azure App Service
✔ PaaS
✔ Escala simplificada
✔ Patch gerenciado
✔ SSL simplificado
❌ Sem acesso ao SO
❌ Sem Registry
❌ Sem instalação de dependências
Opção 2 – Azure VM / VM Scale Sets
✔ Controle total do Windows
✔ Compatibilidade total com IIS legado
❌ Você gerencia Load Balancer
❌ Você gerencia SSL
❌ Você gerencia patch
❌ Você gerencia drift de configuração
❌ Você gerencia imagem
❌ Você gerencia RDP e segurança
Muitas empresas não queriam IaaS. Mas eram obrigadas a escolher IaaS.
O que o Managed Instance realmente resolve
O Managed Instance on Azure App Service não é apenas “mais um SKU”.
Ele é um meio-termo estratégico entre VM e App Service tradicional.
Você continua criando:
- Um App Service
- Dentro de um App Service Plan
Mas agora esse plano permite:
- Executar scripts de configuração
- Montar storage com drive letters
- Criar valores de registry via adapters
- Integrar com Key Vault para segredos
- Usar RDP seguro via Azure Bastion
- Manter escala e patching gerenciado
Em outras palavras:
Você mantém os benefícios de PaaS mas ganha flexibilidade suficiente de SO para rodar aplicações legadas.
Esse é o “PaaS bridge” que faltava.
“Mas eu já fazia isso com VM Scale Sets”
Sim. Eu também.
Já fiz inúmeras migrações usando:
- VMSS
- Load Balancer
- IIS
- Certificados manuais
- Script de bootstrap
- Custom Script Extension
- Golden Images
Funciona? Funciona.
Mas vamos ser honestos: a complexidade operacional cresce rápido. Com VMSS você ainda precisa:
- Configurar e manter o Load Balancer
- Gerenciar certificados TLS
- Orquestrar patching
- Garantir que a imagem está atualizada
- Evitar configuration drift
- Restringir e proteger acesso RDP
- Monitorar instâncias individualmente
O Managed Instance remove boa parte dessa camada de infraestrutura.
Você deixa de gerenciar o “encanamento” E passa a focar na aplicação.
O poder dos scripts como contrato de dependência
Existe uma regra simples para que essa abordagem funcione:
Se não está no script, não existe.
O Managed Instance exige maturidade. Nada de “entrei no servidor e ajustei manualmente”.
Tudo precisa estar:
- Versionado
- Idempotente
- Automatizado
- Reexecutável
Mas isso é uma vantagem, não um problema.
Você transforma anos de configuração manual acumulada em um contrato de dependência reproduzível.
Isso melhora:
- Escalabilidade
- Patch
- Reimage
- Disaster Recovery
- Governança
Storage mounts: desbloqueando o legado
Uma das maiores dores em migração é o file system.
Aplicações antigas assumem:
- Drive letters fixas
- Pastas compartilhadas
- Escrita local persistente
- Caminhos hardcoded
Com Managed Instance você pode:
- Montar Azure Files
- Montar storage via VNet
- Mapear caminhos previsíveis
- Separar armazenamento persistente de temporário
Isso sozinho já destrava muitos cenários que antes empurravam para VM.
Quando eu ainda escolheria VM
Vamos ser equilibrados.
Eu ainda escolheria VM quando:
- Você precisa de controle total contínuo do SO
- Existem dependências que não podem ser scriptadas
- Existe tooling muito específico no servidor
- O modelo “quase-imutável” não é viável
Managed Instance não substitui VM em todos os cenários.
Mas reduz drasticamente os casos em que VM era escolhida apenas por limitação do App Service tradicional.
A estratégia de migração que eu recomendo agora
Com essa nova possibilidade, minha abordagem estratégica muda:
- Mapear dependências reais da aplicação.
- Tentar Managed Instance primeiro.
- Capturar tudo em scripts.
- Estabilizar.
- Modernizar gradualmente por APIs.
- Evoluir para arquitetura mais cloud-native ao longo do tempo.
Isso reduz risco. Evita reescritas forçadas. Permite entregar valor mais rápido.
E cria base sólida para modernização futura — inclusive integração com IA, APIs e novos serviços.
O que isso significa para arquitetos e empresas
Por anos, muitas organizações ficaram presas em VMs porque:
- A aplicação era “sensível”
- O risco de reescrita era alto
- O prazo não permitia modernização profunda
Managed Instance cria uma zona intermediária.
Não é reescrita.
Não é IaaS puro.
É uma ponte.
E, na prática, pontes reduzem risco.
Conclusão
Modernizar não precisa ser uma aposta binária entre:
“Reescreve tudo”
ou
“Fica preso em VM para sempre”
O Managed Instance on Azure App Service muda essa equação.
Ele permite:
- Migrar rápido
- Preservar compatibilidade
- Reduzir complexidade operacional
- Manter benefícios de PaaS
- Criar caminho sustentável de modernização
Na minha visão, ele muda a conversa sobre migração de aplicações IIS para a nuvem.
E isso é algo que há anos estava faltando.
Quer avaliar se isso se aplica ao seu ambiente?
Se você está planejando:
- Migrar aplicações legadas para Azure
- Reduzir dependência de VMs
- Simplificar operação sem reescrever tudo
- Criar um roadmap realista de modernização
Entre em contato.
Podemos avaliar seu cenário, mapear dependências e desenhar a melhor estratégia técnica e financeira para sua migração.
Modernizar com segurança é possível — quando a arquitetura é bem pensada.
