Como calcular o custo total de migrar uma PME para a nuvem

O custo da migração não termina com a transferência dos sistemas

A nuvem pode mudar a forma como uma empresa paga pela sua infraestrutura, mas não garante, por si só, uma poupança. Para decidir com fundamento, uma PME precisa de comparar o custo total de propriedade (TCO) de manter os sistemas atuais com o de um ou mais cenários cloud durante o mesmo período. A comparação deve incluir tanto o projeto de migração como a operação posterior, e não apenas a tarifa estimada dos servidores.

O resultado depende das aplicações, do seu padrão de utilização, do volume de dados, do trabalho necessário para as adaptar e das condições contratadas. Por isso, as estimativas genéricas servem de orientação, mas não substituem os dados da própria empresa.

1. Estabelecer uma linha de base fiável

Antes de projetar as despesas futuras, convém inventariar o que existe e quanto custa atualmente. O registo deve relacionar aplicações e cargas de trabalho com a infraestrutura que utilizam, os respetivos requisitos de capacidade e os serviços que as suportam. Também é útil identificar contratos, equipamentos ou centros de dados cujo vencimento possa influenciar o calendário da migração.

A linha de base não deve limitar-se à compra de servidores. Conforme o modelo atual, pode incluir manutenção, alojamento, energia, armazenamento, cópias de segurança, licenças, ferramentas de gestão e o tempo que os colaboradores dedicam à operação do ambiente. Sempre que possível, é preferível utilizar custos reais e dados de utilização — não apenas a capacidade instalada — para evitar comparar uma infraestrutura dimensionada para picos com uma estimativa cloud baseada numa utilização média.

Esta referência permitirá medir posteriormente se as despesas mudaram e que rubricas explicam a diferença. Se forem omitidos custos atuais ou atribuídas ao projeto despesas que continuarão a existir, a comparação perde consistência.

2. Separar os custos de migração dos custos de operação

Para cada alternativa, organize os custos em dois blocos. O primeiro corresponde ao projeto de migração: avaliação e planeamento, ferramentas, serviços especializados, trabalho da equipa interna, testes, alterações nas aplicações e preparação dos dados. O segundo reúne as despesas recorrentes depois de as cargas de trabalho estarem operacionais.

A mão de obra interna também conta. Nem sempre implica contratar pessoal adicional, mas consome tempo que poderia ser dedicado a outras tarefas. Uma estimativa prática consiste em identificar os perfis que participarão, as atividades que realizarão e o tempo que lhes dedicarão; depois, é possível avaliar esse esforço segundo um critério coerente com o orçamento da empresa.

O método escolhido altera o perfil dos custos. Uma migração com poucas alterações pode exigir menos trabalho inicial, mas manter uma configuração ineficiente na nuvem. Adaptar ou redesenhar uma aplicação pode aumentar o esforço e a duração do projeto, mas permitir a utilização de serviços geridos ou de outras opções de arquitetura. Também existem alternativas intermédias, como migrar primeiro e otimizar alguns componentes mais tarde. Nenhuma opção garante, por si só, um custo total inferior: é necessário modelá-la para cada carga de trabalho.

3. Projetar a fatura cloud com base em padrões de utilização reais

No cenário cloud, calcule separadamente os recursos que se prevê consumir, como computação, memória e armazenamento, e os serviços complementares. A tarifa publicada por um fornecedor não equivale ao custo total: a estimativa depende da configuração escolhida, do consumo efetivo e das condições comerciais aplicáveis.

Inclua também bases de dados, cópias de segurança, monitorização, suporte e ferramentas de administração ou segurança, quer sejam fornecidas pelo fornecedor, quer por terceiros. Reveja as licenças de software existentes: podem mudar quando uma carga de trabalho é migrada, e algumas ferramentas são partilhadas entre ambientes locais e cloud. Evite contabilizar como poupança uma licença ou um contrato que a empresa não poderá realmente cancelar.

A transferência de dados merece uma rubrica própria. Podem existir custos para transferir informação para o ambiente cloud e, dependendo do fornecedor e do destino, para a retirar ou mover entre regiões ou plataformas. O montante depende do volume e da frequência das transferências; se esses dados ainda não forem claros, convém documentar a incerteza e modelar pressupostos distintos, em vez de apresentar um valor como definitivo.

4. Contabilizar a coexistência e a segurança

Durante uma transição, pode ser necessário manter os sistemas antigos e os novos em funcionamento ao mesmo tempo. Esse período de funcionamento em paralelo pode implicar infraestrutura duplicada, licenças, suporte e trabalho adicional. A duração dependerá do plano e das necessidades de validação, pelo que deve ser incorporada no calendário financeiro de cada cenário.

A segurança também não desaparece com a migração. O fornecedor e o cliente podem ter responsabilidades diferentes, pelo que a empresa deve identificar os controlos e as tarefas que continuará a gerir: por exemplo, a configuração de acessos, a proteção de dados, a monitorização e a resposta operacional. Acrescente as ferramentas, os serviços e as horas de trabalho correspondentes. Não atribua automaticamente ao fornecedor todos os custos ou responsabilidades de segurança.

5. Comparar cenários num horizonte comum

Escolha um período que permita refletir a utilização habitual das cargas de trabalho e as variações relevantes, como as alterações sazonais. Para cada alternativa, aplique a mesma duração e os mesmos pressupostos de negócio. Também convém separar o período inicial de entrada em funcionamento: os primeiros meses podem incluir tarefas de ajustamento e despesas que não representem a operação estabilizada.

Uma estrutura simples para o cálculo é:

A saída da nuvem merece uma estimativa própria. Se, no futuro, dados ou serviços forem transferidos para outro fornecedor ou para uma infraestrutura própria, poderão surgir custos de transferência, ferramentas, trabalho técnico e operação em paralelo. Não é possível determinar esse custo sem conhecer o volume de dados, a arquitetura e as condições contratuais; pode ser tratado como uma hipótese e atualizado durante a comparação de propostas.

Uma tabela para organizar a estimativa

Comparar o modelo e rever os seus pressupostos

A comparação é mais valiosa quando cada rubrica se baseia em dados verificáveis e é identificada como custo observado, estimativa ou pressuposto. Para os consumos cloud, as calculadoras dos fornecedores podem ajudar a criar cenários, mas os resultados devem ser comparados com o inventário, a utilização prevista e as condições específicas da contratação.

Em vez de depender de uma única previsão, pode ser útil comparar variantes de consumo e de migração: por exemplo, migrar uma aplicação com poucas alterações em comparação com adaptá-la, ou considerar uma utilização estável em comparação com uma variável. O objetivo não é prever com exatidão uma fatura futura, mas compreender que decisões alteram o custo e em que medida a conclusão depende de pressupostos ainda incertos.

Por fim, reveja o cálculo quando mudarem o consumo, a arquitetura, as licenças ou o calendário. Uma estimativa inicial é uma base para decidir e planear, não uma garantia de poupança. A comparação mais útil para a empresa é a que mostra, de forma transparente, o que está incluído, durante quanto tempo e em que condições.