Plano de saída do provedor de nuvem: como não ficar refém

O que é vendor lock-in e por que ele sai caro

Vendor lock-in, ou aprisionamento tecnológico, acontece quando trocar de fornecedor fica tão caro, arriscado ou demorado que a empresa continua com ele mesmo insatisfeita. Na nuvem isso raramente vem de uma decisão única. O lock-in cresce aos poucos: um banco de dados gerenciado aqui, uma fila proprietária ali, scripts de automação que só funcionam na API de um provedor, backups guardados num formato que só aquele ambiente lê.

O problema quase nunca aparece no dia a dia. Aparece quando o contrato vence e o reajuste vem acima do esperado, quando o nível de serviço cai e o suporte não responde, quando o provedor muda a política de preços ou sai do mercado, ou quando uma exigência regulatória pede que os dados fiquem em outro lugar. Nessa hora a empresa descobre que não sabe quanto tempo levaria para sair, quanto custaria transferir os dados nem quais sistemas parariam no meio do caminho.

Um plano de saída não significa desconfiar do provedor atual nem se preparar para trocá-lo. Serve para manter a empresa com poder de negociação e continuidade garantida. Quem sabe que consegue sair negocia melhor, e quem nunca testou a saída costuma aceitar condições que não aceitaria de outra forma.

Onde o aprisionamento realmente acontece

Antes de montar o plano, é preciso mapear em quais pontos a dependência é real. Nem todo serviço de nuvem prende da mesma forma. Uma máquina virtual com Windows Server ou Linux padrão é relativamente fácil de mover. Um sistema construído em cima de funções serverless, com banco de dados proprietário e autenticação integrada a um único ecossistema, pode levar meses para migrar.

As fontes mais comuns de lock-in em ambientes corporativos são:

• Dados em formato proprietário: bancos gerenciados com recursos exclusivos, arquivos de backup que só podem ser restaurados na mesma plataforma, logs em formatos fechados.
• Custo de saída de dados (egress): muitos provedores cobram pouco para receber dados e bastante para enviá-los para fora. Em volumes de dezenas de terabytes, a conta da migração pode surpreender.
• Serviços gerenciados exclusivos: filas, funções, ferramentas de análise e IA que não têm equivalente direto em outro provedor.
• Identidade e acessos: usuários, grupos, permissões e integrações de login único amarrados a um diretório específico.
• Automação e infraestrutura como código: templates escritos só para a ferramenta nativa de um provedor.
• Conhecimento concentrado: quando só o fornecedor sabe como o ambiente está configurado e não há documentação do lado do cliente.

Esse inventário é o ponto de partida. Para cada sistema crítico, registre onde ele roda, onde ficam os dados, de quais serviços exclusivos ele depende e quem detém o conhecimento de configuração. Muitas vezes a empresa descobre que 80% do ambiente é portável e que o risco real está concentrado em dois ou três sistemas.

Portabilidade de dados e formatos abertos

Numa migração, a infraestrutura pode ser reconstruída. Os dados não. Por isso a portabilidade de dados é o centro de qualquer plano de saída. A pergunta que importa não é se o provedor permite exportar, mas se você consegue exportar tudo, num formato utilizável, dentro de um prazo aceitável e sem depender da boa vontade de ninguém.

Formatos abertos e amplamente suportados reduzem muito esse risco. Para bancos de dados, prefira motores com padrão de mercado, como PostgreSQL, MySQL ou SQL Server, em vez de variações proprietárias que só existem num provedor. Para arquivos e documentos, use formatos que qualquer ferramenta leia. Para máquinas virtuais, formatos de disco reconhecidos por diferentes hipervisores facilitam a conversão. Para backups, a regra de ouro é ter pelo menos uma cópia fora do provedor principal, restaurável em outro ambiente.

A legislação brasileira também trata do tema. A LGPD, no artigo 18, garante ao titular o direito à portabilidade dos seus dados pessoais a outro fornecedor de serviço. Isso não resolve sozinho a portabilidade de toda a operação de uma empresa, mas mostra que exportar dados de forma estruturada é uma expectativa legítima e deve estar prevista no contrato.

Um backup que nunca foi restaurado fora do provedor de origem ainda não provou que é um plano de saída. Até ser testado, é só uma hipótese.

Cláusulas de saída: o que exigir no contrato

O melhor momento para negociar a saída é antes de entrar. Na assinatura, o provedor quer fechar o negócio e costuma aceitar condições que depois ficam difíceis de conseguir. Muitos contratos de nuvem tratam o encerramento em poucas linhas genéricas, e é justamente aí que o risco se esconde.

Ao revisar ou negociar um contrato, verifique pelo menos estes pontos:

1. Propriedade dos dados: cláusula explícita de que os dados pertencem ao cliente, incluindo metadados, logs e configurações.
2. Formato e meio de devolução: em que formato os dados serão entregues, por qual meio e em quanto tempo após a solicitação.
3. Período de transição: prazo em que o ambiente continua acessível após o fim do contrato, para que a migração aconteça sem pressa. De 30 a 90 dias é uma referência comum.
4. Custos de saída: valores de transferência de dados, horas de apoio técnico na migração e eventuais multas por rescisão antecipada, tudo definido por escrito.
5. Assistência na transição: obrigação de o provedor colaborar com o novo fornecedor, fornecendo documentação e acessos necessários.
6. Eliminação comprovada: compromisso de apagar os dados após a migração, com evidência formal, o que também é relevante para a LGPD.

Se o provedor não aceitar alguma dessas cláusulas, isso já é informação útil. Um fornecedor que dificulta a saída no papel provavelmente vai dificultar na prática.

Como montar e testar o plano de saída

Um plano de saída eficiente não precisa ser um documento enorme. Ele deve responder, de forma objetiva, a quatro perguntas: o que precisa ser movido, para onde, em que ordem e em quanto tempo. Com o inventário e o contrato revisados, o próximo passo é transformar isso em procedimento.

Uma estrutura prática inclui:

• Classificação por criticidade: quais sistemas precisam voltar em horas, quais podem esperar dias e quais podem ser desativados.
• Destino alternativo definido: outro provedor de nuvem, nuvem privada ou ambiente híbrido, com capacidade estimada.
• Sequência de migração: dependências mapeadas, como identidade antes de aplicações e banco de dados antes do sistema que o consome.
• Estimativa de custo e prazo: incluindo transferência de dados, horas técnicas e período com ambientes em paralelo.
• Responsáveis: quem decide, quem executa e quem comunica usuários e clientes.

O teste é o que separa um plano real de um documento na gaveta. Não é preciso migrar tudo para validar. Restaurar periodicamente um backup em outro ambiente, subir uma cópia de um sistema crítico em infraestrutura alternativa ou exportar uma base completa e medir o tempo já revelam os gargalos. Um teste por ano, ou a cada mudança relevante de arquitetura, mantém o plano atualizado.

Também vale adotar práticas que reduzem o lock-in no dia a dia: infraestrutura como código com ferramentas multiplataforma, contêineres para aplicações sempre que fizer sentido e uso consciente de serviços exclusivos, escolhidos quando o benefício compensa a dependência, e não por conveniência.

Trocar de provedor com segurança: como a Duk ajuda

Planejar a saída de um provedor de nuvem exige visão técnica e contratual ao mesmo tempo, e a maioria das empresas não tem tempo para isso até o problema aparecer. A Duk Informática & Cloud atua há mais de 18 anos como parceira de TI de mais de 550 empresas e acompanha de perto migrações entre ambientes on-premises, nuvem pública e nuvem privada.

Com data center próprio em Alphaville e experiência como Microsoft Gold Partner, a Duk ajuda a mapear dependências, revisar contratos com foco em portabilidade, estruturar backups restauráveis fora do provedor principal e executar migrações planejadas, com os sistemas em paralelo e sem interromper a operação. O objetivo é que sua empresa escolha o provedor pela qualidade do serviço, e não pela dificuldade de sair dele.

Se o seu ambiente está concentrado num único provedor e você não sabe quanto tempo levaria para trocá-lo, esse é o momento de descobrir, com calma e antes da próxima renovação de contrato. Converse com a equipe da Duk e comece seu plano de saída com um diagnóstico do ambiente atual.