Resumen

  • Trasladar un proyecto Google Cloud cambia su organización superior, pero mantiene la cuenta de facturación original.
  • Los pedidos activos comprados directamente en Cloud Marketplace requieren el consentimiento del cliente y del proveedor para cambiar de cuenta; el trámite puede durar una semana o más.
  • Comprar un producto del mismo proveedor con la cuenta de destino durante el trámite vuelve inviable la transferencia. La coordinación de compras forma parte de la entrega.

La independencia empresarial tiene una versión muy cómoda: cambiar el nombre en el organigrama y dejar la tarjeta de pago de la casa anterior. Google Cloud permite el equivalente operativo. Un proyecto pasa a otra organización y conserva la cuenta que paga sus servicios. La mudanza administrativa puede estar terminada mientras la separación económica sigue en obras.

No hace falta imaginar una avería para encontrar el problema. La documentación de migración lo describe como comportamiento normal. Cambian los metadatos del recurso superior del proyecto; permanecen su identificador, su número, los datos, los recursos y los roles IAM concedidos directamente sobre él. También permanece la cuenta de facturación. Las cuentas Cloud Billing pueden financiar proyectos de distintas organizaciones.

Para quien vende una división, eso plantea una pregunta concreta: qué se ha entregado realmente cuando el proyecto aparece bajo el comprador. La respuesta administrativa es clara. La financiera requiere otra decisión, y la del software comprado puede depender de una tercera empresa.

El consentimiento que no cabe en una orden de migración

El detalle más incómodo lo pone Cloud Marketplace. Su procedimiento de transferencia de pedidos activos, aplicable a productos comprados directamente allí, comienza con una petición del cliente al proveedor independiente de software. El solicitante necesita el rol Billing Account Administrator. Si el proveedor acepta, solicita el cambio a Google. Google procesa la petición y envía los correos de aprobación; todas las partes implicadas deben contestar afirmativamente antes de completar la transferencia y recibir su confirmación.

Google advierte de que puede tardar una semana o más. La semana no es un plazo máximo garantizado. Tampoco todo pedido será transferible en cualquier circunstancia. Se trata de una cadena de consentimientos, con sus propias condiciones, que no se acelera otorgando al administrador del proyecto más permisos.

Durante ese proceso hay una restricción especialmente relevante para compras: adquirir un producto del mismo proveedor desde la cuenta de destino vuelve inviable la transferencia. La regla abarca al proveedor, no solo al producto que ya se está trasladando.

Es fácil ver el choque de incentivos sin inventar una víctima. El equipo que prepara la nueva empresa quiere disponer de sus propias compras cuanto antes. El que transfiere el negocio quiere conservar las compras ya realizadas. Si actúan sin coordinarse, la diligencia del primero puede cerrar la vía del segundo. La factura nueva sería una prueba de actividad; también podría ser el obstáculo que nadie había encargado revisar.

La guía de facturación de Marketplace exige que la cuenta de destino haya comprado los recursos necesarios para el proyecto y contempla avisos en la consola cuando faltan. La guía específica de facturación de proyectos pide transferir antes las compras asociadas. Como cada proyecto solo puede estar vinculado a una cuenta de facturación a la vez, el orden de las operaciones tiene consecuencias prácticas.

Quien mueve el proyecto no necesariamente acepta la factura

Las autorizaciones también están repartidas. La guía de roles para la migración distingue los permisos para mover el proyecto de los necesarios para cambiar su facturación. Para este segundo trabajo incluye roles como Billing Account User en la cuenta de destino y Project Billing Manager en el proyecto. La documentación especializada detalla además los permisos para consultar, desvincular y establecer el nuevo vínculo. El permiso de traslado no da por sí mismo autoridad para cargar gastos a otra cuenta.

En el proyecto, los derechos heredados de la organización anterior se pierden y las políticas de la nueva se aplican. Los roles asignados directamente permanecen. Que los datos y los recursos conserven su identidad no resuelve, por sí solo, las dependencias de acceso de cada aplicación. Hay que distinguir lo que sigue concedido de lo que dependía del antiguo nivel superior.

Mientras tanto, la cuenta pagadora conserva una función operativa. Según la guía para modificar la facturación, debe estar activa y en buen estado para que el proyecto tenga habilitada la facturación. Una cuenta cerrada o suspendida impide utilizar los servicios habilitados, incluso aquellos que cumplen las condiciones de uso gratuito.

El antiguo pagador puede seguir siendo necesario para mantener las condiciones de funcionamiento. Pagar no le otorga automáticamente control IAM del proyecto. Precisamente ahí está la separación interesante: la autoridad administrativa puede haber cambiado de sitio sin que haya cambiado la fuente que sostiene el servicio.

La salida de uno cambia el presupuesto de los que se quedan

Al cambiar finalmente la cuenta, los gastos incurridos antes se facturan a la anterior, incluidos los todavía no comunicados. Según el servicio, la comunicación puede retrasarse hasta dos días. Son consumos antiguos que llegan tarde a la contabilidad, no dos días de consumo nuevo regalados al comprador.

Quedan también costes de cuenta que no se asignan a un proyecto, como Support. La relación de proyectos trasladados no basta para cerrar la reconciliación de gastos.

Otro efecto alcanza a los proyectos que no se mueven. Los descuentos de los compromisos de Compute Engine basados en recursos que pertenecen al proyecto cuya facturación cambia pasan a aplicarse en la cuenta de destino. Los proyectos de la cuenta antigua dejan de beneficiarse de esos compromisos. El alcance del reparto en la nueva cuenta depende de su configuración. Una unidad que permanece en la empresa puede perder parte de la ventaja presupuestaria que compartía con la que sale.

La documentación aporta un segundo ejemplo preciso: si la cuenta de destino carece de la suscripción Cloud Armor Enterprise Annual, el proyecto que participaba en ese plan vuelve a Standard. La continuidad de las máquinas no demuestra continuidad de las condiciones del producto.

A veces conviene seguir pagando desde la casa anterior

Google abordó esta posibilidad en su artículo del 2 de mayo de 2023 sobre separación de organizaciones. Con las empresas hipotéticas RemainCo y NewCo, analiza mantener la financiación en la cuenta original para cumplir un contrato de compromiso existente. También explica que los créditos promocionales y paquetes de soporte no se extienden automáticamente a la nueva entidad o cuenta.

Por tanto, conservar el vínculo financiero puede ser una decisión negociada para aprovechar obligaciones ya asumidas. Lo que diferencia una transición organizada de una dependencia olvidada es el acuerdo entre las partes: quién paga, cómo se reparten los costes y qué condición permite terminar el arreglo.

Para evaluar una entrega concreta faltan sus permisos IAM, vínculos de facturación, compras y aprobaciones; las fuentes públicas describen las reglas, no el expediente privado de un cliente.

La consecuencia para una venta de negocio es bastante terrenal. Quien recibe el proyecto debe aceptar también las relaciones necesarias para usarlo. El administrador puede certificar el cambio de organización. Finanzas tiene que aceptar el gasto. El proveedor debe aprobar lo que exige su procedimiento. El acto de entrega se vuelve creíble cuando esas respuestas coinciden, no cuando alguien consigue una captura de pantalla especialmente convincente.