Planejar a migração para Azure para empresas de médio porte costuma esbarrar em um dilema prático: a operação já tem complexidade suficiente para exigir governança e continuidade, mas não conta com a estrutura de uma grande corporação. Se a sua empresa está nesse cenário, avaliando o que subir primeiro, como dividir o time e o parceiro, e como manter custos e conformidade sob controle, este texto foi escrito para ajudar nessa decisão.
O que muda na migração para Azure em uma empresa de médio porte
Uma empresa de médio porte não migra para o Azure da mesma forma que uma grande corporação, tampouco com a simplicidade de um negócio pequeno. O porte médio carrega uma característica ambígua: já existe complexidade suficiente para exigir governança, identidade centralizada e continuidade de negócio, mas raramente há orçamento ou equipe sobrando para sustentar um centro de excelência em nuvem dedicado. A migração, nesse contexto, precisa equilibrar pragmatismo técnico e disciplina financeira.
O que muda de fato é a escala das decisões. Uma empresa com algumas dezenas de servidores físicos ou virtuais não consegue tratar cada carga de trabalho como um projeto isolado. A migração para Azure deixa de ser um exercício pontual de "subir uma VM na nuvem" e passa a ser um programa estruturado, com inventário, classificação de criticidade, ondas de corte e plano de rollback. O erro mais caro nesse porte é tratar a nuvem como um datacenter remoto: simplesmente realocar servidores sem revisar arquitetura gera fatura alta e pouca evolução operacional.
Outra mudança relevante está na relação com fornecedores e parceiros. Enquanto grandes empresas mantêm times internos de engenharia de nuvem, a média empresa costuma depender de um parceiro especializado para desenho, execução e operação assistida. Isso não é terceirização de responsabilidade, mas divisão de escopo: o time interno preserva o conhecimento de negócio e o parceiro entra com profundidade técnica em Azure, segurança e FinOps. A decisão de contratar é institucional e passa por diretoria, o que alonga o ciclo e exige material técnico consistente para sustentar a aprovação.
Sinais de que sua infraestrutura local já não acompanha a operação
Existem indicadores objetivos de que o ambiente on-premise deixou de ser adequado para o ritmo da empresa. O primeiro deles é a recorrência de incidentes ligados a hardware: falhas de disco, fonte ou controladora que geram indisponibilidade não programada. Quando o tempo médio de reparo depende de peça em garantia ou de fornecedor terceiro, a operação inteira fica refém de um SLA que não foi desenhado para o negócio.
O segundo sinal é a dificuldade de escalar. Se um pico de demanda — como uma campanha comercial ou o processamento de fim de mês — exige comprar servidor, aguardar entrega, instalar e configurar, a infraestrutura virou gargalo. No Azure, esse mesmo pico pode ser absorvido com escalabilidade horizontal ou vertical em minutos, e devolvido depois, pagando apenas pelo período de uso. A elasticidade é um dos poucos benefícios da nuvem com impacto financeiro direto para médias empresas.
Há ainda sinais menos técnicos, mas igualmente reveladores:
- Backups locais que não são testados há meses ou que falham silenciosamente
- Dependência de um único administrador que concentra todo o conhecimento crítico
- Contratos de manutenção de hardware com custo crescente e cobertura decrescente
- Impossibilidade de atender auditorias ou pedidos de evidência de conformidade com agilidade
- Projetos de expansão travados por limitação física de espaço, energia ou refrigeração
Quando três ou mais desses sinais estão presentes, a discussão deixa de ser "se devemos migrar" e passa a ser "em que ordem e com qual estratégia". A migração para Azure para empresas de médio porte raramente é uma decisão binária; quase sempre começa com cargas selecionadas e evolui por ondas.
Avaliação do ambiente atual: o inventário que antecede qualquer decisão
Nenhuma migração séria começa pelo portal do Azure. Começa por um inventário detalhado do parque atual: servidores, sistemas operacionais, versões de banco de dados, aplicações, integrações, fluxos de dados e dependências ocultas. Sem esse levantamento, qualquer estimativa de prazo ou custo é ficção. O inventário também revela o que ninguém documentou: serviços legados que rodam em servidores esquecidos, mas que sustentam processos críticos.
Ferramentas de descoberta automatizada ajudam a mapear consumo de CPU, memória e I/O ao longo de semanas, não de dias. Essa medição contínua é essencial porque o dimensionamento de máquinas no Azure deve refletir o uso real, não a configuração provisionada. Um servidor com 16 vCPUs alocados, mas que raramente passa de 20% de utilização, é candidato natural a um SKU menor na nuvem — e isso muda completamente a projeção de custo.
Mapeamento de servidores, aplicações e dependências
O mapeamento precisa ir além da lista de ativos. Cada aplicação deve ser associada a seus componentes de infraestrutura: servidor de aplicação, banco de dados, fila, serviço de arquivos, integração com terceiros e rotina agendada. Uma aplicação de folha de pagamento, por exemplo, pode depender de um servidor de banco SQL Server, de um compartilhamento de arquivos para exportação e de uma VPN com a contabilidade externa. Migrar apenas o servidor de aplicação sem considerar essas arestas gera falha em produção.
Dependências de rede também entram no mapa: latência tolerável entre sistemas, requisitos de largura de banda, necessidade de acesso a sistemas que permanecerão on-premise. Em ambientes com transações financeiras ou Pix, a latência entre a aplicação e o banco de dados é um requisito de negócio, não apenas técnico. Documentar esses limites antes da migração evita a descoberta tardia de que a arquitetura de destino não atende ao tempo de resposta exigido.
Classificação das cargas de trabalho por criticidade e prontidão
Com o inventário em mãos, a próxima etapa é classificar cada carga em duas dimensões: criticidade para o negócio e prontidão para a nuvem. A criticidade responde à pergunta "quanto tempo essa aplicação pode ficar fora do ar?" e "qual o impacto de uma perda de dados?". A prontidão avalia se a aplicação é tecnicamente compatível com o modelo de nuvem: licenciamento, arquitetura, sistema operacional suportado e dependências de hardware específico.
O cruzamento dessas dimensões gera uma matriz prática:
- Alta criticidade e alta prontidão: candidatas às primeiras ondas, com plano de rollback robusto
- Alta criticidade e baixa prontidão: exigem modernização prévia ou migração tardia e planejada
- Baixa criticidade e alta prontidão: boas para piloto e aprendizado da equipe
- Baixa criticidade e baixa prontidão: candidatas a descomissionamento ou substituição por SaaS
Essa matriz é o artefato que orienta todo o restante do projeto. Sem ela, a tendência é migrar primeiro o que é fácil e deixar o crítico para depois — o que concentra risco exatamente onde o negócio é mais sensível. A classificação também alimenta o desenho de ondas de migração e os critérios de avanço entre elas.
Estratégias de migração: realocar, refatorar, recomprar ou manter
O framework de referência para migração em nuvem trabalha com quatro estratégias básicas: realocar (lift-and-shift), refatorar (modernizar parcialmente), recomprar (substituir por SaaS) e manter (deixar on-premise). Nenhuma delas é superior em abstrato; a escolha depende do estado da aplicação, do ciclo de vida esperado e do retorno que a modernização traria. Para médias empresas, a combinação mais comum é realocar a maioria, refatorar algumas poucas cargas estratégicas e recomprar onde houver SaaS maduro.
Quando cada estratégia faz sentido para o porte da empresa
A realocação faz sentido para aplicações estáveis, com baixo ritmo de mudança e sem expectativa de evolução funcional no curto prazo. O objetivo é sair do datacenter físico rapidamente, eliminando risco de hardware e ganhando a base de gestão do Azure. Não é a opção mais barata em consumo mensal, mas é a que exige menos esforço de engenharia e menor risco de regressão funcional.
A refatoração é reservada para aplicações que precisam de elasticidade, atualização frequente ou integração com serviços nativos do Azure. Migrar um portal de atendimento para App Service com banco gerenciado, por exemplo, reduz a carga operacional de patching e backup manual. O custo de engenharia é maior, mas o retorno vem na forma de menor esforço de manutenção e maior capacidade de evoluir. A recomendação é limitar a refatoração inicial a um ou dois sistemas, para não transformar a migração em um projeto de reescrita sem fim.
A recompra aparece quando existe um SaaS consolidado que substitui a aplicação interna. Migrar e-mail para o Microsoft 365 é o exemplo clássico: elimina servidores Exchange locais, reduz superfície de ataque e transfere a responsabilidade de infraestrutura para o provedor. A mesma lógica vale para ferramentas de colaboração, gestão de projetos e até ERPs verticais. A recompra costuma ser a estratégia com melhor relação custo-benefício quando o SaaS atende aos requisitos funcionais e de conformidade.
O que não deve ser migrado agora
Nem tudo precisa ir para o Azure na primeira leva — e algumas coisas talvez nunca devam ir. Aplicações com dependência de hardware específico, como leitoras biométricas proprietárias ou controladoras industriais, frequentemente não têm equivalente em nuvem. Sistemas com licenciamento perpétuo atrelado a núcleos físicos podem ter custo proibitivo se realocados sem renegociação. Migrar esses casos sem análise gera fatura alta e nenhum benefício operacional.
Também devem ficar para depois as cargas com requisitos de latência extremamente baixa para sistemas que permanecerão locais, a menos que exista conectividade dedicada com SLA adequado. E, por fim, aplicações em fim de vida — aquelas que serão aposentadas em 12 a 24 meses — não justificam o esforço de migração. O inventário e a matriz de criticidade são exatamente o que permite defender essas exclusões com critério técnico, em vez de decisão política.
Arquitetura de destino no Azure: identidade, rede, dados e continuidade
A arquitetura de destino define o padrão que todas as cargas migradas seguirão. Improvisar essa fundação gera ambientes fragmentados, com políticas inconsistentes e custo de gestão crescente. Para médias empresas, o desenho precisa ser simples o suficiente para ser operado por um time enxuto, mas robusto o suficiente para suportar auditoria e crescimento. Os quatro pilares são identidade, rede, dados e continuidade.
Identidade híbrida e controle de acesso
O ponto de partida é o Microsoft Entra ID (antigo Azure AD) como diretório central, sincronizado com o Active Directory local quando ele existir. A identidade híbrida permite que usuários usem as mesmas credenciais em sistemas locais e na nuvem, com políticas de senha e de acesso condicional aplicadas de forma uniforme. Para empresas que lidam com dados sensíveis, o acesso condicional é a camada que exige autenticação multifator para acessos administrativos e para conexões a partir de redes não corporativas.
O controle de acesso deve seguir o princípio do menor privilégio desde o primeiro dia. Isso significa separar contas de uso diário de contas administrativas, conceder permissões por função e auditar acessos privilegiados. No Azure, o gerenciamento de identidades e acessos (IAM) com RBAC permite granularidade por recurso, grupo de recursos ou assinatura. Definir essa hierarquia antes da migração evita o cenário comum em que todo mundo vira administrador "para desbloquear o projeto" — e ninguém revoga depois.
Conectividade entre ambiente local e nuvem
Durante a transição, o ambiente local e o Azure conviverão por meses. A conectividade entre eles pode ser feita por VPN site-to-site ou por conexão dedicada via ExpressRoute, dependendo do volume de tráfego e dos requisitos de latência. A VPN é suficiente para a maioria das médias empresas no início; o ExpressRoute se justifica quando há transferência contínua de grandes volumes ou exigência contratual de rede privada.
O desenho de rede no Azure deve prever segmentação por ambiente (produção, homologação, desenvolvimento), uso de grupos de segurança de rede e roteamento explícito para o tráfego que precisa voltar ao on-premise. Um erro recorrente é permitir que todo o tráfego da nuvem passe pela VPN local, criando gargalo e custo de saída de dados desnecessário. O ideal é que apenas o tráfego que realmente precisa alcançar sistemas locais use o túnel; o restante deve sair diretamente pela borda do Azure.
Backup, recuperação de desastre e alta disponibilidade
A continuidade de negócio na nuvem não é automática. O Azure oferece redundância de infraestrutura, mas a responsabilidade por backup e recuperação de desastre permanece do cliente — um conceito que muitos descobrem tarde demais. Para cada carga crítica, é preciso definir objetivo de ponto de recuperação (RPO) e objetivo de tempo de recuperação (RTO) realistas, e então desenhar a solução correspondente.
O backup de máquinas virtuais e bancos de dados no Azure deve seguir a mesma disciplina que existia on-premise, com a vantagem de poder usar políticas consistentes em ambientes híbridos Azure e on-premise. Para cargas de missão crítica, a recuperação de desastre com replicação para outra região do Azure reduz o RTO de horas para minutos, mas tem custo proporcional. A decisão sobre quais cargas justificam esse investimento é diretamente derivada da matriz de criticidade construída na fase de inventário.
Empresas que operam transações financeiras ou dados sensíveis devem considerar ainda backup imutável como camada de proteção contra ransomware. A imutabilidade impede que credenciais comprometidas apaguem ou alterem cópias de backup, criando uma última linha de defesa quando o pior acontece. O tema se conecta diretamente à estratégia de backup anti ransomware, que deve ser definida antes da primeira onda de migração, não depois.
O que define o custo de uma migração para Azure
O custo de uma migração para Azure é composto por três camadas: o esforço do projeto em si (horas de engenharia, ferramentas, parceiro), o consumo mensal dos recursos na nuvem e o custo de operação contínua. Muitas empresas olham apenas para a segunda camada e se surpreendem com o total. Uma visão honesta de custo precisa considerar as três, além do custo de oportunidade de manter o ambiente atual rodando com risco crescente.
Fatores que mais pesam no orçamento do projeto
O tamanho e a complexidade do inventário são o principal direcionador de esforço. Quanto mais aplicações com dependências ocultas, mais horas de descoberta, desenho e teste. A estratégia escolhida também pesa: realocar é mais rápido e barato em engenharia, mas pode resultar em consumo mensal maior; refatorar exige mais projeto, mas tende a reduzir a fatura recorrente. A quantidade de ondas e a necessidade de janelas fora do horário comercial afetam diretamente o cronograma e o custo de execução.
Outros fatores relevantes incluem:
- Necessidade de licenciamento adicional ou migração de licenças existentes
- Requisitos de conectividade dedicada, como ExpressRoute
- Necessidade de ferramentas de migração especializadas para bancos de dados grandes
- Exigências de conformidade que demandam documentação e evidências formais
- Treinamento da equipe interna e gestão da mudança para os usuários
Como evitar surpresas na fatura após a migração
A surpresa na fatura pós-migração quase sempre vem de três fontes: dimensionamento incorreto, recursos esquecidos ligados e tráfego de saída de dados não planejado. A primeira se combate com o dimensionamento baseado em uso real medido durante o inventário, não na configuração atual. A segunda exige rotina de revisão periódica de recursos e alertas de custo configurados desde o primeiro dia. A terceira exige entender o modelo de cobrança de saída de dados e desenhar a arquitetura para minimizar transferências desnecessárias.
A prática de FinOps — a gestão financeira da nuvem — deve começar junto com a migração, não depois. Isso significa definir orçamentos por ambiente, criar alertas de consumo, usar tags para atribuir custo a centros de custo e revisar a fatura mensalmente com olhar crítico. Para médias empresas, onde cada real de custo operacional compete com investimento em crescimento, essa disciplina é a diferença entre a nuvem ser um ativo estratégico ou uma despesa fora de controle.
Governança, segurança e conformidade durante a transição
A transição para a nuvem é um momento de risco elevado: ambientes novos, equipe aprendendo, pressão de prazo e a tendência de relaxar controles "só durante a migração". É exatamente nesse período que a governança precisa estar mais firme, não menos. Definir as regras antes de criar o primeiro recurso evita retrabalho e reduz a superfície de exposição.
Políticas, tags e controle de gastos
Políticas no Azure permitem impor regras como regiões permitidas, tamanhos de máquina autorizados e obrigatoriedade de tags. Um conjunto enxuto de políticas é mais eficaz que um catálogo extenso que ninguém cumpre. As tags, por sua vez, são o mecanismo que conecta cada recurso a um dono, um projeto e um centro de custo. Sem tags consistentes, a fatura vira uma caixa-preta impossível de atribuir.
O controle de gastos complementa as políticas com orçamentos e alertas. Definir um teto mensal por ambiente e receber notificação ao atingir 70% e 90% do orçamento permite agir antes do estouro. Para cargas com consumo variável, como ambientes de teste, vale avaliar o desligamento automático fora do horário comercial. Essas práticas simples, aplicadas desde o início, evitam a necessidade de um "projeto de otimização de custos" doloroso meses depois.
LGPD e requisitos regulatórios setoriais
A migração para nuvem não transfere a responsabilidade pela proteção de dados pessoais. A LGPD continua aplicável, e a empresa permanece como controladora dos dados que processa. Isso significa que a escolha da região do Azure onde os dados serão armazenados, os controles de acesso implementados e os registros de tratamento mantidos são decisões da empresa, não do provedor de nuvem. O Azure oferece conformidade com a LGPD e com normas setoriais, mas a configuração correta é responsabilidade do cliente.
Para empresas do setor financeiro ou que processam transações via Pix, há requisitos adicionais vindos de regulação setorial, incluindo exigências de trilha de auditoria, retenção de logs e continuidade de negócio. A migração precisa mapear esses requisitos antes da primeira onda e garantir que a arquitetura de destino os atenda. Isso inclui definir onde ficam os logs de acesso, por quanto tempo são retidos e quem pode acessá-los. A documentação de conformidade produzida durante a migração é um ativo valioso para futuras auditorias.
A relação entre backup e conformidade também merece atenção: a LGPD exige medidas de segurança adequadas para dados pessoais, e a existência de backup de dados sensíveis na nuvem é parte dessa demonstração. Saber onde ficam armazenados os dados de backup e quem tem acesso a eles é uma pergunta que aparece em qualquer avaliação de conformidade séria. A migração é o momento certo para acertar essa base, não para adiá-la.
Cronograma realista: fases, marcos e janelas de corte
Um cronograma de migração para médias empresas raramente cabe em uma única janela de corte. A abordagem por ondas distribui o risco e permite aprendizado entre uma leva e outra. O cronograma deve prever fases de preparação, piloto, ondas de migração e estabilização, com marcos objetivos que determinam se o projeto pode avançar.
Piloto, ondas de migração e critérios de avanço
O piloto é a primeira migração real, feita com uma carga de baixa criticidade e alta prontidão. Seu objetivo não é provar que "dá certo", mas validar o desenho de rede, os procedimentos de backup, o modelo de acesso e a comunicação com os usuários. O piloto deve ter critérios de sucesso definidos antes da execução: por exemplo, aplicação funcional em produção na nuvem por duas semanas, sem incidentes de severidade alta, com backup validado e fatura dentro do previsto.
As ondas seguintes são agrupamentos de cargas migradas em janelas planejadas. Cada onda deve ter um dono, um plano de teste e um critério de avanço explícito. O avanço para a onda seguinte só ocorre quando a onda anterior estabiliza — sem incidentes abertos, com desempenho validado e com os usuários confirmando operação normal. Esse mecanismo evita o efeito cascata de migrar tudo rapidamente e descobrir problemas em produção quando já não há mais ambiente local para voltar.
Plano de rollback e comunicação interna
Toda onda precisa de um plano de rollback, mesmo quando a migração é tecnicamente simples. O rollback pode significar reverter o apontamento para o servidor local, restaurar um banco de dados a partir de um ponto anterior ou reativar um serviço que foi desligado. O plano deve definir quem autoriza o rollback, em que condições ele é acionado e quanto tempo leva para executar. Sem essa definição prévia, a equipe tende a insistir em corrigir o problema na nuvem enquanto os usuários ficam parados.
A comunicação interna é frequentemente negligenciada e é uma das principais causas de atrito em migrações. Os usuários precisam saber, com antecedência, o que vai mudar para eles: novas formas de acesso, possíveis janelas de indisponibilidade, mudanças em atalhos ou em procedimentos. A comunicação deve ser objetiva, sem jargão técnico, e repetida nos canais que a empresa já usa. Quando o usuário descobre a migração porque "o sistema caiu", o projeto perde credibilidade — mesmo que tecnicamente tudo corra bem.
Equipe, parceiros e capacitação: quem executa a migração
A execução de uma migração para Azure exige competências que raramente existem completas em um time interno de médio porte: arquitetura de nuvem, segurança, redes, banco de dados, automação e FinOps. A decisão sobre quem faz o quê deve ser tomada com base no que o time já domina e no que precisa ser adquirido ou contratado.
Time interno versus parceiro especializado
O time interno é insubstituível no conhecimento de negócio: sabe quais aplicações são críticas, quem são os usuários, quais integrações existem e quais são as peculiaridades de cada sistema. Esse conhecimento não se transfere por documentação e precisa estar presente em todas as decisões de priorização e validação. O parceiro especializado, por outro lado, entra com a profundidade técnica em Azure que levaria meses ou anos para ser desenvolvida internamente.
A divisão mais eficiente para médias empresas costuma ser: parceiro lidera o desenho da arquitetura, a execução das migrações e a transferência de conhecimento; time interno participa ativamente do inventário, valida cada onda e assume progressivamente a operação. O objetivo não é criar dependência permanente do parceiro, mas também não é fingir que o time interno vai dominar tudo em três meses. A transição de responsabilidades deve ser planejada e gradual, com documentação e sessões de repasse a cada onda concluída.
Treinamento e gestão da mudança para os usuários
O treinamento técnico do time de TI é uma necessidade óbvia, mas a gestão da mudança para os usuários finais é igualmente importante e menos lembrada. Os usuários não precisam entender de Azure, mas precisam entender o que muda no dia a dia: como acessar os sistemas, o que fazer se algo não funcionar, a quem recorrer. Uma migração tecnicamente perfeita pode ser percebida como fracasso se os usuários se sentirem abandonados no processo.
O plano de gestão da mudança deve prever comunicação antes, durante e depois de cada onda. Antes: o que vai acontecer e quando. Durante: canal de suporte reforçado e status atualizado. Depois: confirmação de que tudo está funcionando e coleta de feedback. Para empresas que operam com dados sensíveis, o treinamento também deve reforçar as práticas de segurança no novo ambiente — como o uso de autenticação multifator e o cuidado com credenciais — já que a nuvem amplia a superfície de acesso e exige disciplina redobrada.
Erros que atrasam migrações em empresas de médio porte
Alguns erros aparecem com regularidade em migrações de médias empresas e custam semanas ou meses de atraso. O primeiro é pular o inventário e partir direto para a migração, movido por pressão de prazo ou entusiasmo com a tecnologia. Sem inventário, as surpresas aparecem em produção: a aplicação que dependia de um serviço esquecido, o banco de dados com versão incompatível, a integração que ninguém documentou.
O segundo erro é subestimar a governança. Criar o ambiente sem políticas, sem tags e sem controle de acesso definido gera um caos que só se resolve com retrabalho caro. O terceiro é não definir critérios de avanço entre ondas, permitindo que o projeto avance por inércia mesmo com incidentes abertos na onda anterior. O quarto é ignorar a gestão da mudança, tratando a migração como um projeto puramente técnico quando, na prática, é uma transformação organizacional.
Outros erros recorrentes incluem:
- Dimensionar máquinas pela configuração atual em vez do uso medido
- Não validar backups antes de desligar o ambiente local
- Migrar tudo de uma vez em uma única janela gigante
- Não treinar o time interno para operar o novo ambiente
- Tratar a fatura da nuvem como "custo que a gente vê depois"
O padrão comum a todos esses erros é a ausência de método. A migração para Azure em uma empresa de médio porte não é um evento, é um programa com fases, critérios e responsáveis. Quando o método existe e é seguido, os erros se tornam desvios corrigíveis em vez de crises.
Perguntas frequentes sobre migração para Azure em médio porte
Quanto tempo leva uma migração para Azure em uma empresa de médio porte?
Depende do tamanho do inventário e da estratégia escolhida, considerando inventário, piloto, ondas de migração e estabilização. Migrações exclusivamente de realocação tendem ao limite inferior; projetos com refatoração de sistemas críticos esticam para o limite superior. O cronograma deve ser validado após o inventário, nunca antes dele.
É possível manter parte da infraestrutura local e parte no Azure?
Sim. O modelo híbrido permite migrar gradualmente, mantendo no local o que ainda não está pronto e movendo para a nuvem o que já foi validado. A conectividade entre os ambientes é feita por VPN ou ExpressRoute, e a identidade híbrida garante que os usuários tenham experiência uniforme. O ambiente híbrido também é a base para estratégias de backup em ambientes híbridos Azure e on-premise.
A migração para Azure elimina a necessidade de backup?
Não. O Azure oferece redundância de infraestrutura, mas não substitui o backup. Falhas lógicas, exclusão acidental, corrupção de dados e ataques de ransomware continuam sendo riscos que exigem cópia de segurança independente. A responsabilidade por backup e recuperação é do cliente, e a migração é o momento de definir a política de backup gerenciado como serviço para o novo ambiente.
O que acontece com as licenças de software na migração?
O tratamento de licenças varia por fabricante e por modelo de contrato. Licenças perpétuas podem ser transportadas para a nuvem dentro de regras específicas, enquanto outras exigem conversão para modelo de assinatura. O Azure oferece benefícios para quem já possui licenças com Software Assurance, mas cada caso precisa ser avaliado individualmente. Esse é um dos pontos que mais gera custo inesperado quando ignorado no planejamento.
Como garantir que a migração atenda aos requisitos da LGPD?
A conformidade com a LGPD na nuvem depende de escolhas de arquitetura e de controles operacionais: região onde os dados são armazenados, criptografia em trânsito e em repouso, controle de acesso baseado em função, registros de auditoria e políticas de retenção. A migração deve documentar cada uma dessas decisões e manter evidências para futuras auditorias. Para dados sensíveis, a definição de práticas de backup de dados sensíveis na nuvem é parte integrante da demonstração de conformidade.
