Migrar ERP para Azure: Guia Completo 2026

Uma hora de indisponibilidade custa, em média, mais de US$ 300 mil para empresas de médio e grande porte, segundo levantamento do ITIC divulgado em 2026. Para PMEs brasileiras, o prejuízo médio de um sistema crítico parado gira em torno de R$ 20 mil por hora, de acordo com estimativas do setor. Em nível global, a Cisco/Splunk calcula que o custo da indisponibilidade não planejada nas grandes empresas chegou a US$ 600 bilhões por ano, um salto de 50% em apenas dois anos. Nenhum sistema concentra tanto desse risco quanto o ERP: é ele que sustenta faturamento, estoque, folha e obrigações fiscais ao mesmo tempo, todos os dias.

É por isso que, entre todos os projetos de migração para a nuvem, mover o ERP costuma ser o que os gestores de TI mais adiam. E, paradoxalmente, é também o que mais se beneficiaria da disponibilidade, do backup automatizado e da governança que o Microsoft Azure oferece. Este guia mostra quando faz sentido migrar, como planejar a transição usando o Cloud Adoption Framework da Microsoft, quais estratégias existem, quanto custa e, principalmente, onde a maioria dos projetos de migração de ERP realmente falha.

Por Que o ERP é o Sistema Mais Crítico da Empresa na Hora de Migrar?

O ERP raramente funciona sozinho. Ele impacta financeiro, vendas, estoque, produção e emissão fiscal simultaneamente, e normalmente está conectado a CRM, e-commerce, sistemas bancários e plataformas de nota fiscal por meio de integrações que nem sempre estão documentadas. Essa combinação de alta dependência operacional, necessidade de disponibilidade contínua e grande volume de integrações explica o receio comum entre gestores de TI: medo de indisponibilidade, receio de perda de dados, complexidade das integrações e impacto direto sobre os usuários finais.

O detalhe que costuma passar despercebido é que a infraestrutura on-premises que hospeda esse ERP já carrega boa parte desse risco hoje, mesmo sem qualquer migração: hardware envelhecendo, backup manual, ausência de plano de disaster recovery testado. Migrar bem não elimina a complexidade do ERP, mas transfere parte da responsabilidade por disponibilidade, backup e continuidade para uma plataforma com Availability Zones, replicação geográfica e SLA contratual, quando a arquitetura é desenhada corretamente.

Neste guia você vai entender quando migrar faz sentido, como planejar o projeto, quais estratégias de migração existem, como reduzir riscos operacionais e quais ferramentas da Microsoft apoiam cada etapa.

Por Que Empresas Estão Migrando seus ERPs para o Azure?

Redução de investimentos em infraestrutura

A troca de CAPEX por OPEX é o motivador mais citado, e por um motivo simples: comprar servidores para hospedar um ERP significa dimensionar para o pico de uso e pagar por essa capacidade ociosa o ano inteiro. No Azure, o modelo de consumo permite pagar pelo que é efetivamente utilizado, eliminar ciclos de renovação de hardware e tornar o custo de TI mais previsível ao longo do tempo. Vale um alerta prático: essa economia raramente aparece já no primeiro mês. Ela se consolida ao longo de alguns trimestres, à medida que a equipe ajusta o dimensionamento das máquinas e aplica reservas e benefícios de licenciamento, como detalhamos no guia de preços do Microsoft Azure.

Escalabilidade sob demanda

Fechamento fiscal, Black Friday, picos de produção sazonais e crescimento orgânico da empresa são situações em que o ERP local simplesmente não tem para onde crescer sem uma nova compra de hardware. No Azure, é possível redimensionar uma máquina virtual, adicionar núcleos e memória, ou escalar bancos de dados gerenciados sob demanda, sem esperar um ciclo de aquisição. O framework C.A.S.A. que a InfoB aplica em projetos de licenciamento e dimensionamento, detalhado no guia de custos de VM no Azure, ajuda a decidir quando uma carga de ERP deve rodar em instância reservada e quando faz mais sentido pagamento por consumo.

Maior disponibilidade e continuidade de negócios

A diferença entre um Availability Set e uma Availability Zone no Azure não é sutil: a Microsoft oferece SLA financeiramente garantido de 99,99% de uptime para máquinas virtuais distribuídas em zonas de disponibilidade, contra 99,95% em um Availability Set tradicional. Na prática, isso equivale a menos de uma hora de indisponibilidade por ano contra cerca de cinco horas. Para um ERP que processa faturamento em tempo real, essa diferença importa. Recursos como Azure Site Recovery e Azure Backup complementam essa base, permitindo replicação geográfica e testes de failover sem duplicar toda a infraestrutura. O artigo sobre Azure Backup para empresas detalha como workloads críticos, incluindo SAP HANA, são protegidos nesse modelo.

Segurança corporativa integrada

Um ERP local geralmente depende de uma pilha de segurança montada peça por peça: antivírus, firewall, VPN, controle de acesso. No Azure, Microsoft Defender for Cloud, Microsoft Entra ID, Azure Key Vault, autenticação multifator e Conditional Access já nascem integrados à plataforma. Isso não elimina a necessidade de configuração correta, mas reduz o número de fornecedores e pontos de falha. Detalhamos essa camada no artigo sobre Microsoft Defender for Cloud.

Preparação para IA e automação

Um ERP hospedado no Azure fica posicionado para se conectar a Microsoft Copilot, Azure OpenAI, Power Platform e Azure AI Services sem exigir uma segunda migração no futuro. Empresas que ainda rodam o ERP inteiramente on-premises normalmente precisam construir uma camada de integração extra só para alimentar esses serviços de IA com dados atualizados, o que aumenta latência e complexidade.

Quais ERPs Podem Ser Migrados para o Azure?

A resposta curta é: praticamente qualquer ERP que já roda em servidores Windows ou Linux pode ser migrado, porque a migração acontece na camada de infraestrutura, não dentro do próprio ERP. A diferença está no grau de suporte nativo que cada fabricante oferece dentro do Azure.

SAP: o caminho com mais suporte nativo

SAP é o único grande ERP com um caminho de certificação dedicado dentro do ecossistema Microsoft. Existe uma trilha de certificação específica, o exame AZ-120 (Planning and Administering Microsoft Azure for SAP Workloads), e uma linha de VMs certificadas para SAP HANA, incluindo as chamadas HANA Large Instances. A documentação oficial de SAP on Azure detalha as configurações de alta disponibilidade suportadas, e os anúncios da SAP Sapphire 2026 reforçam esse investimento contínuo em automação de deploy e testes de HA para HANA scale-out.

Principais ERPs utilizados no mercado brasileiro

• SAP (ECC, S/4HANA)
• TOTVS Protheus
• TOTVS Datasul
• Senior
• Sankhya
• Oracle ERP

Diferente do SAP, ERPs como Protheus, Datasul, Senior e Sankhya não têm uma versão de plataforma “nativa” do Azure. Eles rodam como aplicações Windows Server tradicionais, geralmente sobre SQL Server ou Oracle Database, e a migração acontece movendo esse par aplicação e banco de dados para máquinas virtuais e, quando possível, para serviços gerenciados como o Azure SQL Managed Instance. Isso costuma ser positivo: significa uma migração mais previsível, próxima do que já foi feito em milhares de projetos de banco de dados corporativos, como descrevemos no guia de migração de banco de dados para o Azure.

Aplicações customizadas integradas ao ERP

Poucos ERPs no Brasil operam isolados. Módulos fiscais de terceiros, portais de fornecedores, integrações com marketplaces e sistemas de emissão de nota fiscal costumam migrar junto, e cada um desses componentes precisa ser mapeado antes do projeto começar, não descoberto durante o cutover.

Sua Empresa Está Pronta Para Migrar o ERP? Checklist de Prontidão

Inventário da infraestrutura atual

Mapear servidores, storage, banco de dados e aplicações relacionadas ao ERP é o primeiro passo, e é exatamente para isso que existe o Azure Migrate, ferramenta gratuita da Microsoft para descoberta automatizada de ambientes on-premises.

Mapeamento de dependências

Antes de migrar, é preciso identificar todas as integrações ativas: ERP conectado a CRM, ERP alimentando ferramentas de BI, ERP integrado a plataformas de e-commerce e ERP trocando dados com sistemas fiscais. Uma integração esquecida no inventário costuma ser a causa mais comum de retrabalho depois do go-live.

Avaliação de performance

CPU, memória, disco, latência de rede e a curva de crescimento de carga dos últimos 12 meses formam a base para o dimensionamento correto no Azure. É esse histórico de utilização, coletado ao longo de semanas, que o Azure Migrate usa para recomendar o tamanho de VM ideal, aplicando um fator de segurança sobre o pico observado.

Avaliação de riscos

Três perguntas costumam expor o verdadeiro nível de maturidade de um projeto: existe uma janela de indisponibilidade aceitável pelo negócio? Existe um plano de rollback documentado, não apenas mental? Existe um ambiente de homologação onde a equipe pode testar a migração antes do ambiente de produção ser tocado? Quando a resposta para qualquer uma delas é não, o projeto ainda não está pronto para iniciar, independentemente do quanto a infraestrutura esteja mapeada.

O Que Migrar um ERP para o Azure Não Significa

Alguns pressupostos comuns em projetos de migração de ERP costumam gerar frustração quando não são desfeitos logo no início.

• Mover o ERP para uma VM no Azure resolve o problema de hardware envelhecido, mas replica qualquer gargalo de configuração, patch desatualizado ou processo mal dimensionado que já existia on-premises. A nuvem não corrige um ERP mal configurado sozinha.
• A economia de custo costuma se consolidar em alguns meses, à medida que a equipe aplica rightsizing e reservas, e raramente aparece já na primeira fatura.
• Segundo a experiência da InfoB em projetos de nuvem para PMEs, a migração de ERP e banco de dados costuma levar de 4 a 12 semanas, incluindo planejamento, testes, treinamento e cutover. Não é um projeto de fim de semana, mesmo em empresas pequenas.
• Depois do go-live, o ambiente ainda precisa de governança de custos, aplicação de patches e monitoramento contínuo. A operação de TI não termina na virada de chave, ela muda de formato.

As 4 Estratégias de Migração de ERP para o Azure

Rehost (Lift and Shift)

Consiste em mover o ERP para máquinas virtuais no Azure praticamente sem alterações na aplicação. É a estratégia mais indicada para ERPs legados e para empresas que precisam de uma migração rápida, com menor complexidade e menor prazo de projeto. O ponto onde essa estratégia costuma falhar: como nada é otimizado no processo, qualquer ineficiência de dimensionamento do ambiente atual é simplesmente transportada para a nuvem, inflando a fatura até que alguém faça o rightsizing depois.

Replatform

Aproveita serviços gerenciados sem reescrever a aplicação, como migrar de SQL Server para Azure SQL Managed Instance ou substituir rotinas de backup próprias por Azure Backup. O ganho de performance e a redução de esforço administrativo costumam ser reais. Onde essa estratégia falha: bancos de dados com procedimentos armazenados muito antigos ou versões descontinuadas do SQL Server podem ter incompatibilidades com o serviço gerenciado, o que só a Data Migration Assistant da Microsoft consegue detectar antes da migração.

Refactor

Adapta partes do ERP para a nuvem sem redesenhar o núcleo do sistema, geralmente reescrevendo APIs, integrações e processos que passam a rodar em paralelo. Onde essa estratégia falha: um refactor parcial e mal sequenciado pode gerar cenários de dados divergentes entre o sistema antigo e o novo componente em nuvem durante a transição, especialmente quando o mesmo dado é atualizado nos dois lados ao mesmo tempo.

Rearchitect

Redesenha completamente a arquitetura do sistema, e costuma fazer sentido apenas para sistemas muito antigos ou projetos estratégicos de longo prazo, onde o custo de manter a arquitetura atual já supera o custo de reconstruir. Onde essa estratégia falha: é a opção mais cara e mais demorada das quatro, e projetos de rearchitect sem patrocínio executivo forte e sem uma governança de projeto madura tendem a estourar prazo e orçamento com frequência.

Passo a Passo: Como Migrar um ERP para o Azure na Prática

A Microsoft organiza esse processo dentro do Cloud Adoption Framework, que estrutura a jornada em fases de estratégia, planejamento, preparação do ambiente (landing zone), migração e governança contínua. Na prática de um projeto de ERP, essas fases se traduzem em seis etapas.

Etapa 1 — Descoberta e assessment

O Azure Migrate é o ponto de partida: um appliance leve é implantado no ambiente on-premises, descobre servidores, bancos de dados e aplicações web de forma agentless, e envia dados de configuração e performance para a nuvem em intervalos de minutos. A partir desse inventário, a ferramenta gera avaliações de prontidão e estimativas de custo por workload. Desde 2026, o Azure Migrate também conta com um agente de migração baseado em Copilot, ainda em preview, que ajuda a interpretar os resultados da descoberta e comparar estratégias de migração em linguagem natural.

Etapa 2 — Planejamento

Definição de ondas de migração, cronograma e critérios objetivos de sucesso, com uma matriz de riscos, um plano de contingência e um plano de rollback documentados antes de qualquer servidor ser tocado.

Etapa 3 — Construção da landing zone

A landing zone é o ambiente Azure pré-configurado que recebe as cargas de trabalho, e cobre quatro frentes: rede (VNets, subnets, VPN ou ExpressRoute), identidade (Microsoft Entra ID e RBAC), segurança (Defender for Cloud e políticas de acesso) e governança (tags, orçamento e compliance). O próprio Cloud Adoption Framework disponibiliza aceleradores em Bicep e Terraform para padronizar essa etapa.

Etapa 4 — Migração dos dados

Bancos de dados SQL, arquivos e storage migram com Azure Database Migration Service e Azure Data Factory. Para volumes muito grandes, tipicamente acima de 10 TB, o Azure Data Box costuma ser mais rápido do que transferir tudo pela rede.

Etapa 5 — Migração das aplicações e testes

Testes funcionais, de performance, de integrações e de segurança acontecem antes do go-live, idealmente no ambiente de homologação mapeado na etapa de prontidão.

Etapa 6 — Go live

Checklist final antes do corte: usuários treinados, monitoramento ativo via Azure Monitor, backup validado com um teste real de restauração, e uma equipe de suporte disponível nas primeiras horas e dias após a virada.

O diagrama abaixo resume essas fases dentro do Cloud Adoption Framework.

Onde as Migrações de ERP Para a Nuvem Costumam Falhar

Interrupção do negócio

Migrar tudo de uma vez, em um único evento de fim de semana, é o padrão que mais gera incidentes. Migração por ondas, com ambientes paralelos rodando por um período de validação, reduz drasticamente esse risco, mesmo custando um pouco mais em infraestrutura temporária.

Problemas de integração

APIs, sistemas fiscais e integrações bancárias são os pontos que mais quebram silenciosamente, porque muitas vezes dependem de IPs fixos, certificados específicos ou versões antigas de protocolo que ninguém documentou nos últimos anos.

Custos inesperados

Dimensionamento incorreto e falta de governança de custos são as causas mais comuns de fatura acima do esperado. A experiência da InfoB em mais de uma década atendendo PMEs brasileiras mostra que empresas que migram para o Azure sem um diagnóstico prévio gastam, em média, de 30% a 50% mais do que o necessário no primeiro ano, como detalhamos no guia de custos de VM no Azure. Uma prática de FinOps simples, com revisão de consumo a cada 90 dias, evita boa parte desse desperdício.

Questões de compliance e LGPD

O Azure mantém uma região própria no Brasil, a Brazil South, e sustenta certificações internacionais como ISO 27001, ISO 27017, ISO 27018 e ISO 27701, auditadas anualmente por terceiros independentes. Isso ajuda, mas não resolve a LGPD sozinho: a lei opera sob um modelo de responsabilidade compartilhada, em que a Microsoft responde pela segurança da infraestrutura, e a empresa contratante continua sendo a controladora responsável pela base legal do tratamento, pela retenção e pela eventual transferência internacional de dados prevista no artigo 33 da lei. Escolher a região de armazenamento correta e documentar essa decisão é uma etapa de projeto, não um detalhe técnico.

Ferramentas Microsoft que Facilitam a Migração do ERP

• Azure Migrate — hub central de descoberta, assessment e orquestração da migração, com appliance agentless e, desde 2026, um agente de planejamento baseado em Copilot em preview.
• Azure Site Recovery — replicação contínua de servidores, usado tanto para disaster recovery quanto como motor de execução de migrações de VM.
• Azure Backup — proteção de máquinas virtuais, bancos de dados e arquivos, com suporte documentado inclusive para workloads SAP HANA.
• Azure Database Migration Service e Data Migration Assistant — migração e validação de compatibilidade de bancos SQL Server, MySQL, PostgreSQL e Oracle.
• Azure Data Box — transferência física de grandes volumes de dados quando o link de internet tornaria a cópia pela rede impraticável.
• Azure Monitor — monitoramento de performance, disponibilidade e logs após o go-live.

Para simular custos antes de qualquer compromisso financeiro, o passo recomendado é rodar a arquitetura planejada na calculadora oficial, como mostramos no guia do Azure Pricing Calculator.

Quanto Custa Migrar um ERP para o Azure?

Os valores a seguir são estimativas ilustrativas para orientar o planejamento inicial. O custo real depende do tamanho do ambiente, da região escolhida e do modelo de contratação, e deve ser validado na Azure Pricing Calculator oficial da Microsoft ou em um assessment de migração antes de qualquer decisão orçamentária.

Principais fatores de custo em operação

Infraestrutura de VM, storage, banco de dados gerenciado, backup e tráfego de rede compõem a fatura mensal. Servidores dedicados a workloads corporativas como ERP e banco de dados costumam ficar na faixa de US$ 200 a US$ 800 por mês por servidor em cenários de entrada a intermediários, podendo ultrapassar US$ 1.000 por mês em cargas maiores, conforme detalhamos no guia de preços do Azure. Empresas normalmente rodam vários desses servidores ao mesmo tempo, o que multiplica o total.

Custos do projeto de migração em si

Além da operação mensal, o projeto de migração propriamente dito inclui assessment, planejamento, implementação da landing zone e treinamento das equipes. Esse investimento inicial tende a se pagar mais rápido em empresas que já enfrentam custos altos de manutenção de hardware ou reincidência de indisponibilidade.

Como pensar o ROI

A comparação mais honesta soma, do lado on-premises, o custo de hardware, energia, licenças e manutenção ao longo de três a cinco anos, e do lado Azure, o consumo mensal já otimizado com Reservas e Azure Hybrid Benefit, mais o custo de governança contínua. Tratar essa conta como estática, feita uma vez e esquecida, é um dos erros mais comuns em projetos de nuvem.

Azure ou Continuar com Servidores Locais? Comparativo Direto

A tabela abaixo resume os critérios que mais pesam na decisão para um ERP corporativo.

Cenário Ilustrativo: Como Costuma Ser a Migração de ERP em uma Empresa de Médio Porte

O cenário a seguir é ilustrativo, construído a partir de padrões observados em projetos de migração de PMEs, e serve para dar contexto prático às etapas descritas acima, não como um caso auditado específico.

Cenário inicial: servidores físicos em fim de vida útil, ERP local sem redundância, rotina de backup limitada a fitas ou discos externos trocados manualmente. Projeto executado: assessment com Azure Migrate, construção da landing zone com identidade e rede segmentadas, migração por ondas com o ambiente local rodando em paralelo até a validação completa. Resultados típicos observados nesse tipo de projeto: maior disponibilidade percebida pelos usuários, recuperação mais rápida em caso de incidente, custo de infraestrutura mais previsível mês a mês e um ambiente pronto para incorporar automação e IA sem precisar de uma segunda migração.

Conclusão

Migrar o ERP não é apenas mover servidores de um lugar para outro. É uma iniciativa que, quando bem planejada, modernizar a operação, aumenta a disponibilidade, melhora a postura de segurança, reduz riscos de indisponibilidade e prepara a empresa para incorporar inteligência artificial nos próprios processos que já roda hoje.

Empresas que tratam essa migração como um projeto de transformação, e não apenas como uma troca de infraestrutura, tendem a capturar muito mais valor da nuvem no médio prazo.

Perguntas Frequentes Sobre Migrar ERP para o Azure

Quanto tempo leva para migrar um ERP para o Azure?

Em PMEs, o projeto costuma levar de 4 a 12 semanas, incluindo planejamento, testes, treinamento e cutover. Ambientes SAP com múltiplas customizações ou operações multi-país costumam levar mais tempo, medido em meses.

É possível migrar o ERP sem interromper a operação?

É possível chegar perto de zero indisponibilidade percebida usando replicação contínua com Azure Site Recovery e uma janela de corte planejada fora do horário de pico, mas uma migração com indisponibilidade absolutamente zero é rara na prática. O objetivo realista costuma ser minutos a poucas horas de corte controlado, não uma troca instantânea.

Qual ERP funciona melhor no Azure?

SAP tem o suporte mais profundo, com certificação dedicada e VMs desenhadas especificamente para SAP HANA. ERPs como Protheus, Senior e Sankhya funcionam bem como workloads de VM e banco de dados gerenciado, mas não possuem uma versão nativa de plataforma Azure.

Azure é mais barato que manter servidores locais?

Depende de como o ambiente é gerenciado. O modelo de consumo elimina o investimento inicial em hardware, mas sem rightsizing, reservas e Azure Hybrid Benefit a fatura pode crescer além do esperado. Empresas que migram sem diagnóstico prévio costumam gastar de 30% a 50% a mais no primeiro ano.

Como calcular o custo da migração?

O ponto de partida é simular a arquitetura planejada na Azure Pricing Calculator oficial e comparar com o custo total de propriedade da infraestrutura atual, incluindo hardware, energia, licenças e manutenção. Trate qualquer número deste guia como estimativa inicial, não como orçamento fechado.

Preciso redesenhar meu ERP para usar o Azure?

Na maioria dos projetos, não. Rehost e replatform mantêm a lógica da aplicação praticamente intacta. Rearchitect, que exige redesenho completo, fica reservado para sistemas muito antigos ou projetos estratégicos de longo prazo.

Qual a diferença entre Azure Migrate e Azure Site Recovery?

O Azure Migrate é o hub de descoberta, assessment e orquestração do projeto como um todo. O Azure Site Recovery é o motor de replicação que o Azure Migrate aciona para efetivamente mover máquinas virtuais, e que também serve como solução de disaster recovery depois que o ambiente já está em produção.

O Azure é seguro para armazenar dados financeiros e fiscais?

A plataforma sustenta certificações como ISO 27001, ISO 27017, ISO 27018 e ISO 27701, além de uma região própria no Brasil. Isso cobre a segurança da infraestrutura, mas a responsabilidade pela conformidade com a LGPD, incluindo base legal e retenção de dados, continua sendo da empresa controladora.