"Migrar tudo para a nuvem" virou disco riscado em muita reunião de diretoria: alguém ouviu que "todo mundo já foi", encomendou o projeto inteiro de uma vez, e um ano depois a fatura de nuvem custa mais do que o servidor que ela substituiu. A resposta oposta também é comum: a empresa trava, decide não mexer em nada, e o sistema mais importante continua rodando numa máquina que ninguém mais sabe consertar.

As duas respostas partem do mesmo erro: tratar a decisão como uma escolha única, para a empresa inteira. Uma pesquisa de 2023 do Cetic.br com empresas brasileiras já mostrava que não é assim que a decisão acontece na prática: 53% das empresas pagavam por e-mail em nuvem, um serviço simples de trocar; só 33% pagavam por capacidade de processamento em nuvem, e apenas 24% por uma plataforma para hospedar sistemas próprios em desenvolvimento. A distância entre esses números não é atraso — é seleção. Cada empresa já decide, sistema por sistema, o que vale a pena mover.

Quem decide não é só quem assina o contrato de TI. É o dono ou diretor que aprova o investimento, e é o responsável por TI que vai sustentar a escolha depois. Para os dois, a pergunta certa nunca é "vamos para a nuvem ou não" — é "este sistema específico ganha, perde, ou só funciona se for refeito antes de subir".

O que muda de sistema para sistema

A mesma pesquisa do Cetic.br mostra a diferença por setor de atividade: entre empresas de informação e comunicação, 57% já pagavam por capacidade de processamento em nuvem em 2023; no setor de alojamento e alimentação, a proporção era de 23%, e na indústria, 27%. Não é que um setor "entende mais" de tecnologia — é que os sistemas que cada um usa têm perfis diferentes de dependência, atualização e importância para a operação.

Um sistema ganha em nuvem quando o uso varia ao longo do mês (um pico de vendas no fim de ano, uma folha de pagamento processada uma vez por período), quando pessoas em locais diferentes precisam acessar o mesmo sistema, ou quando o fornecedor já entrega a versão em nuvem como padrão — e-mail e ferramentas de escritório são o exemplo mais simples. Também ajuda quando o provedor de nuvem tem centro de dados no Brasil: o Azure, da Microsoft, mantém uma região em São Paulo, o que aproxima o sistema de quem usa daqui.

Um sistema fica melhor dentro da empresa quando ele conversa em tempo real com um equipamento físico local — uma máquina de produção, uma balança, uma catraca —, quando a conexão até o provedor de nuvem é lenta ou instável, ou quando o custo mensal de rodar fora supera o custo de manter dentro. Esse cálculo precisa ser feito, não presumido.

E existe um terceiro grupo, o mais fácil de ignorar: sistemas que só sobem depois de atualizados ou reescritos. A documentação de migração da Microsoft para o Azure trata a avaliação de compatibilidade — versão do sistema, do banco de dados, das bibliotecas usadas — como etapa anterior a qualquer decisão de mover, e recomenda mudar a estrutura de um sistema só quando existe uma razão de negócio clara, porque a troca exige esforço de desenvolvimento e teste significativo. Um sistema que o próprio fabricante já parou de atualizar não é candidato a "subir direto": precisa de uma etapa de correção antes.

Por que decidir tudo de uma vez não resolve

O jeito comum de tratar essa decisão é escolher um lado e aplicar para tudo. De um lado, a empresa contrata a migração completa porque ouviu que reduz custo — e descobre, meses depois, que o sistema que rodava sem custo variável na sala dos servidores agora gera uma fatura que sobe com o uso, sem ninguém ter calculado antes quanto isso custaria no volume real da empresa.

Do outro lado, a empresa que resiste a qualquer mudança mantém um sistema antigo rodando numa máquina física cada vez mais difícil de substituir, alegando que "o fornecedor disse que não roda em nuvem" — sem checar se essa frase, ouvida há alguns anos, ainda é verdade hoje.

As duas posturas têm o mesmo ponto cego: nenhuma fez o levantamento sistema por sistema. A pergunta "o que muda para a empresa" — em tempo de acesso, em dependência de uma pessoa específica, em capacidade de recuperar depois de uma pane — nunca chegou a ser feita para cada sistema individualmente.

O tamanho do problema de decidir errado aparece em números de infraestrutura de forma mais ampla. No levantamento mais recente do Uptime Institute sobre interrupções de data center, publicado em maio de 2026, 57% das empresas atingidas por uma parada relataram prejuízo acima de US$ 100 mil, e uma em cada cinco (20%) relatou prejuízo acima de US$ 1 milhão. O dado não é sobre nuvem especificamente — é sobre o custo de uma decisão de infraestrutura mal dimensionada, esteja ela dentro ou fora da empresa.

O que precisa existir na prática

Um inventário do que a empresa tem, sistema por sistema. Sem saber o que existe — versão, fornecedor, quem depende de quem —, qualquer decisão de mover é um chute. É o primeiro passo antes de qualquer proposta de nuvem.

Um critério técnico por sistema, não só um critério financeiro. Latência até o usuário, dependência de equipamento físico local, se o fornecedor sustenta uma versão em nuvem — cada resposta muda o resultado para aquele sistema específico.

Migração em etapas, começando pelo mais simples. Sistemas de teste e de uso interno primeiro; o sistema que sustenta a operação principal, só depois que o processo já foi validado em algo menos crítico.

Estimativa de custo mensal antes de mover, não depois. O que um sistema custa hoje, parado numa sala, precisa ser comparado com o que vai custar rodando por uso — sem isso, a economia prometida pela nuvem é só uma suposição.

Um plano para o que não sobe ainda. Sistema sem versão em nuvem sustentada entra numa lista com prazo — atualizar, substituir ou reescrever —, em vez de ficar esquecido até quebrar.

Um único responsável acompanhando a decisão inteira. Sem alguém dono do resultado, cada sistema é decidido isoladamente por quem comprou aquele projeto na época, e ninguém revisita a escolha depois.

É assim que a Skills IT trabalha: com o levantamento de cada sistema antes de qualquer proposta, o critério técnico por carga de trabalho e a estimativa de custo mensal apresentada antes de qualquer mudança.

O ganho de decidir sistema por sistema

O ganho não é "economizar com nuvem" nem "manter tudo como está" — os dois são efeitos possíveis, não o objetivo. O ganho real é que cada sistema fica no lugar que sustenta o negócio: o que precisa de acesso de qualquer lugar tem acesso de qualquer lugar; o que precisa de resposta imediata continua perto de onde é usado; e o que precisa de reforma tem uma reforma agendada, em vez de virar um problema descoberto no dia em que quebra.

O efeito financeiro aparece na previsibilidade: sem migrar por modismo nem represar por medo, o custo mensal de cada sistema é uma conta conhecida, calculada antes — não uma surpresa depois. O efeito operacional aparece na hora da pane: quando o levantamento já existe, a equipe sabe exatamente o que checar em vez de reconstruir o mapa do zero sob pressão.

Tem ainda um ganho para quem decide o orçamento: uma proposta de nuvem que chega sem esse levantamento é uma proposta pela metade. O diretor que pede "me mostre sistema por sistema, o que muda e quanto custa" está pedindo exatamente o que deveria ter sido feito antes de qualquer contrato assinado. É por isso que, na Skills IT, a primeira entrega de um projeto de nuvem é esse levantamento — não a proposta de preço.

Um roteiro para começar

  1. Liste todos os sistemas que sustentam a operação, com fornecedor e versão. Sem essa lista, a decisão seguinte não tem base.
  2. Marque, ao lado de cada um, se ele depende de outro sistema ou de um equipamento físico local. É o que decide se ele pode mover sozinho ou só em grupo.
  3. Pergunte ao fornecedor, por escrito, se existe uma versão em nuvem sustentada — e desde quando. "Não roda em nuvem" ouvido há três anos pode já não ser verdade.
  4. Calcule o custo mensal projetado de cada sistema fora da empresa, antes de decidir. Compare com o custo de mantê-lo dentro, incluindo a manutenção do equipamento atual.
  5. Comece a migração por um sistema de baixo risco, não pelo mais importante. O aprendizado do primeiro sistema barateia e reduz o risco dos seguintes.
  6. Defina o que fica de fora por enquanto — e por quanto tempo. Um sistema que não sobe hoje precisa de uma data de revisão, não de um "nunca mais se fala nisso".