Resumo

  • Um projeto do Google Cloud pode passar a outra organização mantendo a conta de faturamento original, enquanto mudam as permissões herdadas.
  • A transferência de pedidos ativos comprados diretamente no Cloud Marketplace exige aprovação do cliente e do fornecedor e pode levar uma semana ou mais.
  • Comprar um produto do mesmo fornecedor na conta de destino durante o processo torna a transferência inviável. Compras e migração precisam combinar a ordem dos atos.

O projeto já foi embora. O desconto que ajudava os projetos que ficaram também pode ir. A fatura, porém, tem seu próprio roteiro. Separar uma operação no Google Cloud exige mais do que conferir se todos os projetos aparecem debaixo do nome certo no console.

A regra básica é simples e pouco compatível com cerimônias de “missão cumprida”. Ao mover um projeto para outra organização, sua conta de faturamento continua sendo a original. A empresa que o entregou pode continuar financiando os serviços, mesmo depois de o projeto ganhar um novo lugar na estrutura administrativa.

O guia de migração de projetos explica o mecanismo: muda o metadado que identifica o recurso superior. Ficam o ID, o número, os dados, os recursos e as funções IAM concedidas diretamente ao projeto. Contas Cloud Billing podem pagar por projetos de organizações diferentes. A separação entre administração e financiamento é uma possibilidade do produto, não uma exceção descoberta após uma falha.

O orçamento de quem fica entra na história

Quando a conta de faturamento do projeto é alterada, as vantagens comerciais precisam ser examinadas uma a uma. A documentação de mudança de faturamento traz um exemplo relevante para quem está do lado que vende a operação: os compromissos do Compute Engine baseados em recursos, pertencentes ao projeto transferido, passam a gerar descontos na conta de destino. Os projetos da conta anterior deixam de receber o benefício desses compromissos. O compartilhamento na nova conta depende da configuração dela.

Uma unidade que permanece na empresa, portanto, pode sentir no orçamento a saída de um compromisso associado a outra unidade. A equipe dessa operação pode não ter movido um único recurso. Ainda assim, a composição dos descontos mudou. É o tipo de efeito que escapa de um plano de entrega organizado exclusivamente por projetos que saem.

Há outras condições ligadas à conta. Se o destino não tiver a assinatura Cloud Armor Enterprise Annual, um projeto que participava desse plano retorna ao Standard. A máquina conservar sua identidade não preserva automaticamente o nível comercial de todos os serviços ao redor dela.

Também é preciso separar despesa antiga de consumo novo. Gastos incorridos antes da troca de conta seguem para a conta anterior, inclusive quando ainda não foram informados. Conforme o serviço, a informação pode demorar até dois dias. São consumos anteriores chegando atrasados, não dois dias adicionais de uso novo pagos pelo antigo responsável. E existem custos de conta, como Support, que não são atribuídos a um projeto específico.

Para finanças, a data da transferência administrativa é uma informação entre várias. Usá-la como linha única de corte apaga tanto obrigações que ficaram quanto benefícios que foram embora.

A troca de organização não troca quem sustenta o serviço

Permissões também têm origem. Os acessos IAM herdados da organização anterior desaparecem na mudança, e as políticas da nova organização passam a valer. As funções concedidas diretamente ao projeto permanecem. Assim, recursos preservados precisam ser analisados à luz das novas regras de acesso e das dependências das aplicações.

O guia de atribuição de funções para migrar separa os poderes necessários para mover o projeto daqueles exigidos para mudar a conta pagadora. Entre os papéis citados para a segunda tarefa estão Billing Account User na conta de destino e Project Billing Manager no projeto. A documentação específica de faturamento detalha ainda as permissões para consultar, desvincular e vincular contas. Poder reorganizar o projeto não dá automaticamente poder para comprometer o dinheiro da conta receptora.

A conta de faturamento vinculada precisa estar ativa e em situação regular para habilitar o faturamento do projeto. Fechamento ou suspensão impede o uso dos serviços habilitados, inclusive dos que se enquadram em uso gratuito. A dependência de financiamento pode, assim, permanecer na empresa anterior enquanto a administração passa à seguinte.

Quem paga não ganha, só por pagar, os acessos IAM do projeto. A questão é justamente a coexistência de poderes diferentes: alguém administra o recurso, outra parte mantém uma condição necessária para seu funcionamento.

A compra bem-intencionada que atrapalha a entrega

O software adquirido no Cloud Marketplace exige mais uma combinação. A orientação de faturamento dos projetos manda transferir antes as compras associadas. O guia de faturamento do Marketplace pede que a conta de destino tenha adquirido os recursos necessários; o console avisa quando faltam compras. Um projeto só pode estar vinculado a uma conta de faturamento por vez.

Para produtos comprados diretamente no Marketplace, a mudança de conta de pedidos ativos depende de cliente, fornecedor independente de software e Google. O cliente precisa do papel Billing Account Administrator e procura o fornecedor. Se concordar, este solicita a transferência ao Google. Depois do processamento, o Google envia os e-mails de aprovação. Todas as partes envolvidas precisam responder aprovando para a transferência ser concluída e comunicada.

A indicação de duração é de uma semana ou mais. Não existe, nessa formulação, promessa de que tudo estará pronto no sétimo dia. A transferência também está sujeita à viabilidade do caso.

O detalhe capaz de desmontar um cronograma está na conduta da conta receptora: durante a transferência, comprar um produto do mesmo fornecedor torna o processo inviável. A restrição alcança o fornecedor, não apenas a repetição do mesmo produto.

O departamento de compras pode estar tentando fazer exatamente o que a separação exige: equipar a nova empresa para funcionar por conta própria. Mas, se compra enquanto outra equipe transfere o pedido existente, altera a viabilidade da operação. A pressa de um departamento transforma a tarefa do outro. Mais acesso de administrador não desfaz essa incompatibilidade; é preciso coordenar a compra com a transferência.

Continuar junto pode ser uma decisão econômica

O próprio Google discutiu a alternativa num texto de 2 de maio de 2023 sobre empresas que se separam. O exemplo usa RemainCo e NewCo, empresas hipotéticas, para examinar a manutenção do financiamento pela conta original quando há um contrato de compromisso a cumprir. Créditos promocionais e pacotes de suporte também não se estendem automaticamente à nova empresa ou conta.

Manter o antigo pagador pode, portanto, ser uma ponte negociada. A diferença entre ponte e pendência esquecida está no acordo que a sustenta: responsável pelo gasto, forma de acerto e condição de encerramento. O console pode mostrar a mesma associação em ambos os casos. O que muda é a capacidade das partes de explicar e cumprir o combinado.

Para avaliar a entrega de uma empresa específica, seriam necessários seus vínculos de faturamento, permissões IAM, compras e aprovações. As regras públicas permitem identificar os pontos de decisão; não revelam esses registros privados.

A entrega econômica só fica clara quando os responsáveis pelo projeto, pelo financiamento e pelos pedidos concordam sobre o que foi recebido e o que continua compartilhado. A nova casa pode ter placa e chaves. Quem paga sua operação — e quem autoriza o uso do software — ainda precisa participar da conversa.