SAP no Azure: Guia Completo de Migração e Custos 2026

SAP no Azure significa rodar SAP ECC, SAP S/4HANA ou SAP BW em VMs certificadas pela SAP, geralmente sob dois modelos: gestão própria da assinatura Azure ou RISE with SAP, em que a própria SAP administra o ambiente. A escolha entre os dois define custo, controle técnico e velocidade de implementação.

Esse é o resumo que responde à pergunta central. O restante deste guia detalha como cada modelo funciona na prática, o que dizem projetos reais de migração e onde as empresas costumam errar o dimensionamento e o cronograma.

O Que Significa, na Prática, Rodar SAP no Azure?

Tecnicamente, SAP no Azure é a execução das camadas de aplicação e banco de dados do ambiente SAP, o que a própria Microsoft chama de paisagem SAP, sobre infraestrutura Azure em vez de hardware próprio. Isso inclui desde sistemas de desenvolvimento e homologação até produção, cada um podendo rodar em máquinas virtuais dedicadas.

Um detalhe que a documentação da Microsoft reforça e que poucos artigos explicam claramente: as duas camadas de um mesmo sistema SAP, banco de dados e aplicação, precisam estar no mesmo lugar. Não é possível manter a camada de banco de dados on-premises e a camada de aplicação no Azure para o mesmo sistema. A migração acontece por sistema completo, não por componente isolado.

Se sua empresa ainda está avaliando entre manter o ERP local ou migrar, e quer entender as quatro estratégias de migração (rehost, replatform, refactor, rearchitect) de forma mais ampla antes de entrar nas especificidades do SAP, vale ler primeiro o guia completo de migração de ERP para o Azure.

RISE with SAP ou SAP no Azure Nativo: Qual a Diferença?

Essa é a decisão mais estratégica de todo o projeto, e boa parte do conteúdo disponível sobre o tema não deixa clara a diferença entre os dois caminhos.

SAP no Azure nativo significa que a empresa contrata o Azure diretamente, com sua própria assinatura, e é responsável por operar a infraestrutura, aplicando patches, dimensionando VMs e gerenciando a landing zone, com o suporte de um parceiro de implementação. É o modelo mais próximo do que a InfoB já executa em projetos de migração de banco de dados e servidores para clientes brasileiros.

RISE with SAP é diferente na raiz: segundo a própria documentação técnica da Microsoft sobre RISE no Azure, os ambientes RISE rodam dentro de assinaturas Azure que pertencem à SAP, e é a SAP quem gerencia essa assinatura e os recursos Azure relacionados, não o cliente final. Na prática, a empresa contrata um serviço gerenciado de ERP na nuvem, com SLA e operação incluídos, abrindo mão de parte do controle direto sobre a infraestrutura em troca de menos responsabilidade operacional.

Para times de TI acostumados a operar sua própria infraestrutura, RISE costuma parecer uma perda de controle. Para CFOs e diretorias que querem previsibilidade contratual e menos time interno dedicado a manter o ERP no ar, costuma ser justamente o atrativo.

Por Que Empresas Estão Migrando SAP para o Azure?

Casos documentados publicamente pela própria Microsoft ajudam a tirar essa decisão do campo teórico.

A farmacêutica ucraniana Darnitsa realizou uma migração completa do SAP para o Azure e reportou uma redução de 60% nos custos de infraestrutura, com corte de metade do custo total de propriedade e ganho de produtividade da equipe de TI. A rede Walgreens Boots Alliance migrou 100 terabytes de dados para o Azure através do programa Embrace, parceria entre Microsoft, SAP e Accenture, na que foi descrita como a maior implantação de expansão de SAP S/4HANA já realizada nesse programa. A seguradora Swiss Re usou a migração para reduzir custo operacional e implementar disaster recovery com failover configurável em um clique.

O caso mais recente e ilustrativo é o da Nokia: no fim de 2025, a empresa fechou um acordo plurianual com a SAP para migrar seu ambiente de ERP para SAP S/4HANA no Microsoft Azure usando a metodologia RISE with SAP, consolidando múltiplos sistemas de ERP em uma única paisagem que cobre finanças, logística, gestão de armazéns, serviços de comércio exterior e cumprimento de pedidos. O projeto, ainda em andamento em 2026, mostra que mesmo empresas com ambientes SAP grandes e altamente customizados estão escolhendo consolidar tudo em uma única nuvem em vez de manter arquiteturas híbridas indefinidamente.

Nenhum desses números deve ser lido como promessa automática de resultado igual. Cada ambiente SAP tem seu próprio nível de customização, e o ganho real depende diretamente da qualidade do assessment feito antes da migração.

SAP HANA no Azure: VMs Certificadas ou Instâncias Dedicadas?

O banco de dados em memória SAP HANA exige hardware certificado especificamente pela SAP, e o Azure oferece hoje mais de 100 configurações certificadas para rodá-lo, entre dois formatos principais.

• VMs certificadas para SAP HANA: máquinas virtuais que rodam em infraestrutura compartilhada, porém isolada, e cobrem a maioria dos cenários de médio e grande porte hoje.
• SAP HANA on Azure Large Instances (HLI): plataforma de computação dedicada, historicamente usada para as maiores cargas de trabalho HANA, sobre hardware exclusivo.

Um ponto que raramente aparece em conteúdo introdutório sobre o tema: a própria Microsoft já documenta o caminho de migração de HLI para VMs certificadas, para clientes que querem sair do modelo de hardware dedicado sem redesenhar a arquitetura de alta disponibilidade. A recomendação oficial é preservar a topologia de disaster recovery existente durante essa transição e revalidar o SLA da arquitetura de destino antes do corte, já que os termos comerciais entre HLI e VM são diferentes.

Como Funciona, na Prática, a Migração de SAP para o Azure?

A Microsoft estrutura projetos de SAP dentro do Cloud Adoption Framework, em um cenário dedicado que cobre estratégia, arquitetura de rede, identidade e integração de dados especificamente para ambientes SAP. Na prática, o projeto passa por quatro momentos.

Avaliação de motivação e prontidão

A própria Microsoft recomenda que a equipe de estratégia de nuvem, incluindo lideranças de TI e de negócio, avalie o que está motivando a migração: redução de custo, fim de um ciclo caro de renovação de hardware local, necessidade de escalar rapidamente para acompanhar uma transformação com S/4HANA, ou uma combinação das três. Essa resposta influencia diretamente se o caminho certo é rehost, RISE with SAP, ou uma reconstrução mais profunda.

Assessment técnico com o Azure Migrate

O Azure Migrate conta com um módulo de avaliação específico para sistemas SAP, hoje em versão prévia, que examina cada SID (System ID) individualmente e detalha estimativas de custo para os servidores de aplicação, banco de dados e ASCS separadamente, já considerando sistema operacional, tipo de implantação e requisitos de alta disponibilidade. Esse nível de granularidade por SID é o que permite priorizar corretamente quais sistemas migram primeiro.

Construção da landing zone SAP

O Cloud Adoption Framework disponibiliza um acelerador de landing zone específico para SAP, cobrindo rede, identidade e, quando aplicável, a integração com Power Platform e outras fontes de dados corporativas. Empresas que já têm uma landing zone Azure geral, construída para outras cargas de trabalho, normalmente estendem essa base em vez de criar uma estrutura paralela só para o SAP.

Migração e estabilização

A execução em si segue arquiteturas de referência publicadas conjuntamente por SAP e Microsoft, com planos de continuidade de negócio, teste e prontidão organizacional documentados antes do corte. Depois do go-live, a proteção dos dados continua sendo essencial, e o Azure Backup tem suporte documentado especificamente para workloads SAP HANA, como detalhamos no guia de Azure Backup para empresas.

Quanto Custa Rodar SAP no Azure?

Os valores a seguir são estimativas ilustrativas para orientar o planejamento inicial. O custo final depende do tamanho do ambiente SAP, do modelo escolhido (nativo ou RISE) e da região, e deve ser validado com um assessment técnico antes de qualquer decisão orçamentária.

No modelo nativo, o custo mensal soma o consumo das VMs certificadas para HANA ou aplicação, storage de alta performance, backup e tráfego de rede, seguindo a mesma lógica de consumo que já detalhamos no guia de custos de VM no Azure, com a diferença de que workloads SAP HANA normalmente exigem séries de VM otimizadas para memória, que custam mais por hora do que instâncias de uso geral. No modelo RISE with SAP, o custo é contratado como serviço gerenciado junto à SAP, o que simplifica o orçamento mas reduz a visibilidade linha a linha do consumo de infraestrutura.

Em ambos os modelos, o erro mais comum de orçamento é dimensionar a memória da instância HANA pelo volume total de dados históricos, em vez de aplicar uma estratégia de tiering que move dados frios para camadas de armazenamento mais baratas. A própria Microsoft documenta esse cenário como uma das formas mais diretas de equilibrar custo e desempenho em ambientes HANA maduros.

Quais os Riscos e Onde os Projetos de SAP no Azure Costumam Falhar?

Subestimar a complexidade das integrações

Ambientes SAP maduros normalmente têm dezenas de interfaces com sistemas fiscais, bancários e de terceiros construídas ao longo de anos, muitas sem documentação atualizada. Migrar sem mapear essas interfaces é a causa mais comum de incidentes pós-go-live.

Tratar HLI e VM como equivalentes automáticos

Como mencionado acima, os termos comerciais e o SLA entre HANA Large Instances e VMs certificadas são diferentes. Assumir que a migração entre os dois formatos é apenas uma troca de nome, sem revalidar arquitetura de alta disponibilidade e disaster recovery, é um erro recorrente em projetos conduzidos sem um parceiro especializado.

Ignorar o modelo de responsabilidade em RISE with SAP

Como a assinatura Azure em um projeto RISE pertence à SAP, times jurídicos e de segurança precisam entender exatamente onde termina a responsabilidade da SAP e onde começa a responsabilidade da empresa contratante, especialmente em cláusulas contratuais sobre localização de dados e continuidade de serviço.

SAP no Azure é Seguro e Compatível com a LGPD?

O Azure sustenta certificações internacionais como ISO 27001, ISO 27017, ISO 27018 e ISO 27701, além de manter uma região própria no Brasil, a Brazil South. Para times jurídicos, o ponto central é que essas certificações cobrem a segurança da infraestrutura, não a conformidade completa com a LGPD, que continua dependendo de como a empresa configura o tratamento, a retenção e a eventual transferência internacional dos dados armazenados no ERP. Isso vale tanto para o modelo nativo quanto, com atenção redobrada, para contratos RISE with SAP, onde a assinatura é gerenciada por um terceiro.

Para CISOs, vale registrar que a integração nativa com Microsoft Defender for Cloud e, mais recentemente, com o Microsoft Security Copilot, amplia a visibilidade sobre ameaças em ambientes SAP hospedados no Azure, um recurso que dificilmente existe em uma operação SAP inteiramente on-premises. Detalhamos essa camada de segurança no guia sobre Microsoft Defender for Cloud.

Conclusão

SAP no Azure deixou de ser uma decisão apenas de infraestrutura para se tornar uma decisão de modelo de operação: manter o controle técnico direto com uma implementação nativa, ou transferir parte dessa responsabilidade à SAP através do RISE with SAP. Nenhuma das duas opções é universalmente melhor, e a resposta certa depende do nível de customização do ambiente atual, da maturidade da equipe interna de TI e do apetite da empresa por gerenciar infraestrutura versus contratar um serviço.

O que os casos documentados por Nokia, Darnitsa e Walgreens Boots Alliance têm em comum não é o número final de economia, que varia bastante entre eles, mas o fato de que todos partiram de um assessment técnico detalhado antes de decidir qual caminho seguir.

Perguntas Frequentes Sobre SAP no Azure

Qual a diferença entre SAP no Azure e RISE with SAP?

No SAP no Azure nativo, a empresa contrata sua própria assinatura Azure e gerencia a infraestrutura, com apoio de um parceiro. No RISE with SAP, a assinatura Azure pertence à SAP, que administra o ambiente como um serviço gerenciado.

Preciso usar HANA Large Instances para rodar SAP HANA no Azure?

Não necessariamente. O Azure oferece mais de 100 configurações de VM certificadas para SAP HANA, que atendem a maioria dos cenários de médio e grande porte. HANA Large Instances é reservado para as cargas de trabalho mais exigentes, e a própria Microsoft já documenta o caminho de migração de HLI para VM certificada.

Quanto tempo leva uma migração de SAP para o Azure?

Varia muito com a complexidade do ambiente. Projetos de rehost em empresas de porte médio costumam levar poucos meses, enquanto consolidações multi-país com RISE with SAP, como o projeto da Nokia, se estendem por mais tempo devido ao número de sistemas e integrações envolvidas.

SAP no Azure é mais barato que manter o SAP local?

Pode ser, mas não automaticamente. O caso da Darnitsa mostrou redução de 60% em custos de infraestrutura após uma migração completa, mas o resultado depende diretamente de um assessment prévio e de um dimensionamento correto das instâncias HANA.

O Azure Migrate consegue avaliar um ambiente SAP completo?

Sim, através de um módulo de avaliação específico para sistemas SAP, atualmente em versão prévia, que analisa cada sistema individualmente e estima custos separados para os servidores de aplicação, banco de dados e ASCS.

Quem é responsável pela LGPD em um contrato RISE with SAP?

A responsabilidade pela conformidade com a LGPD continua sendo da empresa contratante como controladora dos dados, mesmo quando a SAP administra a assinatura Azure. Por isso, cláusulas contratuais sobre localização e retenção de dados merecem revisão jurídica específica antes da assinatura.