Migrar de provedor de nuvem parece uma decisão técnica simples até o momento em que uma empresa tenta fazer isso de fato. Jean Pierre Lessa e Santos Ferreira, diretor de tecnologia, aponta que a dependência excessiva de um único fornecedor raramente nasce de uma escolha deliberada: ela se acumula aos poucos, serviço por serviço, até que sair custa mais do que ficar.
Esse acúmulo silencioso é o que torna o problema difícil de perceber a tempo. Cada integração nativa do provedor resolve um problema imediato e parece uma boa decisão isolada, mas o conjunto delas vai reduzindo as opções da empresa sem que ninguém tenha decidido isso conscientemente.
Como a dependência se instala sem ser percebida?
O caminho mais comum começa com serviços gerenciados que aceleram o desenvolvimento: banco de dados proprietário, fila de mensagens exclusiva, funções que só existem naquele ecossistema. Cada um desses recursos entrega valor real no curto prazo, o que explica por que a equipe segue adotando mais deles sem medir o efeito acumulado. Uma função de computação exclusiva do provedor pode economizar semanas no início e ainda assim se tornar o ponto mais caro de substituir depois.
Jean Pierre Lessa e Santos Ferreira ressalta que o problema não está em usar recursos nativos de um provedor, mas em usá-los sem registrar onde estão as amarras. Sem esse mapeamento, a arquitetura cresce presa a decisões que ninguém revisita, e o custo de desfazer essas amarras só fica visível quando alguém tenta.
O custo que só aparece na hora de sair
Trocar de fornecedor exige reescrever integrações, migrar dados em formatos proprietários e, com frequência, pagar taxas de saída sobre o volume transferido. Esses custos raramente entram no orçamento inicial, porque ninguém planeja a saída no momento da entrada. Uma migração que parecia simples no papel pode levar meses quando se descobre que parte da lógica de negócio foi implementada dentro de funções específicas do provedor, e não no código da aplicação.
Existe também um custo menos visível: o poder de negociação. Uma empresa que não tem alternativa viável perde força para discutir preço, prazo de suporte ou condições contratuais, porque o fornecedor sabe que trocar de provedor seria mais caro do que aceitar os novos termos.
Práticas que mantêm a porta de saída aberta
Adotar contêineres, infraestrutura como código e protocolos abertos como REST e SQL não elimina a conveniência dos serviços gerenciados, mas cria uma camada de portabilidade entre a aplicação e o provedor específico. Jean Pierre Lessa e Santos Ferreira examina que essa camada é o que permite trocar um componente sem reescrever o sistema inteiro, reduzindo tanto o risco técnico quanto o tempo de uma eventual migração.
Manter backups em formato aberto e documentar os modelos de dados de forma independente do provedor também evita que a empresa fique refém de um único ambiente para simplesmente recuperar o que já é seu. São escolhas que custam pouco no momento em que são feitas e evitam um custo bem maior mais adiante.
Independência não é evitar a nuvem, é preservar escolha
O objetivo não é recusar recursos nativos de um provedor por princípio, o que na prática tornaria qualquer arquitetura mais lenta e mais cara de manter. Jean Pierre Lessa e Santos Ferreira esclarece que o objetivo é preservar a capacidade de decidir, mantendo a empresa livre para trocar quando a relação deixar de fazer sentido.
Essa disciplina não se resolve em um projeto único de migração. Ela é uma prática contínua de revisão, feita antes de cada novo serviço proprietário entrar na arquitetura, e não depois que a dependência já se tornou estrutural. O momento certo de perguntar se vale a pena abrir mão de portabilidade é sempre antes da assinatura do contrato, nunca no meio de uma negociação em que a empresa já perdeu a força para recusar.
