Atualizado em
A migração do TOTVS Protheus para a nuvem não acontece em um dia — e projetos que tratam a migração como uma tarefa simples de “mover os arquivos” costumam ter problemas em produção. Este checklist organiza a migração em sete fases estruturadas, com os pontos de atenção de cada etapa e os erros que mais atrasam ou comprometem o resultado.
O checklist foi construído com base na metodologia de migração da Adentro para ambientes Protheus e cobre toda a jornada: da descoberta do ambiente atual até a estabilização pós-go-live.
Neste checklist
- Fase 1 — Descoberta e levantamento
- Fase 2 — Arquitetura e sizing
- Fase 3 — Preparação do ambiente de destino
- Fase 4 — Migração de dados e homologação
- Fase 5 — Corte (go-live)
- Fase 6 — Pós-migração e estabilização
- Fase 7 — Plano de rollback
- Erros que atrasam ou comprometem a migração
- Perguntas frequentes
Fase 1 — Descoberta e levantamento
Antes de planejar qualquer coisa, é necessário entender completamente o ambiente atual. Esta fase gera o mapa do que existe e o que precisa ser migrado.
- Versão do TOTVS Protheus instalada (ERP + módulos)
- Versão do AppServer e DBAccess
- Versão e edição do SQL Server
- Sistema operacional do servidor (versão e licença)
- Configurações de hardware atual (CPU, RAM, storage)
- Volume e tamanho do banco de dados (total e crescimento mensal)
- Lista de customizações ADVPL ativas e responsáveis pelo código
- Lista de integrações externas (EDI, SEFAZ, transportadoras, e-commerce, APIs)
- Usuários simultâneos em pico e horários de pico
- Módulos ativos e jobs batch (horários e duração)
- Política de backup atual (frequência, destino, retenção, último teste de restore)
- Diagrama de rede atual (topologia, link de internet, filiais conectadas)
- Requisitos de conformidade ou restrições regulatórias
Não pule esta fase
Surpresas descobertas durante a migração — uma integração não documentada, uma customização sem código-fonte, um banco maior do que esperado — causam atrasos e custo adicional. O levantamento completo é o investimento que evita esses problemas.
Fase 2 — Arquitetura e sizing
Com o ambiente atual mapeado, esta fase define como o ambiente de destino vai ser construído.
- Definir o modelo de hospedagem (cloud privada, VPS vs Cloud vs Servidor Dedicado, colocation)
- Sizing do AppServer: vCPUs e RAM com base nos usuários simultâneos e módulos
- Sizing do SQL Server: vCPUs, RAM para buffer pool e versão compatível com o Protheus
- Sizing do storage: capacidade total, IOPS necessário, política de crescimento
- Definir arquitetura de rede: link dedicado, VPN, segmentação de rede
- Definir política de backup no ambiente de destino (RPO, RTO e RPO, retenção)
- Definir estratégia de alta disponibilidade (se aplicável)
- Definir estratégia de Guia de Disaster Recovery (se aplicável)
- Obter aprovação do sizing com o parceiro TOTVS
- Definir janela de corte: data e horário com menor impacto operacional
Fase 3 — Preparação do ambiente de destino
- Provisionar o servidor de destino conforme sizing aprovado
- Instalar e configurar o sistema operacional (Windows Server na versão compatível)
- Instalar e configurar o SQL Server na versão homologada para o Protheus
- Instalar AppServer e DBAccess nas versões corretas
- Configurar o firewall e as regras de acesso
- Configurar o link de conectividade (VPN ou link dedicado)
- Configurar monitoramento do ambiente (CPU, RAM, IOPS, disponibilidade)
- Configurar backup do ambiente de destino
- Testar conectividade de todos os sites e usuários remotos
- Documentar as configurações realizadas
Fase 4 — Migração de dados e homologação
Esta fase envolve mover o banco de dados e a aplicação para o ambiente de destino e validar que tudo funciona corretamente antes do corte.
- Fazer backup completo do banco de dados do ambiente atual
- Restaurar o banco no ambiente de destino e validar integridade
- Migrar os arquivos da aplicação Protheus (executáveis, dicionário de dados)
- Migrar customizações ADVPL e validar compilação no ambiente de destino
- Migrar arquivos de configuração do AppServer e DBAccess
- Configurar e testar todas as integrações externas no ambiente de destino
- Executar testes funcionais com usuários-chave de cada módulo
- Validar emissão de NF-e e comunicação com SEFAZ
- Validar rotinas de fechamento fiscal em ambiente de homologação
- Executar testes de carga (simular usuários simultâneos em pico)
- Validar desempenho e comparar com o ambiente atual
- Registrar e resolver todos os problemas identificados
- Obter aprovação formal dos usuários-chave para o corte
Fase 5 — Corte (go-live)
Planeje a janela de corte com antecedência
O corte deve ser realizado em uma janela de baixo impacto operacional — preferencialmente uma sexta-feira à noite, fim de semana ou período de menor movimento. Comunique todos os usuários com antecedência mínima de 48 horas.
- Comunicar todos os usuários sobre a data e horário do corte
- Encerrar todas as sessões ativas no ambiente atual
- Fazer backup final do banco de dados atual (após o encerramento das sessões)
- Sincronizar o banco de dados do ambiente de destino com o backup final
- Atualizar configurações de DNS e/ou redirecionamento de acesso
- Validar acesso de todos os usuários ao novo ambiente
- Validar operações críticas (login, NF-e, consultas de estoque)
- Manter equipe técnica disponível nas primeiras 4 horas após o corte
- Confirmar que o monitoramento está ativo no novo ambiente
- Comunicar aos usuários que o ambiente está disponível
Fase 6 — Pós-migração e estabilização
- Monitorar desempenho nas primeiras 72 horas após o corte
- Verificar se todos os jobs batch estão executando corretamente
- Verificar se todos os backups estão sendo realizados com sucesso
- Validar todas as integrações externas em operação real
- Coletar feedback dos usuários-chave de cada módulo
- Ajustar configurações de AppServer e SQL Server com base no uso real
- Revisar alertas de monitoramento e ajustar thresholds
- Documentar as configurações finais do ambiente de produção
- Definir data de desativação definitiva do ambiente antigo (após período de segurança)
- Revisar o sizing 30 dias após o go-live com base no uso observado
Fase 7 — Plano de rollback
O plano de rollback define o que fazer se algo der errado durante ou após o corte. Ter esse plano documentado e testado é a diferença entre um incidente controlado e uma crise.
- Definir o critério de acionamento do rollback (qual problema justifica reverter)
- Definir o responsável pela decisão de rollback e quem precisa ser notificado
- Garantir que o ambiente antigo permanece intacto por no mínimo 7 dias após o corte
- Documentar o passo a passo de reversão: reconfiguração de DNS, redirecionamento de usuários
- Estimar o tempo necessário para o rollback completo
- Testar o rollback em ambiente de homologação antes do corte real
- Comunicar o plano de rollback à equipe de TI e aos gestores envolvidos
Erros que atrasam ou comprometem a migração
- Descobrir integrações não documentadas durante o corte. Toda integração que não foi testada em homologação vai falhar em produção. Mapeie 100% das integrações na Fase 1.
- Fazer o corte durante o período de fechamento fiscal. Migração durante fechamento de mês ou período fiscal cria risco desnecessário. Planeje o corte para um período de menor criticidade.
- Não ter plano de rollback definido antes do corte. Tomar a decisão de reverter sob pressão, sem um plano, aumenta o tempo de indisponibilidade e o risco de perda de dados.
- Não testar com usuários reais em homologação. Testes feitos só pela TI não identificam problemas de usabilidade e regras de negócio que os usuários de cada módulo encontrariam.
- Subdimensionar o ambiente de destino. Sizing baseado em estimativas sem levantamento preciso resulta em ambiente inadequado que precisará ser expandido logo após o go-live.
- Desativar o ambiente antigo imediatamente após o corte. O ambiente antigo é o rollback. Mantenha-o intacto por pelo menos 7 dias após o go-live antes de desativar definitivamente.
Vai migrar o TOTVS Protheus para a nuvem?
A Adentro conduz o projeto de migração do Protheus do levantamento ao pós-go-live, com metodologia estruturada e equipe especializada.
Ver guia de migração Falar com especialistaPerguntas frequentes
Quanto tempo dura uma migração do Protheus para cloud?
Depende da complexidade do ambiente. Migrações simples (poucos usuários, banco pequeno, sem customizações extensas) podem ser concluídas em 3 a 4 semanas. Ambientes complexos (múltiplos módulos, customizações extensas, integrações, alto volume de dados) podem levar 2 a 4 meses. O levantamento da Fase 1 é o passo que permite estimar com precisão.
O sistema Protheus fica fora do ar durante a migração?
A indisponibilidade fica concentrada na janela de corte — que deve ser planejada para um horário fora do expediente. Durante as fases anteriores (descoberta, preparação, homologação), o sistema atual continua operando normalmente.
Preciso atualizar a versão do Protheus antes ou durante a migração?
Não é obrigatório migrar e atualizar ao mesmo tempo — de fato, fazer os dois juntos aumenta o risco. A recomendação é migrar primeiro com a versão atual e, após a estabilização no novo ambiente, planejar a atualização de versão como um projeto separado.
As customizações ADVPL funcionam igual no ambiente cloud?
Sim, desde que o AppServer e o SQL Server no ambiente de destino estejam nas versões corretas e as customizações sejam compiladas no novo ambiente. A Fase 4 do checklist inclui a validação das customizações — não assuma que vai funcionar sem testar.
Quem é responsável pela migração: a Adentro ou o parceiro TOTVS?
A responsabilidade é dividida. A Adentro é responsável pela infraestrutura: provisionar o ambiente, configurar o SQL Server, AppServer, DBAccess, rede, backup e monitoramento. O parceiro TOTVS é responsável pela aplicação: configuração do Protheus, validação das customizações, testes funcionais e suporte pós-go-live. As duas partes devem estar alinhadas desde a Fase 1.
Você também pode se interessar:
