Como levar o sistema da empresa para a nuvem sem parar a operação

O medo de migrar o sistema para a nuvem tem dia e hora. É a segunda-feira de manhã em que nada funciona, a nota não sai e a impressora não imprime. Uma migração bem feita é o oposto disso, sem emoção nenhuma. Na segunda, as pessoas entram no sistema e só percebem que ele está mais rápido.

O que separa uma coisa da outra é o trabalho feito antes da virada. O plano é escrito para que, no dia, ninguém precise decidir nada.

Comece pelo inventário

O sistema conversa com muito mais coisa do que parece. Antes de mover qualquer servidor, liste tudo o que depende dele.

• Integrações com banco, governo, e-commerce, transportadora e outros sistemas.
• Impressoras, etiquetas e coletores, que costumam ser os primeiros a falhar na segunda-feira.
• Rotinas agendadas, relatórios automáticos e cargas noturnas.
• Regras de acesso por endereço de IP, VPN das filiais, firewall e certificados.
• Bancos e usuários de outros sistemas que dividem o mesmo servidor.
• Pastas compartilhadas e arquivos que o sistema lê ou grava.

A peça esquecida é a que para na segunda.

O inventário também mostra o que não precisa ir. Numa migração, 3 TB iam ser levados para a nuvem quando só uns 80 GB eram necessários.

Decida o tamanho com dados

Meça o uso atual por algumas semanas, incluindo um fechamento de mês. Processador, memória, velocidade de disco, tamanho e crescimento do banco. Com isso, o ambiente na nuvem nasce do tamanho certo, sem pagar por sobra e sem ficar lento no pico. A região também conta, porque servidor perto dos usuários responde mais rápido.

Confira também o tamanho real do banco. Já vimos um banco quatro vezes maior que o informado, porque os 30 GB que todo mundo citava eram o arquivo compactado.

Teste antes de virar

Monte uma cópia da produção no ambiente novo e peça para quem usa o sistema testar as rotinas que importam. Emitir nota, imprimir, rodar as integrações, tirar os relatórios do fechamento. Esse ensaio também mostra quanto tempo a cópia final dos dados leva, e é com esse número que se marca a janela da virada.

Caso real. Num ensaio feito na véspera, o procedimento do fabricante do sistema tinha três lacunas. O mesmo ensaio mediu a janela real, de 2h30 a 3h, contra os 30 a 60 minutos da estimativa inicial. Achar isso no ensaio custou uma noite. Na virada, teria custado a segunda-feira.

O que costuma pegar

• Servidor novo em outro fuso horário, gravando a nota fiscal com 3 horas de diferença.
• Banco criado com outra configuração de idioma e ordenação, que só dá erro quando alguém usa a tela.
• Cópia da produção para teste levando junto a configuração de e-mail. Já vimos a base de teste mandar cobrança para clientes reais.
• Pasta de rede que só fica disponível depois de o sistema subir, e o sistema sobe sem ela.

A virada

A virada acontece fora do expediente, à noite ou no fim de semana, seguindo um roteiro escrito passo a passo. Os dados são sincronizados uma última vez, as conexões passam a apontar para o ambiente novo e usuários-chave conferem o sistema antes de liberar para todos. A conferência tem critério combinado antes, como uma nota autorizada pela SEFAZ de produção e um e-mail saindo do sistema.

O roteiro tem também o caminho de volta. Fica combinado antes qual problema faz voltar para o ambiente antigo e até que horas essa decisão pode ser tomada.

Os primeiros dias

Nos primeiros dias, o monitoramento fica mais perto e o time fica de prontidão para os ajustes que sempre aparecem. Quando surge uma diferença, a regra é contar a mesma coisa nos dois ambientes antes de culpar a migração.

O ambiente antigo continua guardado por alguns dias, como garantia, mas desligado de verdade. Já vimos o servidor antigo ser religado por engano e os dois sistemas gravarem na mesma base. Só depois de tudo estável ele sai de vez, e a empresa para de pagar por dois ambientes.

E se o melhor for ficar no servidor da empresa?

Também acontece, e migrar sem motivo é só custo novo. Link de internet fraco, investimento recente em servidor ou uma exigência do próprio sistema podem fazer do servidor local a melhor escolha por agora. A decisão certa sai da comparação de custo, desempenho e risco, com números, e pode ser revista depois.

Como a Cloud Labs trabalha nisso

A Cloud Labs leva sistemas para ambientes dedicados na Oracle Cloud e na AWS, com a conta em nome do cliente. A migração é planejada, com teste antes da virada e troca fora do horário comercial, e o plano de volta fica escrito antes de começar. Para quem prefere manter o servidor na empresa, a Cloud Labs também assume a gestão do servidor local.