Migrar ERP Brasileiro pra Nuvem em 2026: Guia por Vertical (TOTVS, SAP, Sankhya, Alterdata, Tasy)

ERP brasileiro rodando em servidor físico dentro do escritório virou exceção em 2026. Empresa que ainda mantém esse setup convive com 4 problemas previsíveis: hardware envelhecendo (5-7 anos de vida útil real), backup que ninguém testa, acesso remoto inseguro improvisado (VPN mal configurada, ou pior, RDP exposto direto), e custo de manutenção (energia, refrigeração, técnico). Migrar pra cloud profissional resolve todos os quatro, mas exige planejamento — cada ERP tem peculiaridade que muda a configuração.

Esse guia é pra gerente de TI ou diretor administrativo que precisa migrar ERP brasileiro pra nuvem em 2026 sem cair em armadilha. Cobre os 5 ERPs mais comuns no mercado nacional (TOTVS Protheus, SAP Business One, Sankhya, Alterdata, Tasy), as 4 etapas de migração assistida, requisitos por vertical e checklist de avaliação de provedor.

Por que migrar ERP brasileiro pra nuvem em 2026

Os motivos que mais aparecem em projetos reais de migração:

• Hardware envelhecendo: servidor de 5-7 anos começa a falhar (disco, fonte, RAM), substituir custa R$ 15-50 mil de uma vez, e demora semanas pra chegar
• Acesso remoto seguro: equipe trabalhando de casa, em viagem ou em filial precisa acessar ERP. Improvisação com VPN mal configurada ou RDP exposto direto é risco de incidente LGPD
• Backup que funciona: servidor local raramente tem backup testado. Cloud profissional inclui backup corporativo com restore validado
• Performance previsível: servidor próprio sofre com vizinhança barulhenta (outros sistemas no mesmo hardware) — cloud profissional dedicado entrega IOPS previsível
• Escalabilidade: empresa cresce, precisa de mais usuários simultâneos no ERP. Cloud aumenta RAM/CPU pelo painel sem trocar servidor
• Compliance LGPD: cloud brasileira com datacenter Tier III simplifica auditoria, criptografia e DPA pra LGPD
• Continuidade durante incidente físico: incêndio, enchente, roubo do escritório não derruba a operação se o ERP está em datacenter Tier III

Arquitetura padrão de ERP brasileiro na nuvem

A arquitetura básica usada na maioria das migrações em 2026 tem 4 componentes:

• Servidor de aplicação (Windows Server ou Linux): roda o binário do ERP. Configuração depende do sistema e do número de usuários.
• Banco de dados: SQL Server pra TOTVS Protheus e SAP Business One; Firebird pra Alterdata (via ODBC); Oracle pra Tasy (versões enterprise); PostgreSQL ou MySQL pra Sankhya.
• Camada de acesso remoto: RDS (Remote Desktop Services) com RD Gateway + MFA pra ERPs Windows. Cliente web quando o ERP suporta.
• Backup corporativo: snapshot diário do banco + arquivos de aplicação + configurações, com retenção configurável e imutabilidade anti-ransomware. Veja guia de backup corporativo.

Pra empresa SMB (até 30 usuários), tudo isso pode rodar em um único servidor virtual ou dedicado. Pra empresa média (50-200 usuários), separa-se aplicação e banco em servidores distintos. Pra empresa grande (200+ usuários), entra cluster, replicação e DR.

TOTVS Protheus na nuvem

Protheus é o ERP brasileiro com maior base instalada em médias e grandes empresas. Roda predominantemente em Windows Server com SQL Server, mas algumas versões antigas usam Microsoft DBF/CTREE ou Oracle.

Configuração típica em 2026:

• 10-30 usuários simultâneos: servidor virtual 4 vCPU + 16 GB RAM + 100 GB NVMe + Windows Server 2022 + SQL Server Standard
• 30-50 usuários: servidor virtual 8 vCPU + 32 GB RAM + 200 GB NVMe + Windows Server + SQL Server
• 50-100 usuários: servidor dedicado (bare metal) Xeon Gold 16 cores + 64-128 GB RAM ECC + NVMe RAID 1 + Windows Server + SQL Server Standard ou Enterprise
• 100+ usuários: servidor dedicado + SQL Server replicado + RDS farm com múltiplos servidores de aplicação

Acesso remoto: RDS com RD Gateway + MFA é o padrão. Pra empresa que prefere browser, Protheus tem cliente HTML5 (THTML) em versões recentes.

Backup específico: SQL Server full diário + diferencial a cada 4-6h + log shipping pra DR. Detalhe em guia Protheus na nuvem.

SAP Business One (SAP B1) na nuvem

SAP B1 é o ERP mais comum em empresas brasileiras de médio porte que precisam padrão SAP sem o ticket S/4HANA. Roda Windows Server + SQL Server (versões anteriores) ou Linux + HANA (versão moderna).

Configuração típica em 2026:

• SAP B1 with SQL Server (10-30 usuários): Windows Server 2022 + SQL Server Standard, 4-8 vCPU + 16-32 GB RAM + NVMe
• SAP B1 with HANA (qualquer porte): Linux SUSE ou RHEL + HANA — requisitos de RAM significativos (64 GB+ pra base pequena, 256 GB+ pra base maior)
• 50+ usuários: separa aplicação e banco em servidores distintos, considera bare metal pra HANA

Acesso remoto: SAP B1 Client desktop via RDS. Web client disponível em SAP B1 Cloud (versão SAP, paralela ao deploy próprio).

Particularidade: SAP B1 com HANA exige hardware certificado pela SAP em alguns cenários. Provedor brasileiro decente confirma certificação antes de fechar.

Sankhya na nuvem

Sankhya é ERP brasileiro forte em médias empresas (especialmente distribuição, varejo e serviços). Tem banco MySQL ou Oracle conforme versão. Cliente é desktop (RDS) ou web (Sankhya Om).

Configuração típica em 2026:

• 10-30 usuários: servidor virtual 4 vCPU + 16 GB RAM + 100 GB NVMe + Windows Server ou Linux + MySQL
• 30-100 usuários: 8 vCPU + 32-64 GB RAM + 200 GB NVMe, separa aplicação e banco
• 100+ usuários: servidor dedicado + MySQL/Oracle em servidor próprio + RDS farm

Diferencial: Sankhya Om (cliente web) reduz necessidade de RDS pra muitos casos de uso, simplificando arquitetura.

Alterdata na nuvem

Alterdata é forte em pequena e média empresa brasileira (contabilidade, distribuição, varejo, RH). Roda Windows + Firebird (via ODBC) ou Oracle em versões maiores.

Configuração típica em 2026:

• 5-20 usuários: servidor virtual 2-4 vCPU + 8-16 GB RAM + 80 GB NVMe + Windows Server + Firebird
• 20-50 usuários: 4-8 vCPU + 16-32 GB RAM + 150 GB NVMe
• 50+ usuários: servidor dedicado, considera migração Firebird → Oracle se Alterdata oferece pra essa versão

Particularidade: Firebird precisa de configuração específica em ambiente cloud (page cache, drivers ODBC). Provedor com experiência em Alterdata sabe ajustar — pergunte antes de fechar.

Acesso remoto: RDS com RD Gateway + MFA é o padrão. Algumas funcionalidades Alterdata têm versão web.

Tasy na nuvem (vertical saúde)

Tasy (Philips Healthcare) é o ERP/HIS dominante no setor de saúde brasileiro — hospitais, clínicas grandes, operadoras de plano de saúde. Roda Oracle Database em versões enterprise. Comparativo de Tasy ao lado de outros ERPs brasileiros (Protheus, SAP B1, Sankhya, Alterdata) em migrar ERP brasileiro pra nuvem por vertical.

Configuração típica em 2026:

• Clínica média (50-200 usuários): servidor dedicado Xeon Gold 16-24 cores + 128-256 GB RAM ECC + NVMe RAID + Oracle Database + Windows Server
• Hospital médio (200-500 usuários): servidor dedicado de alto porte + Oracle separado + RDS farm
• Hospital grande (500+ usuários): múltiplos servidores dedicados, Oracle RAC, DR ativo

Particularidades críticas:

• LGPD + Resolução CFM: retenção de prontuário mínimo 20 anos, criptografia obrigatória, log de auditoria detalhado
• Licenciamento Oracle: verificar implicações de licença em ambiente cloud (alguns modelos cobram por núcleo virtualizado)
• Acesso remoto: RDS com RD Gateway + MFA + log de auditoria completo (quem acessou qual prontuário, quando)
• Backup corporativo com retenção longa e restore drill mensal

Setor saúde é o que mais ganha com migração pra cloud profissional brasileira — compliance LGPD + CFM fica muito mais simples que cloud internacional. Guia específico vertical saúde em cloud pra clínica e hospital com Tasy ou MV.

Processo de migração assistida — 4 etapas

Provedor brasileiro decente faz migração assistida em 2-4 semanas. As etapas padrão:

Etapa 1 — Diagnóstico do ambiente atual (1-3 dias)

Inventário: versão do ERP, versão do banco, número de usuários simultâneos, volume de dados, integrações ativas (NFe, boleto, plano de saúde, etc), políticas de segurança vigentes. Saída: documento de arquitetura recomendada na cloud.

Etapa 2 — Provisionamento do ambiente espelho (1-3 dias)

Provedor monta o servidor (virtual ou dedicado), instala sistema operacional, banco de dados, ERP, configura backup e RDS. Ambiente fica pronto pra testes antes de migrar dado real.

Etapa 3 — Migração de dados em paralelo (2-7 dias)

Copia base do ERP do servidor antigo pro novo, em paralelo (ambiente antigo continua operando). Roda testes funcionais, valida relatórios, performance, integrações.

Etapa 4 — Cutover em janela combinada (1-4h)

Em horário de baixo movimento (madrugada, fim de semana): para o ERP antigo, faz sincronização final delta dos últimos dados, aponta usuários pro novo ambiente, valida. Ambiente antigo fica como rollback por 30 dias até estabilização.

Checklist pra avaliar provedor de cloud pra ERP brasileiro

1. Equipe que conhece o ERP específico (Protheus, SAP B1, Sankhya, Alterdata, Tasy) — não “genérico”
2. Datacenter Tier III em território brasileiro com peering IX.br pra latência baixa
3. Suporte engineer em português 24h via WhatsApp/telefone (não tíquete)
4. Migração assistida inclusa ou disponível como serviço, sem precisar contratar consultoria externa
5. Backup corporativo com imutabilidade anti-ransomware e DPA pra LGPD
6. RDS configurado com MFA e log de auditoria
7. SLA contratual com multa por descumprimento
8. Pagamento em Real com nota fiscal brasileira, sem IOF e sem variação cambial
9. Licenças Microsoft (Windows Server, SQL Server) inclusas ou cobradas com clareza
10. Janela de cutover combinada em horário de baixo movimento
11. Ambiente antigo como rollback por 30 dias até estabilização
12. Documentação técnica clara sobre arquitetura, configurações e processo de restore

Por que considerar Audaks pra rodar ERP brasileiro na nuvem

A Audaks Cloud opera servidor dedicado bare metal e servidor virtual em datacenter Tier III em São Paulo, com foco em hospedar ERP brasileiro pra empresa SMB e média. Pontos que costumam pesar na decisão:

• Equipe técnica que conhece TOTVS Protheus, SAP B1, Sankhya, Alterdata e Tasy — não “cloud genérica”
• Migração assistida gratuita pra cenários SMB/médios, com cutover combinado em janela de baixo movimento
• Suporte direto com engenheiro via WhatsApp 24h — sem tíquete de primeira linha
• Backup corporativo com imutabilidade anti-ransomware e retenção configurável de 7-365+ dias
• RDS com RD Gateway + MFA configurado por padrão pra empresa regulada
• DPA pra LGPD disponível, log de auditoria completo
• Pagamento em Real com nota fiscal brasileira, sem IOF, sem dólar
• Datacenter Tier III em SP com peering IX.br — latência de 1-5ms pra Sudeste e Sul

Perguntas frequentes sobre migração de ERP brasileiro pra nuvem

Posso migrar ERP brasileiro pra AWS, Azure ou Google Cloud?

Tecnicamente sim, na prática raramente compensa. Cloud internacional cobra em dólar com IOF de 6,38%, suporte em inglês (sem fluência em Protheus/SAP B1/Alterdata), latência maior pra integrações brasileiras (NFe, boleto, plano de saúde) e compliance LGPD precisa de cláusula adicional de transferência internacional. Provedor brasileiro especializado entrega o mesmo serviço em Real, com equipe que conhece o ERP específico.

Quanto tempo leva pra migrar ERP pra nuvem?

Migração típica de empresa SMB ou média: 2-4 semanas do primeiro contato até cutover completo. Diagnóstico (1-3 dias), provisionamento (1-3 dias), migração de dados (2-7 dias), cutover (1-4h em janela combinada), estabilização (30 dias com rollback disponível). Empresas grandes com múltiplos sistemas integrados podem levar 2-4 meses.

Quanto custa rodar ERP brasileiro em servidor profissional na nuvem?

Investimento varia conforme ERP, número de usuários e configuração. Faixa de mercado em 2026: empresa SMB (10-30 usuários) costuma operar em servidor virtual; empresa média (30-100 usuários) geralmente em dedicado bare metal; empresa grande (100+ usuários) em arquitetura com múltiplos servidores. Provedor brasileiro dimensiona pelo workload — peça orçamento sob medida.

Posso continuar usando minhas licenças Windows Server e SQL Server na cloud?

Geralmente sim, via programa Microsoft License Mobility through Software Assurance. Verifique com seu parceiro Microsoft antes da migração. Provedor brasileiro decente também oferece licenças inclusas em modelo BYOL (Bring Your Own License) ou SPLA (Service Provider License Agreement) — confirme antes de fechar.

Como configurar acesso remoto seguro pra ERP brasileiro na nuvem?

Padrão moderno: RDS (Remote Desktop Services) com RD Gateway + autenticação multi-fator (MFA). Usuário conecta de qualquer lugar (escritório, casa, viagem) com login + senha + segundo fator (app autenticador). Tudo sob TLS, com log de auditoria de cada sessão. RDP exposto direto na internet sem RD Gateway é vulnerabilidade — não usar nunca.

O que acontece com o servidor antigo após a migração?

Fica como rollback por 30 dias até estabilização do ambiente novo. Depois desse período, dado é arquivado em backup (cumprindo retenção obrigatória por regulação) e o hardware antigo pode ser desativado ou repurposed.

ERP brasileiro na nuvem cumpre LGPD?

Cumpre, quando hospedado em cloud brasileira com datacenter Tier III em território nacional, criptografia AES-256, log de auditoria, política de retenção documentada e DPA assinado entre cliente (Controlador) e provedor (Operador). Cloud brasileira simplifica esse compliance — sem cláusulas adicionais de transferência internacional como exige cloud estrangeira.

Posso migrar só o banco de dados e manter aplicação local?

Tecnicamente pode (arquitetura híbrida), mas raramente compensa. Latência entre aplicação local e banco na cloud pode degradar performance significativamente em ERP transacional. Recomenda-se migrar ambos juntos pra manter a comunicação aplicação-banco na rede interna do datacenter.

O que é restore drill e por que importa pra ERP?

Restore drill é o teste periódico de restauração do backup em ambiente isolado pra validar que funciona. Pra ERP brasileiro, recomenda-se drill mensal. Backup que nunca foi restaurado é hipótese, não backup — empresa só descobre que o backup falha quando precisa restaurar e não funciona. Provedor sério ajuda a executar e documenta cada drill.

Posso ter ambiente híbrido (cloud + local) durante a migração?

Pode, e é o padrão. Durante as 2-4 semanas de migração assistida, o ambiente antigo continua operando enquanto o novo é preparado. Cutover acontece em janela curta (1-4h em horário combinado) e o ambiente antigo fica como rollback por 30 dias. Depois disso, ambiente único na cloud.